Escrow services for NIS2 compliance: How to safeguard digital continuity

Imagine this: a business-critical application is hosted by a SaaS provider that suddenly shuts down. You have backups of your own data, but the source code, configuration files, and technical knowledge required to run the application independently remain with the provider.

You cannot restore the service.

This is exactly the type of scenario that makes NIS2 a very real concern for executives, IT leaders, risk managers, and compliance teams.

The NIS2 Directive, in force as the European cybersecurity framework since October 18, 2024, places a duty of care on organizations across 18 critical sectors that goes well beyond basic cybersecurity hygiene. Business continuity, incident management, and supply-chain risk management are explicitly covered under Article 21.

In the Netherlands, NIS2 is implemented through the Cyberbeveiligingswet (Cbw), which entered into force on August 15, 2026. Organizations must therefore not only have appropriate measures in place, but also be able to demonstrate to regulators that those measures are effective.

Escrow is one of the practical tools that can support this requirement. Here is how.

What NIS2 article 21 requires

Article 21 of the NIS2 Directive sets out the cybersecurity risk-management measures organizations are expected to implement. These explicitly include backup management, disaster recovery, crisis management, and supply-chain security.

ENISA also published its NIS2 Technical Implementation Guidance on June 26, 2025, helping organizations translate these requirements into operational measures.

In practice, this comes down to three things:

1. You need policies and measures that protect business continuity in the event of system or supplier failure.
2. You need to be able to demonstrate that recovery is actually possible — not merely describe it in a Business Continuity Plan.
3. Your management body must approve these policies and oversee their implementation.

The third point is where many organizations face challenges.

An escrow agreement that has never been tested provides limited value during an audit. Demonstrating recoverability requires deposits, verification, periodic recovery testing, and documented evidence of the results.

Three types of escrow services and their relevance to NIS2

Not every software dependency requires the same escrow solution. The right approach depends on how the technology is deployed and the continuity risk your organization faces.

Software Escrow for on-premises and custom-built software

If your organization depends on custom-built software or licensed applications running within your own environment, software escrow offers one of the most direct ways to protect recoverability.

Source code, build instructions, technical documentation, and dependencies are securely deposited with an independent escrow provider.

If a release event occurs — for example, the software vendor becomes insolvent or permanently discontinues support — your organization can obtain access to those assets and either maintain the software internally or appoint another provider to do so.

From an NIS2 perspective, this creates tangible evidence for backup management and disaster recovery. You can demonstrate that the continuity of a business-critical system does not depend entirely on a single supplier.

SaaS Escrow for cloud and web applications

Recoverability is more complex in SaaS environments.

The application runs on the supplier’s infrastructure, while your data is often hosted there as well.

SaaS escrow defines which data exports, configuration files and, where relevant, container images or deployment scripts are periodically deposited. This enables your organization to migrate, rebuild, or reproduce the service if the SaaS provider can no longer deliver it.

This directly addresses the supply-chain dimension of NIS2.

It reduces your operational dependency on a single cloud or SaaS provider and demonstrates that your organization has taken concrete steps to prepare for supplier failure.

In this context, reducing vendor lock-in is no longer simply a commercial consideration. It becomes part of your operational resilience and compliance strategy.

Data Escrow for data-critical dependencies

In some environments, continuity depends primarily on continued access to a specific dataset.

Examples include registry databases, industry data platforms, and other data-driven services.

Data escrow provides a contractually and technically secured fallback mechanism for these situations.

Escrow4All provides Data Escrow and Registry Data Escrow services, including ICANN-approved Registry Data Escrow (RyDE). For organizations with similar data-critical dependencies, this creates an independently safeguarded route to continued access when normal service delivery is disrupted.

The evidence you need for a NIS2 audit

An escrow agreement on paper is a starting point, but it is not evidence of recoverability.

Regulators and internal auditors will typically expect to see a documented chain showing that the continuity measure works in practice.

Key elements include:

• Deposit scope: a documented inventory of exactly what has been deposited, including source-code versions, configuration files, runbooks, and data exports.
• Verification report: technical confirmation by the escrow provider that the deposited materials are complete and usable.
• Recovery test results: evidence that the deposited assets can actually be used to recreate or restore a working environment, including the test date and responsible parties.
• Release conditions: clearly defined and auditable trigger events, such as supplier insolvency, permanent discontinuation of service, or contractual breach.
• Update protocol: documented procedures defining how and how often escrow deposits are updated following new software releases or changes.

Escrow does not replace your internal Business Continuity Plan or disaster recovery strategy.

Instead, it strengthens those plans for one very specific scenario: when the technology supplier itself becomes part of the problem.

From NIS2 Gap to an Effective Escrow Strategy in Five Steps

Step 1: Identify your critical software dependencies.
Determine which applications are business-critical and which third-party suppliers they depend on. Distinguish between on-premises, SaaS, and hybrid deployments.

Step 2: Define your continuity objectives.
Establish the maximum acceptable recovery time objective (RTO) and recovery point objective (RPO) for each system. These targets help determine how frequently deposits should be updated and how rigorous recovery testing needs to be.

Step 3: Define the escrow scope for each system.
Identify the assets required to restore or independently operate the application. For custom-built software, this often involves much more than source code alone. Build scripts, infrastructure documentation, dependencies, configuration information, and licensing information may all be required.

Step 4: Establish governance.
Determine who is responsible for maintaining the deposit, who owns the contractual relationship, and who has the authority to trigger a release.

Document clear responsibilities across IT, Legal, and Risk & Compliance, and ensure that the management body has formally approved the approach.

Step 5: Verify, test, and document recovery.
Carry out verification and recovery tests and document the results.

Annual testing may be appropriate as a baseline, but systems with demanding RTO requirements may require more frequent testing. These test results provide some of your strongest evidence to regulators and auditors.

Supply-Chain Risk: Escrow as a Demonstrable Control

NIS2 does not simply require organizations to identify supply-chain risks. Those risks also need to be managed.

Three scenarios are particularly relevant:

• A supplier becomes insolvent and support stops immediately.
• A supplier suffers a major cyber incident and remains unavailable for an extended period.
• A supplier discontinues a critical product without providing a viable migration path.

In each of these scenarios, the quality of your escrow arrangement directly influences how quickly your organization can respond.

As an ISO 27001-certified escrow provider in the Benelux, Escrow4All provides both the technical infrastructure and the contractual framework required to prepare for these situations.

ISO 27001 certification is more than a quality indicator in this context. It also provides internal and external auditors with an independent reference point for the information security controls surrounding the escrow deposit itself.

Three Misconceptions That Can Undermine Your Escrow Strategy

“We have backups, so we’re covered.”

Backing up your own data is not the same as having independent access to the source code, configurations, documentation, and technical knowledge required to rebuild an application.

Your backup will not solve the problem if the supplier itself is no longer available.

“Escrow is only about source code.”

That view is too narrow.

In SaaS environments, continuity may depend on data exports, deployment configurations, infrastructure definitions, container images, and other assets.

The escrow scope should be determined by what you actually need to recover the service — not by what happens to be easiest to deposit.

“We’ll arrange escrow if we ever need it.”

Escrow only works if the arrangements are already in place before a release scenario occurs.

NIS2 is fundamentally about proactive risk management. An escrow agreement established only after a supplier is already experiencing serious problems may be too late to provide meaningful legal or operational protection.

Frequently Asked Questions About NIS2 and Escrow

Which type of escrow is right for my organization?

If the software runs on-premises or has been custom-developed, software escrow is typically the most appropriate solution.

If your organization depends on a SaaS platform, SaaS escrow is more relevant.

Both solutions can coexist within the same organization for different systems and suppliers.

How often should verification and recovery testing take place?

NIS2 does not prescribe a specific minimum testing frequency.

Annual testing is common, but testing frequency should ultimately be linked to your recovery objectives. The shorter your required recovery time, the more important it becomes to ensure that your most recent test remains relevant.

How should escrow be integrated into our BCP and incident-management processes?

Your Business Continuity Plan should clearly identify which systems use escrow as a fallback mechanism, under which circumstances a release can be requested, and who has authority to make that decision.

This turns escrow into an active part of your crisis and continuity process rather than leaving it as a purely contractual arrangement.

What is the relationship between escrow and ISO 27001?

ISO 27001 requires organizations to manage supplier-related risks and to test continuity measures periodically.

When properly implemented and documented, escrow can contribute evidence supporting both objectives.

Working with an ISO 27001-certified escrow provider further strengthens that evidence chain.

Five Takeaways for Your NIS2 Compliance Roadmap

NIS2 Article 21 requires concrete and demonstrable measures for business continuity and supply-chain security.

Escrow addresses a very specific but important part of that challenge: providing independent recoverability for software and data dependencies that cannot be adequately protected through internal backups alone.

Five actions you can start with today:

1. Identify which business-critical systems are hosted, managed, or controlled by external suppliers.
2. Determine what would actually be required to recover each system: source code, data, configuration files, documentation, or a combination of these.
3. Put escrow agreements in place with clearly defined release conditions before a supplier encounters difficulties.
4. Perform deposit verification and recovery testing, and retain the results as audit evidence.
5. Ensure that management formally approves the policy and that ownership and responsibilities are clearly assigned.

Want to understand which type of escrow best fits your software dependencies — and how to implement it as a demonstrable NIS2 control?

Escrow4All can help you perform an Escrow Scope Check for your business-critical systems.

Escrow4All — to be sure.