I got a call from a client after their MSP went dark.
Not a courtesy call. A crisis call. The service had been breached. Everything dependent on it had stopped. They were buying laptops, actual laptops, from a shop, just to keep people working.
The breach lasted over a month.
When I arrived, the first thing I asked for was the contract. RTO within 24 hours. RPO guarantees. Standard business continuity language, professionally written, legally reviewed, commercially negotiated.
None of it had worked. Not because the contract was wrong. Because nobody had ever tested whether the promises in it reflected what would actually happen under pressure.
The due diligence hadn’t been lazy. It had been performative. They’d collected the certificates, read the audit reports, had the reassuring conversations. What they hadn’t done was ask the vendor to show them
— in operational terms, with the actual team, against the actual service — what recovery looked like in practice.
So when it happened, they found out the hard way.
That’s not unusual. Third-party breaches now account for 35.5% of all data breaches, up from 29% the year before.¹ In 2024, nearly a third of all breaches involved a third-party vendor, twice the rate of the previous year.
You’re not just buying a service. You’re inheriting every risk decision that vendor makes in boardrooms you’ll never enter.
The Gap Between Promise and Reality
When I arrived at that client, the gap was obvious within the first hour.
The MSP’s paperwork promised standard RTO and RPO times. Things would be up within a day. The client had negotiated those terms. Legal had reviewed them. The renewal had been signed.
They were useless.
Not because the contract was wrong. Because the client had built their entire recovery model on the assumption that the MSP would be more resilient than it actually was. When I looked at what business continuity actually required, who rebuilds end-user capability, how quickly, from where, at whose cost, none of it had been tested against the service they were actually consuming.
The original due diligence had fallen for the vendor presentation. Polished policies. Good audit outcomes. Confident answers. All the right language. Nobody had asked for evidence that any of it worked in reality. Nobody had verified whether the BC/DR processes were relevant to the specific service being consumed, not just the vendor’s generic control set.
tbh that’s the pattern I see most often. The due diligence produces a file of documents that feel like assurance. Certificates, questionnaire responses, audit summaries. Each one looks like evidence. Collectively they test almost nothing about how the service actually behaves under pressure.
Traditional point-in-time assessments offer a snapshot of a vendor’s risk profile at a single moment.² They don’t capture what changes in the months between reviews. A lot can change in a year. Leadership shifts. Cost pressures. Platform migrations. Staffing decisions. The certificate stays current. The resilience model quietly moves.
Most organisations review supply chain partners annually. Annual checks are not enough.
The Question That Cuts Through
After that engagement I started using a single question with every vendor conversation. It’s the one that separates operational reality from policy performance.
Walk me through the last time this specific service failed, and how you actually recovered it, step by step.
Then I stay quiet.
What I’m listening for isn’t the textbook answer. It’s whether they can describe real operational behaviour. Timelines. Decisions made under pressure. Trade-offs. Customer impact. What didn’t go to plan and why.
If they default to “we meet our RTO/RPO commitments” or point at a policy document, the conversation is over in the useful sense. They’re still in theatre mode. The actual recovery capability — whether it exists, who owns it, what it depends on — is still unknown.
If they do have a genuine answer, I follow it immediately with a second question.
If that same scenario happened tomorrow at twice the scale, what breaks first?
That’s usually where the truth surfaces. A vendor who has genuinely exercised recovery can answer it. One who has been pointing at documentation can’t.
The point isn’t to catch vendors out. It’s to understand whether the resilience you think you’re buying actually exists in a form that matches your dependency on it. A vendor can have perfectly adequate BC/DR for their business model and still be completely misaligned to what your operations actually need from them.
That misalignment is what my client discovered. Not that the MSP was incompetent. That the recovery model they’d been sold didn’t map to the operational dependency that had quietly built up over three years of renewal cycles.
Show me the evidence. Not the policy. Not the certificate. The evidence.
When Risk Tolerance Shifts Without Warning
Businesses are not static. That’s one of the biggest blind spots in how most organisations manage third-party risk.
I’ve seen vendors present extremely well at the point of onboarding. Polished policies. Good audit outcomes. Confident answers in the due diligence meeting. Twelve months later something has changed internally, and the client finds out through a service failure rather than a conversation.
The trigger events are recognisable once you know what to look for. A private equity transaction. A cost reduction programme. Rapid growth. Offshoring. A platform migration. A key operations leader leaves.
What changes is rarely the policy set. Policies stay in place long after the decisions behind them have shifted. What changes is the decision-making under pressure. Longer recovery windows get accepted. Staffing gets thinner. Shared dependencies multiply. Testing gets deferred. Technical debt accumulates. On paper, nothing dramatic has happened. In practice, the resilience model has moved completely.
The Federal Reserve’s own third-party risk guidance asks specifically whether there have been changes in the third party’s strategy, corporate culture, leadership, or risk exposure.³ These aren’t theoretical concerns. They’re the exact trigger events where inherited risk becomes visible, usually only after the incident.
That’s why I say third-party risk is not a procurement exercise. It’s a live dependency on somebody else’s leadership choices, commercial pressures, and operating culture. Those move faster than any certificate renewal cycle will reveal.
The earliest signal is almost never technical. It’s behavioural.
A provider that used to speak clearly about recovery dependencies, testing cadence, key people and decision paths starts retreating into safer language. Globally consistent process. Standard control environment. Aligned to policy. That loss of operational specificity is often the first indication that something underneath has shifted.
After that, I look for a small number of early indicators. Governance gets thinner, the people who used to own resilience discussions are no longer in the room, or they can no longer make decisions without escalating. Exceptions start getting normalised, missed test dates, delayed remediation, more use of waivers, each one sounding reasonable in isolation.
The language shifts from resilience to efficiency, as soon as a vendor starts talking heavily about simplification, consolidation, or operating model optimisation, I want to know what protection has quietly been removed alongside it. And experienced operators disappear, when the people with institutional memory leave, risk tolerance often changes before the documentation does.
You rarely detect the shift first in the control set. You detect it in the quality of the conversation and the consistency of operational follow-through.
What Relationship Ownership Actually Looks Like
Most organisations know annual reviews aren’t enough. The problem is that genuine third-party risk management cuts across procurement, security, operations, legal, and the business. Once you try to do it properly, it exposes ambiguity over who is actually accountable for seeing the whole picture.
So what happens instead? They fall back to process. A questionnaire. A review meeting. A risk rating. A date in the diary. Administratively neat. Politically safer than giving someone the mandate to challenge whether a strategically important vendor relationship is drifting out of tolerance.
It’s rarely a failure of awareness. It’s a failure of operating model and leadership resolve. People accept the theory of continuous third-party risk management but don’t redesign incentives, authority, or capacity around it. The old compliance mechanism survives even though everyone in the room knows it misses the point.
The practical answer isn’t to monitor every vendor the same way. You tier by business dependency, then monitor for change signals rather than control evidence alone.
The small number of vendors that can materially disrupt operations, customer service, or regulatory obligations get a very different level of attention from the long tail. For those critical vendors, assign named relationship ownership across procurement, technology, risk, and the business. Then define a handful of trigger events that force a live review, leadership change, M&A activity, major platform transformation, repeated service issues, missed testing, weaker transparency, or a noticeable change in the quality of operational dialogue.
The key point is that last one. Don’t ask for more paperwork. Ask whether the story has changed.
An annual reviewer checks whether the process was completed. An effective relationship owner notices when the risk story has changed and brings that back into the business before it becomes an incident. They join the dots that different functions see separately. Procurement sees contractual change. Operations sees service deterioration. Security sees delayed remediation. The business sees reduced responsiveness. The named owner turns those weak signals into a single view of risk.
When experienced operators leave a vendor, I frame it directly for leadership. This is not a people change at the supplier. It’s a change in where operational judgement sits, and that can change your risk position overnight.
Experienced operators carry unwritten knowledge. Where the service is fragile. Which workaround actually holds under pressure. Which dependency fails noisily versus silently. Who needs to be called. When the documented process isn’t enough. When those people leave, the service may look identical from the outside while its real resilience has already dropped.
The mechanism I use to test it isn’t a document request. It’s a targeted operational walkthrough tied to the service we actually buy. I ask the vendor to take us through a credible failure scenario for that specific service, with the current team, current dependencies, current escalation paths. Not the policy version. The real version. Who leads, who decides, what gets restored first, what they depend on, how they communicate, where they expect friction.
For more critical suppliers I want to see that tested, not just described. A joint tabletop. A service recovery drill. Evidence from a recent live recovery event.
Half of all companies now work with more than a hundred vendors, up from 38% in 2023.⁴ For each direct third-party relationship, organisations typically carry indirect exposure to nearly fourteen times more fourth and fifth-party dependencies. You cannot monitor everyone at the same depth. You have to choose where to look, and you have to make that choice deliberately rather than defaulting to whoever filled in the questionnaire fastest.
The First Conversation
Looking back at that client, the one buying laptops while their MSP was dark, what would have been different if this model had been in place before the breach?
They would have understood, before anything went wrong, that this wasn’t just an outsourced IT service. It was a hard operational dependency with hidden assumptions built into it over three renewal cycles. Instead of taking comfort from the contract language, they would have been asking the harder question much earlier.
If this MSP was compromised, who actually rebuilds end-user capability, how quickly, from where, and at whose cost?
That question wasn’t in the due diligence. It wasn’t in the renewal conversation. It wasn’t anywhere, until the answer became a month of operational disruption and a car boot full of laptops.
If the model had been in place, they would have identified that gap, challenged the recovery assumptions, exercised the scenario, and either tightened the service, added contingency, or accepted the risk explicitly with eyes open. That’s a different position from discovering it under pressure.
The data makes the cost of that discovery concrete. Third-party breaches cost roughly 40% more to remediate than those originating inside an organisation’s own systems.⁵ The additional complexity of managing an incident spanning multiple entities, legal jurisdictions, and data environments adds a premium to everything — response time, legal exposure, customer communication, recovery.
When your vendor has a bad day, you don’t just inherit their incident. You inherit the cost of cleaning up someone else’s mess across boundaries you don’t control.
Most boards I work with understand this in principle. The gap is between understanding it and acting on it before something forces the conversation.
The first move isn’t complicated. Pull your critical vendor list — the ones whose failure would materially affect operations, customer service, or regulatory obligations. For each one, ask two questions. When did we last verify that their recovery capability matches our actual dependency on them, not their generic control set? And if their service failed tomorrow, do we genuinely know what happens next?
If either answer takes more than a few minutes to produce, that’s the gap.
You can define your own risk appetite all you want. The moment you sign the contract, you’ve inherited theirs. The question is whether you understood what you were actually buying.
Which vendor in your current estate would you be least comfortable answering that second question about?
Acceptable Risk (Documented)
References
1. Recorded Future. (2024). Third-Party Risk Statistics. https://www.recordedfuture.com/blog/third-party-risk-statistics
2. TechTarget. Third-party risk management (TPRM). https://www.techtarget.com/searchcio/definition/third-party-risk-management-TPRM
3. Federal Reserve. (2024). Third-Party Risk Management. https://www.federalreserve.gov/publications/2024-may-third-party-risk-management.htm
4. Recorded Future. (2024). Third-Party Risk Statistics. https://www.recordedfuture.com/blog/third-party-risk-statistics
5. Recorded Future. (2024). Third-Party Risk Statistics. https://www.recordedfuture.com/blog/third-party-risk-statistics