NIS2 Personal Liability, €10M Fines, and Dual Reporting: A Legal Counsel’s Action Guide to Article 20 Compliance

Most NIS2 compliance programmes are built around IT departments. That is a structural mistake. Directive (EU) 2022/2555 places legal liability squarely on the management body, mandates security requirements in supplier contracts, and creates parallel reporting obligations that run simultaneously to two different regulatory authorities. Legal counsel and compliance teams are not peripheral advisers in this framework — they are primary actors with specific operational obligations that start before an incident occurs.

This guide covers the four areas where legal teams carry direct NIS2 responsibility: the personal liability mechanism under Article 20, the contractual cascade flowing from Article 21(2)(d), the jurisdiction determination under Article 26, and the operational challenge of coordinating GDPR Article 33 and NIS2 Article 23 notifications simultaneously.

What Article 20 Actually Requires of Your Management Body

Article 20(1) of the NIS2 Directive imposes a governance obligation that most organisations have under-read. The management body — which includes boards of directors, managing directors, and equivalent governance structures — must not only approve the cybersecurity risk-management measures required under Article 21, but must actively oversee their implementation. Non-compliance can result in personal liability for members of the management body. This is a first for EU cybersecurity regulation: previous frameworks treated cybersecurity as an IT function; NIS2 treats it as a board-level governance obligation with individual accountability attached.

Article 20(2) adds a mandatory training requirement. Members of the management body must follow regular cybersecurity training. Organisations must also offer training to employees so that staff can identify risks and evaluate risk-management practices. The training obligation is not aspirational — it is a documented compliance requirement that competent authorities may examine during supervisory reviews [2].

Legal counsel’s role here is threefold. First, advise the board on whether the entity is classified as essential or important, since this determines which penalty regime applies. Second, ensure the board has a documented record of approving the Article 21 measures, including the date, the measures approved, and who voted. Third, build the training log demonstrating compliance with Article 20(2). An undocumented training programme provides no protection during enforcement — the evidence must exist in writing before a supervisory event, not reconstructed afterwards.

The personal liability provision is intentionally broad. Member States may include managing directors, chief executives, and other natural persons with senior management responsibilities. Counsel advising board members should distinguish between entity-level liability (administrative fines under Articles 33–34) and natural-person liability (enforcement measures under Article 32(5)), since both can run concurrently against different defendants.

The Contractual Cascade: Embedding Article 21(2)(d) in Supplier Agreements

Article 21(2)(d) requires entities to address supply chain security, including the security-related aspects of relationships with direct suppliers and service providers. The mechanism is contractual: the only enforceable way to extend NIS2 obligations downstream is through contract clauses that specify what security standards suppliers must meet, what evidence they must provide, and what happens when they fail. Most existing master service agreements pre-date NIS2 and do not contain these provisions.

Legal teams should ensure the following five clauses are present in all contracts with direct suppliers whose compromise could affect the entity’s NIS2-in-scope services:

1. Security baseline requirement. The supplier must implement cybersecurity measures equivalent to those required under Article 21(2) of Directive 2022/2555, adapted to the supplier’s role and the data it processes.
2. Right to audit. The entity retains the right to conduct or commission security assessments of the supplier, including access to relevant documentation and testing environments, on reasonable notice. Without this clause, the entity cannot demonstrate Article 21(2)(d) compliance to a competent authority.
3. Incident notification obligation. The supplier must notify the entity of any security incident that could affect the in-scope service within 24 hours of the supplier becoming aware, to align with the entity’s own NIS2 Article 23 early-warning window.
4. Sub-contracting restrictions. The supplier may not sub-contract elements critical to the entity’s in-scope service without prior written approval. The entity’s security requirements must flow through to approved sub-contractors.
5. Termination for security cause. The entity may terminate immediately if the supplier suffers a material security breach, fails to meet the agreed security baseline, or refuses to participate in a right-to-audit exercise.

These clauses apply to new contracts immediately. For existing agreements, legal teams should identify which suppliers are critical to in-scope services and prioritise those for amendment. The common mistake is treating this as a procurement function — the obligation sits with the entity, not the supplier, and enforcement exposure belongs to the entity if the supply chain is not documented [for further context on NIS2 supply chain requirements, see our NIS2 Supply Chain Security guide].

Multi-Jurisdiction Complexity: Which Competent Authority Leads?

Entities operating in multiple EU member states face a question that the directive answers — but not simply. NIS2 operates a two-track jurisdiction system under Article 26. Track 1 is the standard rule: most entities are supervised by the member state where they are established. A Spanish subsidiary is supervised by Spain’s competent authority; a German subsidiary by Germany’s. If your entity has subsidiaries in five member states, you may in principle have five separate competent authority relationships, five separate incident reporting channels, and five potentially different national transpositions to satisfy.

Track 2 applies only to specific digital service providers: DNS providers, TLD registries, cloud computing operators, content delivery networks, managed service providers, and online platforms. These entities are supervised by the member state of their “main establishment in the Union” — a single lead authority regardless of operational footprint [4].

The three-tier test for determining main establishment applies in sequence and should only advance to the next tier when the prior tier is genuinely indeterminate [4]:

• Tier 1: The member state where decisions related to cybersecurity risk-management measures are predominantly taken. Evidence: CISO location, board security committee jurisdiction, policy approval records.
• Tier 2: Where cybersecurity operations predominantly occur, if Tier 1 is indeterminate. Evidence: Security Operations Centre location, incident response team base.
• Tier 3: The member state with the largest EU employee count, as a backstop only.

Legal counsel’s documentation obligation here is concrete. The main establishment determination must be supportable with written evidence — not the registered office address, which carries little weight, but formal board security committee meeting records showing location, CISO appointment documents with jurisdiction, and policy approval trails. The registration deadline under Article 27 was January 17, 2025; non-registration is an active breach. Entities that missed that window and have Track 2 characteristics should register immediately [4].

Note the critical limitation: Article 26(5) allows any member state to take enforcement measures against entities providing services on its territory, provided the lead authority has made a mutual assistance request. Lead designation does not create exclusive jurisdiction. Entities active in multiple member states cannot assume that a single lead authority relationship resolves all local enforcement exposure.

Dual Reporting: Coordinating GDPR Article 33 and NIS2 Article 23

A ransomware attack that disrupts services and encrypts customer records triggers both NIS2 and GDPR at the same time. The two reporting obligations do not merge and are not satisfied by filing once. They run in parallel, to different authorities, under different triggers, with different content requirements — and as of early 2026, those authorities do not share a common reporting portal or automatically exchange incident data [5].

The comparison table below sets out the operational differences:

Dimension	GDPR Article 33	NIS2 Article 23
Trigger	Personal data breach affecting rights and freedoms	Significant impact on service provision (operational, financial, or reputational)
Initial deadline	72 hours to DPA	24-hour early warning to CSIRT
Full notification	Single submission (phased if information incomplete)	72-hour incident notification with impact assessment
Final report	Not required by default	1-month final report required
Recipient	Data Protection Authority (e.g. CNIL, BfDI)	CSIRT or competent authority (e.g. ANSSI, BSI)
Data-sharing between authorities	Not automatic as of 2026	Not automatic as of 2026

The divergence in triggers is the most operationally significant point. A DDoS attack disrupting critical services triggers NIS2 Article 23 even if no personal data is accessed — it does not trigger GDPR Article 33. Conversely, a low-volume credential exposure affecting personal data may trigger GDPR without reaching the “significant impact” threshold for NIS2. Most incidents involving operational disruption and data access will trigger both.

Legal teams should build a written incident classification protocol before an incident occurs. The protocol should specify: (a) the classification criteria for NIS2 “significant impact”, (b) the classification criteria for GDPR “personal data breach”, (c) who owns each filing (typically legal or compliance for GDPR, IT/security for NIS2, with legal sign-off on both), and (d) the internal escalation timeline that ensures the 24-hour NIS2 early-warning window is met regardless of the GDPR deadline. The GDPR 72-hour window is familiar; the NIS2 24-hour early-warning — which requires only a preliminary assessment — is often missed because incident response procedures were written before NIS2 came into force [1].

Enforcement Risk: Fines, Supervisory Measures, and Civil Liability

NIS2’s penalty structure under Articles 33 and 34 sets minimum floors, not uniform fines. For essential entities, member states must provide for a maximum administrative fine of at least €10,000,000 or 2% of total worldwide annual turnover of the preceding financial year, whichever is higher. For important entities, the floor is €7,000,000 or 1.4% of global turnover [6]. Individual member states may set higher maxima in national transposition, and several have done so.

Administrative fines are calibrated to the nature, gravity, and duration of the infringement, the damage caused, and whether the infringement was intentional or negligent. This means the entity’s documented response — what it knew, when it knew it, and what it did — directly influences the penalty level. An entity that can show a mature incident response programme and immediate remediation will be assessed differently from one that had no documented measures in place.

Beyond fines, Article 32 gives competent authorities a toolkit of supervisory measures: binding instructions requiring specific security measures, orders to notify affected parties, security audits at the entity’s expense, and compliance orders with defined remediation deadlines. For essential entities facing serious or persistent infringement, Article 32(5) allows temporary suspension of the natural person responsible for the management-body-level failure. This is the personal accountability mechanism that makes Article 20 governance documentation materially consequential rather than theoretical.

Civil liability is a separate and often overlooked exposure. NIS2 does not bar civil claims from parties affected by an entity’s cybersecurity failure. A significant incident affecting customers or business partners may generate civil litigation alongside regulatory enforcement proceedings. Legal counsel should assess whether the entity’s directors’ and officers’ insurance covers NIS2-related personal liability exposure under Article 32(5), and whether the entity’s cyber insurance policy addresses both administrative fines and third-party civil claims. Many legacy policies contain exclusions that were drafted before NIS2’s management liability provisions existed [see our analysis of NIS2 Penalties and Management Liability].

Structuring Internal Governance Documents for NIS2

Most NIS2 governance documentation guides are written for CISOs. Legal teams own a distinct set of documents that sit alongside the technical policy set and are not substitutable by it. The following are the documents legal counsel specifically drives or co-owns:

Board exposure memo. A periodic (at minimum annual) written assessment delivered by legal or compliance to the management body, summarising the entity’s NIS2 classification, scope, current compliance status, open remediation items, and penalty exposure. This serves as evidence that the board received the information required under Article 20 and responded to it. Without this memo, demonstrating Article 20 compliance in a supervisory review relies on informal or reconstructed communications.

Incident notification protocol. The written procedure governing who files what, to which authority, by when, and who signs off. This document should be maintained and tested (at minimum annually through a tabletop exercise) before an incident occurs. Legal must own the GDPR Article 33 filing track; IT/security typically owns the NIS2 Article 23 track; both tracks should have a single legal sign-off checkpoint. The protocol must specify the handoff between tracks to avoid a situation where GDPR and NIS2 filings are made independently with inconsistent facts.

Supplier contract review log. A register of in-scope supplier agreements reviewed against Article 21(2)(d) requirements, noting which contracts have been amended, which are pending, and which suppliers have declined the right-to-audit clause. This log demonstrates active supply chain governance and is directly relevant if a supplier-related incident triggers a supervisory inquiry.

Jurisdiction determination record. For entities with multi-jurisdictional structures, a documented analysis of the Article 26 track classification and, where Track 2 applies, the main establishment determination under the three-tier test. This should include the board resolution or management decision recording the determination, supported by the factual evidence (CISO location, policy approval records) used to reach it.

Training completion register. Evidence that management body members have completed cybersecurity training as required by Article 20(2), including dates, content, and attendance records. Regulators in other compliance frameworks (GDPR, DORA) have treated absence of training records as an aggravating factor in enforcement decisions. The same logic applies under NIS2.

These five documents function as a legal governance layer that sits above and complements the technical policies owned by the CISO. Together they provide the paper trail that demonstrates management body engagement — the core of what Article 20 requires. For internal links between this governance framework and the broader compliance structure, see our overview of the NIS2 Directive and the detailed discussion of management body obligations under NIS2.

Frequently Asked Questions

Does NIS2 Article 23 replace GDPR Article 33 incident notification?
No. Both obligations apply independently where their respective triggers are met. An incident involving personal data and significant service disruption requires separate filings to separate authorities. There is currently no joint notification mechanism, and the two authorities operate distinct classification and assessment criteria [5].

If our entity operates in multiple EU member states, do we need separate NIS2 compliance programmes for each?
For Track 1 entities (standard rule), each subsidiary is supervised by its national authority, and national transpositions vary. You will need a consistent core compliance framework adapted to each jurisdiction’s specific requirements. For Track 2 digital service providers, the main establishment rule provides a single lead authority, but Article 26(5) means local member states retain enforcement capacity for services delivered on their territory [4].

Can legal counsel personally be held liable under NIS2?
The personal liability mechanism under Article 32(5) targets natural persons holding senior management positions in the entity. Whether in-house legal counsel falls within scope depends on the individual’s governance role (is the General Counsel a member of the management body?) and on national transposition. In jurisdictions where the General Counsel sits on the management board, personal exposure is plausible. This question warrants specific legal advice in each relevant member state jurisdiction, rather than a uniform EU-level answer [6].

Sources

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.

1. NIS 2 Directive Article 23: Reporting Obligations — NIS-2-Directive.com
2. NIS 2 Directive Article 20: Management Bodies — NIS-2-Directive.com
3. Directive (EU) 2022/2555 (NIS2) — Official Consolidated Text — EUR-Lex
4. Which EU Authority Actually Supervises Your Organisation Under NIS2? — NIS2-Templates.com
5. Incident Reporting: Aligning DORA, NIS2, and GDPR — Legiscope
6. NIS2 Directive FAQs — European Commission Digital Strategy