Backup and DR selection: the criteria that matter under NIS2 and DORA

Why it matters

The recovery point objective is how much work you lose. A nightly job means a full day of transactions gone; a database that changes every second needs minutes, not hours. The interval a product can actually sustain differs by workload type: what works for a file server may be impossible for a busy database or a SaaS mailbox, and the marketing number is the best case across all of them.

Why it matters

Recovery time scales with data volume, network throughput and the number of systems that must come back in parallel. A demo restores a small virtual machine in minutes. Your tier one systems are terabytes with dependencies, and fifty of them queue behind one appliance. DORA expects recovery objectives that the entity can actually meet, which means measured at your scale, not on a slide.

Why it matters

Modern ransomware operators do not encrypt production first. They find the backup console, use stolen admin credentials to delete or expire the copies, and only then encrypt. A backup that an administrator can shorten, delete or overwrite is not immutable, and an isolated copy is only isolated if the path, the credentials and the console that manages it are outside the blast radius of a production compromise. NIS2 Art. 21 names backup management as a required measure, and a backup the attacker can erase does not meet the intent.

Why it matters

A backup product that does not cover one of your workload types leaves that type with no backup at all. Virtual machines are the easy case; databases with application consistency, containers with persistent volumes, physical hosts and above all SaaS platforms are where coverage thins out. SaaS runs under a shared responsibility model: the provider keeps the service available, you are responsible for your data, and a deleted mailbox or compromised account can wipe records the provider is not obliged to bring back.

Why it matters

Backup data grows faster than production data because retention multiplies it. Global deduplication and compression decide whether three years of copies fit into the storage you budgeted or three times that. The ratio the vendor quotes was measured on a favourable data mix; encrypted, compressed or media-heavy data barely deduplicates, and a ratio measured at a small scale often collapses at yours.

Why it matters

A backup that has never been restored is a hope. Silent corruption, missing application consistency, expired keys and forgotten dependencies only show up when someone actually restores. DORA Art. 11 expects business continuity plans to be tested, and NIS2 Art. 21 expects backup management to be effective, which an untested backup cannot be shown to be. Tests that disrupt production do not get run, so the test has to be non-disruptive and scheduled.

Why it matters

A copy in the same building, the same cloud region or the same account shares the fate of the original. Cross-site or cross-cloud replication is what makes a site loss, a regional outage or an account takeover survivable. Whether replication is synchronous or asynchronous decides how much you lose on failover, and whether failover is automated decides whether it happens at 3am or after someone finds the runbook.

Why it matters

Most restores are not disasters. They are one deleted file, one mailbox item, one dropped table, one virtual machine that has to be up in ten minutes. If every small restore requires bringing back a whole volume or a whole database, the daily recovery work eats operating time and the small incident becomes a big outage. Instant mount of a snapshot as a running system is what makes granular recovery fast.

Why it matters

After an attack you cannot restore into the compromised network, because the attacker's persistence comes back with it, and you cannot restore the latest copy, because it may already contain the malware. You need to find the last clean recovery point and an isolated environment to restore into, scan, verify and only then reconnect. DORA Art. 12 expects restoration to use systems that are segregated from the source system, and NIS2 Art. 21 expects crisis management that works in practice, not on paper.

Why it matters

A disaster recovery is dozens of systems that must come back in the right order, with the right network settings, the right IP addresses and the right dependencies. If that order lives in someone's head or in a document last updated two years ago, the recovery takes days. Orchestration turns the runbook into something the product executes and tests, and it is the difference between the recovery time you measured for one system and the one you will get for the estate.

Why it matters

A backup job that has been failing silently for three weeks is discovered on the day you need it. Monitoring has to tell you about failed and missed jobs, shrinking success rates and growing restore times before they matter, and the report has to prove to an auditor that the backup policy was actually met over time. NIS2 and DORA both ask for evidence, and the evidence is the trend, not today's dashboard.

Why it matters

Most estates are hybrid: virtual machines on premises, workloads in two hyperscalers, SaaS on top. If each environment needs its own backup tool with its own policy engine, you cannot prove one retention policy across the company, and the environment added last gets the weakest protection. One policy applied uniformly is what makes the compliance story simple.

Why it matters

Backups are the most complete copy of your organisation in one place. GDPR Art. 32 expects appropriate technical measures, and encryption is the obvious one. But encryption only protects you if the vendor cannot decrypt your copies without you, and it only helps in recovery if you can still reach the keys after your key management system is itself part of what was lost.

Why it matters

Every backup product costs people. Policies to maintain, agents to update, storage to expand, failed jobs to chase, restore requests to serve. At small scale that is a side task; at a thousand workloads it is a team, and the product that saves storage but needs two more administrators is not cheaper. The staffing the product needs at your target scale is part of its price.

Why it matters

Backups collide with change. A full backup during a database migration, a restore request that nobody tickets, a retention change that is not in the change log: each is a small gap in the evidence chain that an auditor will find. Integration with your ITSM turns restore requests into tickets with approvals and makes the backup system aware of change and maintenance windows instead of running into them.

Why it matters

Backup data grows faster than production data because retention multiplies it, and the storage bill grows with it. The three-year cost is the license plus the storage at year three volume, plus the immutable tier, plus the isolated copy, plus the egress fees for the large restore you will one day run. The cheapest quote today is often the most expensive contract by year three.

Why it matters

Where the copies sit is only half the question. The control plane that schedules jobs, holds metadata, catalogs file names and issues restore commands is often a global service, even when the copies and replicas are in an EU region. Backups contain every personal record you hold, so GDPR Art. 28 and the transfer rules apply to the copies, the replicas, the catalog and the support access to all three.

Why it matters

Backups have to remain restorable for as long as your retention obligations run, which can be years after you leave a vendor. If the copies are in a proprietary format that only the vendor's software can read, your exit costs are the whole retention window, not just the migration, and the egress bill for moving petabytes out is the second lock. DORA Art. 28 expects exit strategies for ICT services supporting important functions; backup is one of them.

Why it matters

The attacks on backups change every year, and so do the workloads you need to protect. A vendor whose roadmap is about dashboards while attackers target backup consoles, or whose cloud-native and SaaS coverage trails what you deploy, will be the wrong product in two years even if it is the right one today. The roadmap is part of the evaluation because the contract runs for three years.

Why it matters

The recovery times you measured in the pilot are your evidence; what the vendor commits to in writing is your protection. DORA expects recovery objectives that the entity can meet, and a supervisor will ask what the provider owes you if the restore fails or takes three times as long. A ransomware recovery guarantee with a payout ceiling and a page of exclusions is a marketing instrument, not a commitment.

Why it matters

Backup licenses are priced per protected terabyte, per workload or per virtual machine, and each model rewards a different estate. Capacity pricing punishes growth and long retention; per-VM pricing punishes many small systems; per-workload pricing is only cheap if the workload definition matches yours. The model that is cheapest at today's estate is often the most expensive at the estate you will have in year three.

Why it matters

The license is the predictable part of a backup bill. The unpredictable parts are egress fees when you restore or leave, snapshot storage that accumulates in the cloud account outside the backup product's own accounting, and retention tiers whose price per gigabyte changes when data ages. A budget that only contains the license will be wrong in the first year.

Why it matters

The quoted annual price at your current data volume is the number the board compares. It is only comparable between vendors if each quote covers the same scope: the same protected volume, the same retention, the same immutable and isolated copies, the same SaaS sources and the same support level. A quote that is 30 percent lower usually protects 30 percent less.