A critical service can stop without a successful cyberattack. A software vendor may face financial distress, withdraw support, suffer an operational failure, or be affected by a cyber incident or wider geopolitical disruption. When that happens, cybersecurity controls alone cannot answer the essential question: can the organization keep operating when the vendor can no longer support the application it depends on?
That question frames a discussion with Alex McCulloch, Market Development Director – Middle East at Escode. McCulloch argues that written plans and contractual guarantees are not enough to demonstrate operational resilience. Organizations need evidence that continuity arrangements can be activated, and that the technical materials required for recovery are current and have been tested.
He explains the role of software escrow and technical verification within an agreed scope of service, drawing a distinction between the right to access software and the actual ability of deposited materials to support recovery. He also discusses how to identify the dependencies that matter most to the business, and the questions boards should ask before disruption occurs.
Cybersecurity Is Only Part of the Resilience Picture
Cybersecurity dominates much of the conversation about technology resilience, but cyber risk is only one part of the picture. A critical service can be disrupted even without a successful cyberattack. A technology vendor may encounter financial difficulty, stop providing support, experience an operational failure, or itself be affected by a cyber incident or broader geopolitical disruption.
What organizations sometimes overlook is how dependent they are on the vendor behind a critical application. If that vendor can no longer support the software, the central question becomes: what practical options does the organization have to maintain operational continuity for that critical service?
Operational resilience should therefore be built in from the design stage, before disruption occurs. Organizations need to identify their dependencies on critical software, put continuity arrangements in place in advance, and establish whether those arrangements can actually support recovery if the vendor can no longer provide support.
Mapping Dependencies That Threaten Critical Operations
With companies relying on increasingly complex networks of third-party and even fourth-party technology providers, CIOs and risk leaders need a clear method for identifying the software dependencies that could genuinely threaten critical operations if a vendor’s services become unavailable.
The starting point is not the software itself, but the critical business process that depends on it. CIOs and risk leaders should identify the applications that support critical services, then understand the dependencies those applications rely on. Where necessary, that means looking beyond the direct vendor and understanding the wider ecosystem of third and fourth parties supporting the service.
They should then assess what could happen if one of the elements those applications depend on were no longer available. Can the software be replaced quickly and safely? Can the organization move to another provider within an acceptable timeframe? Or would the loss of vendor support create a fundamental continuity problem?
When replacement is difficult, costly, or carries operational risk, organizations need alternative continuity arrangements in place before disruption occurs. Third-party software risk should not be treated as a procurement matter alone. When software supports a critical process, vendor dependency becomes an operational resilience issue.
The Gap Between a Continuity Plan and Recovery Capability
Many organizations already have business continuity plans and contractual guarantees. The real gap appears when organizations assume that a contractual arrangement or a documented continuity plan automatically means they can recover. A plan has value only if it can actually be activated.
For critical software, organizations need clear access rights, current technical materials, appropriate documentation, operational knowledge, tested recovery procedures, and defined release conditions. These arrangements also need to be maintained and updated as software changes over time.
This matters particularly in software escrow. An escrow agreement defines the rights of access to deposited materials and the conditions for release. But the existence of those rights does not prove that the materials can support recovery. Technical verification should be carried out to confirm usability within an agreed testing scope.
The principle is clear: resilience should be verified, not assumed. Robust continuity arrangements should provide evidence that deposited materials are complete, current, and capable of supporting recovery when needed.
What Technical Verification Should Test
Independent technical verification matters because depositing software without testing its usability is not enough. Organizations should first distinguish between access to materials and their usability.
In software escrow, a software developer deposits software assets, including source code and supporting documentation, with an escrow agent—an independent third party. The agreement sets out the conditions under which those materials are released to the beneficiary. The agent’s role includes technical verification and testing within the agreed scope, answering a practical question: can these materials be used to restore operation of the software when needed?
At a basic level, organizations need to confirm that deposited materials are complete and current, include the files specified in the agreement, and are supported by technical documentation that is comprehensive and sufficient.
Depending on the agreed scope of technical verification, assessment can include testing whether the software can actually be rebuilt, deployed, or operated using the deposited materials. Scenario testing can be particularly useful because it moves the discussion from documentation to practical recovery.
For example, Vision Bank completed a two-stage technical verification that combined a knowledge transfer assessment with practical scenario testing for a critical cloud application. The process confirmed the usability of the deposited materials, deployment instructions, configuration information, and access mechanisms.
The core question is therefore not only whether source code has been deposited, but whether the deposited materials are complete, current, and genuinely capable of supporting recovery.
What the CBUAE Operational Risk Framework Changes
The new Operational Risk Management Regulation issued by the Central Bank of the UAE (CBUAE) reinforces the focus on operational resilience, critical operations, and third-party dependency. The regulation does not name software escrow as a specific requirement. What it reflects is a broader shift toward stronger operational resilience, with greater emphasis on critical operations, material third-party dependencies, contingency planning, and executable exit arrangements.
For financial institutions, this changes the nature of the discussion about critical software vendors. The questions become: what third-party software dependencies support our critical operations? What happens if one of those vendors’ services becomes unavailable? Can an alternative service be provided within the required timeframe? If replacement is difficult, what continuity options are available?
When critical software cannot be replaced quickly or safely, software escrow arrangements that include independent technical verification can provide an additional control to support continuity. They do so by preserving access, under agreed conditions, to software assets and recovery materials if the vendor can no longer provide support. These measures can support broader operational resilience and readiness objectives, but they should not be presented as a guarantee of regulatory compliance.
Why Escrow Arrangements Can Fail When Needed
Many organizations assume that depositing source code in software escrow provides sufficient protection. The fundamental issue is that being able to access deposited materials does not confirm they are usable. An escrow agreement may grant a right of access to software assets, but the deposited materials may be incomplete, out of date, or insufficiently documented. In some cases, an organization may receive source code but still lack deployment instructions, configuration information, operational knowledge, or other technical components needed to restore operation of the application.
This is why technical verification matters. Independent technical verification can assess whether deposited materials are complete and current, whether technical documentation is sufficient, and—depending on the agreed level of verification—whether the software can actually be rebuilt, deployed, or operated using those materials.
The agreement defines access rights and release conditions, while the results of technical verification and testing show how far the deposited materials can support recovery. These are complementary aspects of the software escrow service, within the agreed scope of service.
The goal should be to move from having contractual protection to having recovery capability that can be activated.
Digital Sovereignty and Software Continuity in the Middle East
Digital sovereignty, regulatory resilience, and reliance on external technology providers are attracting growing attention across the Middle East. Interest is clearly increasing in operational resilience, third-party dependency, and the ability to demonstrate that continuity arrangements are practical and current.
As organizations become more dependent on digital technologies, the software ecosystems they rely on become more complex. At the same time, issues such as vendor concentration, geopolitical disruption, and digital sovereignty are receiving greater attention.
The important shift is from asking whether continuity arrangements exist to asking whether they have actually been tested. For critical software, an organization should be able to demonstrate that recovery materials are current, that the required knowledge and documentation are available, and that continuity arrangements can be activated if the vendor can no longer provide support.
This is where independent technical verification becomes important. The broader direction is toward resilience that is documented, verifiable, and actionable, rather than relying on contractual protection alone.
Three Questions for Boards and Executive Teams
When advising a board or executive team today, three questions are most useful for determining whether the organization could continue operating if a critical software vendor suddenly stopped supporting an essential application.
- Have we put continuity arrangements in place before disruption occurs? The organization needs to understand its dependencies on software that supports critical operations and confirm that appropriate arrangements are already in place.
- Have we independently verified that these arrangements will actually work? It is not enough to know that source code or technical materials have been deposited somewhere. The organization needs evidence that these materials are complete, current, and capable of supporting recovery.
- Can these arrangements actually be activated if the vendor can no longer provide support? That means having legal rights, technical materials, operational knowledge, defined procedures, and tested recovery capability in place to respond.
These three questions reflect the core of software resilience: resilience built in from the design stage, resilience that is verified rather than assumed, and readiness to face disruption.
Ultimately, operational resilience goes beyond protecting technology from attacks. It also involves understanding dependence on the vendors behind critical technologies and being prepared to continue operating if their support is no longer available.