Data Classification Policy Under NIS2: One Level Sets 9 Other Requirements — Labels, Handling Rules and the Evidence Auditors Check

Search the official English text of NIS2, its implementing regulation, and ENISA’s 170-page implementation guidance for the word “label” and you get zero hits in all three. What the rules ask for is a classification level for every asset, including information, scored on four requirements: confidentiality, integrity, authenticity and availability. That level then gets used: nine binding points elsewhere in the Commission Implementing Regulation (EU) 2024/2690 annex tie a control to it, from encryption strength to who needs a background check.

That changes what a data classification policy is for. It is less a document-marking scheme than the input file for your cryptography, authentication, backup and personnel controls. A scheme that only answers “who may read this?” leaves most of those controls with nothing to read. This guide covers what the text requires, how to build levels that work, what handling rules to attach, and the evidence an auditor will ask for.

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 the classification requirement apply to you?

In plain terms: every essential and important entity owes “asset management” under NIS2. Only certain digital providers get the detailed classification rules written out in EU law; everyone else gets them through national law, which may say less.

Article 21(2)(i) of Directive (EU) 2022/2555 lists “human resources security, access control policies and asset management” among the minimum measures. The Directive never says how to classify anything. Regulation 2024/2690 does, but Article 1 limits it to eleven provider types: DNS service providers, TLD name registries, cloud computing, data centre, content delivery network, managed service and managed security service providers, online marketplaces, online search engines, social networking platforms, and trust service providers.

Your situation	What binds you	Practical reading
One of the 11 provider types in Article 1 of Regulation 2024/2690	Annex points 12.1 (classification) and 12.2 (handling), directly applicable	Follow the Annex point by point; document reasoning wherever a point says “where appropriate”
Any other essential or important entity	Your national law transposing Article 21(2)(i)	Check national text first; the Annex is the most detailed EU benchmark available, so it is a sensible design target
Outside NIS2 scope, but a supplier to an in-scope entity	Contract terms flowing from your customer’s supply-chain policy	Expect questions about how you classify customer data and the products you supply

Penalties attach to Article 21 as a whole, not to classification on its own. Under Article 34(4) and 34(5), Member States must set maximum fines of at least EUR 10 million or 2% of worldwide annual turnover for essential entities, and at least EUR 7 million or 1.4% for important entities, whichever is higher. The amount in any case is decided nationally. The more immediate cost of a missing scheme is evidential: every control that depends on a classification level loses its stated basis.

What points 12.1 and 12.2 actually say

In plain terms: define levels, put every asset on one, align availability with your continuity plan, review periodically, and write a handling policy that covers the asset’s whole life.

Point	Requirement (Regulation 2024/2690 annex)	What your policy must contain
12.1.1	Lay down classification levels of all assets, “including information”, for the level of protection required	A defined scope: information plus systems, devices and services
12.1.2(a)	Lay down a system of classification levels	Named levels with definitions
12.1.2(b)	Associate all assets with a level based on confidentiality, integrity, authenticity and availability, according to sensitivity, criticality, risk and business value	Assignment criteria for all four requirements, and a record per asset
12.1.2(c)	Align availability requirements with the delivery and recovery objectives in the business continuity and disaster recovery plans	Availability ratings that match your recovery time objectives
12.1.3	Review classification levels periodically and update them “where appropriate”	A review trigger and cadence you set yourself
12.2.1	Handling policy “in accordance with” the security policy, communicated to anyone who uses or handles assets	Distribution to staff, suppliers and third parties
12.2.2	Cover acquisition, use, storage, transportation and disposal; rules on safe use, storage, transport and “irretrievable deletion and destruction”; secure transfer according to the type of asset	Lifecycle rules, including destruction methods
12.2.3	Review the handling policy at planned intervals and after significant incidents or significant changes	A dated review record

Two details are easy to miss. First, the binding text of 12.2 never mentions classification. It ties handling to your security policy and to the “type of asset”. The link between level and handling rule comes from ENISA’s Technical Implementation Guidance, which advises entities to “link the asset handling policy with the asset classification by providing handling details for each classification level”. That is guidance, not law, but it is also the only design that makes the other nine points workable. Second, Recital 25 of the regulation says a business impact analysis may be used to set the classification level. If you have already done one for business continuity, much of the availability work is finished.

Many organisations already have a confidentiality scheme from GDPR work. It is a starting point, not a substitute. The comparison of data governance and NIS2 shows why a privacy labelling scheme indexes the wrong key: it rates personal data, while the annex rates every asset on four requirements.

The nine requirements that read your classification level

In plain terms: nine binding points in five other annex chapters tell you to set a control “in accordance with” or “appropriate to” an asset’s classification. If the level doesn’t exist, those controls have no stated basis.

We counted every use of “classif” in the regulation’s English text: 25 hits. Setting aside the recitals, chapter 12 itself and the event-classification points in chapter 3 (which classify incidents, not assets), nine operative points use the asset classification as an input:

Annex point	What the classification level decides	Article 21(2) measure
2.1.3	Which risk treatment options get priority (alongside risk results, cost and the business impact analysis)	(a) risk analysis
4.2.2(d)	Physical and logical access controls on backup copies	(c) business continuity
9.1	The cryptography policy must be “in line with” the asset classification	(h) cryptography
9.2(a)	Type, strength and quality of cryptographic measures, at rest and in transit	(h) cryptography
10.2.2(b)	Background verification of personnel, in proportion to the classification of what they can reach	(i) HR security
11.6.2(a)	Authentication strength appropriate to the asset accessed	(i) access control
11.6.3	State-of-the-art authentication “to the extent feasible”, per risk and classification	(i) access control
11.7.1	Multi-factor or continuous authentication “where appropriate”, per classification	(j) MFA
11.7.2	Strength of authentication appropriate to the classification	(j) MFA

A tenth point, 5.1.2(c), asks you to consider “the risks and classification level of the ICT products and ICT services” when selecting suppliers. That classifies what you buy rather than what you hold, but the same scheme can serve both.

Why the table matters: an auditor checking your MFA requirements or your cryptography obligations will ask why a given system gets the control it gets. The defensible answer is “because it is classified X, and our policy maps X to this control”. Without the level, every one of those decisions has to be justified one at a time.

Designing the levels: four requirements, not one ladder

In plain terms: keep one visible confidentiality level that people recognise, and record integrity, authenticity and availability as separate ratings per asset.

ENISA’s guidance offers an “indicative example” of three levels: public, internal and confidential. It also suggests reusing schemes such as the traffic light protocol. Both are confidentiality ladders. FIRST’s TLP 2.0 defines its five labels, from TLP:CLEAR to TLP:RED, purely as sharing boundaries. Neither says anything about whether data can be altered, forged or lost.

A confidentiality-only scheme fails hardest where it matters most to the eleven provider types. Take a DNS provider’s zone data. It is public by design, so a single ladder labels it “Public”. Yet its integrity and authenticity are the whole service: a tampered record redirects users. Under a one-axis scheme the strongest signing-key and change controls have no level to attach to. Under 12.1.2(b) they do, because authenticity is rated separately.

A practical design that satisfies all four requirements:

Requirement	Scale	Where it lives	Set by
Confidentiality	4 levels: Public, Internal, Confidential, Restricted	On the document or system (visible marking) and in the asset register	Information owner
Integrity	Low / Medium / High	Asset register	Asset owner, from impact of unauthorised change
Authenticity	Low / Medium / High	Asset register	Asset owner, from impact of forged origin
Availability	Tiers matching your recovery time objectives	Asset register	Taken from the business continuity plan (point 12.1.2(c))

For systems and devices, inherit rather than invent. ENISA advises classifying assets other than information “in accordance with the classification of the information they store, process, handle or protect”. NIST’s FIPS 199 gives a tested rule for this: a system takes the highest rating, per requirement, of any information type it holds (the “high water mark”). A file server holding one Restricted folder is Restricted for confidentiality. FIPS 199 is a US federal standard, not EU law, so cite it as your method, not as a requirement. Record each rating in your asset management inventory, not in a separate spreadsheet that drifts.

Labels: an ISO 27001 idea you will probably still want

In plain terms: NIS2 doesn’t require labels, but it requires people to know the levels and handling rules, and labels are the cheapest way to show that.

Labelling comes from ISO/IEC 27001:2022, where Annex A control 5.13 “Labelling of information” builds on the classification scheme in control 5.12. As ISMS.online’s summary of control 5.13 notes, labelling covers both physical and digital information, including metadata. ENISA’s own mapping table links point 12.1 to ISO controls A.5.9, A.5.12 and A.5.13, and point 12.2 to A.5.9, A.5.10, A.5.14 and A.7.10.

The NIS2 reason to label is evidential. ENISA lists “personnel knowing classification levels and protection requirements for each level” as evidence for 12.1, and 12.2.1 requires the handling policy to reach everyone who handles assets. A visible confidentiality marking in a document footer, email subject tag or sensitivity label in your collaboration suite does both jobs. Keep integrity, authenticity and availability out of the marking. Users can’t act on them, and they belong in the register, where the controls in the table above read them.

Handling rules per level

In plain terms: one row per lifecycle stage from 12.2.2(a), one column per level, and the rules get stricter as you move right.

The matrix below is an illustrative starting point, not text from the regulation. Adjust it to your risk assessment and record why.

Stage	Public	Internal	Confidential	Restricted
Acquisition / creation	No marking needed	Default level for new material	Owner assigns and marks at creation	Owner assigns; register entry before first use
Use	Anyone	Staff and contracted parties	Need-to-know; MFA (11.7)	Named individuals; MFA; background-checked roles (10.2.2)
Storage	Any approved system	Approved company systems	Encrypted at rest (9.2(a)); access-controlled backups (4.2.2(d))	Encrypted at rest with managed keys; segregated backups
Transport / transfer	Unrestricted	Company channels	Encrypted in transit; encrypted removable media only (12.3.2(d))	Removable media prohibited; approved transfer only
Disposal	Normal deletion	Standard secure deletion	Irretrievable deletion or destruction (12.2.2(b)), logged	Verified destruction with certificate

Two rules apply across all levels. ENISA’s guidance says assets should leave your premises only with management approval. And for staff departures, point 12.5 requires assets to be returned, deposited or deleted, or cut off from your systems in line with 12.2.2 where that isn’t possible. Retention periods are a separate decision; the data retention policy guide covers them.

The evidence auditors check

In plain terms: auditors want the scheme, the per-asset records, proof people know it, and proof you review it.

Evidence	Annex point	Status
Documented classification levels and assignment criteria	12.1.1, 12.1.2(a)	ENISA example of evidence for a binding point
Current asset record showing each asset’s classification	12.1.2(b)	ENISA example of evidence
Availability ratings that match the BC/DR recovery objectives	12.1.2(c)	Binding text; no ENISA example given, so cross-reference the plan
Review schedule plus records of the last review, including reclassifications and added or removed assets	12.1.3	ENISA example of evidence
Handling policy, user instructions, training records and signed acknowledgements	12.2.1	ENISA examples of evidence
Access request and approval records; incident reports on lost, stolen or damaged assets	12.2.2	ENISA examples of evidence
Crypto, MFA and backup settings that match the level mapping	9.2(a), 11.7.2, 4.2.2(d)	Binding; tested by sampling

On review frequency, the binding text says only “periodic” for classification and “planned intervals” for the handling policy. ENISA’s guidance suggests at least annually for both. Treat annual as a sensible floor and write your chosen interval into the policy, because the documented interval is what you will be measured against. Where you decide an annex point marked “where appropriate”, such as MFA under 11.7.1, does not apply to an asset, Article 2(2) of the regulation requires you to “document its reasoning” in a comprehensible manner.

Who does what

Role	Responsibility	Effort
CISO / IT security	Design the four-requirement scheme; map each level to crypto, MFA and backup controls; configure sensitivity labels	High (first build), Low (annual)
Asset and information owners	Assign and review ratings; ENISA advises that owners be responsible for classification	Medium
Compliance officer	Keep the evidence set, run the review calendar, record Article 2(2) reasoning	Medium
SME owner without a security team	Start with three confidentiality levels and High/Low ratings for the rest; classify systems, then inherit to devices	Low to Medium
Board / management body	Approve the risk-management measures, this policy included, and oversee their implementation (Article 20(1))	Low

Frequently asked questions

Does NIS2 require a data classification policy?
The Directive requires asset management under Article 21(2)(i). For the eleven provider types covered by Regulation 2024/2690, annex point 12.1 requires classification levels for all assets, including information, and 12.2 requires a handling policy. Other entities should check their national transposition.

How many classification levels do we need?
No text sets a number. ENISA’s example uses three confidentiality levels. Most organisations manage with three or four, plus separate integrity, authenticity and availability ratings.

Can we reuse our GDPR classification scheme?
As the confidentiality axis, yes. You still need the other three requirements and coverage of every asset, not only personal data.

Is the traffic light protocol enough?
No. ENISA names it as a scheme you can use, but TLP only sets sharing boundaries, so it covers one of the four requirements.

Sources

• Directive (EU) 2022/2555 (NIS2), EUR-Lex: Article 20(1), Article 21(2)(i) and Article 34(4)–(5).
• Commission Implementing Regulation (EU) 2024/2690, EUR-Lex: Articles 1 and 2(2); Recital 25; Annex points 2.1.3, 4.2.2(d), 5.1.2(c), 9.1, 9.2(a), 10.2.2(b), 11.6.2(a), 11.6.3, 11.7.1, 11.7.2, 12.1–12.3 and 12.5.
• ENISA, Technical Implementation Guidance on cybersecurity risk-management measures, version 1.0, June 2025: guidance and examples of evidence for points 12.1 and 12.2. Non-binding.
• ENISA, Technical Implementation Guidance mapping table, version 1.2, September 2025: ISO/IEC 27001:2022 mappings for points 12.1 and 12.2.
• NIST, FIPS PUB 199, Standards for Security Categorization of Federal Information and Information Systems: per-objective impact levels and the high water mark rule.
• FIRST, Traffic Light Protocol (TLP) version 2.0: label definitions.
• ISMS.online, ISO 27001:2022 Annex A 5.13 Labelling of Information: summary of the labelling control.

Verification note: annex points and recitals were checked against the official English text of Regulation 2024/2690 and Directive 2022/2555. Word counts (“label” = 0 in the Directive, the regulation and ENISA’s guidance; “classif” = 25 in the regulation) refer to the English versions. ENISA material is guidance and is labelled as such.