GRC
NIS2 - Executive Implementation Brief
By Clateway Technology Council · · 14 min read
Key takeaways
A board-level guide to scope, obligations, timelines, and the work programme required to comply with the EU's NIS2 Directive.
Executive Implementation Brief
What organisations actually need to do
A board-level guide to scope, obligations, timelines, and the work programme required to comply with the EU's NIS2 Directive.
Clateway Insights
Executive Series
The NIS2 Directive is now national law across most of the EU. Member States were required to apply national transposition measures from 18 October 2024. Supervision and enforcement are live. Administrative fines reach EUR 10 million or 2% of group worldwide turnover for essential entities, and personal accountability sits with the management body — including, as a last resort, temporary prohibition of senior individuals from managerial functions.
For most organisations in scope, NIS2 is not primarily a technology project. It is a governance, risk and accountability programme that has technology consequences. The work concentrates in five areas: confirming whether and how the organisation is in scope; bringing the management body into formal accountability; closing the gap on the ten Article 21 risk-management domains; rebuilding the incident-reporting playbook around the 24 / 72 / 30-hour cadence; and extending cybersecurity due diligence into the supply chain. Each of these requires a defensible evidence trail, because supervisors will ask for one.
This brief is written for boards, executive committees, and the CIO/CISO/CRO leadership preparing or refining their NIS2 programme. It is deliberately compact: the structure, the obligations, and the work to do — without legal restatement. A separate Clateway reference document covers the Directive article-by-article.
The single most important slide NIS2 holds the management body — not the CISO, not the CIO, not IT — accountable for cybersecurity risk-management measures. Boards must approve the programme, oversee its implementation, undertake training, and can be held liable for the entity's infringements. This is the change that matters most. Everything else flows from it. |
1. Confirm scope first
Before any control work, the organisation must answer one question with a documented answer: are we in scope, and if so, as an essential entity or as an important entity? The answer determines the supervisory regime, the maximum fine, and the depth of evidence the organisation must maintain.
The scoping test
Walk the test in this order, document each step, and store the conclusion as the foundation of the compliance file:
Is the organisation in a sector listed in Annex I (sectors of high criticality) or Annex II (other critical sectors)?
Does it meet the size threshold — medium-sized enterprise or above (broadly: 50+ employees and EUR 10m+ turnover or balance-sheet total)?
If it does not meet the size threshold, does any 'regardless of size' trigger apply? These include trust services, TLD registries, DNS service providers, sole provider of an essential service in a Member State, central-government public administration, and entities critical at national or regional level.
Has the organisation been identified as a critical entity under the Critical Entities Resilience (CER) Directive? If so, it is automatically an essential entity under NIS2.
Does any Article 2 carve-out apply (national security, defence, law enforcement, exempt financial entities under DORA)?
Essential vs important — what changes
Essential entity | Important entity |
|---|---|
Annex I sectors above the size threshold; certain entity types regardless of size; central-government public administration; CER critical entities | All other in-scope entities in Annex I or II that do not qualify as essential |
Proactive (ex ante) supervision: regular and ad-hoc audits, on-site inspections, security scans, mandatory documentation | Reactive (ex post) supervision: triggered by evidence, indication or information of non-compliance |
Last-resort enforcement available: temporary suspension of certifications and authorisations, temporary management ban for senior individuals | Last-resort enforcement (Article 32(5)) does not apply |
Maximum administrative fine: at least EUR 10 million or 2% of total worldwide annual turnover of the undertaking, whichever is higher | Maximum administrative fine: at least EUR 7 million or 1.4% of total worldwide annual turnover of the undertaking, whichever is higher |
If the organisation operates in multiple Member States, jurisdiction must also be settled. For most entities, jurisdiction is concurrent — each Member State where services are provided has authority. For digital infrastructure and digital providers (DNS, TLD registries, cloud, data centre, CDN, MSP, MSSP, online marketplaces, search engines, social networking platforms), jurisdiction follows main establishment, similar to the GDPR one-stop-shop. Document the location of cybersecurity decision-making — that is what determines main establishment, not where servers physically sit.
2. Bring the management body into accountability
Article 20 is the structural change in cybersecurity governance. The management body must approve the cybersecurity risk-management measures, oversee their implementation, undertake training, and can be held personally liable for the entity's infringements. National transposition translates this into administrative, civil, or in some cases personal liability. Several Member States have introduced explicit director-liability provisions; others rely on existing corporate-governance frameworks. The board's exposure should be reviewed against the relevant national act, not against the Directive text alone.
What the board needs to put in place
A formal, dated approval of the cybersecurity risk-management framework — the policies, the control set, the risk appetite, the supplier-cybersecurity expectations.
A standing reporting cadence (typically quarterly) covering the risk register, significant incidents, near misses, third-party assurance status, and remediation tracking against the framework.
Annual cybersecurity training for management body members, with content relevant to identifying risks and assessing risk-management practices, and with attendance recorded.
Clear delineation between management-body, executive, and operational responsibilities — typically expressed as a RACI or equivalent governance map.
Director-and-officer insurance and indemnity reviewed against the relevant national NIS2 transposition act, particularly where personal liability applies.
Documented evidence that significant cybersecurity decisions (control investments, supplier choices, risk acceptances) are taken with management-body awareness and approval where appropriate.
A practical heuristic If a supervisor asked the chair of the board today to produce evidence — a single binder — that the management body has approved, oversees, and is being trained on the cybersecurity programme, could the organisation produce it within 48 hours? If not, that gap is the first one to close. |
3. Close the gap on the ten risk-management domains
Article 21 is the operational control set. Measures must be appropriate, proportionate, state-of-the-art, and follow an all-hazards approach — covering not only cyberattacks but theft, fire, flood, telecommunications and power failures, unauthorised physical access, human error, malicious acts, and natural phenomena. The Directive does not prescribe specific controls. It defines outcomes across ten domains, which the organisation must map to a recognised standard (ISO/IEC 27001, IEC 62443, NIST CSF, sectoral standards) and demonstrate implementation against.
The ten domains
Policies on risk analysis and information system security.
Incident handling.
Business continuity, including backup management, disaster recovery, and crisis management.
Supply-chain security, including direct supplier and service-provider relationships.
Security in network and information system acquisition, development, and maintenance — including vulnerability handling and disclosure.
Policies and procedures to assess the effectiveness of cybersecurity risk-management measures.
Basic cyber hygiene practices and cybersecurity training.
Cryptography and, where appropriate, encryption.
Human-resources security, access-control policies, and asset management.
Multi-factor or continuous authentication; secured voice, video, and text communications; secured emergency communications — where appropriate.
How to demonstrate implementation
Supervisors expect evidence, not assurances. For each of the ten domains, the organisation should be able to produce: the policy or standard that governs the domain, the controls that operationalise it, the evidence that the controls run as designed, the metrics that track effectiveness, and the remediation log for known gaps. A useful test: can the organisation produce, for each domain, the most recent version of the policy, the latest assurance evidence, and the open-issue log within one working day?
For digital infrastructure and digital providers Commission Implementing Regulation (EU) 2024/2690 sets concrete technical and methodological requirements for DNS service providers, TLD registries, cloud, data centre, CDN, MSP, MSSP, online marketplaces, online search engines, social networking platforms, and trust service providers. Entities in those categories should treat that implementing act, not Article 21 alone, as the relevant control specification. |
4. Rebuild the incident-reporting playbook
Article 23 is the most operationally demanding provision in the Directive. The reporting cadence is fixed and short, the significance test must be applied early, and the organisation must be able to produce structured notifications under pressure — usually before the root cause is known.
The 24 / 72 / 30 cadence
Hour 0 — the organisation becomes aware of a significant incident. Incident handling begins. The significance assessment must be running in parallel.
Hour 24 — early warning to the CSIRT or competent authority, indicating where applicable whether the incident is suspected to be unlawful or malicious and whether it could have cross-border impact.
Hour 72 — incident notification updating the early warning with an initial assessment of severity and impact, and indicators of compromise where available.
On request — intermediate report with relevant status updates if the CSIRT or competent authority asks for one.
Day 30 from notification — final report with a detailed description of the incident, the root cause, the mitigation measures applied and ongoing, and any cross-border impact. If the incident is still active, a progress report is submitted on day 30 and the final report follows within one month of closure.
Trust service providers — derogation: the incident notification is due within 24 hours of awareness, not 72.
Significance — the threshold question
An incident is significant if it has caused or is capable of causing severe operational disruption of services or financial loss to the entity, or has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. The triage must run early. For digital infrastructure and digital provider categories, Implementing Regulation (EU) 2024/2690 sets concrete numeric thresholds; for other sectors, national transposition typically supplies guidance. The playbook must reference both.
What the playbook must contain
A clear definition of 'becoming aware', so the 24-hour clock starts at a defensible moment.
A significance-assessment checklist mapped to the relevant implementing act and national guidance.
Templates for the early warning, incident notification, intermediate report, final report, and progress report.
A named accountable role per stage — typically CISO for the technical content and General Counsel or DPO for legal and regulator coordination.
A coordination process with GDPR notification under Article 33, since many significant incidents will trigger both regimes simultaneously.
A communications protocol for service recipients potentially affected by the incident or by a significant cyber threat.
A rehearsal schedule — at least one tabletop per year that exercises the 24-hour clock end-to-end.
5. Extend cybersecurity into the supply chain
Article 21(2)(d) and 21(3) make supply-chain cybersecurity a first-class obligation. The organisation must take into account the vulnerabilities specific to each direct supplier and service provider, the overall quality of products and cybersecurity practices of suppliers (including secure-development procedures), and the results of any Union-level coordinated risk assessment carried out under Article 22.
This is the area where most NIS2 programmes underestimate the work. Procurement, vendor risk management, and contract templates typically need to be rebuilt — not lightly amended — because the obligation is ongoing and evidence-based, not a one-time questionnaire.
What needs to be in place
A current inventory of direct suppliers and service providers, classified by criticality to the in-scope services.
A tiered due-diligence process that scales with criticality — light-touch questionnaires for low-risk suppliers, formal cybersecurity assessments for high-risk ones, on-site or independent-audit assurance for the most critical.
Standard contract clauses covering cybersecurity risk-management obligations, incident-notification timelines aligned to the entity's own 24 / 72 / 30 cadence, audit rights, sub-processor approval, and termination triggers on serious failures.
Ongoing monitoring of supplier cybersecurity posture, not just point-in-time onboarding checks.
A process for ingesting and acting on Article 22 coordinated supply-chain risk assessments published at Union level — these may impose mandatory mitigation measures on specific technologies.
Particular attention to managed service providers (MSPs) and managed security service providers (MSSPs), which are now formally defined and brought directly into scope, anchoring supply-chain accountability at the contractual perimeter.
MSP and MSSP risk MSPs and MSSPs are explicitly named in Annex I and singled out in the recitals because of their privileged access to client environments. If the organisation outsources detection, response, identity, or core operations to an MSP or MSSP, the supplier's cybersecurity practices are effectively the organisation's. Increased diligence in selection — and in ongoing assurance — is now an explicit expectation. |
6. The work programme — at a glance
A typical NIS2 implementation programme runs across six workstreams. The shape and pace varies with starting maturity, but the structure does not.
Workstream | What it covers | Key deliverables |
|---|---|---|
Scoping & registration | Document scope conclusion, classification (essential/important), main establishment, and jurisdiction. Register with the relevant competent authority by the national deadline. | Scoping memo, registration confirmation, jurisdiction analysis |
Governance | Stand up management-body accountability, board approval of the framework, training programme, reporting cadence, and personal-liability review. | Board-approved framework, training records, RACI, indemnity review |
Risk management | Map the ten Article 21 domains to a recognised standard, run a gap assessment, prioritise remediation, build the evidence library. | Gap assessment, remediation roadmap, control-evidence repository |
Incident reporting | Rebuild the playbook around 24 / 72 / 30. Define significance triage, build templates, rehearse end-to-end. | Playbook, templates, tabletop after-action reports |
Supply chain | Rebuild vendor due diligence, contract templates, ongoing assurance, MSP/MSSP scrutiny. | Vendor inventory, due-diligence framework, contract clauses |
Multi-jurisdiction tracking | For multinationals, track each national transposition law, each competent authority, and each variation in scope or fines. | Jurisdiction matrix, national law tracker, single-point-of-contact list |
Indicative timeline
For an organisation starting from a typical mid-market baseline — broadly aligned with ISO/IEC 27001 but without formal NIS2 mapping — the first cycle of work usually runs six to nine months across these workstreams, with a steady-state operating model from month nine onward. Organisations starting from a lower baseline, or with significant scope across multiple Member States, should plan for twelve months. Organisations that are already mature on ISO 27001 and have structured third-party risk management can usually compress to four months.
The single most useful early action is the scoping memo and the management-body approval of the programme charter. Both can be completed in four to six weeks and unlock everything else: budget authority, accountability, and a defensible position if a supervisor engages before remediation is complete.
7. What 'good' looks like
A NIS2 programme is in good shape when, taken together, the following statements are all true and evidenced:
Scope is documented and signed off. The organisation knows whether it is in scope, as essential or important, and under whose jurisdiction in each Member State of operation.
The management body has formally approved the cybersecurity risk-management framework, receives regular structured reporting against it, and has been trained within the last twelve months.
Each of the ten Article 21 domains maps to a named policy, a control set, and current evidence of operation. Gaps are tracked in a single remediation log with owner and date.
The incident-reporting playbook has been rehearsed end-to-end in the last twelve months, with the 24 / 72 / 30 timeline tested under realistic conditions.
The supplier base is inventoried, classified by criticality, and subject to ongoing assurance proportionate to that classification — with MSP and MSSP relationships under particular scrutiny.
Registration with the relevant competent authority is current, contact details are accurate within the two-week change window, and SPOC relationships are established.
The programme is integrated with adjacent regimes (GDPR, DORA where relevant, CER, eIDAS, EECC, the Cyber Resilience Act, the AI Act) so that overlapping obligations are met once, not multiple times.
The board-level test Could the organisation, on a Monday morning, produce a single one-page summary that tells a supervisor: this is our scope conclusion, this is our framework, this is our last board approval, this is our last training session, this is our last tabletop, this is our open-issue log, this is our register of suppliers? If yes, the programme is in good shape. If not, the priority is to make that page real, then back-fill the evidence behind it. |
How Clateway helps
Clateway is a fractional executive practice for IT and cybersecurity leadership in mid-market organisations. We bring senior, multi-jurisdiction CTO and CIO experience into NIS2 programmes — at a fraction of the cost of full-time hires — and we apply a structured methodology, RCEC, that turns the NIS2 obligation into a defensible, board-grade work programme.
RCEC — Research, Commit, Execute, Control
RCEC is the methodology behind every Clateway engagement. It is designed for exactly the kind of programme NIS2 demands — one where the work is partly technical, mostly governance, and entirely accountability-driven.
Research — scope confirmation, gap assessment against the ten Article 21 domains, jurisdiction analysis, supplier-base review, and a clear baseline that the management body can act on.
Commit — a formal Board Commitment Ledger that captures what the management body has approved, what it has committed to fund, and what it has accepted as residual risk. This is the artefact that anchors personal accountability under Article 20.
Execute — delivery of the remediation roadmap, the incident-reporting playbook, the supplier-assurance rebuild, and the evidence library — with a fractional CTO or CIO embedded as a recognisable, accountable executive presence.
Control — steady-state oversight, board reporting cadence, training, tabletop rehearsals, and the ongoing assurance loop that keeps the programme defensible across regulatory cycles.
What we typically deliver in an NIS2 engagement
A documented scope and classification memo, signed off by the management body.
A board-approved cybersecurity risk-management framework, with a quarterly reporting pack template the board actually uses.
A gap assessment against the ten Article 21 domains, mapped to ISO/IEC 27001 or the standard the organisation already operates.
A remediation roadmap with named owners, dates, and budget — sized against the organisation's actual capacity, not against an idealised maturity model.
A complete incident-reporting playbook aligned to 24 / 72 / 30, with templates, an exercised tabletop, and a coordination protocol with GDPR notification.
A rebuilt supplier-cybersecurity framework — inventory, classification, due-diligence process, contract clauses, ongoing assurance — with particular attention to MSP and MSSP relationships.
A multi-jurisdiction tracker for organisations operating across Member States, including SPOC contacts, national transposition variation, and registration status.
Management-body training, designed and delivered in plain language, with attendance recorded and content tailored to the organisation's actual risk profile.
Why fractional executive leadership fits NIS2
NIS2 needs senior, accountable leadership — but most mid-market organisations cannot justify a full-time cybersecurity executive for a programme of this shape. The fractional model gives the board a recognisable executive presence, with the experience to run the programme and the standing to engage with regulators, without the cost or overhead of a permanent hire. The same person designs the framework, presents it to the board, leads the supplier negotiations, and is in the room when a supervisor calls.
Start the conversation If your organisation is in scope of NIS2 — or unsure whether it is — Clateway can run a structured scoping and readiness review in four to six weeks, ending in a board-grade report that tells you exactly where you stand and what the work to closure looks like. clateway.ai Fractional - board - CTO and CIO leadership for the mid-market and small enterprise — RCEC methodology, multi-jurisdiction experience, board-grade delivery. |
— End of brief —
Topics: GRC
Related articles
- THE NIS2 DIRECTIVE - A Complete Article-by-Article Reference and Explanation – A complete Articly by Article Reference and Explanation
- The Technology Leadership Platform: a working guide for digital leadership teams – How the platform's four core base modules — Baseline, Technology Management, Strategy Execution and GRC — fit together, and how a digital leadership team uses them in practice.
How Clateway can help
- GRC and compliance software with AI – AI-powered GRC software: generate ISO 27001, NIS2, DORA and GDPR policies, run your Statement of Applicability, controls, audit findings and management review…
- Fractional CIO services – Hire an experienced fractional CIO: senior IT leadership two days a week that owns strategy, roadmap, budget, suppliers, cyber and compliance (NIS2, DORA, ISO…
- Technology and cyber board advisory – Independent technology and cyber expertise for boards and supervisory boards: advice on management's plans, NIS2 accountability, AI governance and director…