Concentration Risk Is No Longer a Theoretical Problem 

Concentration risk is no longer a background governance issue. It is now a front-and-centre regulatory expectation. 

As organisations deepen their reliance on third-party software, SaaS platforms, hyperscale cloud providers and AI systems, operational resilience increasingly depends on a small number of technology suppliers. When one of those suppliers fails, withdraws support, becomes insolvent, or suffers a major outage, the consequences can be immediate and systemic. 

Concentration risk is not about how many vendors sit on a spreadsheet or traffic light coding. It is about dependency depth, switching friction, and whether your organisation can continue operating when a critical third party is suddenly unavailable. 

And regulators are no longer satisfied with assurances.  

Regulators Are Asking for Proof, Not Promises 

In its 2026 priorities letter, the Bank of England made clear that firms must not rely solely on third-party assurances. Institutions are expected to understand their dependency chains and prepare for disruption, including scenarios where a supplier fails or becomes insolvent. 

That expectation sits alongside the PRA’s Operational Resilience framework (SS1/21), which requires firms to: 

“Demonstrate their ability to remain within their impact tolerances through severe but plausible disruption scenarios.” 

Similarly, under the EU’s Digital Operational Resilience Act (DORA), firms must: 

“Test the resilience of ICT systems and tools” and demonstrate that they can maintain critical or important functions during disruption. 

In the United States, FFIEC guidance requires institutions to: 

“Test the institution’s ability to recover from disruptions” and “demonstrate that critical operations can be resumed within established recovery time objectives.” 

Across jurisdictions, the language is consistent: identify, test, demonstrate, evidence. 

The word regulators increasingly care about is prove. 

An SLA is not proof. A resilience statement is not proof. A contract clause is not proof. 

Executable continuity is. 

The Tick-Box Software Escrow Era Is Over 

Historically, software escrow was often implemented as a contractual safeguard. It provided theoretical access to source code if a vendor became insolvent. For many years, that was sufficient due to the hosting and licensing model deployed. 

But concentration risk today is multi-layered. It is not just about insolvency. It may involve: 

• Withdrawal of support 

• Cloud provider outages 

• Cyber incidents 

• AI system failures 

• Vendor acquisition or strategic pivot 

Access to source code alone does not guarantee recoverability. 

Even where software escrow materials include code, documentation and build artefacts, a practical challenge remains: knowledge. In a live incident, does the beneficiary possess the internal expertise required to redeploy and operate that system in a short, regulated recovery window? 

Having the materials is not the same as having the capability. 

When the Cloud Fails 

Consider a further layer of concentration risk. What if the software vendor relies entirely on a single cloud provider such as Azure, and that cloud region suffers a prolonged outage? 

If your recovery strategy depends on redeploying into the same cloud environment, even a duplicate environment may not solve the problem. Concentration risk can sit not only with the software vendor, but with the underlying hyperscaler. 

True resilience requires optionality across infrastructure layers. 

Modern SaaS Escrow as an Operational Control 

Modern software escrow  and SaaS escrow frameworks address the evolution in risk. As well as code storage, a fit for purpose software or SaaS escrow agreement today can include: 

• Source code 

• API information or third-party dependencies 

• Deployment artefacts and configurations 

• Infrastructure-as-code and CI/CD pipelines 

• Documentation and build instructions 

• AI models, weights, inference pipelines and training components (where appropriate) 

• Access credentials to production cloud environments 

• Redundant replica fall back cloud environments 

• A Software Escrow partner who can deploy to and manage a cloud environment 

• Tested recovery plan 

The agreements should incorporate independent verification and testing aligned to stressed exit planning. But if  your organisation does not have the necessary expertise to deploy and manage the new environment, even this may not be enough to ensure continuity. 

The Role of Managed Continuity 

When looking beyond theoretical access to critical assets or third-party IP, a managed service model becomes increasingly relevant. 

Under such an arrangement, a software escrow provider can step in, beyond passive holding of materials. With appropriate agreements and investment in testing, the software escrow agent can: 

• Work with the vendor to replicate the solution on the same or an alternative cloud environment where feasible 

• Operate the application on behalf of the client during transition 

• Bridge the skills and knowledge gap 

• Maintain service availability while longer-term remediation occurs 

Critically, this may include structured knowledge sharing between the vendor and the software escrow provider in advance, reducing reliance on undocumented tribal knowledge. As well as an option not to release any IP but deliver a service during interruptions or supplier failure on an interim basis. In a failure event, time matters. Regulators measure impact tolerances in hours and days, not months and compliance teams need to evaluate options and controls. 

Concentration Risk Cannot Be Eliminated – But It Can Be Controlled 

Adding more vendors is not always realistic. Specialist software providers often dominate niche markets. Hyperscalers underpin entire ecosystems. 

The question is not how to remove concentration risk entirely. It is how to reduce its operational impact. 

Modern software and SaaS escrow, particularly when supported by verification and managed continuity options, provides enforceable control in a scenario where assurances alone collapse. 

For boards, risk committees and technology leaders, the issue is no longer whether a third-party agreement exists. It is whether continuity can be evidenced under stress. 

Because in today’s regulatory environment, the difference between a theoretical safeguard and a tested recovery mechanism is the difference between compliance and failure.