Docply Browse kits
NIS-2

NIS-2 Top Management Responsibilities: Article 20 Explained

NIS-2 Top Management Responsibilities: Article 20 Explained
By Alessandro Stella · · 12 min read

Article 20 of the NIS-2 Directive is short — three paragraphs, fewer than 200 words in the official text. It is also the article that has changed how boards across Europe think about cybersecurity. NIS-1 spoke vaguely about “appropriate measures” without specifying who, in the organisation, was supposed to make them appropriate. Article 20 fixes that gap with surgical precision: the management body approves, oversees, can be held personally liable, and must be trained. Four duties, no delegation clause, no exceptions for organisations that find this inconvenient.

This article walks through what Article 20 actually requires of management bodies — boards of directors, C-suite executives, equivalent governing structures in public administration — and what it looks like operationally. It is written for two audiences: the directors and senior managers personally exposed under Article 20, and the compliance and legal teams briefing them. The framing is pragmatic: what to approve, what to ask, what to record, and what personal exposure looks like when these are not done.

For the broader compliance context, see the pillar guide on NIS-2 compliance; for the financial and supervisory consequences of failing to meet Article 20, see NIS-2 penalties and enforcement.

What Article 20 actually says

Article 20 is structured in two operational paragraphs.

Article 20(1) establishes three obligations for the management body:

  1. Approve the cybersecurity risk-management measures taken by the entity to comply with Article 21
  2. Oversee the implementation of those measures
  3. Can be held liable for infringements of those obligations by the entity

The third point is the structural shift. Liability is not contingent on bad faith or fraud — it attaches to infringement of the entity’s obligations under Article 21, which the management body is required to approve and oversee. This is what transforms Article 20 from a governance clause into a personal accountability regime.

Article 20(2) introduces the training requirement:

Management body members must “follow training” to gain “sufficient knowledge and skills to identify risks and assess cybersecurity risk-management practices and their impact on the services provided by the entity.” Member States must require this training; entities are encouraged to extend similar training to all employees.

The training requirement is non-delegable. A CEO cannot send a designate to be trained in their place. A non-executive director cannot opt out because cybersecurity is not their specialism. Personal training is the operational expression of personal accountability.

Who counts as the “management body”?

Article 20 does not define “management body” — and this is intentional, because corporate governance structures vary across Member States. The Directive leaves the definition to national implementation, which has produced a near-universal pattern: management body is the board of directors (or equivalent governing body) of the in-scope entity, plus senior executives with cybersecurity decision authority.

In practice, the in-scope set typically includes:

For multinational groups, scoping is more complex. NIS-2 attaches obligations to the in-scope legal entity, not the group. Each in-scope national subsidiary has its own management body for Article 20 purposes — even when actual cybersecurity decisions are made at headquarters. This creates a real tension for organisations with centralised security functions: the local board is accountable for compliance with measures it does not actually decide. The pragmatic solution most groups are adopting is a hybrid model: local boards formally approve and oversee compliance with measures designed centrally, with documented reliance on the group security function and clear local sign-off authority for material exceptions.

If your organisation is a national subsidiary of a larger group, do not assume “head office handles it” satisfies Article 20. The local board still needs to approve, oversee, and document.

The four duties, in operational terms

The text of Article 20 is brief; the operational implications are not. Each of the four duties translates into specific actions, recorded in specific places.

1. Approve the cybersecurity risk-management measures

“Approve” means a formal decision recorded in board minutes or equivalent. It is not “the board was generally supportive.” It is not “the CISO presented and there were no objections.” It is a documented resolution that names the measures being approved, the date of approval, and the members voting in favour.

What to approve, at minimum:

The frequency varies by document type. The information security policy and the cybersecurity programme typically receive annual approval; the risk assessment results and material updates receive approval whenever they change materially; incident response and continuity plans receive approval at least annually and after every significant exercise or real incident.

Each approval should produce a record. The Docply NIS-2 Total Kit includes a project launch decision template specifically designed to record management body approval at the start of the cybersecurity programme — exactly the type of artefact regulators ask for first when assessing Article 20 compliance.

2. Oversee the implementation

“Oversee” is continuous, not episodic. The management body must receive regular reporting on the operation of the cybersecurity programme and document its review of that reporting.

What “regular” looks like in practice:

The audit trail is what evidences oversight. Board minutes that show “the cybersecurity report was received and discussed” are weaker than minutes that record specific questions, specific decisions, and specific actions taken. Pattern matters: a board that asks substantive questions across multiple meetings demonstrates oversight; a board that nods through quarterly reports does not.

3. Liability for infringements

The third element of Article 20(1) is structural rather than procedural. It establishes that the management body can be held liable when the entity infringes its obligations under Article 21.

The mechanism for that liability operates through Article 32(6) and national transposition. For essential entities, regulators have specific powers:

For important entities, the personal regime is lighter. The temporary ban from management is reserved for essential entities. But personal liability for criminal-level offences (consent, connivance, wilful neglect) typically extends across the entire scope through general national company law.

For the financial penalty regime in detail and the early enforcement pattern, see NIS-2 penalties and enforcement.

4. Mandatory training

Article 20(2) requires management body members to follow cybersecurity training. The Directive does not prescribe a specific format, duration, or accreditation — these are left to national implementation and to the entity’s judgment. What the Directive does require is that the training produce “sufficient knowledge and skills” to:

In practice, an Article 20-compliant training programme covers:

Format options range from one-off intensive sessions (3-4 hours, often used for initial onboarding) to ongoing modular programmes spread across the year. Most mature programmes combine an annual baseline session with quarterly briefings tied to the regular cybersecurity reporting cycle. Both approaches are defensible; what matters is that the training is delivered, documented, and renewed.

The documentation requirement is precise: attendance records for each session, agenda or syllabus showing the content, and individual completion certificates or board minutes recording attendance. “We had a session” is not sufficient; “Director X attended a 3-hour session on Y date covering Z agenda, certified by W trainer” is.

For the detailed approach to building and evidencing a NIS-2-aligned training programme — including the management body training specifically — see NIS-2 cybersecurity training requirements.

The board accountability flow

Article 20 produces a recurring flow that, once established, becomes the operating rhythm of the cybersecurity programme:

  1. Approve — at programme launch, then annually for major artefacts and on material change
  2. Oversee — quarterly reporting cycle plus ad-hoc on incidents
  3. Train — annually at minimum, with renewal on material regulatory or organisational change
  4. Document — every step, in board minutes and supporting records

Each cycle produces evidence. Each piece of evidence reduces personal exposure. An organisation that has run two complete cycles is in markedly better defensive position than one that has just started.

What the management body should be asking

A passive board that receives reports and nods is a board that is technically compliant but operationally weak. Mature boards interrogate their cybersecurity programme. The questions worth asking — and recording in minutes — fall into five categories.

On risk: What are our top five cybersecurity risks? What has changed since last quarter? Where are we accepting risk we should be treating?

On controls: Which of the ten Article 21 measures are we strongest on, and which weakest? Do we have evidence of operation, or only documentation? When did we last test our incident response plan?

On incidents: How many significant incidents this quarter? Did we report on time under Article 23? What did we learn?

On suppliers: How many critical suppliers do we have? When were they last assessed? Are our contractual security clauses current?

On the programme itself: What did the last internal audit find? Are findings being closed within stated timelines? When did the management body last receive cybersecurity training, and is the next session scheduled?

The questions matter more than the answers. A board that asks questions creates a record of substantive oversight; a board that does not asks creates a record of the absence of it.

Common Article 20 failure modes

After two years of advising organisations through NIS-2 readiness, four failure patterns recur often enough to be worth flagging.

Failure 1: The “the IT team handles it” board. The cybersecurity programme is presented at board level once a year as an information item, no decisions are recorded, no questions are asked, no training is delivered. When the regulator arrives, there is no evidence of approval and no evidence of oversight. This is the most common failure pattern in mid-market organisations and the one most damaging in early enforcement actions.

Failure 2: Training delivered once, never renewed. Initial Article 20 training is delivered to the board in an intensive session, attendance is recorded, certificates are issued — and then nothing. Two years later, half the board has changed and the other half has forgotten. The training requirement is ongoing, not one-off.

Failure 3: Approvals without records. The CEO approves the information security policy verbally; the board “discusses” the cybersecurity programme without a recorded resolution; the incident response plan is signed off by the CISO without management body involvement. None of these produce the documentation an auditor expects under Article 20.

Failure 4: Centralised group function, absent local board. The national subsidiary inherits group cybersecurity policy, the local board has not formally approved anything specific to the local entity, and there is no documented reliance arrangement explaining the dependency. Local regulators routinely flag this when inspecting subsidiaries of multinationals.

Each failure has the same root cause: treating Article 20 as a documentation exercise to complete once rather than as a governance regime to operate.

What “operating Article 20” looks like in steady state

A mature implementation of Article 20 produces, over a complete year, the following documented artefacts:

If your file looks like this at year-end, you are in defensible Article 20 shape. If it does not, the gaps are where regulators will focus.

How Docply fits in

The Docply NIS-2 Total Kit includes the specific documentation regulators look for under Article 20. The kit’s Bundle 1 (Governance and Setup) provides the project launch decision template that records initial management body approval, the governance model document that defines who counts as the management body in your specific context, and the management review meeting template that produces the recurring oversight record. Bundle 8 (Corrective Actions and Training) provides the training plan template and the training records register specifically structured for management body documentation.

Three sample documents are downloadable from the NIS-2 Total Kit page, including the project launch decision template — the foundational artefact for Article 20 compliance.

Includes management body approval template and training records register. 77 audit-ready NIS-2 documents covering all eight bundles, with specific Article 20 governance artefacts: project launch decision, management review template, training records, escalation procedures. Lifetime updates included. See the NIS-2 Total Kit →

Sources and further reading

Last updated: 8 June 2026.