Third-party risk management is one of the better-funded and less effective areas of most security programs. Organizations send questionnaires, collect responses, assign scores, and remain almost entirely exposed to the thing they were trying to manage.
The problem is not effort. It is that the standard method measures something other than risk.
What Questionnaires Actually Tell You
A security questionnaire captures what a vendor says about their controls, at the moment they answered, completed by someone whose commercial interest lies in the answers being acceptable.
That is not worthless. It establishes a baseline, creates a contractual record, and a vendor unable to answer coherently has told you something. It is evidence of diligence, and in a regulatory conversation that has value.
What it does not do is measure your exposure. Two facts explain why.
First, nothing is verified. A vendor asserting encryption at rest and multi-factor authentication may well have both. You have no idea, and neither does the person filing the response.
Second, and more fundamentally, the questionnaire asks about the vendor's environment when your exposure is determined by yours. What matters is not how good their controls are but what they can reach inside your systems if those controls fail.
Reachability Is the Better Question
Ask instead: if this vendor were compromised tomorrow, what would the attacker have?
That question is answered by examining your own architecture, which means you can answer it without the vendor's cooperation and without trusting their self-assessment.
Work through it for each significant third party:
- What access do they hold? Named accounts, service accounts, API credentials, VPN access, an agent installed on your endpoints.
- What privilege does that access carry? An MSP with domain administrator is a different proposition from a marketing tool with read access to a mailing list.
- What data do they hold on their side? A compromise of their environment exposes your data in it regardless of your controls.
- What could they reach by moving laterally? Access to one system is rarely access to one system.
- What is the operational dependency? If they went offline for a week, what stops.
The output is a ranked list of vendors by consequence rather than by score, and it usually reorders the list substantially. The vendors that come out highest are frequently not the ones with the largest contracts.
Managed Service Providers Are a Category of Their Own
If you use an MSP, their security is functionally part of yours.
An MSP typically holds privileged access across the entire estate, often through remote management tooling that can execute code on every endpoint. That is a more powerful position than most internal administrators hold, and attackers understand the leverage: compromising one MSP yields access to every client it serves.
The controls that matter here are specific. Their access should be through named accounts rather than shared ones, protected by phishing-resistant multi-factor authentication, granted just-in-time rather than standing, logged in your environment rather than only in theirs, and scoped to what they actually administer. The remote management agent deserves particular attention, because it is the single most powerful thing in most environments.
We have written more on this in offensive security for MSPs.
Software Supply Chain
The other route in is through code rather than people: a compromised update from a legitimate vendor, or a malicious dependency in a package you build with.
For software you consume, the practical controls are knowing what you run, maintaining a software bill of materials, and being able to answer quickly when a vendor discloses a compromise. The organizations that handled recent supply chain incidents well were the ones who could establish within hours whether they ran the affected version.
For software you build, dependency scanning that covers transitive dependencies, pinned versions, and treating the build pipeline as production infrastructure. Deployment credentials typically carry more privilege than any human account and are protected considerably less.
Contracts and Notification
The contractual term that matters most is breach notification, because your own obligations may depend on it.
If a vendor incident is material to you, SEC disclosure timelines may run. If protected health information is involved, HIPAA obligations apply. State breach notification laws have their own clocks. A vendor who notifies you three weeks after they knew has consumed time you did not have.
Specify a timeline in days, require cooperation during investigation, require notice of subcontractor incidents, and require that they tell you what data of yours was involved rather than only that an incident occurred.
Planning for Someone Else's Incident
Most incident response plans assume the incident is yours. A meaningful proportion will not be.
Rehearse it: a critical vendor announces a compromise, they cannot yet say whether your data was affected, and your customers are asking. Who decides what you tell them? How quickly can you determine what that vendor could access? Can you revoke their access immediately without stopping operations?
That last question is worth testing literally. Organizations frequently discover that cutting off a vendor's access is either impossible without an outage or takes far longer than the situation allows.
To assess what your third parties could actually reach, get in touch.
Frequently asked questions
Why are security questionnaires so limited?
They measure self-reported control existence at a point in time, answered by someone whose commercial interest is in passing. They do not verify anything, they go stale immediately, and they say nothing about the question that determines your exposure, which is what that vendor could reach in your environment if they were compromised. They are evidence of diligence rather than a measure of risk.
What is reachability assessment?
Working out, from your own architecture, what each third party can actually access: which systems, which data, what privilege, and what they could reach from there by moving laterally. It is answered by examining your environment rather than by asking the vendor. It is more useful than any score because it tells you the size of the problem you would have.
What is fourth-party risk?
The risk from your vendors' vendors. Your SaaS provider runs on a cloud platform, uses a payment processor and depends on open-source components, and an incident in any of those affects you through them. Complete visibility is unrealistic, but knowing your critical vendors' critical dependencies identifies concentration risk you would otherwise miss.
What should be in a vendor contract?
Prompt breach notification with a defined timeline, the right to audit or to receive independent assessment evidence, defined security requirements proportionate to the access granted, obligations on subcontractors, data handling and return or destruction terms, and clear incident cooperation duties. Notification timelines matter most, because your own regulatory clocks may depend on them.
How do managed service providers change the calculation?
Substantially, because an MSP typically holds privileged access across your entire estate, which makes them a higher-consequence dependency than almost any other vendor. Attackers target MSPs specifically for this leverage. If you use one, their security is functionally part of yours, and the access they hold deserves the same scrutiny as your own administrator accounts.