Why the Cybersecurity Act (NIS2) Is Changing Your Software Strategy (and How Escrow Helps)

For years, relying on an external software vendor felt like a calculated risk that most organizations quietly accepted. The vendor delivers, keeps everything running, and everyone moves on. The Cybersecurity Act (NIS2) has completely changed that equation.

The European directive on network and information security in its second iteration is not just another cybersecurity checkbox. It represents a structural shift in how regulated organizations must think about their software dependencies.

If you are responsible for vendor risk or IT security at a bank, insurer, or other entity in a critical sector, you have probably already felt the pressure. Below you will find exactly what has changed and why a software escrow agreement deserves a place in your compliance toolkit.

The Cybersecurity Act (NIS2) Has Been Enacted and Takes Effect This Summer

Important update: NIS2 has now been transposed into national law as the Cybersecurity Act and will enter into force this summer. This means organizations in critical sectors must now take concrete steps to meet the requirements. The preparation window has closed. Compliance is from this point forward a hard obligation with direct legal consequences.

NIS2 Puts Software Supply Chains in the Spotlight

The original NIS directive focused on incident response and baseline resilience. NIS2, which EU member states were required to transpose into national law by October 2024, goes significantly further. Article 21 now explicitly requires in-scope entities to manage and document security risks across their supply chains, including the software and services they procure from third parties.

That is a meaningful shift. Organizations can no longer point to a vendor contract and call it risk management. Regulators and auditors want to see demonstrable controls: what happens if your critical software vendor becomes insolvent? Gets acquired and changes direction? Experiences a prolonged outage? Can you recover and can you prove it?

The penalties for non-compliance are real. Essential entities risk fines of up to €10 million or 2% of global annual revenue, whichever is higher. Important entities can be fined up to €7 million or 1.4% of revenue. And under the directive, management bodies can be held personally liable. This is a risk you cannot delegate.

The Specific Problem with Third-Party Software

Many organizations running critical business processes rely heavily on niche SaaS platforms, custom-built applications, or sector-specific software. The source code, configurations, and technical documentation for those systems typically reside entirely with the vendor.

Under NIS2, that is now a documented risk exposure. If the vendor disappears through bankruptcy, acquisition, or simply discontinuing the product, your organization may be unable to recover or migrate those systems. Rebuilding critical software can realistically take 6 to 18 months. In a financial institution or healthcare environment, that is not just an operational problem—it is also a regulatory one.

The Cybersecurity Act requires organizations to report significant incidents within 24 hours. You cannot meet that deadline if your recovery depends on access to code and configurations you do not legally control.

How Software Escrow Turns Intent into Evidence

A software escrow arrangement is straightforward in practice. The software vendor deposits source code, technical documentation, build instructions, and configuration data with an independent escrow agent. If a defined release trigger occurs—such as vendor insolvency, material breach of contract, or termination of support—the deposited materials are released to the licensee.

This structure addresses multiple requirements under the Cybersecurity Act (NIS2) simultaneously:

• Supply chain risk management: The escrow agreement is documented evidence that vendor dependency has been assessed and contractually mitigated. Auditors have something concrete to evaluate, not just a policy statement.
• Business continuity: With verified access to source code and deployment assets, your team can recover, migrate, or independently maintain the application—even if the vendor is no longer reachable.
• Incident response readiness: Verification services confirm that the deposited code is actually functional. This significantly reduces mean time to recovery when incidents occur.
• Audit trail: Escrow providers generate logs, updated deposit records, and verification reports—exactly the documentation internal audit and regulators expect.

For SaaS applications specifically, SaaS escrow goes beyond traditional software escrow by also securing cloud infrastructure, access, hosting, continuity arrangements, and data portability—closing gaps that a standard escrow agreement would leave open.

What Good Looks Like in Practice

Vendor risk teams looking to roll out these controls across dozens of vendor relationships have one practical need: an approach that is repeatable. That means a mechanism you can embed in master agreements, verify annually, and present to internal audit or a regulator without debate.

A well-structured escrow agreement delivers that. Release conditions are predefined and legally binding. Deposited materials are periodically verified to confirm they are complete and buildable. The security posture of the escrow provider itself also matters. ISO 27001 certification, for example, reduces procurement friction and accelerates approvals in organizations with formal InfoSec review processes.

Escrow4All, the ISO 27001-certified escrow provider in the Benelux, offers Software, SaaS, and Data escrow solutions built specifically for organizations that need governance-ready continuity controls. Their verification services ensure deposited code is usable—not just stored—which is the difference between a compliance document and an actual fallback.

To understand what happens operationally when an IT vendor fails, read the article What Does Digital Escrow Do When Your IT Vendor Fails for a concrete explanation.

NIS2 Compliance Is Now a Procurement Conversation

One practical implication that is often overlooked: the supply chain obligations of the Cybersecurity Act (NIS2) mean you can and should include escrow clauses when entering contracts. When onboarding a new software vendor, requiring an escrow arrangement as part of the master agreement is far simpler than retrofitting it later. IT vendors who object are implicitly signaling something about their confidence in long-term continuity.

Regulated entities set a good example here. Outsourcing controls, operational resilience frameworks, and data protection obligations all converge on the same question: can you maintain critical services if a vendor fails? Digital escrow provides a legally documented, technically verified answer.

The Cybersecurity Act did not create the risk of software vendor dependency. It simply exposed the cost of ignoring it—and made that cost substantially higher. The organizations getting ahead of this are not treating digital escrow as a last resort. They are building it into vendor selection, contract templates, and their regulatory evidence packages.

That is the shift the Cybersecurity Act demands. Escrow is one of the most effective ways to meet it.

Want to learn more? Contact our consultants?

Escrow4All

To be sure