Data Governance and NIS2: The CIR Annex Names Personal Data Once — Which GDPR Documents Count as Evidence

If your organisation already runs a mature data protection programme, you hold a good share of the evidence a NIS2 supervisor will ask for — and almost none of it in the shape the supervisor expects. The regulation that turns Article 21(2) into concrete technical requirements, Commission Implementing Regulation (EU) 2024/2690, contains the phrase “personal data” exactly once across the entire instrument, in a footnote citing a different regulation. It never cites the GDPR, and “data subject” does not appear in it at all [2]. That absence is the whole story: your GDPR artefacts are a starting corpus, never a substitute. This guide scores eight of them against the exact CIR clause each one could evidence.

Which Regime Owns What — and What Happens When Both Fire

One scoping note before the comparison. The CIR binds only the digital-sector entities listed in its Article 1 — DNS and cloud providers, data centres, CDNs, managed service and managed security providers, online marketplaces, search engines, social networks and trust service providers [2]. Every other essential or important entity is measured against Article 21(2) of the Directive itself, with the CIR functioning as the most detailed benchmark available for what “appropriate and proportionate” looks like. Both readings of this guide work; only the enforceability of the individual points changes.

In plain terms: the GDPR protects people from what your data processing does to them; NIS2 protects the continuity and security of the systems your organisation runs. The same server can sit inside both scopes for entirely different reasons, and neither regulator accepts the other’s paperwork as a defence.

Question	GDPR (Regulation (EU) 2016/679)	NIS2 (Directive (EU) 2022/2555) + CIR 2024/2690
What is protected	The rights and freedoms of natural persons — the risk object named in Article 35(1) [3]	The security of network and information systems used for the entity’s operations or the provision of its services — Article 21(1) [1]
What pulls you into scope	Any processing of personal data, in any sector	Being an essential or important entity in a listed sector, regardless of whether you process personal data at all
Who signs it off	The controller, under the accountability principle; the DPO advises and monitors (Article 39(1)) [3]	The management body approves the measures, oversees implementation, and can be held liable for infringements — Article 20(1) [1]
The technical rulebook	Article 32 — four principles-based bullets, deliberately open-ended [3]	The CIR Annex — thirteen sections of numbered, prescriptive points, binding on the entities in its scope [2]

The two supervisory chains are wired together in only two places. Article 31(3) requires competent authorities to “work in close cooperation with supervisory authorities under Regulation (EU) 2016/679 when addressing incidents resulting in personal data breaches”. Article 35(2) then bars a second administrative fine for conduct a data protection authority has already fined — while preserving every non-financial enforcement measure in Articles 32(4)(a) to (h), 32(5) and 33(4)(a) to (g) [1]. Neither provision merges the programmes. For the notification mechanics, see our breakdown of why a GDPR breach does not always start the 24-hour NIS2 clock.

The Scope Inversion: Your GDPR Programme Indexes the Wrong Key

Run a word count over the CIR and the result is stark. “Personal data” appears once, in footnote 3, citing Regulation (EU) 2018/1725 — the data protection regulation for EU institutions. “Data protection” appears once, in recital 42, recording that the European Data Protection Supervisor was consulted. “GDPR”, “2016/679”, “data subject” and “privacy” each appear zero times [2]. Neither hit creates an obligation. The binding control set was written without reference to whether the data in a system is personal.

The mechanism behind the mismatch is indexing. A GDPR programme is indexed on processing purposes: Article 30(1) asks for purposes, categories of data subjects, categories of personal data, recipients and envisaged erasure limits [3]. The CIR inventory is indexed on services: point 12.4.2 requires “the list of operations and services and their description” and “the list of network and information systems and other associated assets supporting” them [2]. Two registers, same estate, different primary keys — which is why a record of processing activities cannot be relabelled as an asset inventory. Everything that supports a service but touches no personal data — build servers, OT historians, network management platforms, backup infrastructure — is invisible to the first register and mandatory in the second.

Classification inverts in the same way. CIR point 12.1.2(b) requires entities to associate every asset with a classification level “based on confidentiality, integrity, authenticity and availability requirements”, and point 12.1.2(c) requires the availability axis to be aligned with the recovery objectives in the business continuity plan [2]. A typical GDPR labelling scheme runs on one axis — confidentiality, sometimes with a special-category flag. Three of the four required axes are missing, and availability, the one that most often decides a NIS2 classification, is the axis privacy schemes never rate.

The risk assessments diverge most sharply. Article 35(1) GDPR is triggered by processing “likely to result in a high risk to the rights and freedoms of natural persons” [3]; CIR point 2.1.1 requires a framework “to identify and address the risks posed to the security of network and information systems” [2]. Different risk object, different treatment logic. A DPIA library evidences assessment discipline, not compliance with point 2.1.

The Reuse Map: Eight GDPR Artefacts Scored Against the CIR Annex

The practical question is not whether the regimes overlap — it is which specific document you can put in front of an auditor. This map scores each artefact against the CIR clause it comes closest to satisfying. The ratings are our own assessment, built by reading each pair of provisions side by side; they are a planning aid, not a legal opinion.

GDPR artefact you already hold	Closest NIS2 / CIR requirement	Reuse	What has to be added
Records of processing activities (Art 30(1))	Asset inventory, CIR 12.4.1–12.4.3	Partial	Systems processing no personal data; the operations-and-services list in 12.4.2(a); traceable change history
Description of security measures (Art 30(1)(g), Art 32(1))	Article 21(2) measures; CIR policy 1.1.1	Partial	A clause-by-clause map to the CIR points, plus the date of formal management-body approval required by 1.1.1(k)
Data classification / labelling scheme	Asset classification, CIR 12.1.1–12.1.3	Partial	The integrity, authenticity and availability axes, and alignment with recovery objectives under 12.1.2(c)
DPIA library (Art 35(7))	Risk assessment, CIR 2.1	None as a substitute	A separate assessment whose object is the network and information systems, a documented risk treatment plan, and residual-risk acceptance under 2.1.1
Processor contract clauses (Art 28(3))	Supplier contract clauses, CIR 5.1.4	Partial — strongest reuse on the list	Supplier incident notification to you (5.1.4(d)), right to audit (e), vulnerability handling (f), subcontractor security requirements (g)
Breach documentation register (Art 33(5))	Incident records under CIR 3.4–3.5 and Article 23 filings	Partial	Incidents involving no personal data, the significance assessment, and the 24-hour / 72-hour / one-month filing trail
Retention schedule (Art 5(1)(e))	Documentation retention 1.1.1(h); log period 3.2.5; backup periods 4.2.2(f)	Full — as the ceiling	A documented security justification for each period you set
Awareness training records (Art 39(1)(b))	Cyber hygiene and training, Article 21(2)(g)	Partial	Security-specific content, and separate management-body training evidence under Article 20(2)

Three rows carry most of the reusable value — and most of the wasted effort.

Processor contracts are the best bargain on the list. Article 28(3) already forces you into a written instrument with every processor, covering documented instructions, confidentiality commitments, sub-processor conditions, deletion or return of data at the end of the service, and contribution to audits [3]. CIR 5.1.4 asks for a contract with the same suppliers covering a different clause set: cybersecurity requirements, training and background-verification expectations, incident notification without undue delay, a right to audit or to receive audit reports, vulnerability handling, subcontracting conditions, and retrieval and disposal of information at termination [2]. The contracting vehicle, the counterparty list and the negotiation calendar are shared; the clauses are not. Adding a NIS2 schedule at the next renewal cycle costs a fraction of a fresh supplier programme — but 5.1.4 opens with “where appropriate”, so omitting a clause needs a documented reason, not silence.

The RoPA is a scoping accelerator, not an inventory. It gives you owners, system names, hosting locations and vendor relationships that would otherwise take weeks to reconstruct. Treat it as the seed list for CIR 12.4, then run the estate a second time along the service axis and expect the inventory to grow. The Article 30(5) carve-out for organisations under 250 staff is a further trap: an entity can be lawfully RoPA-light under the GDPR and still owe a complete asset inventory. The CIR has no equivalent size threshold; size enters only through the proportionality rule in its Article 2(2), which weighs exposure, size and incident likelihood but exempts nobody [2].

The DPIA is the row where reuse fails outright. The methodology transfers — register format, scoring conventions, review discipline. The output does not. Article 35(7)(c) requires “an assessment of the risks to the rights and freedoms of data subjects” [3], a different question from the one CIR 2.1.1 asks, producing a different treatment plan and a different sign-off. Point 2.1.1 also names the approver: results and residual risks “shall be accepted by management bodies”, or by delegated persons who are accountable and have the authority to manage risks, provided the management body is adequately informed [2].

Log Retention: The One Place the Two Regimes Genuinely Pull Against Each Other

Security logs are personal data more often than not — usernames, IP addresses, device identifiers and access timestamps all identify people. Hence the standard claim in compliance briefings: NIS2 forces organisations to keep logs longer than the GDPR permits. Checked against the text, it does not survive.

The CIR requires extensive logging: point 3.2.3 lists twelve categories, from inbound and outbound network traffic to privileged access, configuration and backup file changes, and the activation or pausing of logs themselves. Point 3.2.5 then says entities “shall maintain and back up logs for a predefined period” [2]. That is the entire retention instruction. The word “retention” appears three times in the whole regulation and never attached to a number: point 1.1.1(h) requires the top-level policy to “list the documentation to be kept and the duration of retention of the documentation”, and point 4.2.2(f) requires backup “retention periods based on business and regulatory requirements” [2]. Every one of those provisions hands the number back to you.

That has a specific consequence. Because NIS2 sets no floor, it cannot be cited as the legal basis for holding personal data beyond what Article 5(1)(e) GDPR allows — data must be kept in identifying form “for no longer than is necessary for the purposes for which the personal data are processed” [3]. The two rules do not collide; they compose. NIS2 supplies a legitimate security purpose, that purpose sets a duration, and the duration must be written down and defended. In practice the defensible number comes from detection reality — the interval over which your organisation can realistically discover, investigate and reconstruct an intrusion — and is then justified in the policy. Our guide to what CIR 2024/2690 actually requires for logging works through the retention-window reasoning in detail.

Who Can Own the Merged Programme

Once the evidence base is shared, the obvious efficiency is to give one person both programmes. That is where the GDPR’s own structural rules push back.

NIS2 puts accountability at the top: Article 20(1) requires management bodies to approve the cybersecurity risk-management measures, oversee implementation, and be capable of being held liable for infringements [1]. CIR 2.1.1 permits delegated acceptance of residual risk to accountable persons with authority, provided the management body is properly informed [2]. Nothing in either instrument assigns the work to a data protection function.

The GDPR, meanwhile, insulates the DPO deliberately. Article 38(3) states that the DPO “does not receive any instructions regarding the exercise of those tasks” and reports directly to the highest management level; Article 38(6) permits other duties only where they do not “result in a conflict of interests” [3]. The WP29 guidance on DPOs, endorsed by the EDPB [5], draws the boundary: a DPO “cannot hold a position within the organisation that leads him or her to determine the purposes and the means of the processing of personal data”. Its footnote 34 lists conflicting posts as a rule of thumb — chief executive, chief operating, chief financial and chief medical officers, heads of marketing and HR, “or head of IT departments” — plus “other roles lower down in the organisational structure if such positions or roles lead to the determination of purposes and means of processing” [4]. The Court of Justice landed in the same place in Case C-453/21: a conflict “may exist where a data protection officer is entrusted with other tasks or duties, which would result in him or her determining the objectives and methods of processing personal data”, assessed case by case [6].

Whether owning a NIS2 programme crosses that line is unsettled. One reading is that setting security measures for systems that process personal data determines the means of processing, making the combined role a conflict; the other is that security configuration is an implementation detail leaving purposes and essential means with the controller. Neither the guidance nor the judgment resolves it in the abstract. The low-risk structure most practitioners land on is to share the evidence base but split the roles: the security function owns the CIR artefacts and the risk treatment plan, the DPO monitors and advises without directing, and the management body signs. Our analysis of why NIS2 does not assign DPO responsibility by default sets out that division, and the personnel-side controls sit in our guide to access control and human resources security under Article 21(2)(i).

What Changes on Monday, by Role

The pattern that holds across all eight rows: the GDPR gives you the discipline and the counterparties, the CIR gives you the index and the axes. Every hour saved comes from reusing the first; every gap found comes from ignoring the second. In the mappings we have run, the supplier contract set and the retention schedule transfer fastest, and the asset inventory is always the longest job — not because the documents are hard, but because nobody has previously listed the systems that support a service without touching personal data.

Compliance officer or DPO. Export the RoPA and mark every entry with the operation or service it supports — that column is what CIR 12.4.2(a) asks for and what the RoPA never had. Then list the systems your colleagues in engineering run that never appear in it. That delta, not the RoPA itself, is the scoping deliverable.

CISO or IT security manager. Take the existing classification scheme and add the three missing axes. Rating availability against the recovery objectives in the continuity plan, as point 12.1.2(c) requires, is usually the fastest route to a defensible classification, because the business impact analysis has already done the hard thinking [2]. Then reconcile your log retention figure with the data protection team’s schedule before an auditor does it for you.

Board member. Ask for one document: the mapping from Article 21(2)’s ten measures to the evidence that supports each. Where the evidence cited is a GDPR artefact, ask which CIR point it is claimed to satisfy. Article 20(1) makes that approval yours, and the fine bar in Article 35(2) protects you only from a duplicate financial penalty — not from suspension, mandatory audits or the other enforcement measures the provision expressly preserves [1].

Frequently Asked Questions

Does NIS2 require a data protection officer?
No. The Directive neither creates a DPO role nor assigns NIS2 duties to one. Article 20(1) places approval and liability with the management body [1]; the CIR Annex allocates tasks to roles the entity defines itself.

Can we use our GDPR record of processing activities as the NIS2 asset inventory?
Only as a seed list. CIR 12.4.2 requires the list of operations and services and the systems supporting them [2] — a different index from Article 30’s processing purposes [3]. Expect to add every system that supports a service without touching personal data.

How long must we keep security logs under NIS2?
The regulation does not say. Point 3.2.5 requires a “predefined period” and 1.1.1(h) requires the duration to be written into the policy [2]. You choose the number, justify it against detection and investigation needs, and keep it within what Article 5(1)(e) GDPR allows for the personal data in those logs [3].

If a data protection authority fines us, can the NIS2 authority fine us too?
Not for the same conduct. Article 35(2) bars a second administrative fine where a supervisory authority has already imposed one under Article 58(2)(i) GDPR — but preserves the non-financial enforcement measures in Articles 32(4)(a) to (h), 32(5) and 33(4)(a) to (g) [1].

Our GDPR programme is certified and audited. Does that reduce our NIS2 workload?
It reduces the documentation build, not the control build. You inherit governance habits, a supplier contracting machine and a retention schedule — but still owe an asset inventory, a four-axis classification scheme, a systems-focused risk assessment with residual-risk acceptance, and logging across the twelve categories in point 3.2.3 [2].

One convergence is coming. The Commission’s Digital Omnibus proposal of 19 November 2025 would create a single reporting interface covering NIS2, GDPR and DORA notifications; it remains a proposal before the Parliament and Council [7], so nothing in your current filing obligations changes yet.

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.

Sources

1. Directive (EU) 2022/2555 (NIS2) — EUR-Lex. Articles 20(1), 20(2), 21(1)–(2), 31(3), 35(2).
2. Commission Implementing Regulation (EU) 2024/2690 — EUR-Lex. Annex points 1.1.1, 2.1.1, 3.2.3, 3.2.5, 4.2.2, 5.1.4, 12.1, 12.4.
3. Regulation (EU) 2016/679 (GDPR) — EUR-Lex. Articles 5(1)(e), 28(3), 30, 32, 33(5), 35, 38, 39.
4. Guidelines on Data Protection Officers, WP243 rev.01 — Article 29 Data Protection Working Party, section 3.5 and footnote 34 (linked above).
5. Endorsed WP29 Guidelines — European Data Protection Board.
6. Judgment in Case C-453/21, X-FAB Dresden — Court of Justice of the European Union, 9 February 2023 (linked above).
7. EU Digital Omnibus Introduces a Single Reporting Point for Cybersecurity Incidents — Hunton Andrews Kurth (linked above).