Cyber resilience laws: Navigating a new age of software continuity compliance

For years, operational resilience was treated as a best practice, something mature organizations aspired to rather than something regulators demanded proof of. That has changed. A cluster of new cyber resilience compliance rules, spanning the EU, the UK, Australia, and the United States, now sets a legal floor for how businesses must manage the software they depend on.

This post explains why these rules arrived together, what each one requires, and what they're all pointing at underneath the different names and deadlines.

What one faulty update tells us about the new regulations

On July 19, 2024, a single software update did what most people assume only hackers can do. A faulty release from the security vendor CrowdStrike crashed around 8.5 million Windows machines at once, and the effects spread far beyond IT departments.

Airlines grounded their fleets, hospitals turned patients away, and payment systems stopped working, all because one widely used vendor pushed out one bad file. Not because anyone broke in.

That distinction is what regulators couldn't ignore, and it's problems like it that explain the wave of new rules. Too many broken software updates and dependencies have caused the kind of damage usually tied to serious attacks. Your uptime promises can't rest on good intentions anymore.

If your business runs on software you didn't build, these rules now shape what you're expected to prove.

Why the rules all arrived at once

CrowdStrike was the infamous example, but it wasn't the first warning. Four years earlier, attackers slipped malicious code into a routine update from SolarWinds, and roughly 18 000 of its customers installed the compromised version without knowing. In both cases, a single provider sat at the center of thousands of organizations, so when that provider failed, the failure didn't stay contained. It spread everywhere at once.

That pattern has a name: concentration risk. Whole industries now depend on the same small group of cloud platforms, security tools, and infrastructure providers. Those vendors quietly became shared infrastructure, and shared infrastructure fails for everyone simultaneously. A disruption that would once have been isolated to one company now has the reach of a sector-wide event.

The regulatory response followed the evidence. Policymakers in the EU, the UK, Australia, and the United States each ran their own analysis of what CrowdStrike, SolarWinds, and similar incidents revealed about systemic exposure, and they reached the same answer: the rules governing how businesses manage software dependency had not kept pace with how dependent on software those businesses had become.

The four regulations behind the change

Four regulations are leading this shift globally. They target different sectors and jurisdictions, but they share a common concern: that organizations have become dangerously reliant on third-party software vendors without adequate plans for what happens when those vendors fail. The starting point is understanding each one on its own terms.

DORA: Digital Operational Resilience Act

DORA is the EU's framework for the financial sector and the technology providers that sector depends on. Its core intent is to move operational resilience from a checkbox exercise to a continuously tested and demonstrated capability. Financial entities must manage ICT (information and communications technology) risk in a structured, documented way, and critically, they cannot simply rely on contractual assurances from their suppliers. DORA can designate certain technology providers as critical and supervise them directly, which is the first time an EU regulation has pulled third-party vendors into scope on that basis. It has been directly binding since January 17, 2025, with no national transposition required and no grace period.

NIS2: Network and Information Security Directive 2

NIS2 extends the EU's cybersecurity obligations far beyond the financial sector, covering essential and important entities across energy, health, transport, digital infrastructure, and more. Its defining shift is one of accountability: NIS2 moves cyber risk out of IT departments and into the boardroom, making leadership personally liable for compliance failures. Penalties can reach €10M or 2% of global turnover. The goal is to ensure that the people with authority to resource and prioritize resilience, executives and board members, also carry the legal exposure when they don't. National transposition was due by October 17, 2024.

CRA: Cyber Resilience Act

Where DORA and NIS2 focus on how organizations operate, the CRA focuses on what they ship. It applies to products with digital elements, which captures most commercial software, and its central purpose is to shift responsibility for security from the buyer to the builder. Historically, organizations purchasing software bore the burden of securing it after the fact. The CRA reverses that: vendors are now responsible for building and maintaining secure products throughout their lifecycle, including mandatory vulnerability disclosure. The regulation entered into force in December 2024, with vulnerability reporting required from September 11, 2026, and full compliance expected by December 11, 2027.

CPS 230: APRA Prudential Standard

CPS 230 is Australia's contribution, issued by the banking regulator APRA (Australian Prudential Regulation Authority) and applying to all regulated banks, insurers, and superannuation funds. Its focus is operational continuity under stress: regulated firms must identify their critical operations, map the service providers those operations depend on, and demonstrate, through testing, that they can keep running if a key provider is disrupted or fails. The standard has been in full force since July 1, 2025.

Those aren't the only major regulatory changes. It's a global mindset change. The UK introduced its own operational resilience framework under PS21/3, with full compliance required by March 2025. The United States is moving in the same direction, though through sector-specific regulators rather than a single equivalent to DORA.

A single thread runs through the global change. Until these rules arrived, the liability for a third-party software failure sat with no one in particular. Vendor contracts disclaimed it, procurement teams rarely demanded proof of recovery, and regulators hadn't drawn a clear line. Read on their own, the four are separate compliance problems. Read together, they close that vacuum by asking every organization the same question.

What each of these rules  is really asking for

Strip away the different names, sectors, and deadlines, and every one of these rules is asking for the same thing: proof that your business keeps running when the software it depends on doesn't. That's the whole game, and it shows up as five shared demands.

• Their risk is now your risk. You can't hand a vendor your accountability along with your data. If a provider you rely on fails or gets breached, regulators treat that as your problem to have planned for.

• A written plan isn't proof. It's no longer enough to say you could recover. You have to show you can. The rules expect continuity that's been documented and tested, because a recovery plan no one has ever run is just a hopeful guess.

• Someone's name is on it. These rules push responsibility up to named executives and board members, who can face personal liability when continuity gaps are found. Compliance stopped being something you could fully delegate downward.

• You have to answer the disappearance question. Regulators want to know what happens if one critical provider vanishes overnight. "It's unlikely" isn't an answer; they expect you to have mapped the dependency and prepared for the day it breaks.

• Every critical dependency needs an exit. For each piece of software your business can't operate without, there has to be a real recovery path: a way to access the code, data, and knowledge to keep going. This is the heart of business continuity software dependency planning.

Seen this way, cyber resilience compliance isn't really about cybersecurity at all. It's about whether you can prove your business survives the loss of something you don't control, and that's a question most companies have never been forced to answer in writing.

Why this matters even if you're not regulated

The reach of these regulations extends well beyond the entities they formally govern. The mechanism is procurement: a regulated bank must demonstrate that its critical service providers can maintain operations under stress, so it writes that obligation into its contracts. Every vendor selling into that bank then inherits the bank's resilience requirements, irrespective of whether any regulator has ever looked at them directly.

The practical effect is that a small software company with a skeleton crew may find itself contractually required to show proof of recovery as a condition of closing an enterprise deal. The obligation doesn't arrive from a regulator; it arrives from a procurement team enforcing its client's obligations downstream. For software vendors, the ability to demonstrate resilience and tested recovery has become a commercial differentiator at exactly the stage where deals are won or lost. For enterprise buyers, requiring it from vendors is simply how they manage their own exposure under the rules that now apply to them.

The broader implication is that resilience compliance is no longer a concern only for regulated industries or large organizations. The supply chains running into regulated entities are long, and the requirements travel their full length. Software escrow and proof of recovery exist precisely to close this gap, for vendors who need to prove it and for buyers who need to demand it.

How to get ahead of cyber resilience compliance

These regulations will reach most organizations eventually, either through direct applicability as frameworks expand or through the procurement obligations of clients who are already in scope. The honest starting point isn't a compliance checklist; it's an accurate assessment of whether you could recover your critical software today, not just whether you believe you could. Most organizations, if pressed, find that belief and reality are further apart than expected.

To get there, you have to close the gap between assuming you can recover and proving it. These five steps work regardless of which rule applies to you.

1. Map your critical software dependencies. List the software your business runs on and who supplies each piece. You can't protect what you haven't named.

2. Find the ones that would stop you tomorrow. Not every dependency is critical. Identify the few whose sudden loss would halt operations, because those are what regulators and clients will ask about.

3. Confirm you could get the code. For each critical dependency, check that you have a real route to the source code, data, and documentation you'd need to keep running without the vendor.

4. Test the recovery instead of assuming it. This is where most plans fall apart. Roughly 90% of untested escrow deposits fail when someone finally tries to use them. That's why Codekeeper offers Verification for all escrow plans.

5. Document the proof before anyone asks. Auditors and clients want evidence, not assurances. Keep dated records showing each critical dependency has been verified and can be recovered.

Run the process, and you get a clear picture of where your exposure sits, and something concrete to show when the question arrives, whether from a regulator, an auditor, or a client's procurement team.

Resilience is now the requirement

The rules that have emerged across the EU, the UK, Australia, and the United States differ by sector and jurisdiction, but they all reach the same conclusion: organizations can no longer treat the failure of critical software as an edge case that someone else is responsible for managing. 

Software resilience compliance, underneath all the acronyms and deadlines, is the formal demand that you answer one question: when the software you depend on fails, can you prove you keep running? The frameworks will continue to evolve, but that question will not change. The organizations that answer it now, with tested recovery and documented proof rather than assurances, are the ones that will find it least disruptive when the requirement reaches them.

»  Take a look at how Codekeeper's Software Escrow helps you satisfy industry compliance requirements.