Escrow in the SaaS Era: Valuable Resilience Tool or Box-Ticking Exercise?

Mike Day • 4 October 2026

Third Party Therapy Podcast — featuring Nathan Hopkins, Chief Revenue Officer, the escrow company

Software escrow has a reputation problem: many third party risk management (TPRM) professionals see it as something you put in a contract and then never think about again. In this episode of Third Party Therapy, host Mike Day speaks with Nathan Hopkins of the escrow company about how escrow has evolved for the SaaS era, and how to make sure it's a genuine resilience tool rather than a box-ticking exercise.
 
## From Source Code to SaaS
 
Traditional software escrow is straightforward: a vendor licensing software to an end user deposits their source code with an independent escrow agent, so the customer can keep maintaining the software if the vendor fails. SaaS fundamentally changes the risk, because the provider is now responsible for far more than code — availability, infrastructure, and the functionality of a live service the customer never directly controls. Nathan's own career bridged data centre and managed service environments before joining the escrow company roughly in line with the industry's shift toward cloud adoption.
 
## Four Models for SaaS Escrow
 
Nathan sets out a spectrum of approaches, which can be combined depending on the risk:
 
- **Traditional deposit** — source code plus the additional materials a SaaS product needs to be meaningfully rebuilt: customer data, deployment scripts, infrastructure-as-code, and pre-configured containers or snapshots.
- **Access/credentials escrow** — for single-tenant deployments, depositing credentials to the existing live production environment (typically hosted on AWS, Azure or similar), so a beneficiary can take over billing and ownership of an already-running system rather than rebuilding from scratch.
- **Secondary environment** — a standby environment, controlled either by the vendor or the escrow provider, kept ready to take over.
- **Fully managed service** — the escrow provider takes on redeployment and ongoing operational management of the solution following a trigger event.
 
Nathan is clear escrow typically protects against business-led failure (insolvency, breach of contract, inability to support the product) rather than a pure technical disaster, which should still sit within the vendor's own backup and disaster recovery planning.
 
## The Airline Case Study
 
Nathan describes (without naming the airline) a customer facing exactly this scenario: a third party provider delivering its core, revenue-generating flight booking system went into administration. Because the airline had invested in the managed escrow option, Nathan's team redeployed a replica of the solution and ran it for roughly three months — including a DNS failover that Nathan says produced zero downtime for the airline's customers — while the airline made a longer-term plan, ultimately bringing the capability in-house and hiring some of the affected vendor's staff.
 
*Editorial note: the specifics of this case study (the duration of the managed takeover, the zero-downtime claim, and the hiring outcome) are Nathan Hopkins's own account on the podcast, given in general terms to protect client confidentiality, and have not been independently verified by this publication.*
 
## Making Escrow Work: Testing Is Everything
 
Nathan's clearest message is that escrow only has value if it's verified. Historically, two things undermined escrow: deposits falling out of date, and beneficiaries lacking the operational resource to actually use materials even once released. His organisation now runs automatic, frequent (often daily) deposits tied to production versions, and offers verification services ranging from witnessing and documenting a vendor's own rebuild process, to independently repeating that rebuild themselves and inviting the beneficiary to run functional tests against the replica — for example, confirming a flight can actually be booked through the rebuilt system.
 
He shares a cautionary example: a customer who was also an investor in a software company deposited materials into escrow but declined formal verification. When the vendor later failed and the materials were released, the customer discovered files were missing — something Nathan says routine testing would have caught.
 
## Who Owns the Escrow Relationship?
 
Mike and Nathan discuss a shift in ownership: rather than escrow being bolted on as a one-off contractual clause during supplier negotiation, financial institutions in particular are increasingly treating the escrow relationship itself as something the customer owns and manages strategically across a multi-vendor portfolio — partly driven by regulators such as the PRA and equivalents overseas (DORA in the EU) requiring firms to address supply failure risk, including insolvency, directly.
 
## Handling Personal Data in Escrow
 
Because SaaS deposits can include customer data, Nathan describes using encrypted deposits where the escrow company holds no decryption key — the beneficiary alone holds that — as one mechanism for managing GDPR and data sensitivity concerns without compromising the ability to recover a service.
 
## What Happens When Escrow Is Invoked
 
Invocation isn't instant. A beneficiary triggers a claim (for example, alleging insolvency); the depositor is given the opportunity to accept or dispute it; disputes that can't be resolved between the parties can ultimately go to the courts, since the escrow agent remains strictly impartial and does not adjudicate. Nathan notes some contracts pre-agree conditions under which certain release processes can bypass dispute altogether.
 
## Rollbacks and Historical Versions
 
Because the escrow company typically stores a rolling history of deposits (Nathan cites roughly a year of daily deposits under some models, plus permanently retained verified copies), a rollback to an earlier version is often possible if a recent update caused the underlying problem.
 
## AI and the Future of Escrow
 
Asked about AI's impact, Nathan is candid that the market is still in an early, "prove it first" adoption phase, similar to the early days of cloud. Fundamentally, AI platforms still rely on data, which escrow can still protect — but he flags that the growing scale of AI training data, and the IP and licensing questions around who owns what, will be a genuine emerging challenge for the escrow model to address as adoption matures.
 
## Lessons Learned
 
Nathan's clearest advice: go into an escrow arrangement with your eyes open about what you actually want to achieve and what risk you're addressing, rather than treating it as a standard contractual afterthought bolted on late in negotiation. Organisations that get the most value tend to standardise their approach across vendors, decide upfront which models suit which criticality of service, and — critically — commit to testing and verification rather than assuming a deposit alone is sufficient protection.
 
---
 
**Listen to the full episode of Third Party Therapy, produced in association with CeFPro, on Apple Podcasts, Spotify, Amazon Music, Audacy and YouTube, or visit [thirdpartytherapy.com](https://thirdpartytherapy.com) to subscribe to the mailing list.**
 
---
 
### Tags
 
#ThirdPartyTherapy #TPRM #SoftwareEscrow #SaaSEscrow #OperationalResilience #ThirdPartyRiskManagement #VendorRiskManagement #DORA #BusinessContinuity #DisasterRecovery #ExitPlanning #SupplierFailure #ContractualResilience #RiskManagementPodcast #IsEscrowWorthIt #HowDoesSaaSEscrowWork #TPRMPodcast

by Mike Day • 4 October 2026
Third Party Therapy Podcast — featuring Dharminder Mehmi, third party risk specialist, Legal & General
by Mike Day • 4 October 2026
Third Party Therapy Podcast — featuring Harj Mattu, Partner, Deloitte
by Mike Day • 4 October 2026
Third Party Therapy Podcast — featuring Oliver Jones, H&Z
by Mike Day • 4 October 2026
Inside the Recruitment Market for Third Party Risk Talent - Third Party Therapy Podcast — featuring Jack Birch, Head of Interim Management Practice, and Will Cook, Senior Consultant, Procurement Heads
by Mike Day • 4 October 2026
Third Party Therapy Podcast — featuring Stephen Boyer, Co-Founder and Chief Innovation Officer, BitSight. Why Static Binary Analysis Is the Missing Piece in Software Supply Chain Risk
Third Party Therapy logo
by Mike Day • 14 September 2026
BitSight's Stephen Boyer on why annual cyber assessments aren't enough, and how continuous monitoring catches risks like MoveIt and CrowdStrike fast.
Third Party Therapy logo
by Mike Day • 14 September 2026
Emerging tech adviser Ian Ellis on how corporate TPRM processes look from a startup's side, and how slow due diligence can cost you the best suppliers.
Third Party Therapy logo
by Mike Day • 14 September 2026
Zurich's Gemma Stewart on building a concentration risk programme from scratch: geographic, fourth party and cloud risk, and why data must come first.
by Mike Day • 14 September 2026
Third Party Therapy Podcast — featuring Aki Eldar, co-founder of Mirato
by Mike Day • 14 September 2026
Third Party Therapy Podcast — Series 1, Episode 1 — featuring Paul Huggett, Managing Director, Helios For the very first episode of Third Party Therapy, host Mike Day speaks with Paul Huggett, Managing Director at Helios and a former head of third party risk management (TPRM) at Lloyds Banking Group, Bank of Ireland and Nationwide Building Society. Having sat on both sides of the fence — as a buyer of pooled due diligence for over a decade, and now as a provider of it — Paul offers a rare, grounded view of what community due diligence really delivers, and where its limits are. From "Poacher" to "Gamekeeper" to Provider Paul's career path is itself a neat illustration of how TPRM as a discipline emerged almost by accident. Starting in operational and IT project management in the early 1990s, he moved into outsourcing project delivery — describing himself at the time as a "poacher," someone focused purely on moving functions quickly, for whom procurement was simply an obstacle. A move into internal audit at Lloyds Banking Group — auditing the sourcing and property functions — turned him into a "gamekeeper," and from there he spent a decade running third party risk functions across three major financial institutions, all of which were customers of Helios's FSQS scheme, before joining Helios itself roughly 18 months ago. Ten Years of Change in TPRM Paul's account of how far the discipline has moved is stark. His first supplier management audit revealed that "due diligence" at the time amounted to a signed letter from the supplier saying "everything's fine, thank you." The regulatory framework consisted of a handful of bullet points essentially saying "you can't outsource the risk." The period from roughly 2015 to 2018 — driven by GDPR, the growth of cloud outsourcing, and European regulators waking up to the risk — triggered rapid change, followed by growing UK regulatory focus (SS2/21 and PS7/21) on operational resilience, conduct risk, and more recently ESG, which Paul says has moved from "almost at the bottom of the pile" to near the top of the risk league table. What Pooled Due Diligence Actually Is Paul's explanation is refreshingly plain: the traditional model is a "many-to-many mesh" — every buyer individually asking every one of their suppliers largely the same questions, repeatedly. Pooled or community due diligence flips this into a one-to-many model: a supplier answers a shared, standardised question set once, and that data is made available (with the supplier's consent and quality-checked) to every buyer in the community who needs it. The win is symmetric. Suppliers spend less time repeatedly answering near-identical questionnaires from dozens of buyers. Buyers get a faster start, a broader pool of pre-assessed suppliers, and — critically — a question set that reflects a decade of collective input from the buying community, not just their own risk team's best guess. As Paul puts it, being able to tell your board "this is good enough for [named peer firms], therefore we believe it's good enough for us" is valuable air cover for a new entrant to the model. From Niche to Mainstream When Lloyds Banking Group first adopted the model, it was the only buying firm in the community — making it a hard sell to suppliers. Today, Helios's UK community includes just under 70 buying firms, plus roughly 20 more across Europe, spanning tiny building societies through to major international investment banks. Paul attributes the shift to sustained pressure on TPRM budgets and headcount ("you never get, as a TPR person, someone come to you and say... would you like some more people?"), combined with a regulatory turning point around 2018-2019 when European regulation first explicitly acknowledged shared assurance as acceptable — provided the buyer using it still applies its own risk appetite to the results, rather than simply outsourcing the decision. Confidentiality and Competition Law Two objections come up repeatedly with pooled models, and Paul addresses both directly. On confidentiality, where a supplier is unwilling to upload a sensitive document (such as a full cybersecurity policy) directly, Helios instead asks granular, structured yes/no questions about the specific controls contained within that document — meaning a buyer's risk specialist can still assess control coverage without the underlying document ever being shared. On competition law, Helios never discloses which buyers work with which suppliers to other buyers in the community, never comments on individual suppliers as a collective, and never directs buyers to take action against a specific supplier — all of which would risk anti-competitive behaviour. Not a Silver Bullet — Part of an Ecosystem Paul is careful to position pooled due diligence as one part of a wider TPRM toolkit, not a replacement for the buyer's own risk judgement. Helios provides primary, source-verified data (rather than scraped or blended third-party data), but the buyer still has to decide what matters to them and act on it. His framing: "we give you the information, but your job is to decide what to do with it." Real-World Stress Testing: Russia-Ukraine One of the clearest illustrations of the model's value came with the outbreak of the Russia-Ukraine conflict. Because Helios already held country of registration, operating location and fourth party data for its supplier community, buyer firms could establish their exposure "within about half an hour" of the event breaking — rather than manually cross-referencing finance systems to work out who they'd been paying, and where. Helios then issued a bespoke follow-up questionnaire to roughly 10,000 suppliers within about ten days, with an 80% response rate — giving buyers not just a static exposure map, but live intelligence on downstream impact. The same approach was repeated for the Israel-Gaza conflict and rolling energy blackouts. Where AI Fits — and Where Helios Is Deliberately Cautious Asked about AI, Paul draws a pointed comparison to cloud computing circa 2017-2018: a lot of noise, real underlying risk, but limited clarity on exactly where the exposure sits. Helios is building a new question set specifically to assess suppliers' use of AI, aligned to the EU AI Act's risk-based, proportionate approach. But Paul is candid that Helios itself is deliberately slow to deploy AI at scale in its own data pipeline, given its core value proposition rests on primary, verified data rather than scraped or AI-generated content — and flags the emerging industry concern that large language models may increasingly be trained on data that itself originated from other AI systems, creating a quality-degradation risk over time. Editorial note: the discussion of AI training data and model quality reflects Paul Huggett's own views and industry commentary referenced on the podcast, not an independently verified technical claim. Concentration Risk and the Regulator's Blind Spot Paul also touches on Critical Third Party (CTP) regulation and the new, more detailed outsourcing and DORA registers now required by UK and EU regulators — designed to help regulators identify concentration risk across the financial sector. He's candid that Helios, precisely because of the same competition and confidentiality constraints discussed earlier, cannot fill this gap entirely: it knows what a supplier does, but not what each buyer considers critical about that relationship, since criticality varies hugely between an insurer, a reinsurer, a building society and an investment manager. The Direction of Travel: From Data to Assurance Looking ahead, Paul sees the community model extending from data-gathering into genuine assurance — Helios has already introduced ESG benchmarking that lets suppliers see how they compare to peers, and has launched pooled, supplier-funded virtual site visits testing controls across the top operational risk domains. Notably, he observes that resistance to pooled assurance has historically come more from buyers wanting to "do things their way" than from suppliers, who are generally keen to spend less time on duplicate assurance requests. A Practical Starting Point For any organisation considering this path, Paul's advice is to look at your own organisation from the supplier's point of view: how many different, overlapping data requests are you sending out? Are you actually using everything you collect, or gathering data you never act on? And do you genuinely understand your broader (not just your most critical) supplier population — because, as Paul notes pointedly, "Covid did not care that it was taking out your workforce from a whole swathe of your medium risk suppliers." His clearest warning, drawn from watching organisations invest heavily in shiny new source-to-pay platforms: the technology is rarely the problem. "Systems and technology are not going to solve your problems. They're just going to give you a shinier problem to grapple with," unless matched with the cultural change and data discipline to actually populate and use them. Listen to the full episode of Third Party Therapy, produced in association with CeFPro, on Apple Podcasts, Spotify, Amazon Music, Audacy and YouTube, or visit thirdpartytherapy.com to subscribe to the mailing list. Tags #ThirdPartyTherapy #TPRM #CommunityDueDiligence #PooledDueDiligence #VendorRiskManagement #ThirdPartyRiskManagement #FSQS #SharedAssurance #DueDiligence #FinancialServicesRegulation #ConcentrationRisk #CriticalThirdParty #DORA #SupplierRiskManagement #RiskManagementPodcast #WhatIsPooledDueDiligence #HowDoesCommunityDueDiligenceWork #TPRMPodcast