Why NIS2 Does Not Assign DPO Responsibility by Default — and What Article 21 Requires Instead

Many data protection officers assume NIS2 is their problem to solve. They carry the compliance muscle, the legal background, and the board access. When an organisation discovers it qualifies as an essential or important entity under the Directive, the DPO often ends up coordinating the response by default.

That assumption creates risk on both sides. NIS2 Article 20 places accountability with the management body — the board, not the DPO. The Directive builds a separate reporting chain that runs through the national competent authority or CSIRT, not through the data protection supervisory authority the DPO works with every day.

This does not mean DPO expertise is irrelevant to NIS2 compliance. There is a precise zone where it matters — and a larger zone where relying on it alone creates accountability gaps. The distinction turns on legal basis, on who owns each notification obligation, and on what happens when a single incident triggers both regimes simultaneously.

This guide gives DPOs at NIS2-covered entities a clear answer to the question every privacy professional in scope should be asking: what do I actually own in NIS2, and what belongs elsewhere in the organisation?

Two Laws, Two Accountability Chains

GDPR and NIS2 share a common purpose: protecting organisations and individuals from harm caused by failures in digital systems. But they approach that goal from different legal bases, with different accountability structures and different supervisory bodies.

GDPR (Regulation EU 2016/679) is a directly applicable regulation governing personal data processing. It creates obligations for data controllers and processors and enforces them through national Data Protection Authorities. The DPO is GDPR’s mechanism for ensuring an internal compliance function with a direct line to that supervisory authority.

NIS2 (Directive EU 2022/2555) governs network and information system security for essential and important entities. It operates through no DPO equivalent. Compliance accountability sits with the management body, which must approve cybersecurity risk-management measures under Article 20(1) and can be held personally liable for violations [2]. The reporting chain runs to the national competent authority or CSIRT — not to the DPA.

For organisations subject to both frameworks — which covers every NIS2-in-scope entity that processes personal data — this structural difference is the starting point for any role-clarity conversation.

Different supervisory authorities

The DPO’s primary legal relationship under GDPR is with the supervisory authority — the national data protection authority. GDPR Article 39(1)(d) specifies that the DPO’s tasks include cooperating with the supervisory authority and acting as the contact point for that body [6].

NIS2 significant incident reports go to a completely different body: the CSIRT or national competent authority [3]. An incident notification under NIS2 Article 23 is never routed to the DPA. An Article 33 GDPR notification is never routed to the CSIRT. Same event, two authorities, two reporting tracks.

NIS2 Recital 108 signals the intended coordination mechanism at the authority level: “Personal data are in many cases compromised as a result of incidents. In that context, the competent authorities should cooperate and exchange information about all relevant matters with the authorities referred to in Regulation (EU) 2016/679.” That cooperation happens between regulators [8] — it is not a substitute for the organisation’s own dual notification obligations.

For a full comparison of scope, fine structures, and supervisory arrangements under both frameworks, see our NIS2 vs GDPR comparison guide.

Why NIS2 carries no DPO-equivalent requirement

A DPO appointment is mandatory under GDPR Article 37(1) in three circumstances: processing by a public authority or body; core activities involving regular and systematic monitoring of data subjects at large scale; or core activities involving large-scale processing of special category data [5]. That mandate is grounded in data protection law.

NIS2 includes no equivalent requirement. Article 20 places responsibility on the management body itself — board members must receive training, must approve the security measures, and bear personal liability for failures [2]. NIS2 intentionally made network security governance a board-level obligation rather than one delegable to a specialist officer.

This is a structural design choice, not a gap. GDPR assumes the controller may lack internal data protection expertise and mandates a specialist to fill it. NIS2 assumes cybersecurity governance cannot be outsourced from management.

What Article 21 Demands — and Why Management Body Approval Is Not the DPO’s Role

NIS2 Article 21(1) requires essential and important entities to implement “appropriate and proportionate technical, operational and organisational measures” to manage risks to their network and information systems. The proportionality test considers the entity’s exposure to risks, its size, and the likelihood and severity of incidents [1].

Article 21(2) sets the ten-domain minimum baseline every covered entity must address [1]:

1. Risk analysis and information system security policies
2. Incident handling
3. Business continuity — backup management, disaster recovery, and crisis management
4. Supply chain security, covering relationships with direct suppliers and service providers
5. Security in acquisition, development, and maintenance of systems and networks
6. Policies and procedures to assess the effectiveness of cybersecurity risk-management measures
7. Cyber hygiene practices and cybersecurity training
8. Cryptography and encryption policies and procedures
9. Human resources security, access control policies, and asset management
10. Multi-factor authentication and secured voice, video, and text communications

None of these ten domains assigns any function to the DPO. Article 21 is addressed to the entity as a whole. Article 20 establishes that the management body must formally approve the measures covering all ten areas — not review a DPO’s recommendations, but actively own them.

The approval and liability chain

Under Article 20(1), the management body must approve the cybersecurity risk-management measures and oversee implementation compliance with Article 21. Article 20(2) requires management body members to receive training sufficient to identify and assess cybersecurity risks and evaluate their management implications. Organisations must provide similar training to employees on a regular basis [2].

In an audit or enforcement action, the competent authority will examine whether the management body approved the measures and evidenced that approval. A documentation trail showing that the board endorsed a DPO’s compliance report, without direct management body ownership of the Article 21 measures themselves, does not satisfy Article 20.

Our Article 20 management liability guide covers the personal liability exposure and training requirements that fall directly on board members. The practical implication for DPOs: NIS2 compliance progress should be reported to the management body, not owned by the DPO on the management body’s behalf.

Where DPO Expertise Genuinely Contributes — A Task-by-Task Assessment

GDPR Article 39(1) assigns the DPO five mandatory tasks [6]. Mapping those tasks against NIS2 identifies where DPO expertise contributes and where it stops at the boundary of the DPO’s legal mandate.

DPO Task (GDPR Art.39)	Direct NIS2 application?	How it connects
Inform and advise on GDPR and data protection obligations	Limited	Relevant only where NIS2 security measures involve personal data processing — not to NIS2 compliance as a whole
Monitor GDPR compliance, including training and audits	No direct application	DPO monitors data protection compliance; NIS2 control monitoring is a security function under Article 21(2)(f)
Advise on Data Protection Impact Assessments	Yes — indirectly	New NIS2 security tools that process personal data (e.g. network behaviour analytics) may require a DPIA under GDPR Article 35
Cooperate with the supervisory authority	No	The NIS2 supervisory chain runs to the CSIRT or NCA, not to the DPA; the DPO’s cooperative duty is to the DPA only
Act as contact point for the supervisory authority	No	The DPA is not the NIS2 supervisory authority; the DPO’s contact-point role does not extend to the national competent authority

Three areas emerge where DPO expertise adds concrete value to the NIS2 programme — not as accountability, but as advisory input that prevents gaps in both regimes.

Identifying when a cybersecurity incident also constitutes a personal data breach

The DPO typically has the clearest view of what personal data the organisation holds, how it is classified, and what constitutes a breach for GDPR Article 33 purposes [4]. When the security team raises a significant incident under NIS2, the DPO’s first function is to assess whether personal data has been compromised — and if so, to start the GDPR 72-hour clock. This is reactive advisory work, not lead ownership of the incident response.

DPIA advisory for new Article 21 security measures

Implementing Article 21 may require deploying network monitoring tools, behaviour analytics platforms, or access control systems that process personal data. Where these tools are introduced as part of the NIS2 programme, GDPR Article 35 may require a Data Protection Impact Assessment before deployment. The DPO is the statutory advisor for that process — and early involvement prevents both a GDPR compliance gap and a delayed NIS2 implementation timeline.

Building a unified incident register that serves both regimes

GDPR Article 33(5) requires controllers to document all personal data breaches [4]. NIS2 Article 23 requires detailed records for significant incidents [3]. A single unified incident register — with metadata fields that satisfy both requirements — is more defensible than two parallel systems that can diverge under pressure. The DPO’s documentation expertise makes this a natural contribution to the NIS2 programme, even though the register as a whole belongs to the security function.

When Both Regimes Trigger Simultaneously — The Dual Notification Decision Tree

Not every NIS2 significant incident triggers a GDPR Article 33 notification, and not every personal data breach triggers NIS2 Article 23. The two thresholds are independent, and each can fire without the other.

The NIS2 significant incident threshold

Under Article 23(3), an incident is significant when it has caused, or is capable of causing, severe operational disruption of the services or financial loss to the entity — or when it has affected, or could affect, other entities by causing considerable material or non-material damage [3]. A four-hour system outage that halts operations at a utility qualifies as a significant incident under NIS2 even if no personal data is involved.

For a full analysis of how to apply the significance test in practice, including the assessment criteria auditors examine, see our NIS2 significant incident guide.

The GDPR personal data breach threshold

A personal data breach under GDPR is a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data [4]. Notification to the DPA is required within 72 hours when the breach is likely to result in a risk to the rights and freedoms of individuals. An internal misconfiguration that briefly exposes employee email addresses to an unintended internal distribution group may constitute a personal data breach — but will not trigger NIS2 if there is no significant operational disruption.

When both trigger — a worked example

A ransomware attack that encrypts a healthcare provider’s patient management system and halts all clinical operations triggers both frameworks simultaneously. The attack causes severe operational disruption (NIS2 Article 23(3)(a) threshold met). It also results in the encryption of patient health records, constituting a personal data breach involving special category data (GDPR Article 33 threshold met).

The organisation faces two parallel clocks from the moment it becomes aware of the incident:

Obligation	Authority	Deadline from awareness	Who leads
NIS2 early warning (Art.23)	CSIRT or national competent authority	24 hours	Security team / CISO
NIS2 incident notification (Art.23)	CSIRT or national competent authority	72 hours	Security team / CISO
GDPR breach notification (Art.33)	Data Protection Authority	72 hours	DPO
GDPR communication to data subjects (Art.34)	Affected individuals	Without undue delay if high risk	DPO / Controller

The NIS2 early warning at 24 hours contains what is available: attack type, affected systems, initial mitigation steps. The GDPR notification at 72 hours adds the data protection dimension: categories and approximate number of data subjects affected, likely consequences for individuals, and remediation measures taken.

These notifications carry consistent factual information but go to different authorities through separate channels. Inconsistencies between what was filed with the CSIRT and what was filed with the DPA — in the timeline of discovery, the number of systems affected, or the description of compromised data — will be flagged if both authorities compare notes.

For full procedural guidance on the NIS2 notification steps and required content at each stage, see our Article 23 incident notification guide.

Building the Coordination Protocol

When a significant incident also involves personal data, four internal functions must work in parallel without creating accountability confusion or factual inconsistency between the two notification tracks. A clear RACI prevents both overlap (which produces conflicting authority) and gap (which produces missed deadlines).

Responsibility	NIS2 Art.23 notification	GDPR Art.33 notification	Art.21 measures ownership	DPIA for new security tools
Management body	Accountable (approves)	Informed	Responsible (owns and approves)	Informed
CISO / Security team	Responsible (files)	Consulted (provides technical facts)	Responsible (implements)	Consulted
Data Protection Officer	Informed	Responsible (files)	Consulted (advises where data processing is involved)	Responsible (leads)
Legal / Compliance	Consulted	Consulted	Informed	Consulted

R = Responsible (does the work), A = Accountable (owns the outcome), C = Consulted (input required), I = Informed (kept updated)

The two most common coordination failures

The 24-hour NIS2 early warning is the tightest clock. Because the security team is focused on containment in the first hours, the DPO may not be notified until the GDPR 72-hour window is already closing. The fix is an incident escalation policy that activates the DPO within two hours of any incident declaration — not to lead the NIS2 response, but to begin the GDPR breach assessment in parallel.

The second common failure is factual inconsistency. The NIS2 Art.23 notification and the GDPR Art.33 notification may be filed hours apart by different teams. If the two accounts of the same incident diverge — in the number of affected systems, in the timeline of discovery, or in the description of personal data involved — regulators from both authorities may request explanations. A single shared incident identifier and a common evidence log, accessible to both security and compliance, prevents that divergence before either notification is filed.

Article 32 GDPR and Article 21 NIS2 — shared technical control territory

GDPR Article 32 requires controllers to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, listing encryption, pseudonymisation, availability, integrity, and confidentiality as examples, plus a process for regularly testing and evaluating those measures.

NIS2 Article 21 extends that baseline across ten domains, adding supply chain security, vulnerability management, crisis management, and multi-factor authentication to the minimum required [1]. For NIS2-covered entities, implementing Article 21 in full means the Article 32 technical security baseline is met within the domains Article 21 addresses.

This efficiency argument is the strongest case for DPO involvement in the NIS2 programme from the start: not as the implementation owner, but as the team that identifies where Article 21 documentation simultaneously satisfies Article 32 — and where a single evidence set can serve both regimes without duplication.

For CISOs working alongside DPOs to structure this coordination, see our companion guide on NIS2 obligations and the CISO’s role.

Frequently Asked Questions

Is the DPO the point of contact for NIS2 with the national competent authority?

No. The NIS2 supervisory chain runs to the CSIRT or national competent authority, not to the data protection authority. The DPO’s statutory relationship under GDPR is with the DPA. Most organisations designate a separate security contact — the CISO or a nominated security officer — as the primary point of contact for NIS2 regulatory matters, while the DPO retains primary contact responsibility for DPA communications.

Can the same person serve as both DPO and NIS2 compliance lead?

There is no legal prohibition. In smaller organisations, the same individual may hold both functions. However, the roles carry different accountability structures. GDPR’s independence requirement for the DPO must be preserved regardless of whether the same person performs both roles. The organisational reporting lines for each function must remain distinct, and the DPO must not be penalised for performing their data protection tasks.

Does every NIS2 significant incident require a GDPR Article 33 notification?

No. Many significant incidents under NIS2 — DDoS attacks, hardware failures, operational system disruptions — do not involve personal data and therefore do not trigger a GDPR notification. A GDPR Article 33 notification is required only when personal data has been breached in a way likely to create risk for individuals [4]. The DPO should be consulted at the incident triage stage to make that determination early, not at the 70-hour mark.

Key Takeaways for DPOs at NIS2-Covered Entities

• NIS2 Article 20 places compliance accountability on the management body, not the DPO. Treating the DPO as the default NIS2 owner creates a structural accountability gap that neither the DPO nor the board is positioned to defend in an enforcement scenario [2].
• The DPO’s five tasks under GDPR Article 39 have limited direct application to NIS2 — except where incidents involve personal data, where new security measures require a DPIA, or where Article 21 evidence can simultaneously satisfy Article 32 documentation requirements [6].
• NIS2 Article 23 notifications go to the CSIRT or national competent authority. GDPR Article 33 notifications go to the DPA. Same incident, different clocks (24 hours vs 72 hours), different recipients, different leads — the DPO owns the GDPR track; the security team owns the NIS2 track [3][4].
• The most effective coordination model establishes parallel notification tracks from the moment an incident is declared, with a shared evidence log and a RACI that prevents both overlap and gap between the two obligations.

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. NIS2 Directive (EU) 2022/2555, Article 21 — Cybersecurity risk-management measures. nis-2-directive.com.
2. NIS2 Directive (EU) 2022/2555, Article 20 — Governance. nis-2-directive.com.
3. NIS2 Directive (EU) 2022/2555, Article 23 — Reporting obligations. nis-2-directive.com.
4. GDPR (EU) 2016/679, Article 33 — Notification of a personal data breach to the supervisory authority. gdpr-info.eu.
5. GDPR (EU) 2016/679, Article 37 — Designation of the data protection officer. gdpr-info.eu.
6. GDPR (EU) 2016/679, Article 39 — Tasks of the data protection officer. gdpr-info.eu.
7. GDPR (EU) 2016/679, Article 34 — Communication of a personal data breach to the data subject. gdpr-info.eu.
8. NIS2 Directive (EU) 2022/2555, Recital 108 — Cooperation on personal data incidents. nis-2-directive.com.