What NIS2 requires for backup verification

NIS2 is live. The EU Directive on cybersecurity (2022/2555) required member states to transpose it into national law by October 2024. As of early 2026, most have. Some are still catching up (the Commission sent reasoned opinions to 19 member states for non-transposition in 2025). But the directive's obligations are in force regardless. If your company is classified as an "essential" or "important" entity, Article 21 applies to you now.

One of the measures Article 21 names explicitly is backup management. The obligation is framed as "appropriate and proportionate" (the directive is deliberately not prescriptive about how), but backup management is named, and penalties for inadequate measures are real: up to EUR 10M or 2% of global turnover for essential entities.

This guide focuses on one slice of the NIS2 backup obligation: database backup verification. NIS2's scope is broader (file systems, configurations, identity systems, VM images, secrets all fall under backup management), but database restores are where I have the most operational experience and where the verification gap is sharpest. If you want the regulatory context before making a decision about your database backup strategy, this is for you.

What Article 21 says

NIS2 Article 21(2) lists the minimum cybersecurity risk-management measures that essential and important entities must implement. The relevant sub-paragraphs:

• Article 21(2)(c): "business continuity, such as backup management and disaster recovery, and crisis management." Backups are named as a component of business continuity. Not optional. Not "recommended." Named.
• Article 21(2)(f): "policies and procedures to assess the effectiveness of cybersecurity risk-management measures." This is the one most teams miss. Having backups is not enough. You must assess whether they work. That means testing. Regularly.

Read those two sub-paragraphs together: you need backups (c), and you need to test that they work (f). The combination is what auditors will enforce.

Who does this apply to?

NIS2 classifies entities as "essential" or "important" based on sector and size. The directive covers sectors including energy, transport, banking, financial market infrastructure, health, drinking water, digital infrastructure, ICT service management, and public administration.

The size threshold: medium-sized enterprises and above (50+ employees or EUR 10M+ annual turnover). But member states can designate smaller entities if they provide critical services.

If you run infrastructure for a SaaS in one of these sectors, or you provide managed services to companies in these sectors, you are likely in scope. The safe assumption: if you are reading this and you operate in the EU, check whether your national transposition lists your sector.

What auditors look for

An auditor assessing your backup posture will not ask "do you have backups?" They know you do. Every managed database provider runs automated backups. The green checkmark on your Neon or Supabase dashboard is not what they are interested in.

They will ask:

1. When was the last time you tested a full restore? Not a logical replica. Not a point-in-time recovery to a staging environment. A cold restore from a backup artifact into a fresh, isolated environment. If the answer is "never" or "during our last migration," expect follow-up questions. NIS2 enforcement is still maturing and national supervisors vary, but the trajectory is clear: untested backups are increasingly hard to defend as "appropriate."
2. Show me the evidence. A Slack message that says "restore worked" is not evidence. A monitoring dashboard that says "backup job succeeded" is not evidence of a restore. They want a dated artifact that documents: what was restored, where, when, whether application-level checks passed, and who can verify this independently.
3. How often do you test? A restore test from 2023 does not prove your backups work today. Schemas change. Extensions drift. Collation settings break silently after OS upgrades. The restore test needs to be recent and recurring.
4. Who holds the encryption keys? If your backup provider holds the keys, a provider-side breach exposes your backup data. Auditors increasingly ask about key management as part of the backup posture review.

How this maps to other frameworks

NIS2 does not exist in isolation. If you are already certified or working toward one of these frameworks, the backup verification requirement overlaps:

• ISO 27001, Annex A control A.8.13 (Information backup): "Backup copies of information, software and systems shall be maintained and regularly tested in accordance with the agreed topic-specific policy on backup." The "regularly tested" clause is the operative phrase. Having backups satisfies half the control. Testing restores satisfies the other half.
• SOC2, Trust Services Criteria A1.2 and A1.3 (Availability): A1.2 requires backup processes and recovery infrastructure designed to meet recovery objectives. A1.3 requires testing recovery plan procedures, including backup integrity and completeness, "using realistic scenarios." Together they mean: have backups, test them, and keep evidence of the tests.
• DORA, Articles 11 and 12 (ICT business continuity and backup): For EU financial entities, DORA Article 11 requires testing business continuity plans "at least yearly" and after "substantive changes," including cyber-attack scenarios. Article 12 goes further: it requires periodic testing of backup procedures and restoration methods, with recovery into systems "physically and logically segregated from the source" and post-recovery integrity checks. DORA entered application in January 2025.
• BSI C5 (German Cloud Computing Compliance Criteria Catalogue): OPS-04 and related controls require documented and regularly tested backup and restore procedures. Relevant for selling into German public sector and regulated markets.

The pattern across all of these: having backups is necessary but not sufficient. Testing restores is the control. Evidence of the test is what auditors verify.

What "good" looks like

A backup posture that satisfies NIS2 Article 21 (and the related frameworks above) has four properties:

1. Automated, scheduled restore tests. Not ad-hoc. Not "we tested once." A recurring schedule that runs a full restore from a backup artifact into an isolated environment. NIS2 does not specify a frequency. ISO 27001 says "regularly." DORA says "periodically" with annual minimums for BCP testing. For most non-financial entities, monthly or quarterly is defensible. Weekly is better if you can automate it, because schemas drift faster than you think.
2. Application-level verification. pg_restore succeeding is necessary but not sufficient. The restored database should pass schema assertions: expected tables exist, row counts are within bounds, required indexes are present, NULL constraints hold. Your application's invariants, not the database engine's.
3. Independently verifiable evidence. Each restore test produces a dated, structured artifact that records what was tested, the outcome, and who can verify it. "The monitoring was green" is not independently verifiable. A signed receipt that a third party can validate against a public key, without needing access to your infrastructure, is.
4. Customer-held encryption keys. Backup data encrypted with keys you control, not keys your provider controls. If the provider is breached, your backup data remains ciphertext. This is not a NIS2 explicit requirement, but it is a best practice that aligns with NIS2's risk management intent and increasingly shows up in audit questionnaires.

What this guide does not cover

This is a database-shaped view of a broader requirement. Three things that matter for NIS2 backup compliance that I have not covered here:

• Immutability and air-gap. A verified backup that an attacker can delete is still gone. Ransomware resilience depends as much on backup immutability (write-once storage, offline copies, network isolation) as on restore verification. ENISA's threat landscape reports consistently rank ransomware at the top. If you are designing backup architecture, immutability deserves at least as much attention as verification.
• Supply chain risk (Article 21(2)(d)). Your backup vendor's security posture is your problem under NIS2. If a third party stores or processes your backups, their risk profile feeds into yours. Key management (who holds the keys?) is one piece of this, but vendor due diligence, contract terms, and incident notification obligations are also in scope.
• Management accountability (Article 20). NIS2 requires management bodies to approve and oversee cybersecurity risk-management measures, including backup. Backup decisions now need documented management sign-off, not just an ops team running a cron job. If your backup policy is undocumented tribal knowledge, Article 20 is the reason to write it down.

The gap most teams have

Most teams I talk to have backup automation. A cron job writes pg_dump to S3. The managed database provider runs nightly snapshots. The monitoring says green.

What they do not have:

• A record of the last time someone ran pg_restore against a backup.
• Evidence that the restore produced a usable database.
• An artifact an auditor can verify independently.
• Confidence that the backup from last Tuesday would restore today.

The gap is not backup. The gap is verification. The green checkmark means the upload succeeded. It does not mean the restore will succeed at 3 AM when the schemas have drifted and the collation settings have changed.

If your auditor asks "show me your last restore test and the evidence it passed," and you cannot answer within 30 seconds, that is the gap NIS2 Article 21 is designed to close.

What to do about it

Three options, from least to most effort:

1. Manual quarterly restore tests. Schedule a calendar reminder. Pull a backup. Run pg_restore into a throwaway instance. Document the result. Low cost. High discipline required. Most teams attempt this and stop after the second quarter.
2. Script it yourself. Write a CI job or cron task that pulls a backup, restores it, runs assertions, and writes a log. More reliable than manual testing. Maintenance cost scales with the number of databases and the complexity of your checks. Most teams build this for one database and never extend it.
3. Use a purpose-built tool. Automated restore tests, application-level checks, signed evidence artifacts, recurring schedule. Higher upfront cost. Lower maintenance. The evidence trail is the deliverable, not a side effect.

Restorable is the tool we built for option 3. Open-source agent, EU-sovereign infrastructure, customer-held encryption keys. Each restore test produces a signed receipt your auditor can verify independently. But regardless of which option you pick, the important thing is that you pick one before your next audit.