What do they receive?
Which log sources, endpoints, identities, and networks are actually in scope, and which parts of the estate send them nothing.
Research program
Vendor and supply-chain resilience
Other organisations hold much of a company's security in their hands: managed providers, cloud platforms, software vendors, clinical systems, contractors, open-source maintainers, and AI providers. This program asks what those parties actually do when trouble starts.
When something goes wrong at three in the morning, what does the vendor do, and when was that last tested?
Replacing the sentence that ends the conversation
Claim: observation
The phrase our vendor handles that often ends the inquiry too soon. The vendor handles a defined set of events, sees a defined set of data, and can take only the actions the contract and customer permit.
The questions that replace it
Claim: recommendation
These questions are deliberately operational. A questionnaire response cannot answer most of them.
What do they watch for?
The specific detections in place, rather than a category name like twenty-four seven monitoring.
Who is called?
Named roles on both sides, with an out-of-hours path that has been dialled at least once.
What may they do?
Whether they can isolate a host, disable an account, or block traffic without waiting, and what requires your approval.
What is the response commitment?
Contracted times, and the observed times from the last several events.
What if the vendor is compromised?
The most under-examined question. Their access to your estate is a blast radius you own.
What a vendor certificate leaves out
Claim: inference
A vendor's certification report describes their control environment at a point in time against their own scope definition. It is evidence about their program, not about your configuration of their product, which is where a large share of incidents originate.
Shared-responsibility boundaries therefore need direct testing. Published incident reports support that view, but the claim should keep being checked against new cases.
What would prove us wrong?
Claim: unknown
The program assumes tested vendor workflows predict outcomes better than vendor attestations.
- Incident data showing that vendor certification status correlates with client outcomes as strongly as rehearsed escalation does.
- Evidence that joint exercises are so costly or disruptive that they are only feasible for the largest clients, making the recommendation impractical rather than wrong.
- Findings that most third-party loss originates in software supply chain compromise, where escalation testing changes little.
Experiments for this program
- Out-of-hours vendor escalation drill What does the provider actually do when called at three in the morning?
Patterns and anti-patterns
- Rehearse the out-of-hours call (pattern)
- Our vendor handles that (anti-pattern)
Evidence for this program
- NIST SP 800-161 revision 1, supply chain risk management Third-party practice guidance. The gap this area studies is between its practices and the tested escalation path.
- CISA Secure by Design Places responsibility for safe defaults with the supplier, which is the vendor-side form of this area's design argument.
- Verizon Data Breach Investigations Report Annual incident pattern data. Useful for base rates, with the usual caution that the sample is not a population.
Research notes
Escalation paths decay quietly
Contacts leave, numbers change, portals replace phone trees, and contracts renew with different terms. An untested escalation path is an assumption with a date on it.
What happens if the vendor is the one compromised?
The note recommends assessing what a compromised vendor's own access could reach, not only whether the vendor protects your data, and how you would sever that access without the vendor's cooperation. Third-party risk programs assess whether a vendor protects your data. They rarely assess the blast radius of the vendor's own access to your systems.