Cyber Resiliency Board Briefing 8: The Third-Party Recovery Problem, Why Your Recovery Depends on Organisations Outside Your Control
Executive Summary
Modern organisations do not operate or recover in isolation. Critical business services increasingly depend on cloud providers, Software-as-a-Service platforms, managed service providers, telecommunications companies, payment processors, identity providers, software vendors and other organisations connected into increasingly complex digital ecosystems.
During normal operations these relationships create efficiency, agility and cost savings. During a destructive cyberattack they create recovery dependencies that sit outside your direct control.
In my experience of dealing with hundreds of destructive cyberattacks, most recovery plans implicitly assume that your organisation is the only one recovering. They rarely consider what happens when your cloud identity provider is unavailable, your managed service provider has also been compromised, your cloud platform is experiencing regional disruption, or your key software vendor has hundreds of customers simultaneously requesting emergency support.
But there is another side to the problem that receives even less attention, following a destructive cyberattack, your third parties may deliberately disconnect you. Banks may suspend interfaces. Suppliers may disable integrations. Customers may block network connections. Partners may revoke credentials, certificates or API access. Managed service providers may isolate environments while they determine whether compromise could spread into their infrastructure.
Recovery therefore depends on more than restoring your own technology, it depends on restoring trust between organisations.
The questions the Board should be asking are: “How much of our recovery depends upon other organisations recovering before we can?” and “If we suffer a destructive cyberattack, what level of assurance will our third parties require before they reconnect us to their services?”
The answers to these questions may determine how quickly the organisation can genuinely return to business.
The Third-Party Recovery Illusion
Most organisations maintain inventories of third parties for procurement, security assessments, regulatory compliance and third-party risk management. Far fewer understand which of those organisations become critical-path dependencies during recovery.
A supplier that appears relatively unimportant during normal operations may become indispensable during a cyber crisis. Examples of these include:
Identity providers required before users can authenticate
DNS providers required before applications become reachable
Telecommunications providers restoring connectivity
Cloud platforms required to rebuild infrastructure
Managed service providers operating critical environments
Software vendors required to reactivate licences or rebuild platforms
Certificate authorities required to re-establish trusted communications
Hardware suppliers replacing destroyed or untrusted equipment
Payment providers reconnecting financial services
Backup and recovery vendors supporting large-scale restoration
If any of these organisations are unavailable, compromised or unwilling to reconnect you, your recovery timeline immediately elongates. Your recovery planning therefore should extend far beyond your organisational boundary.
Third-Party Dependency Works in Both Directions
Traditional third-party risk management focused on what happens to us if your suppliers fail, but an equally important aspect is what happens if your suppliers decide that your organisation represents a risk?
Following a destructive cyberattack, third parties have their own security and risk-management obligations. A supplier may reasonably decide that maintaining connectivity to a compromised organisation creates unacceptable exposure. Connections may therefore be suspended deliberately.
This could include:
Network connections
APIs
VPNs
Federated identity relationships
Privileged support access
File transfers
Payment interfaces
Supply-chain integrations
B2B gateways
Cloud interconnections
These actions may be entirely appropriate from the third party's perspective, but can create significant problems for your organisation if you have never considered how the loss of those connections will affect critical business services, or how those connections will subsequently be restored.
Disconnection Is Easy. Reconnection Requires Trust.
I have consistently argued that while business continuity and disaster recovery are largely technical processes focused on restoring systems and data, cyber recovery is an operational business process focused on restoring trust. It requires a shared-responsibility model in which technology, cybersecurity, business, risk and executive leadership work together to make informed, risk-based decisions about recovery.
Third-party risk management is no different. Disconnecting a third-party organisation can take minutes. Reconnecting it may take days or weeks. The third party now faces its own risk decision “Is it safe to trust this organisation again?”
That decision may require evidence that:
The attack has been contained.
The attacker's persistence has been removed.
Compromised identities have been remediated.
Credentials, keys, secrets and certificates have been rotated where necessary.
Affected infrastructure has been rebuilt or validated.
Relevant vulnerabilities have been remediated.
Security controls are operational.
Monitoring has been restored.
Recovered systems have been validated as being in a trusted state.
Different third parties may require different levels of evidence. While some may accept an executive attestation, others may require evidence from an independent Digital Forensics and Incident Response (DFIR) provider. Highly regulated organisations may go further, requiring independent technical assurance from a nominated or mutually agreed third party before allowing reconnection.
The organisation can therefore be technically recovered but still unable to resume business because its ecosystem does not yet trust it.
Recovery Is Also an Assurance Problem
This creates a frequently overlooked component of cyber recovery, recovery assurance. During an incident, technical teams naturally focus on restoring systems but somebody must also determine:
What evidence will third parties require?
How will be preserve that evidence in a manner that maintains its integrity and admissibility?
Who is authorised to provide it?
What can legally and safely be disclosed?
Who approves statements about containment and eradication?
What technical evidence supports those statements?
Which third parties require independent assurance?
Who owns the decision to request reconnection?
How will conflicting assurance requirements be managed?
These questions should not be answered for the first time during a ransomware incident. The required evidence, decision rights and communications paths should be established in advance.
Shared Failure is Shared Delay
Cyber incidents do not always affect organisations individually. Many organisations depend upon the same:
Cloud platforms
SaaS providers
Identity providers
Managed service providers
Security vendors
Telecommunications providers
Technology supply chains
A major vulnerability, supply-chain compromise or nation-state campaign can therefore create hundreds or thousands of simultaneous incidents. When this occurs, vendor recovery capacity can quickly become constrained.
In one particular nation-state incident I was involved in, persistence was suspected of existing within hard disk firmware, prompting the purchase of hundreds of thousands of replacement hard drives. The resulting demand contributed to a worldwide shortage and drove up the price of drives significantly.
In other incidents, the constraints may be less dramatic but equally consequential. Third-party support queues increase. Specialist engineers become unavailable. Professional services become fully allocated. Replacement hardware becomes scarce. Incident-response capacity becomes constrained.
Your Priority One incident may simply become one of hundreds competing for the same finite resources.
At that point, recovery stops being purely a technical challenge. It becomes a capacity and prioritisation problem across the ecosystem.
Your RTO Is Not Their RTO
Organisations frequently define Recovery Time Objectives internally, but an internal RTO cannot compel another organisation to recover or reconnect you within the same timeframe.
Your organisation may require a critical service within four hours. Your provider may have a 24-hour restoration commitment.
A specialist engineer may not be available for two days. A partner's risk function may require evidence before approving reconnection.
Their security team may require additional validation. Their legal team may require notification. Their executive management may ultimately own the risk decision.
Your four-hour RTO can therefore become wishful thinking. An internal recovery objective is only credible if the external dependencies required to achieve it can support the same outcome.
The Invisible Dependencies
Boards frequently understand their organisation's largest suppliers, but they rarely dig into the dependencies beneath those suppliers.
Consider a critical SaaS platform. Its availability might depend upon:
Cloud infrastructure
Identity services
DNS
Telecommunications
Certificate authorities
Content delivery networks
Managed databases
Security services
Software supply chains
Third-party APIs
Your dependency is therefore not simply on the SaaS provider, you’re indirectly dependent upon an entire ecosystem of organisations with which you have no contractual relationship whatsoever. Cyber recovery is consequently not a simple supply chain, it is a dependency graph.
Understanding that graph becomes essential when determining whether critical business services can actually be recovered.
Regulators Have Recognised the Same Problem
The importance of third-party dependency is no longer simply a matter of good cyber-resilience practice. Operational resilience regulation increasingly treats third-party risk as a fundamental part of an organisation's ability to continue delivering important services during disruption.
In the UK financial sector, the Prudential Regulation Authority's operational resilience framework explicitly connects operational resilience with the management of outsourced relationships. Its supervisory expectations require firms to understand how third parties support important business services and to remain operationally resilient irrespective of whether those services are delivered internally or externally. The PRA's separate supervisory statement on outsourcing and third-party risk management complements these operational-resilience requirements and includes expectations around business continuity, exit planning and oversight of material third-party arrangements.
The UK regulatory direction has subsequently gone further. The Bank of England, PRA and FCA have established a regime specifically addressing Critical Third Parties whose disruption could threaten the stability of, or confidence in, the UK financial system. More recent reporting requirements are also designed to improve regulatory visibility of material third-party arrangements, interconnectedness and concentration risk.
The European Union's Digital Operational Resilience Act (DORA) is even more explicit. DORA requires financial entities to manage ICT third-party risk as an integral component of their overall ICT risk-management framework. It requires organisations to understand the nature, scale, complexity and importance of ICT dependencies; maintain information about contractual arrangements; establish a strategy for ICT third-party risk; and retain responsibility for resilience even where services have been outsourced. For services supporting critical or important functions, contractual arrangements must also address matters such as service levels, incident notification, security measures and tested business-continuity capabilities.
NIS2 extends the same principle beyond financial services and into other critical sectors. Article 21 explicitly identifies supply-chain security, including the security-related aspects of relationships with direct suppliers and service providers, as one of the cybersecurity risk-management measures organisations must address. The Directive places this alongside incident handling, business continuity, backup management, disaster recovery and crisis management—effectively recognising that organisational resilience and supply-chain resilience cannot be separated.
This regulatory direction is also likely to continue in the UK. The forthcoming Cyber Security and Resilience Bill is expected to strengthen requirements around supply-chain and third-party cyber risk, extending greater scrutiny to organisations providing critical digital and managed services and reinforcing the principle that resilience must extend beyond an organisation's own boundaries.
Different regulations use different terminology, but the direction of travel is consistent: An organisation cannot outsource its accountability for resilience.
Using a cloud provider, MSP, SaaS platform or other external service does not transfer the operational consequences of that dependency to the supplier.
Regulators increasingly expect organisations to understand:
Which third parties support important or critical business services
How failure of those providers affects service delivery
Where concentration and systemic dependencies exist
What contractual protections and assurance mechanisms are in place
Whether business continuity and recovery arrangements have been tested
How services would continue or be recovered if a third party became unavailable
This creates an important distinction for Boards: Third-party risk management cannot end with determining whether a supplier is secure enough to use. Operational resilience requires understanding whether the organisation can continue, recover and remain within its tolerances when that supplier is disrupted.
These service providers are often subject to the same third-party risk-management requirements themselves. The next logical step is therefore to extend that thinking further: what happens to the delivery of our critical business services when the third party is operational, but is unwilling to reconnect us because it no longer trusts our environment?
That is the recovery problem that traditional third-party risk assessments rarely address.
Minimum Viable Company Must Include Third Parties
The concept of the Minimum Viable Company (MVC) asks what is the minimum set of business services required for the organisation to continue operating while meeting its safety, regulatory, contractual and operational obligations?
Those services inevitably contain third-party dependencies. For every MVC service, organisations should therefore understand:
Which third parties are required?
Which specific services or interfaces are required from them?
Which third parties sit on the recovery critical path?
Which dependencies represent single points of failure?
What contractual recovery commitments exist?
What happens if the third party is simultaneously recovering?
Could the third party disconnect us following an incident?
What evidence would they require before reconnecting?
Who within each organisation can authorise reconnection?
What alternatives or manual workarounds exist?
An MVC that identifies only internal technology is incomplete, the real Minimum Viable Company extends across organisational boundaries.
Contracts Do Not Guarantee Recovery
Many organisations assume that contractual Service Level Agreements address this problem. Those SLAs may define:
Availability
Response times
Support commitments
Escalation procedures
Service credits
They also may say very little about:
Your organisation’s relative priority during a systemic cyber event
Dedicated recovery engineering
Reserved recovery capacity
Simultaneous customer recovery
Emergency credential reissuance
Re-establishing integrations following compromise
Evidence required before reconnection
Authority to approve reconnection
Participation in joint recovery exercises
A contractual right to service is not the same thing as an operational capability to recover it.
Receiving a financial penalty for a missed SLA months after an event provides little consolation when your organisation is in the middle of a crisis and critical business services and products cannot be delivered to customers.
Third-Party Risk Management Must Extend into Recovery
Traditional Third-Party Risk Management frequently concentrates on whether suppliers have appropriate security controls.
Questionnaires ask about:
ISO 27001
SOC 2
Vulnerability management
Penetration testing
Encryption
Access control
Incident response
Business continuity
These remain important, but cyber resilience requires another layer of questioning: one that understands not simply whether the supplier can recover itself, but whether the relationship between the two organisations can be recovered.
This is particularly important in light of operational resilience regulation. Regulators are increasingly moving organisations away from narrow assessments of individual controls and towards understanding the end-to-end operational capability to continue delivering a business service through disruption.
Third-party assurance therefore needs to mature accordingly. Evidence that a supplier has controls is useful., but evidence that a jointly dependent service can be recovered is considerably more valuable.
The unit of resilience is no longer just the supplier, it is the service, the dependency and ultimately the connection between the organisations.
What Good Looks Like
Resilient organisations treat third-party recovery as an operational dependency rather than simply a procurement or compliance exercise.
They:
Map third-party dependencies into critical business services and the Minimum Viable Company.
Identify external organisations sitting on the recovery critical path.
Align third-party dependencies with regulatory impact tolerances and recovery objectives where applicable.
Understand concentration risk and dependencies on common underlying providers.
Understand which third parties could disconnect them following a cyberattack.
Pre-agree escalation and emergency communication channels.
Determine what evidence critical partners require before reconnection.
Establish governance for producing and approving recovery assurance.
Validate supplier recovery assumptions rather than relying solely on questionnaires.
Include strategic suppliers and partners in cyber recovery exercises.
Test the process of disconnecting and reconnecting critical integrations.
Develop alternative suppliers, exit strategies or manual workarounds where practical.
Ensure contracts address recovery cooperation and reconnection where appropriate.
Maintain out-of-band contact information for critical suppliers and partners.
Most importantly, they recognise that restoring technology is not necessarily the same as restoring the business.
A Practical Analogy
Imagine an international airport following a serious security incident.
The airport restores its systems: The runways are operational. Air traffic control is functioning. Passengers can enter the terminal. Technically, the airport has recovered.
However, the airlines will not resume flights until they are satisfied that the airport is safe. Regulators may require evidence. Security authorities may require validation. Partner airports may impose restrictions.
The airport's own declaration that everything is operational is insufficient. Operations resume only when the wider ecosystem trusts the airport again.
Cyber recovery often works in much the same way.
Questions to Ask Your Executive Team
Which third parties are required to operate our Minimum Viable Company?
Which of those organisations sit on our recovery critical path?
Have we mapped those dependencies to our important or critical business services?
Which critical services depend upon the same underlying third parties?
Where do we have material concentration risk?
What happens if those organisations are simultaneously recovering from the same event?
Which suppliers, customers or partners could disconnect us following a destructive cyberattack?
Do we know what assurance each critical third party requires before reconnecting?
Who within our organisation is authorised to provide that assurance?
What technical evidence would support it?
Have we tested recovery and reconnection with our most important third parties?
Can our third-party dependencies support our regulatory impact tolerances and recovery objectives?
What business services could we operate if critical third parties remained unavailable for days or weeks?
Key Takeaways for the Board
Third-party dependency can determine how quickly an organisation recovers.
Dependency works in both directions: suppliers may be unavailable, or they may deliberately disconnect the victim organisation.
Operational-resilience frameworks including PRA requirements, DORA and NIS2 explicitly recognise third-party and supply-chain risk as integral to resilience.
Organisations remain accountable for resilience even when critical capabilities are delivered by external providers.
An organisation can restore its technology while remaining unable to operate because third parties have not re-established trust.
Recovery plans must therefore include both technical restoration and external assurance.
Internal RTOs are meaningless if critical external dependencies cannot support them.
Contracts and security questionnaires provide limited evidence of real recovery capability.
The Minimum Viable Company must incorporate external dependencies and the interfaces required to deliver critical services.
Third-party cyber risk management should consider how relationships are recovered, not simply how suppliers are protected.
The Board's Role
The Board should ensure that cyber resilience programmes extend beyond the organisation's own technology estate and consider the broader ecosystem required to sustain and recover critical business services.
Increasingly, this is not merely a matter of prudent governance but reflects the direction being established by operational-resilience regulation: organisations are expected to understand their material dependencies, assess the risks those dependencies introduce and remain accountable for the resilience of the services they deliver even where significant components are outsourced.
The Board should therefore challenge management to demonstrate not only that critical suppliers are resilient, but that the organisation understands how those relationships behave during a destructive cyberattack.
The Board should expect management to know:
Which external organisations are essential to recovery.
Which critical business services depend upon them.
Where systemic or concentration risk exists.
Which could become unavailable at the same time.
Which could disconnect the organisation because it represents a potential security risk.
What assurance those organisations require before reconnecting.
Who is accountable for providing that assurance.
Whether these assumptions have actually been exercised.
The fundamental governance question is “Can we recover the ecosystem of trust, dependencies and connectivity required for our organisation to operate?”
Closing Thought
Organisations rarely recover alone. Every critical business service exists within an ecosystem of suppliers, customers, partners, infrastructure providers and interconnected technology.
Regulators have increasingly recognised this reality.
Resilience cannot stop at the organisational boundary simply because accountability for part of the service has been transferred contractually to somebody else.
During a destructive cyberattack, some of those organisations may be recovering alongside you. Others may deliberately disconnect from you.
Restoring your own systems is therefore only part of recovery.
The organisation has not truly recovered until the organisations it depends upon are themselves operational, and are willing and able to trust it again.
Next Briefing
Cyber Resiliency Board Briefing #9: The Recovery Capacity Problem - Why Recovery Is Often Limited by People, Not Technology
