Does NIS2 Require Encrypted Backups? CIR Annex 4.2 Never Says ‘Encrypt’ — Annex 9.2(a) and the Classification Level Decide It

Short answer: not in so many words. Point 4.2 of the NIS2 Implementing Regulation, the backup point, never uses the word “encrypt”. What it asks for, in 4.2.2(d), is “appropriate physical and logical access controls to backup copies, in accordance with the asset classification level”. The encryption duty arrives from a different chapter. Point 9.2(a) tells you to set “the type, strength and quality of the cryptographic measures” for each classification level, “including data at rest”. A backup is data at rest. So the answer for your backups is the answer your cryptography policy already gives for the data inside them.

That shifts the real question. You aren’t asking “does NIS2 say encrypt backups?” You’re asking which classification level the data in each backup carries, and what your policy prescribes for that level. The rest of this guide follows that chain, the key-management trap that can make an encrypted backup unrecoverable, and the separate GDPR reason to encrypt.

One disclosure: we sell NIS2 templates, including a business continuity pack with a backup policy. Weigh the product mention below with that in mind. Everything else here is sourced to the Official Journal text, ENISA, the EDPB or Germany’s BSI.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Does this apply to you? Scope first

In plain terms: every NIS2 entity needs backups and a cryptography policy. Only eleven types of digital-sector entity are bound by the detailed Annex wording quoted below. For everyone else, national law is the legal test and the Annex is the most detailed reference point available.

Article 21(2) of the NIS2 Directive lists “business continuity, such as backup management and disaster recovery, and crisis management” as point (c) and “policies and procedures regarding the use of cryptography and, where appropriate, encryption” as point (h). Article 21(1) frames both as “appropriate and proportionate” measures. The detail sits in Implementing Regulation (EU) 2024/2690 (the CIR), and its Article 1 limits it to a named list of entity types.

Your organisation	What governs backup encryption	The legal test
DNS service provider, TLD registry, cloud, data centre, CDN, managed service provider, managed security service provider, online marketplace, search engine, social networking platform, trust service provider	CIR Annex points 4.2.2(d), 9.1, 9.2 and 12.1 apply directly	The Annex text, plus national supervision
Any other essential or important entity (energy, health, manufacturing, transport and so on)	Article 21(2)(c) and (h) as transposed into national law	Your national law. The Annex is a strong reference, not the binding text
Organisation outside NIS2 scope	No NIS2 duty; GDPR Article 32 may still apply to personal data in backups	GDPR and any sector rules

Note: national transposition laws can add detail or stricter rules. Confirm with your national competent authority.

Where “encrypt” actually appears: a word count

In plain terms: the CIR uses the word “encryption” twice in its whole text, and neither time in the backup rules. “Cryptographic” language is concentrated in chapter 9.

We counted every occurrence over the full Official Journal text of the CIR. The results explain why vendor articles disagree: the backup chapter and the cryptography chapter never cross-reference each other.

Where	Wording (verbatim)	Binding?
CIR Recital 25 (asset management)	measures “such as encryption, access control …, backups, logging and monitoring, retention and disposal”, applied by risk level	No. Recitals explain intent; they do not create obligations
CIR Annex 11.4.2(c)	“protect access to system administration systems through authentication and encryption”	Yes, but it covers admin access, not stored backup data
CIR Annex 9.2(a)	“cryptographic measures … including data at rest and data in transit”, set “in accordance with the relevant entities’ classification of assets”	Yes. This is the route to backups
CIR Annex 12.3.2(d)	“where appropriate”, cryptographic techniques “to protect data on removable storage media”	Yes, qualified by “where appropriate”
CIR Annex 4.2 (backup and redundancy)	None. 4.2.2(d) asks for access controls by classification level	Yes, with no encryption wording
NIS2 Article 21(2)(h)	“cryptography and, where appropriate, encryption”	Yes, as transposed nationally

Read the Directive line carefully. Some backup vendors quote Article 21(2)(h) and conclude that “backups must therefore be encrypted”. The provision’s own qualifier, “where appropriate”, is exactly what that conclusion skips. Nothing in the Directive or the CIR makes encryption of every backup copy automatic. What the CIR does make automatic is a documented decision.

So point 4.2 leaves the encryption decision to you, and an auditor will look for where you made it. If your backup policy is silent, the answer has to be findable in your cryptography policy, mapped to the classification of the data being backed up.

The three-step chain: 4.2.2(d) → 12.1.2 → 9.2(a)

In plain terms: the backup point hands the decision to your classification scheme, and your classification scheme hands it to your cryptography policy. Follow the three links and the answer for each backup set falls out.

1. Point 4.2.2(d) requires “appropriate physical and logical access controls to backup copies, in accordance with the asset classification level”. The protection follows the classification, not the storage medium.
2. Point 12.1.2(b) requires you to “associate all assets with a classification level, based on confidentiality, integrity, authenticity and availability requirements”. Point 12.1.1 says this covers “all assets, including information”. In practice, a backup takes the highest classification of the data it holds.
3. Point 9.2(a) requires the cryptography policy to set, “in accordance with the relevant entities’ classification of assets”, the cryptographic measures for “data at rest and data in transit”. Point 9.1 ties the policy to protecting “the confidentiality, authenticity and integrity of data”.

Notice that 9.2(a) carries no “where appropriate”. You must define a measure for each classification level. “No encryption” can be a defensible entry for public or low-confidentiality data. But it has to be the policy’s answer, not an accident of the backup tool’s default settings.

What the chain typically produces for a four-level scheme is shown below. It is an interpretation, not Annex text. Your own levels and risk assessment decide the entries.

Classification of data in the backup	Typical 9.2(a) entry for data at rest (interpretation)	What 4.2.2(d) access control adds
Public	Encryption optional; integrity protection (hashes) still useful	Write and delete rights restricted to backup admins
Internal	Encryption usually expected once a copy leaves your premises	Role-based access, separate backup admin accounts
Confidential (incl. most personal data)	Encryption at rest and in transit, with approved algorithms under 9.2(b)	Restricted admin group, logged access, key custody separate from backup operators
Restricted / critical	Strong encryption plus documented key escrow and recovery	Dual control for restores and for key access

Most organisations’ backups mix levels. A single nightly image of a file server or database usually contains confidential data, which pulls the whole backup set to that level. Our guide to building a data classification policy covers how to set the levels in the first place.

Where encryption becomes hard to avoid

In plain terms: the moment a backup copy leaves your own controlled network, which point 4.2.2(c) effectively requires, access controls alone get much harder to show.

Point 4.2.2(c) asks you to store backup copies “(online or offline)” in a safe location that is “not in the same network as the system” and far enough away “to escape any damage from a disaster at the main site”. That off-site copy usually sits in a cloud storage account, a second data centre or on tape in someone else’s vault. Whether a copy inside the same cloud tenant counts as “not in the same network” is its own question, covered in our Microsoft 365 Backup “same network” analysis. Once a copy is off-site, three more Annex points reach it:

Backup copy	Annex points that reach it	Practical reading
Copy replicated to cloud storage or a second site	4.2.2(c), 9.2(a) “data in transit”, 12.2.2(c) secure transfer “in accordance with the type of asset”	Encrypt in transit; encrypt at rest wherever the provider’s staff or tenants could reach confidential data
Tape or removable disk moved off-site	12.3.2(c) protect portable storage “in transit and in storage”; 12.3.2(d) cryptography “where appropriate”	A lost tape of confidential data is hard to defend without encryption
Immutable or air-gapped copy	4.2.2(d) access controls; 4.2.3 integrity checks	Immutability protects integrity and availability, not confidentiality. It does not replace encryption

ENISA’s technical implementation guidance points the same way. Its examples of evidence for 4.2.2 include “Backups physically separated and with an appropriate level of protection, including encryption”, and a cloud tip says backup data should be encrypted at rest using cloud-native key management and in transit using TLS 1.2 or later. Keep the status of that text straight. ENISA states that this part of the guidance “is not legally binding and is only recommendations”. Treat it as what supervisors are likely to expect, not as the rule itself.

For the wider 4.2 picture, including RPO and RTO targets and testing cadence, see our NIS2 backup policy and recovery requirements guide.

The trap: encryption that blocks your own recovery

In plain terms: an encrypted backup whose key was stored next to it, or lost with it, is a backup you cannot restore. The CIR’s key-management list exists partly to stop that.

Chapter 9 mentions backups exactly once, and it is about keys rather than data. Point 9.2(c) lists key-management methods to include “where appropriate”, among them “(viii) recovering lost or corrupted keys” and “(ix) backing up or archiving keys”. ENISA’s tip under 4.2 is direct: “Encryption keys should be stored separately from the backup data to prevent unauthorized access and ensure recoverability.” Its chapter 9 guidance adds key escrow as a way to keep information available if keys are lost.

Germany’s BSI backup module CON.3 describes the failure in one sentence: an encrypted backup becomes unrecoverable when the decryption key is hit by the same data loss, which happens “if no one thought of storing the key separately” (our translation).

Run this check against your own setup. Assume ransomware has encrypted your primary site, including the domain controllers and the server that holds your key management system. Can a named person restore the most critical backup from scratch? To do it, they need the key or key-recovery material, the software and the procedure, without using anything that sat in the compromised network. Point 4.2.6 requires recovery tests to cover “the copies, processes and knowledge to perform an effective recovery”. If your restore test never includes the decryption step from escrowed keys, it has not tested that knowledge.

Two more rules apply here. If you decide a “where appropriate” key method doesn’t fit your organisation, CIR Article 2(2) requires you to “document its reasoning” in a comprehensible manner. And 9.3 asks you to review the policy “taking into account the state of the art in cryptography”, so algorithm choices for backups kept for many years need a review date.

The GDPR payoff: why encrypted backups change breach notification

In plain terms: if backups hold personal data, encryption is the difference between a breach you document internally and a breach you may have to tell every affected person about.

GDPR Article 32(1) lists “the pseudonymisation and encryption of personal data” among the measures to apply “as appropriate”. More useful for a board is Article 34(3)(a). Communication to data subjects is not required where the data was protected by measures that “render the personal data unintelligible to any person who is not authorised to access it, such as encryption”.

The EDPB’s breach-notification examples (Guidelines 01/2021) show the effect with three cases:

EDPB case	Facts	EDPB conclusion
No. 01: ransomware with proper backup	Data encrypted at rest with a state-of-the-art algorithm, key not compromised, no exfiltration, restored from backup within hours	No notification to the supervisory authority and no communication to data subjects; the breach is still documented under Article 33(5)
No. 10: stolen encrypted devices	Encrypted tablets stolen; backup “effectively and readily available”	No notification needed, but the breach must be documented under Article 33(5)
No. 11: stolen unencrypted laptop	Personal data of more than 100,000 customers, no encryption; daily backups available	Notification to the authority and communication to data subjects required

Case 11 shows that having a backup protects availability, not confidentiality. A stolen backup copy has the same confidentiality problem as Case 11’s laptop. Encryption with an uncompromised key is what moves it toward Case 10. NIS2 incident reporting runs on its own criteria, so encryption does not by itself settle whether an incident must be reported to the CSIRT or authority. Our guide to ransomware reporting obligations covers that side, and our NIS2 vs GDPR comparison covers how the two regimes overlap.

How a national authority draws the line: BSI CON.3

The BSI’s backup module uses the same logic as the CIR, with the tiers spelled out. It is a German standard rather than EU law, but it is a useful benchmark for where a supervisor might draw the line.

CON.3 tier	Requirement	Encryption?
Basic (A14, “MUST”)	Backups must be protected against unauthorised access and accidental or deliberate overwriting	Not named
Standard (A9, “SHOULD”)	Contracts for online backup storage should cover encryption on the storage and in transit	Yes, for third-party online storage
Increased protection need (A13, “SHOULD”)	IT operations should encrypt all backups, keep them restorable over long periods, and protect keys with a separate backup	Yes, all backups

The pattern matches the CIR chain: access protection for everything, encryption once data leaves your control, and full encryption where the protection need is high. The BSI also says the high-protection measures are decided “within an individual risk analysis” (our translation). That is the same instruction CIR 9.1 gives when it ties cryptography to “the results of the risk assessment”.

What to write down, and who owns it

Different readers need different things from this.

Role	What to do
CISO / IT security	Map every backup set to the highest classification it contains. Set the 9.2(a) measure per level, and store keys outside the backed-up environment. Include decryption from escrowed keys in the 4.2.6 restore test.
Compliance officer	Make sure the backup policy references the cryptography policy (or states the encryption rule itself). Record the Article 2(2) reasoning for any “where appropriate” item you skip. Keep restore-test records that show the decryption step.
SME owner	Ask one question: “If our backup drive or cloud account were stolen tomorrow, could anyone read it?” If the answer is yes and it holds customer or staff data, budget for encryption and key escrow first.
Board / management body	Treat backup encryption as a breach-impact control. It can change the GDPR notification outcome (EDPB Cases 01, 10, 11). Article 20 of NIS2 makes management bodies approve and oversee these measures.

Evidence an auditor can reasonably ask for:

1. Backup inventory showing each backup set’s classification level (12.1.2(b), 4.2.2(d))
2. Cryptography policy entries for data at rest per classification level, with approved algorithms (9.2(a)–(b))
3. Key-management procedure covering key backup, recovery and separation from backup data (9.2(c)(viii)–(ix))
4. Restore-test reports that include decryption and key retrieval (4.2.6)
5. Documented reasoning for any skipped “where appropriate” measure (CIR Article 2(2))

For the full chapter 9 control set behind these entries, see our guide to NIS2 cryptography and encryption obligations. For how backups fit the wider continuity programme, see our NIS2 business continuity guide.

Frequently asked questions

Does NIS2 require encrypted backups?

Not as a blanket rule. The backup point, CIR 4.2.2(d), asks for access controls matched to the asset classification level. Point 9.2(a) then requires your cryptography policy to set measures for data at rest by classification level. For backups holding confidential data, that usually means encryption. For low-classification data, it can legitimately mean none.

Is an immutable backup enough without encryption?

No, they answer different risks. Immutability stops deletion and tampering (integrity and availability). It does nothing for confidentiality if the copy is stolen or read by someone with storage access. ENISA lists immutable backups as an integrity measure and encryption as a separate protection.

Where should backup encryption keys be stored?

Separately from the backup data and outside the environment being backed up. ENISA’s 4.2 tip says this directly, and BSI CON.3.A13 says keys should be protected by a separate backup. Your 9.2(c) key-management procedure should name the location, the custodians and the recovery method.

Does encrypting backups mean we never have to report a breach?

No. Under GDPR, Article 34(3)(a) can remove the duty to tell data subjects if the data was unintelligible and the key was not compromised. You still document the breach under Article 33(5), and whether the authority must be told still turns on a case-by-case risk assessment, as in EDPB Case 01. NIS2 incident reporting follows separate criteria.

We’re not a digital-infrastructure entity. Does the CIR apply to us?

Not directly. CIR Article 1 limits the Annex to eleven entity types. Other essential and important entities answer to Article 21(2)(c) and (h) as transposed into national law. National authorities and auditors often use the Annex as a reference anyway.

Sources

1. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 — EUR-Lex, Official Journal text. Articles 1 and 2(2); Recital 25; Annex points 4.2.2, 4.2.3, 4.2.6, 9.1–9.3, 11.4.2(c), 12.1.1–12.1.2, 12.2.2(c) and 12.3.2.
2. Directive (EU) 2022/2555 (NIS2 Directive) — EUR-Lex. Articles 20, 21(1) and 21(2)(c) and (h).
3. Technical Implementation Guidance on cybersecurity risk-management measures, version 1.0 — ENISA, June 2025. Guidance, evidence and tips under Annex points 4.2.2–4.2.6 and 9.2.
4. Regulation (EU) 2016/679 (GDPR) — EUR-Lex. Articles 32(1), 33(5) and 34(3)(a).
5. Guidelines 01/2021 on Examples regarding Personal Data Breach Notification, version 2.0 — European Data Protection Board. Cases No. 01, 10 and 11.
6. IT-Grundschutz-Kompendium, module CON.3 Datensicherungskonzept, Edition 2023 — Federal Office for Information Security (BSI). Requirements CON.3.A9, A13 and A14.