Alex Makhlouk on Tech Resilience

Alex Makhlouk, Director of Market Development at Escode, told the portal that critical services can fail without a cyber attack. He explained that a software vendor may stop supporting an application, forcing an organization to ask whether it can keep operating when the vendor can no longer provide support. This question sparked a discussion with the portal about operational resilience. Makhlouk said that written plans and contractual guarantees are not enough to prove resilience; companies need evidence that continuity arrangements can be activated and that the necessary technical materials are up to date and tested. He described the role of software escrow and the importance of technical verification within the agreed service scope, distinguishing software access from the ability to support recovery. He also outlined how to identify the most impactful dependencies in a business and the questions boards should ask before disruptions occur. Makhlouk noted that cybersecurity dominates discussions of technical resilience, but institutions often overlook other risks associated with third‑party software. He said that a critical service can fail even without a successful cyber attack, citing financial distress, loss of support, operational failure, or broader geopolitical pressures that affect the vendor. He emphasized that institutions sometimes fail to recognize how much they depend on the third‑party provider behind a vital application, and when that provider can no longer support the software, the key question becomes what practical options remain for maintaining operational continuity. He argued that resilience must be built into design before disruptions happen, urging firms to map dependencies on critical software, establish continuity arrangements in advance, and verify that those arrangements can actually support recovery if a vendor stops providing support.

He added that as companies rely on complex networks of third‑ and fourth‑party technology providers, chief information officers and risk leaders must identify dependencies that could jeopardize critical operations if a supplier fails. He said the starting point is not the software itself but the vital process it supports, and that leaders must understand the applications that underpin critical services and the dependencies they rely on, looking beyond the immediate vendor to the broader ecosystem. He explained that they must evaluate what would happen if a dependent component became unavailable, whether the software can be replaced quickly and safely, and whether migration to another provider is feasible within an acceptable timeframe, or whether loss of support would cause a fundamental continuity problem. When replacement is difficult or risky, he said firms need alternative continuity arrangements in place before disruptions occur, and that third‑party software risk should be treated as an operational resilience issue, not just a procurement concern. Makhlouk observed that many organizations already have business continuity plans and contractual assurances, but a gap remains between having a plan on paper and being able to activate recovery in practice. He said the gap appears when firms assume that a documented continuity plan automatically enables recovery, but a plan is only valuable if it can be executed. He stressed that for critical software, organizations need clear access rights, up‑to‑date technical materials, proper documentation, operational knowledge, tested recovery procedures, and defined release conditions, and that these arrangements must be maintained and updated as software evolves. He highlighted that software escrow agreements grant access to deposited materials and define termination and release conditions, but that merely having these rights does not prove the materials can support recovery; technical verification is required to confirm that the deposited assets can be used as agreed.

He concluded that resilience must be verified, not assumed, and that robust continuity arrangements should provide evidence that deposited materials are complete, current, and capable of supporting recovery when needed. Finally, he advocated for independent technical verification rather than simply depositing software without testing its usability, and outlined what organizations should test to ensure that deposited software and recovery materials can be used in a realistic recovery scenario. He said the first step is to distinguish between access to materials and their actual usability, and described how a software escrow arrangement works: the developer deposits source code and supporting documentation with an independent escrow agent, and the agreement specifies when and how the materials can be released to the beneficiary. He explained that the escrow agent performs technical verification according to a mutually agreed scope, answering the practical question of whether the materials can restore the software if needed. He recommended that firms verify that deposited materials are complete, up to date, and include all files specified in the agreement, and that technical verification may involve testing the ability to rebuild, deploy, or run the software using the deposited assets. He also suggested scenario testing, citing Vision Bank’s two‑phase technical verification that combined knowledge transfer assessment with practical recovery scenario testing for a critical cloud application, confirming that the deposited materials, deployment instructions, configuration details, and access mechanisms were usable. He emphasized that such testing moves the discussion from documentation to actual recovery capability.