Earlier this year, our CEO, Anthony Watson, sat down with CIOs and senior IT leaders across banking, insurance, healthcare and media in Nairobi. The agenda covered the usual suspects: cloud migration, automation, AI, but the concern that kept resurfacing underneath all of it was:
• Not whether these organisations should adopt new technology – it was what happens when the provider behind it is no longer there,
• Not whether a platform is secure. Whether the service can continue if the company behind it fails, withdraws support, loses the engineers who understand it, or gets acquired by someone with different priorities.
Nobody in the room had a confident, evidenced answer.
This is not a South African problem viewed from a distance:
Across East Africa, organisations are digitising at pace. Core banking systems, policy administration platforms, ERP environments and the infrastructure customers touch every day are increasingly built and run by outside vendors. That is simply how modern business critical software is delivered.
What has not kept pace is the planning for what happens when that dependency breaks.
• Vendors go insolvent.
• They get bought and quietly deprioritised.
• Key technical staff leave and take undocumented knowledge with them.
• Support gets withdrawn.
• A cyber incident takes a supplier offline permanently.
None of this is theoretical.
It is the ordinary cost of building a business on someone else’s software.
The software industry does not only lose vendors through insolvency. Businesses are acquired, product lines are discontinued, support models change, engineering teams are restructured and strategic priorities shift. From the customer’s perspective, the result can be the same. The software they rely on is no longer supported in the way it was when the contract was signed. Continuity risk often arrives gradually, not dramatically.
Why this now sits with the board, not just IT
South Africa’s Joint Standard 1 of 2023, in force since November 2024, makes this explicit for regulated financial institutions. It places responsibility on the governing body to ensure the institution can identify, assess, manage, monitor and report material IT risks on a continuous basis. Third-party software dependency sits squarely inside that requirement. It is not a side issue to be handled by a vendor management spreadsheet.
Regulatory attention on this, in South Africa and in other markets moving through the same digitisation curve, is only increasing. The direction of travel is consistent: institutions are being asked to demonstrate resilience with evidence like contracts, procedures and recovery protocols, not just describe it in principle.
What we are actually seeing
We have spent over twenty years watching vendor dependency risk play out in South African boardrooms. What the Nairobi conversations confirmed is that the pattern is not unique to South Africa. It shows up wherever an economy digitises quickly and the governance conversation has not caught up with the technology conversation yet.
That gap, between what a business depends on and what it can prove it could survive without, is the one ESCROWSURE exists to close. Not by suggesting vendors cannot be trusted. By giving institutions a legally enforceable, tested way to keep operating if that vendor relationship ends.
The question worth putting to your own board
If the provider behind one of your critical systems disappeared tomorrow, could you show, with evidence rather than assumption, how the business would keep running? If the honest answer is “we would have to figure it out,” that is worth resolving before you are forced to.
Key Takeaways
- Software dependency risk extends beyond vendor insolvency. Vendor acquisition, withdrawal of support and loss of technical knowledge can all disrupt critical business systems.
- As organisations become more dependent on third party software, software continuity becomes a governance issue rather than simply an IT issue.
- Regulated organisations are increasingly expected to demonstrate how material technology risks are identified, managed and monitored through governance, contracts and operational resilience. Joint Standard 1 of 2023 places responsibility on governing bodies for oversight of material IT risks.
- Software escrow is one mechanism organisations may use to support business continuity where software supplier dependency represents a material operational risk.
Questions Boards and Technology Leaders Ask
What is software dependency risk?
Software dependency risk is the operational risk created when an organisation relies on software supplied and maintained by another company. If that supplier becomes unable or unwilling to continue supporting the software, the customer may experience operational disruption.
Does software dependency only occur if a software company goes bankrupt?
No. Dependency risk can also arise when a software company is acquired, withdraws support, restructures engineering teams, discontinues products or changes its commercial priorities.
Why is software dependency becoming a board issue?
Many organisations now rely on software to deliver critical business functions.
Boards are increasingly expected to demonstrate oversight of material technology risks and ensure appropriate governance and operational resilience measures are in place. For South African financial institutions, Joint Standard 1 of 2023 establishes governance responsibilities for managing material IT risks.
Does software escrow remove vendor risk?
No. Software escrow does not eliminate vendor risk.
It provides a contractual mechanism that may help organisations maintain access to critical software assets when agreed release conditions occur, subject to the terms of the escrow agreement.
How can organisations assess their software dependency exposure?
A practical starting point is to identify business critical systems supplied by third parties and ask whether the organisation could demonstrate, with documented evidence, how operations would continue if supplier support ended unexpectedly.
When should software escrow be considered?
Software escrow should be considered whenever an organisation depends on third party software that supports critical operations, regulatory obligations or customer services, and where loss of supplier support would create material business disruption.
What should organisations ask about critical software suppliers?
If this supplier could no longer support our business tomorrow, could we demonstrate, with evidence, how operations would continue?
Is your organisation prepared?
If one of your critical software providers disappeared tomorrow, could your organisation demonstrate how operations would continue?
Speak to an Escrowsure Executive Risk Consultant to assess your software dependency risk and discuss whether software escrow forms part of your operational resilience strategy.
