Scarlet Risk · Learn · Vendor Risk Basics
Third-Party Risk 101: What Your Vendors Can Expose You To
Some of the most damaging breaches in recent years didn't start with the company that got breached — they started with one of that company's vendors. A payroll processor, a marketing tool, an IT contractor with too much access. The company did everything right on their own systems, and got hurt anyway.
That's vendor risk, and most small businesses have far more of it than they realize.
Why this matters even if you're small
Every tool you connect to your business — accounting software, a CRM, an email marketing platform, a payment processor — is a vendor with some level of access to your data or systems. If any one of them gets breached, or handles your data carelessly, you inherit the consequences even though you didn't cause the problem. Your customers and regulators generally don't care whose fault it was; they care that their data was exposed.
Step 1: Know who your vendors actually are
This sounds obvious, but most businesses have never actually written down every vendor with access to sensitive data or systems. Start a simple list: the tool or company, what data or system it touches, and who on your team owns that relationship. You'll likely find more than you expected.
Step 2: Not all vendors carry the same risk
A vendor who only sees your public marketing calendar is a very different risk than one who has access to customer financial records or employee health data. Sort your vendor list roughly into tiers based on what they can actually touch. This lets you focus your limited time on the vendors that matter most, instead of treating every SaaS subscription equally.
Step 3: Ask before you sign
For anything in your higher-risk tier, a few basic questions before you commit go a long way: Do they have a security certification (SOC 2 is common)? Do they encrypt data at rest and in transit? What's their process if they have a breach, and how would they notify you? Most legitimate vendors have straightforward answers to these questions — and if a vendor can't or won't answer, that itself is useful information.
Step 4: Revisit it periodically, not just once
A vendor's security posture isn't static. Companies get acquired, change practices, or have incidents. A yearly check-in on your higher-risk vendors — has anything changed, are they still who you thought they were — catches problems before they catch you.
Step 5: Have a plan for when (not if) a vendor has an incident
At some point, one of your vendors will have a security incident. It's less a question of if than when. What matters is whether you find out quickly, understand what data of yours was involved, and have a plan for what to communicate to your own customers if needed.
The bottom line
Vendor risk management doesn't need to be a formal program with a dedicated headcount to be effective. Even a simple list, sorted by risk tier, with a habit of asking a few good questions before signing anything new, closes most of the gap that trips up small businesses.
Work through one provider relationship
Choose a provider that supports an important workflow. Record the information it receives, access it has, business owner, and the effect of an outage. Check whether the relationship includes subcontractors or integrations that copy information elsewhere. This establishes the context for the questions you ask.
Request proportionate evidence: relevant assurance reports, security answers, incident-notification arrangements, recovery responsibilities, and data-return terms. A SOC 2 report is an attestation report, not a certification. Confirm that its scope covers the service you buy instead of treating the provider’s name as sufficient assurance.
Document approval and outstanding conditions
Summarize the evidence reviewed and any unanswered questions. Record whether the relationship is approved, approved with conditions, awaiting evidence, or subject to further review. Assign an owner to each condition and explain any accepted risk so a missing answer does not disappear into a general approval label.
Consider how you would respond to a provider incident: establish a contact, identify the information and systems involved, and determine who can adjust access or activate an alternative. Your notification duties depend on the circumstances and applicable obligations; the provider’s statement alone may not answer them.
Revisit when the relationship changes
Review additional access, a new service, acquisition, renewal, or a credible incident notice as changes to the relationship rather than assuming the original approval remains sufficient. A review frequency should reflect exposure and change, not a universal annual rule.
For exit, verify data return, access removal, and required retention arrangements. A public breach match is not confirmation that your account was affected, and a clean external report is not proof of complete security. Keep source dates and evidence limits with each assessment.
Put this into practice with Scarlet Risk.
AI-powered risk intelligence that shows you exactly where you're exposed — and what to do about it.
Get started with Scarlet Risk