Don't make it easy for non-compliance: Prove your recovery ahead of time

Security compliance is often seen as necessary busywork, something to check off your list so you can get back to the business operations that really matter to you. There’s always another tedious security questionnaire to fill in, and another annual audit disrupting your sprints just when the roadmap was finally moving.

Problem is, the proof most businesses use to check off their compliance requirements doesn’t hold up the way they think it will. Security questionnaires, SOC 2 reports, and penetration test results approximate how safe a new supplier, a new tool, or a new home for your critical data really is. But it’s often still a hedged bet.

And the regulators behind those requirements aren’t playing around. If you fall short, you could face millions in fines, or even be banned from operating in a market altogether.

This post is part of a series exploring this year’s Cybersecurity Awareness Month themes, and covers why non-compliance should be seen in the same light as any security risk, why a continuity clause won’t keep you compliant, and what proof of recovery really looks like.

A continuity clause is only a promise

When you bring a new software provider on board, you push for a continuity clause that commits them, in writing, to data exports, disaster recovery assistance, and other contingencies for if they ever go down. That’s good practice. It’s a step toward securing the longevity of your business, and it keeps your assessors happy, especially in a regulated market.

But in the end, all that clause really is, is a promise. The kind of incidents that wipe a provider out usually take all the support you negotiated for with it. Sure, you might get some recompense. But a payout won’t bring critical customer data back, or win back the reputation you lose to days of downtime. And it certainly won’t satisfy an auditor who expected your operations to keep running no matter what happens.

And if you’re on the other end of that deal, in the vendor seat, so to speak, sometimes you can’t honor a continuity clause through no fault of your own. You sit right in the middle of a string of services. When one lets you down, your compliance obligations go out the window, and you let your customers down. Telling them “it’s not our fault” doesn’t undo the fact that their operations stopped too, or that they’re now absorbing their own downtime damages and non-compliance. Being the middleman just adds liability from both sides.

» See what happened to the vendors caught in the middle when Synapse collapsed.

Compliance now means proving you can recover

Frameworks worldwide have caught on that questionnaires, clauses, and written policies aren’t curbing supply chain cascade damage, customer data loss, or costly breaches the way they should. So regulators are drawing a harder line in the sand. They don’t just want you to stop bad things from happening anymore. They expect you to bounce back after something terrible does.

Frameworks written for software security compliance spell that expectation out directly, and they back it with real penalties.

• DORA, the EU’s Digital Operational Resilience Act, exists so financial firms can withstand, respond to, and recover from disruption, and it requires them to restore backups on systems segregated from the source systems. Each member state sets the penalties, which can reach the management body.

• NIS2 makes backup management and disaster recovery part of the minimum cybersecurity measures for essential and important entities in the EU. Member states have to set maximum fines for essential entities of at least €10 million or 2% of worldwide annual turnover, whichever is higher.

• Under SS2/21, the UK’s Prudential Regulation Authority (PRA) expects banks and insurers to develop, maintain, and test a business continuity plan and an exit strategy for every material outsourcing arrangement, and it warns that negotiating audit rights isn’t enough unless they’re used. Breaches of PRA rules can bring fines, public censure, and restrictions on the firm.

• The HIPAA Security Rule requires US healthcare organizations and their business associates to keep a data backup plan, a disaster recovery plan, and a plan for running critical processes in emergency mode. Civil penalties for the most serious violations reach $2,190,294 each.

Fines are only one kind of penalty. Under NIS2, an essential entity that keeps falling short can have its certification or authorization suspended for part or all of its services, and its CEO temporarily barred from managing it.

» Assess which compliance frameworks apply to your business and what they expect you to prove.

Paper compliance falls apart the moment it’s tested

None of these penalties are empty threats. Regulators are already enforcing the shift toward proven recovery, and they don’t wait for an attack, a breach, or a failure to do it.

The Australian Securities and Investments Commission (ASIC) took that shift to court this year. Its case against FIIG Securities, a fixed-income investment firm, is a warning lesson against resilience planning that focuses too much on possibilities and promises. FIIG promised its clients secure computer systems and kept written security policies, but it never fully put those policies, or its own risk controls, into practice.

For more than four years, it ran no vulnerability scans, and until early 2023 it had no tested plan for getting its systems back to normal after an incident. The first real test came from an attacker in May 2023, who downloaded around 385GB of data, including client personal information.

In February, the Federal Court ordered FIIG to pay a penalty of A$2.5 million, about 8% of its annual turnover. The court also ordered FIIG to bring in an independent expert, agreed with ASIC, to set out what its cyber resilience still needs and confirm it all gets done. The policies existed the whole time. FIIG just couldn’t show that any of them worked in practice.

Not every penalty needs an incident to expose the problem first.

In September, Honeywell Aerospace agreed to pay $2,042,518, with no finding of liability, to settle allegations that one of its networks fell short of a Department of Defense contract’s cybersecurity standard from 2020 to 2023. The case started with a former employee’s whistleblower lawsuit.

Put the two cases side by side, and they share the same weak point. Both companies had security commitments on paper that looked fine until they were put to the test or scrutinized more closely. If your security compliance rests on boilerplate continuity clauses, you might want to put it through a stress test.

Give both sides of the relationship a way back

All software security frameworks call for backups and disaster recovery — it’s the baseline. But running them entirely in-house is where things get shaky. An untested recovery plan can’t tell you how long recovery takes or whether your lined-up alternative vendors will work, and an attacker who reaches your systems will target the backups connected to them too.

So if compliance best practice technically falls short of newer regulatory requirements, what exactly are you expected to do?

You need a foolproof way back to fully functioning systems without data loss, independent of a software supplier’s cooperation. That’s a tall order, but the solution is simpler than you might think.

Software escrow sets up an agreement with a neutral third party like Codekeeper to hold live copies of critical software, the data that runs through it, and, for cloud platforms and AI models, the environments and materials that support them. Those copies sit in vaults protected by AES256/512 encryption and stay current through 50+ integrations.

If something goes wrong, those materials are released to the software user, who can rebuild and host the application in-house. That matters because continuity, by its definition, expects software to keep working no matter what happens.

Let’s take a closer look at what that offers both sides of a software relationship.

Users keep running when a vendor can’t

If you rely on someone else’s software, escrow turns your continuity clause into something you can act on.

• Recover critical systems in-house when a release condition like insolvency or discontinued support is met.

• Get the whole working setup back, including the data, configurations, and credentials cloud software needs.

• Keep serving your own customers, so their operations don’t stop because a provider’s did.

• Give your continuity and exit plans the guaranteed access to software and data regulators expect.

Vendors clear security reviews with continuity already covered

If you supply the software, the same agreement settles one of the toughest questions in every security review.

• Secure your customers’ continuity even after you’re gone, which covers what their regulators expect of suppliers.

• Clear security reviews and procurement faster, because prospects see continuity handled before they sign.

• Keep your source code and IP protected, released only under conditions both sides agreed to.

• Give your own auditors evidence that the continuity in your customer contracts is real.

Either way, both sides end up relying on the same deposit, which is exactly why it has to hold up the day someone finally opens it.

Turn the promise of recovery into proof

Putting recovery materials in a neutral party’s custody means, in theory, that nothing happening inside either company, like a breach or a ransomware attack, can touch your ability to recover and stay compliant. But it’s still just a promise that a recovery is possible. And regulatory bodies don’t deal in promises anymore.

That’s why Codekeeper offers Software Verification to prove a recovery ahead of time. Our engineers take the assets in the deposit, build and deploy the software in an isolated, clean environment, and test that it runs, all without the vendor’s input. That includes technical build reviews, full reproducibility tests, and an annual expert review.

An Exit Exercise goes further for complex architectures, matching the environment to production and testing features based on actual usage. It leaves you with evidence no clause can give you: a working example of the software brought back as though the vendor were already gone.

Every step is documented as software resilience evidence that you can hand to auditors, procurement teams, and boards to back your own compliance case.

Make practiced recovery part of your security compliance

If you’re found non-compliant, you can be hit with fines or market bans that can shut down your business just as surely as any cyberattack or broken system. So be careful how you choose to tick off your security compliance.

It tends to look a lot less like a checkbox, and much more like a safety net when you’re looking at a verified rebuild.

Whether you build software or rely on it, getting compliance in place that won’t buckle under pressure starts with a software escrow agreement and a deposit you’ve had verified.

Keep an eye out for the next post in this series, on broken code and why untested deposits fail when you need them.

» Back your security compliance with proven recovery through Codekeeper’s verified Software Escrow, so you’re ready whenever someone asks for proof.