NIS2 for CISOs and Security Programme Leads — From directive to programme

In this lesson

Translate articles 20, 21 and 23 into the workstreams of a security programme, with an owner and an output for each.
Establish, legal entity by legal entity, what the programme must cover, and recognise where DORA takes over from NIS2.
Set up the governance the directive assumes: a management body that approves and oversees, and a security lead who reports to it.
Sequence the first twelve months so that the reporting chain and the evidence exist before anyone asks for them.

What the directive actually asks of an entity

Every NIS2 programme starts from one sentence. Article 21(1) requires member states to ensure that essential and important entities “take appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems which those entities use for their operations or for the provision of their services, and to prevent or minimise the impact of incidents on recipients of their services and on other services.”

Read it as a programme brief. It names three kinds of measure, so a programme made only of tools fails it as surely as one made only of policies. It covers the systems you use for your operations and those you use to provide your services. And it sets two purposes: managing risk to those systems, and limiting the impact of incidents on the people who depend on you. That second purpose separates NIS2 from most corporate risk programmes, which measure impact on the company alone.

Notice who the sentence addresses: “Member States shall ensure”. The obligation reaches your entity through the national law that transposes the directive. Programme design can be European; the legal reference you cite to a supervisor is national, and /transposition tracks it for each member state. This course stays on the directive's own numbering, the only one common to all 27.

Four obligations, not one

Arts 20, 21, 23

Chapter IV of the directive carries four duties that become the backbone of your programme.

Governance, article 20. The management body approves the risk-management measures, oversees their implementation, and can be held liable for infringements of article 21. Its members are required to follow training.
Risk-management measures, article 21. Article 21(2) lists ten measures, points (a) to (j), that the measures “shall include at least”. Ten is a floor, not a menu.
Corrective action, article 21(4). An entity “that finds that it does not comply with the measures provided for in paragraph 2 takes, without undue delay, all necessary, appropriate and proportionate corrective measures.” Your first gap assessment therefore creates a duty: once you have found the gap, you must act on it.
Reporting, article 23. Significant incidents go to the CSIRT or the competent authority on a 24-hour, 72-hour and one-month chain. Module 4 covers it in detail.

Around these sit duties that are easy to forget because they are administrative: submitting registration information (articles 3(4) and 27), and notifying the competent authority when you join or leave a cybersecurity information-sharing arrangement (article 29(4)). A programme plan that has no line for them will miss them.

Scope is decided per legal entity

Art. 6(38)

Article 6(38) defines an “entity” as a natural or legal person created and recognised as such under the national law of its place of establishment. Obligations attach to that person, not to a brand or a group. A group with eight subsidiaries may have three in scope, in two classes, under two national laws. Your first programme artefact is therefore a scope register: each legal entity, its Annex I or II type if any, its size assessment, its class (essential or important), the member state whose jurisdiction applies under article 26, and the evidence behind each conclusion.

The group can still run one programme. Shared policies, one security operations centre and one supplier process are efficient and defensible. What cannot be shared is accountability: each in-scope entity's management body approves the measures that apply to it, and each entity must be able to produce its own evidence.

Where DORA takes over

DORA art. 1(2)

Article 4(1) of NIS2 disapplies its relevant provisions, including supervision and enforcement, where a sector-specific Union act imposes risk-management or incident-notification requirements “at least equivalent in effect”. Regulation (EU) 2022/2554, DORA, settles the question for itself in article 1(2): for financial entities identified as essential or important entities under the national rules transposing article 3 of NIS2, DORA “shall be considered a sector-specific Union legal act for the purposes of Article 4 of that Directive.”

Three consequences for a programme lead. First, a credit institution in a group follows DORA's ICT risk-management and reporting regime, not article 21 and article 23. Second, the carve-out follows the entity, not the group: a non-financial subsidiary that is itself an Annex I or II entity, such as a group data-centre company that meets the size rule, stays under NIS2. Third, article 2(10) of NIS2 adds that the directive does not apply to entities that member states have exempted from DORA under article 2(4) of that regulation. The scope register should record which regime each entity follows and why.

Governance the directive assumes

Art. 20(1)–(2)

Article 20(1) gives the management body three roles: approve, oversee, be liable. None of them is delegable to the security lead, but all of them depend on the security lead. The body can only approve what is put in front of it in a form it can decide on, and it can only oversee what it is shown. Your job is to make both possible: a measures document written for decision, and a reporting cadence that lets the body see progress, exceptions and residual risk.

Article 20(2) requires members of management bodies to follow training. For employees, the directive's wording is weaker: member states “shall encourage essential and important entities to offer similar training to their employees on a regular basis”. Staff training is nevertheless required, through a different door: article 21(2)(g) lists “basic cyber hygiene practices and cybersecurity training” among the measures. Keep the two sources apart in your records; lesson 2.5 returns to them.

Reg. 2024/2690, Annex 1.2

For the entity types listed in Implementing Regulation (EU) 2024/2690, the reporting line is explicit: point 1.2.3 of its annex reads: “At least one person shall report directly to the management bodies on matters of network and information system security.” For every other entity it is not a legal requirement, but it is the cleanest way to show a supervisor how oversight under article 20(1) actually happens.

Ten measures as ten workstreams

Art. 21(2)

Use the ten points of article 21(2) as the spine of the programme, one workstream per letter. Each workstream gets an accountable owner, a policy or procedure, operating records, an effectiveness measure and a backlog of corrective actions. Workstreams will share people and tools; (b) and (c) both depend on the asset inventory that sits under (i). What matters is that, for any letter, you can open one folder and show what exists.

The letters are also your mapping key. If every internal control carries the directive letter it serves, each national or framework mapping becomes a lookup table rather than a rebuild. Module 5 develops this.

Sequencing the first twelve months

There is no legal order of implementation; there is a sensible one. Four principles drive it.

Reporting before maturity. Article 23 applies the day national law applies to you. A significant incident in month two will not wait for the programme. In the first weeks, put in place a minimal reporting runbook: who decides significance, who submits, through which national channel, with which template.
Know what you protect. Services, the systems that support them, and the suppliers behind those systems. Without this inventory, risk analysis is guesswork and continuity planning has no order of recovery.
Assess, then correct. A risk assessment and a gap assessment against points (a) to (j) produce the corrective plan that article 21(4) requires. The management body approves it, with owners and dates.
Prove it works. Before the year ends, run the first effectiveness assessment under point (f), an incident exercise and a restore test, and take the results back to the management body.

A workable calendar: weeks 0 to 4 for scope, registration, the reporting runbook and a first briefing of the management body; months 1 to 3 for inventory, risk assessment and gap assessment; months 3 to 9 for policies and the highest-risk technical gaps; months 9 to 12 for effectiveness, exercises and the first annual review.

In practice

Corvel Machines, a fictitious manufacturer of industrial machinery with 900 staff, three plants and annual turnover well above the medium-sized ceilings, is an Annex II manufacturing entity and therefore, unless its member state identifies it as essential, an important entity. Its new security lead starts with a scope register covering the group's four legal entities: the manufacturing company is in scope, the three sales companies are not. In the first month she registers the entity through the national channel, writes a two-page reporting runbook naming the incident manager as the person who declares significance, and gives the management body a one-hour briefing that ends with a decision to schedule the members' training.

By day 70 the inventory lists 14 business services and 420 systems, and the gap assessment against points (a) to (j) finds 23 gaps, six of them rated high: no multi-factor authentication on the remote maintenance gateway, backups reachable from the production domain, no supplier tiering, no restore test in two years, no logging on the plant firewalls, and no written incident classification criteria. The management body approves a corrective plan on day 75 with an owner and a date for each gap. When a supervisor later asks what the entity did once it knew, the minutes of that meeting are the answer.

What a supervisor will ask

Which of your legal entities are in scope, in which class, and why? The scope register, with the size assessment and the Annex I or II type for each entity.
Show me the management body's approval of the risk-management measures. Minutes or a resolution, dated, referring to an identified version of the measures document.
What did you do when you found gaps? The gap assessment against article 21(2)(a) to (j) and the corrective plan required by article 21(4), with owners, dates and status.
How is the management body kept informed? The reporting calendar and the last reports actually presented.

Key points

Article 21(1) asks for technical, operational and organisational measures, and for limiting the impact of incidents on recipients of services, not only on the entity.
The ten measures of article 21(2) are a minimum. Article 21(4) turns every gap you find into a duty to correct it without undue delay.
Scope, class and jurisdiction are decided per legal entity. A group can share a programme, not accountability.
For financial entities, DORA is the sector-specific act under article 4 of NIS2 (DORA art. 1(2)); the carve-out follows the entity, not the group.
Sequence for risk: the reporting chain first, then inventory, assessment and correction, then proof of effectiveness.