Introduction: The NIS2 Directive
Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 - commonly called the NIS2 Directive - is the European Union's cornerstone legal instrument for a high common level of cybersecurity across the Union. It repeals and substantially expands the original Network and Information Security Directive (Directive (EU) 2016/1148, 'NIS1'). NIS2 entered into force on 16 January 2023, and Member States were required to transpose it into national law by 17 October 2024, with the transposed rules applying from 18 October 2024. NIS2 is a directive, not a regulation, which means it is not directly applicable; each Member State enacts its own transposing legislation (for example, Germany's NIS2UmsuCG, Belgium's NIS2 Act, and equivalent laws elsewhere). Entities must therefore comply with the national transposition applicable to them, using this guide as a harmonised baseline.
NIS2 shifts the EU from a fragmented, sector-limited regime to a broad, risk-management-driven framework covering eighteen sectors, imposing binding cybersecurity risk-management measures, strict multi-stage incident reporting deadlines, direct accountability of management bodies, and administrative fines comparable in magnitude to the GDPR. This deep-dive is written for both the assessor or auditor validating conformity and the CISO or implementation team building the programme. It enumerates the specific obligations, deadlines, thresholds, and control expectations that arise directly from the Directive and its implementing acts.
Copyright and source note
The NIS2 Directive text is published by the EU in the Official Journal and is freely accessible; EU legislation is not subject to copyright restriction for reuse, though attribution is good practice. This guide is original CyberSigma commentary and interpretation. It paraphrases obligations and does not reproduce the verbatim Directive text or any licensed derivative material. Always verify against the applicable national transposition law and the Commission Implementing Regulation (EU) 2024/2690, which specify the legally binding requirements for your entity.
What is NIS2
NIS2 is a horizontal cybersecurity directive establishing minimum obligations for public and private entities that provide services considered critical or important to the functioning of the internal market and society. Its central architecture rests on four pillars: (1) national cybersecurity frameworks - each Member State must adopt a national cybersecurity strategy, designate competent authorities, single points of contact (SPOCs), and Computer Security Incident Response Teams (CSIRTs); (2) cooperation and information sharing at Union level through the NIS Cooperation Group, the CSIRTs network, and EU-CyCLONe for large-scale crisis management; (3) cybersecurity risk-management obligations on in-scope entities under Article 21; and (4) incident reporting obligations under Article 23, with supervision and enforcement under Articles 31 to 37.
Compared with NIS1, the material changes are: elimination of the 'operator of essential services' identification process in favour of a size-cap rule that brings entities into scope automatically; a two-tier classification of 'essential' and 'important' entities with differentiated supervision; a codified minimum set of ten risk-management measures; a harmonised three-stage incident-notification timeline (24-hour early warning, 72-hour incident notification, one-month final report); explicit personal accountability and training duties for management bodies; and a strengthened enforcement toolkit including fines up to EUR 10 million or 2% of global annual turnover for essential entities.
Key terminology
| Term | Meaning under NIS2 |
|---|---|
| Essential entity | Larger or highly critical entity subject to proactive (ex-ante) supervision and the higher fine ceiling. |
| Important entity | In-scope entity subject to reactive (ex-post) supervision, triggered by evidence of non-compliance. |
| Significant incident | An incident that has caused or is capable of causing severe operational disruption or financial loss, or has affected others by causing material damage - the trigger for Article 23 reporting. |
| Cyber threat | Any potential circumstance, event or action that could damage, disrupt or adversely affect network and information systems, their users, or other persons. |
| Near miss | An event that could have compromised availability, authenticity, integrity or confidentiality but was successfully prevented or did not materialise. |
| CSIRT | National Computer Security Incident Response Team designated to receive notifications and provide support. |
| SPOC | Single Point of Contact ensuring cross-border cooperation between Member State authorities and ENISA. |
| Management body | Board or equivalent governing organ, personally accountable for approving and overseeing risk-management measures. |
Who must comply: scope of applicability
NIS2 applies to public and private entities that operate in the listed sectors, meet a size threshold, and provide their services or carry out their activities within the Union. The default rule is the 'size-cap': the Directive applies to medium-sized and large enterprises within the covered sectors. A medium enterprise employs at least 50 persons or has annual turnover and balance-sheet total above EUR 10 million; a large enterprise employs at least 250 persons or has turnover above EUR 50 million and balance-sheet above EUR 43 million (based on EU Recommendation 2003/361/EC). Micro and small entities are generally excluded unless a specific carve-out applies.
Sectors of high criticality (Annex I) - entities are Essential if large
| Sector | Illustrative sub-sectors / entity types |
|---|---|
| Energy | Electricity, district heating and cooling, oil, gas, hydrogen. |
| Transport | Air, rail, water, road (including ITS operators). |
| Banking | Credit institutions. |
| Financial market infrastructures | Trading venues, central counterparties. |
| Health | Healthcare providers, EU reference laboratories, manufacturers of critical medical devices and pharmaceuticals. |
| Drinking water | Suppliers and distributors of water for human consumption. |
| Waste water | Collecting, disposing or treating urban, domestic or industrial waste water. |
| Digital infrastructure | IXPs, DNS service providers, TLD registries, cloud, data centres, CDNs, trust services, public electronic communications and networks. |
| ICT service management (B2B) | Managed service providers (MSPs) and managed security service providers (MSSPs). |
| Public administration | Central government and, where designated, regional administration entities. |
| Space | Operators of ground-based infrastructure supporting space-based services. |
Other critical sectors (Annex II) - entities are Important if in scope
| Sector | Illustrative sub-sectors / entity types |
|---|---|
| Postal and courier services | Providers of postal and courier services. |
| Waste management | Waste collection, treatment and recovery operators. |
| Manufacture, production and distribution of chemicals | Producers and distributors of chemical substances. |
| Production, processing and distribution of food | Food businesses engaged in wholesale, industrial production and processing. |
| Manufacturing | Medical devices, computers/electronics, machinery, motor vehicles, other transport equipment. |
| Digital providers | Online marketplaces, online search engines, social networking platforms. |
| Research | Research organisations. |
Entities in scope regardless of size (size-cap exceptions)
- Providers of public electronic communications networks or publicly available electronic communications services.
- Trust service providers, DNS service providers, TLD name registries and domain name registration service providers.
- Sole providers in a Member State of a service essential for societal or economic activities.
- Entities whose disruption could have a significant impact on public safety, security or health, or induce systemic risk (particularly cross-border).
- Entities identified as critical under the Critical Entities Resilience (CER) Directive (EU) 2022/2557.
- Certain public administration entities as designated by the Member State.
Jurisdiction rule
Most entities fall under the jurisdiction of the Member State where they are established. However, DNS providers, TLD registries, cloud, data centre, CDN, MSP/MSSP, marketplaces, search engines and social networks are deemed under the jurisdiction of the Member State where they have their main establishment (typically their EU head office). Non-EU providers of these digital services must designate a representative in the Union. Registration with the competent authority is mandatory - entities are largely responsible for self-identifying and registering.
Structure of NIS2: articles, obligations and control domains
The Directive comprises 46 articles across seven chapters plus two annexes. For an assessor, the operationally relevant provisions cluster into governance, the ten risk-management measures of Article 21, the reporting cascade of Article 23, and supervision/enforcement. The Commission Implementing Regulation (EU) 2024/2690 further specifies the technical and methodological requirements of Article 21(2) and defines when an incident is 'significant' for the digital and ICT sub-sectors it covers.
| Provision / domain | Focus | Assessment relevance |
|---|---|---|
| Chapter I (Arts 1-6) | Subject matter, scope, definitions. | Determines applicability and entity classification. |
| Chapter II (Arts 7-13) | National frameworks: strategy, competent authorities, CSIRTs, cooperation. | Context; identifies the CSIRT/authority the entity reports to. |
| Chapter III (Arts 14-16) | Cooperation Group, CSIRTs network, EU-CyCLONe. | EU-level coordination; peer review. |
| Article 20 | Governance - management body approval, oversight, and training duties. | Board accountability evidence. |
| Article 21 | Cybersecurity risk-management measures (the ten measures). | Core control baseline - primary audit scope. |
| Article 22 | Union-level coordinated security risk assessments of critical supply chains. | Supply-chain risk context. |
| Article 23 | Incident reporting obligations and the 24h/72h/1-month cascade. | Reporting process and timeline evidence. |
| Article 24 | Use of European cybersecurity certification schemes. | May mandate certified ICT products/services. |
| Article 25 | Standardisation - use of European and international standards. | Justifies use of ISO 27001, IEC 62443, etc. |
| Article 26-27 | Jurisdiction, territoriality and the registry of entities. | Registration evidence. |
| Articles 31-37 | Supervision, enforcement, penalties and administrative fines. | Consequences; supervisory powers. |
| Commission Impl. Reg. (EU) 2024/2690 | Detailed technical requirements and significance thresholds. | Legally binding control detail for covered sub-sectors. |
| Annexes I and II | Lists of high-criticality and other critical sectors. | Scope determination. |
Master assessment checklist
This is the core of the guide. Article 21(2) enumerates ten cybersecurity risk-management measures that all in-scope entities must implement on an 'all-hazards' and proportionate basis, taking into account the state of the art, relevant standards, cost of implementation, and the entity's exposure and size. Below, each measure is decomposed into what an auditor must verify and the typical evidence to request. Governance (Article 20) and reporting (Article 23) are treated as their own control groups because they carry independent statutory obligations.
Group 0 - Governance and management body accountability (Article 20)
| What to verify | Typical evidence |
|---|---|
| The management body has formally approved the cybersecurity risk-management measures. | Board minutes, signed approval records, governance charter, RACI showing board ownership. |
| The management body oversees implementation and can be held liable for infringements. | Oversight cadence records, board risk dashboards, liability acknowledgement, delegation-of-authority matrix. |
| Members of the management body have followed cybersecurity training. | Training completion certificates, attendance logs, curriculum, dated within reasonable recency. |
| Entities offer similar training to employees on a regular basis. | Awareness programme plan, phishing-simulation results, completion metrics. |
| Cybersecurity is embedded in enterprise risk governance and reporting. | ERM register linkage, risk appetite statement referencing cyber, audit committee reports. |
Group 1 - Risk-analysis and information-system security policies (Art 21(2)(a))
| What to verify | Typical evidence |
|---|---|
| A documented, approved information security policy and topic-specific policies exist and are current. | ISMS policy set, version control, approval signatures, review dates. |
| A risk-analysis methodology is defined and applied on an all-hazards basis. | Risk assessment methodology, risk register, threat and impact scoring, treatment plans. |
| Risks are periodically reassessed and after significant change. | Reassessment schedule, change-triggered reviews, updated register entries. |
| Policies are communicated and enforced across the organisation. | Distribution records, acknowledgements, exception log. |
Group 2 - Incident handling (Art 21(2)(b))
| What to verify | Typical evidence |
|---|---|
| A documented incident-handling process covers detection, analysis, containment, eradication, recovery. | Incident response plan, playbooks, severity classification criteria. |
| Roles, escalation paths and a 24/7 or defined coverage model are established. | IR team charter, on-call roster, escalation matrix, contact tree. |
| Incidents are logged, triaged and linked to the Article 23 reporting decision. | Incident ticketing records, significance-assessment worksheets, timelines. |
| Post-incident reviews capture lessons learned and feed corrective action. | PIR reports, root-cause analyses, remediation tracker. |
| Detection capability (logging, monitoring, SIEM/SOC) supports timely handling. | SIEM configuration, alert rules, SOC runbooks, MTTD/MTTR metrics. |
Group 3 - Business continuity, backup management, disaster recovery and crisis management (Art 21(2)(c))
| What to verify | Typical evidence |
|---|---|
| Business continuity and disaster recovery plans exist with defined RTO/RPO. | BCP/DRP documents, BIA, RTO/RPO register. |
| Backups are performed, secured (including offline/immutable copies) and tested. | Backup schedules, encryption/immutability config, restore-test logs. |
| Crisis-management arrangements and a crisis team are defined. | Crisis management plan, war-room procedures, communication plan. |
| Continuity plans are exercised and results drive improvement. | Tabletop/failover exercise reports, remediation actions. |
Group 4 - Supply-chain security (Art 21(2)(d))
| What to verify | Typical evidence |
|---|---|
| Security-related aspects of relationships with direct suppliers and service providers are addressed. | Supplier security policy, vendor risk assessments, tiering by criticality. |
| Contracts impose appropriate security requirements and audit/notification rights. | Contractual security clauses, DPAs, SLAs with security terms, right-to-audit. |
| Supplier-specific vulnerabilities and overall product/service quality are considered. | Vendor due-diligence records, SBOM requests, secure-development attestations. |
| Coordinated Union-level supply-chain risk assessments (Art 22) are reflected where relevant. | References to Commission/Cooperation Group risk assessments (e.g. high-risk vendor decisions). |
| Ongoing monitoring and periodic reassessment of key suppliers occurs. | Continuous-monitoring records, reassessment schedule, offboarding controls. |
Group 5 - Security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure (Art 21(2)(e))
| What to verify | Typical evidence |
|---|---|
| Security requirements are defined for acquisition and development (secure SDLC). | SDLC policy, security requirements templates, secure-coding standards. |
| A vulnerability management process identifies, prioritises and remediates flaws within SLAs. | Vulnerability scan reports, remediation SLA tracker, patch records. |
| A coordinated vulnerability disclosure process exists. | CVD policy, security.txt, disclosure handling records. |
| Change management controls maintenance activities securely. | Change management records, approvals, rollback plans. |
| Testing (SAST/DAST, penetration testing) is performed on critical systems. | Pen-test reports, code-review evidence, retest confirmation. |
Group 6 - Policies and procedures to assess the effectiveness of risk-management measures (Art 21(2)(f))
| What to verify | Typical evidence |
|---|---|
| Defined metrics and methods assess whether controls are effective. | KPI/KRI definitions, control-effectiveness methodology. |
| Internal audits, control testing or maturity assessments are conducted periodically. | Internal audit plan and reports, self-assessment results. |
| Findings feed a corrective-action / continual-improvement cycle. | CAPA tracker, management review minutes, trend analysis. |
| Independent assurance (external audit or certification) is obtained where appropriate. | ISO 27001 certificate, external assessment reports. |
Group 7 - Basic cyber hygiene practices and cybersecurity training (Art 21(2)(g))
| What to verify | Typical evidence |
|---|---|
| Core hygiene controls are in place (patching, least privilege, network segmentation, secure configuration). | Hardening baselines, patch compliance reports, segmentation diagrams. |
| Zero-trust principles, software/hardware updates and account hygiene are applied. | Update policy, privileged-access reviews, config-management records. |
| A recurring, role-appropriate security awareness programme runs. | Training plan, completion rates, phishing simulation outcomes. |
| Awareness of current threats (phishing, social engineering) is maintained. | Threat-briefing communications, awareness content library. |
Group 8 - Policies and procedures on the use of cryptography and, where appropriate, encryption (Art 21(2)(h))
| What to verify | Typical evidence |
|---|---|
| A cryptography policy defines approved algorithms, key lengths and use cases. | Crypto policy, approved algorithm list, standards references. |
| Data is encrypted in transit and at rest where appropriate. | TLS configuration, disk/database encryption evidence, scan results. |
| Key management (generation, storage, rotation, revocation) is controlled. | Key management procedures, HSM/KMS configuration, rotation logs. |
| Cryptographic controls are reviewed against evolving standards. | Review records, deprecation of weak ciphers, PQC readiness notes. |
Group 9 - Human-resources security, access-control policies and asset management (Art 21(2)(i))
| What to verify | Typical evidence |
|---|---|
| HR security controls (screening, confidentiality terms, onboarding/offboarding) exist. | Background-check policy, NDAs, joiner-mover-leaver procedures. |
| Access-control policy enforces least privilege and periodic recertification. | Access-control policy, RBAC matrix, access-review records. |
| An asset inventory (hardware, software, data, cloud) is maintained and classified. | Asset register, CMDB, data classification scheme. |
| Privileged access is managed and monitored. | PAM configuration, privileged-session logs, break-glass procedures. |
Group 10 - Multi-factor authentication, continuous authentication, and secured communications (Art 21(2)(j))
| What to verify | Typical evidence |
|---|---|
| MFA or continuous authentication solutions are deployed where appropriate. | MFA policy, coverage report, enforcement configuration. |
| Secured voice, video and text communications are used where relevant. | Encrypted comms tooling, configuration, usage policy. |
| Secured emergency communication systems are available for crisis use. | Out-of-band comms plan, tested emergency channels. |
| Authentication controls extend to remote access and third-party access. | VPN/ZTNA config, third-party access controls, conditional-access rules. |
Group 11 - Incident reporting obligations (Article 23) - the reporting cascade
Where an incident is 'significant', the entity must notify its CSIRT or competent authority through a defined multi-stage cascade. A significant incident is one that has caused or is capable of causing severe operational disruption or financial loss to the entity, or that has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.
| What to verify | Typical evidence |
|---|---|
| Early warning submitted without undue delay and within 24 hours of becoming aware of a significant incident, indicating any suspicion of unlawful/malicious cause or cross-border impact. | 24h early-warning submissions, timestamped, CSIRT acknowledgement. |
| Incident notification submitted within 72 hours, updating the early warning with an initial assessment (severity, impact, indicators of compromise). | 72h notification records, severity assessment, IOC list. |
| Where requested, an intermediate/progress report is provided on status updates. | Intermediate report correspondence with CSIRT. |
| Final report submitted within one month of the incident notification, with detailed description, root cause, mitigation, and any cross-border impact. | Final report, root-cause analysis, mitigation summary. |
| For ongoing incidents, a progress report at that time and a final report within one month of handling completion. | Progress report and later final report for prolonged incidents. |
| Recipients of the entity's services are informed of significant incidents/threats and remedial measures where appropriate. | Customer notifications, public communications, threat advisories. |
| A significance-assessment procedure applies the Implementing Regulation thresholds where relevant. | Significance criteria worksheet, decision log referencing 2024/2690. |
The 24 / 72 / 1-month rule
Memorise the cascade: 24 hours for an early warning, 72 hours for a full incident notification, and one month for the final report (or within one month of the incident being handled if it is still ongoing at the 72-hour mark). The 'clock' starts when the entity becomes aware of the significant incident. Late or absent reporting is itself an enforceable infringement, so the reporting decision workflow must be pre-built, tested and owned - not improvised during a crisis.
Scoping, materiality and tiering
NIS2 scoping proceeds in three questions: (1) Do we operate in an Annex I or Annex II sector? (2) Do we meet the size-cap (medium/large), or does a size-independent exception apply? (3) Are we therefore an essential or an important entity? The answer determines supervisory regime and fine ceiling. Materiality within the programme is then driven by the 'all-hazards' and proportionality principle of Article 21(1): controls must be proportionate to the risk, exposure, size and the societal/economic impact of a potential incident.
| Classification | Typical trigger | Supervision model | Maximum administrative fine |
|---|---|---|---|
| Essential entity | Large enterprise in an Annex I sector, or a size-independent critical entity (e.g. TLD registry, trust service, DNS, qualified digital infrastructure, CER-designated). | Ex-ante (proactive): audits, inspections, requests for information at the authority's initiative. | At least EUR 10 million or 2% of total worldwide annual turnover, whichever is higher. |
| Important entity | Medium enterprise in Annex I, or medium/large enterprise in an Annex II sector. | Ex-post (reactive): supervision triggered by evidence or indication of non-compliance. | At least EUR 7 million or 1.4% of total worldwide annual turnover, whichever is higher. |
Materiality for incident reporting is governed by the 'significant incident' definition and, for the sub-sectors covered by Implementing Regulation (EU) 2024/2690, by specific quantitative and qualitative thresholds (for example, recurring incidents with a common root cause, thresholds on affected users, duration of downtime, financial loss, or data affected). Entities should build a significance-assessment decision tree so that the 24-hour clock is never missed due to uncertainty over whether an incident qualifies.
Implementation approach
A pragmatic NIS2 programme is delivered in phases. Each phase below lists the core activities and the deliverables an auditor will later expect to see.
Phase 1 - Applicability, registration and governance (Weeks 0-4)
- Activities: confirm sector(s), size-cap and classification (essential vs important); identify the competent authority, CSIRT and SPOC in each Member State of operation; register the entity where required; establish board sponsorship and assign accountable owner.
- Deliverables: applicability and classification memo; registration confirmation; management-body approval record; programme charter and RACI.
Phase 2 - Gap assessment against Article 21 and Article 23 (Weeks 3-8)
- Activities: assess current state against all ten risk-management measures, governance and reporting duties; map to an existing framework (ISO 27001, IEC 62443) to reuse controls; rate maturity and prioritise gaps by risk.
- Deliverables: gap-assessment report; prioritised remediation roadmap; risk-treatment plan approved by the board.
Phase 3 - Control design and remediation (Months 2-6)
- Activities: implement or uplift policies, incident handling, BC/DR, supply-chain security, vulnerability management, cryptography, access control, MFA and awareness training; build the significance-assessment and reporting workflow.
- Deliverables: policy suite; incident response and reporting playbooks; tested backups; supplier security clauses; MFA rollout; training programme live.
Phase 4 - Testing, exercising and reporting readiness (Months 5-7)
- Activities: run tabletop and technical exercises, penetration tests and restore tests; dry-run the 24h/72h/1-month reporting cascade with the CSIRT contact path; validate detection and monitoring.
- Deliverables: exercise and pen-test reports; validated reporting runbook; MTTD/MTTR baselines; remediation of exercise findings.
Phase 5 - Assurance, sustainment and continual improvement (Ongoing)
- Activities: internal audit and effectiveness assessment (Art 21(2)(f)); management reviews; continuous supplier monitoring; keep board training current; monitor national-transposition and Implementing Regulation updates.
- Deliverables: internal audit reports; management-review minutes; updated risk register; evidence library maintained for supervisory requests.
Maturity / capability model
NIS2 does not prescribe a maturity model, but proportionality and 'state of the art' expectations map naturally to a five-level capability scale. Assessors can use it to describe current versus target state per control group.
| Level | Name | Characteristics | NIS2 posture |
|---|---|---|---|
| 1 | Initial / Ad hoc | Controls informal, undocumented, reactive. | Non-conformant; high enforcement exposure. |
| 2 | Developing | Some policies exist; inconsistent application; gaps in reporting readiness. | Partial; unlikely to satisfy supervision. |
| 3 | Defined | All ten measures documented and largely operational; reporting cascade defined; board approval in place. | Baseline conformity achievable. |
| 4 | Managed | Controls measured for effectiveness; exercises and audits routine; supplier monitoring continuous. | Strong conformity; audit-ready. |
| 5 | Optimising | Threat-informed, automated, continually improved; near-real-time detection; mature crisis management. | Leading practice; resilient to supervision and incidents. |
Assessment and audit approach
- Confirm scope and classification: validate sector, size-cap, essential/important status, jurisdictions, and registration status.
- Establish the audit criteria: the applicable national transposition law, Article 20/21/23 obligations, and Implementing Regulation (EU) 2024/2690 where relevant.
- Review governance: obtain board approval and oversight evidence and management-body training records.
- Test each of the ten risk-management measures using the master checklist tables - verify design and operating effectiveness through document review, configuration inspection and sampling.
- Assess incident-handling and the reporting cascade: walk through past incidents and a simulated significant incident against the 24h/72h/1-month timeline.
- Evaluate supply-chain security including contractual clauses and consideration of coordinated Union risk assessments.
- Assess effectiveness measurement (Art 21(2)(f)): review internal audits, metrics and corrective actions.
- Sample technical controls: MFA coverage, encryption, patching, backups (with restore evidence), logging and monitoring.
- Rate maturity per control group and identify gaps against the proportionality/state-of-the-art standard.
- Report findings with risk ratings, prioritised remediation, and a re-assessment date; retain the evidence library for supervisory inspection.
Evidence request list
- Governance: board minutes approving measures, oversight records, management-body training certificates, delegation-of-authority matrix.
- Scope and registration: applicability memo, entity classification, registration confirmations, list of Member States of operation.
- Policies: information security policy, risk-management methodology, risk register, topic-specific policies.
- Incident management: IR plan and playbooks, incident logs, significance-assessment worksheets, 24h/72h/1-month submissions and CSIRT acknowledgements, post-incident reviews.
- Continuity: BCP/DRP, BIA, RTO/RPO register, backup schedules, restore-test logs, crisis-management plan and exercise reports.
- Supply chain: supplier inventory and tiering, vendor risk assessments, contractual security clauses, SBOM/attestation requests, monitoring records.
- Secure development and vulnerabilities: SDLC and secure-coding standards, vulnerability scans, patch and remediation SLAs, CVD policy, penetration-test reports.
- Effectiveness: internal audit plan and reports, KPI/KRI definitions, corrective-action tracker, management-review minutes.
- Hygiene and training: hardening baselines, patch compliance, awareness programme, phishing-simulation results.
- Cryptography: crypto policy, approved algorithms, encryption configuration, key-management procedures.
- HR and access: screening policy, joiner-mover-leaver procedures, access-control matrix, access-recertification records, PAM configuration.
- Authentication: MFA policy and coverage report, secured/emergency communications evidence, remote-access controls.
- Asset management: asset register/CMDB, data classification scheme.
- Certifications and standards: ISO 27001 certificate, relevant European certification-scheme evidence (Art 24).
Roles and responsibilities
| Role | NIS2 responsibility |
|---|---|
| Management body / Board | Approve risk-management measures, oversee implementation, undertake training, and accept personal accountability for infringements (Art 20). |
| CISO / Head of Security | Design and operate the Article 21 measures; own the ISMS and control effectiveness. |
| Incident Response Lead | Run incident handling; drive the 24h/72h/1-month significance and reporting decisions. |
| DPO / Legal / Compliance | Interpret national transposition, manage regulatory correspondence, and coordinate with GDPR duties. |
| IT / Infrastructure teams | Implement technical controls: patching, segmentation, encryption, MFA, backups, monitoring. |
| Procurement / Vendor Management | Enforce supply-chain security clauses and vendor risk assessments (Art 21(2)(d)). |
| Business Continuity Manager | Maintain and exercise BC/DR and crisis-management arrangements. |
| Internal Audit | Independently assess control effectiveness (supports Art 21(2)(f)) and report to the board. |
| Competent Authority / CSIRT | External: supervise, receive notifications, and provide incident support (national bodies). |
| SPOC / ENISA | External: cross-border cooperation and Union-level coordination. |
KPIs and metrics to track
- Percentage of the ten Article 21 measures fully implemented and independently validated.
- Board training completion rate and recency; percentage of staff completing awareness training.
- Mean time to detect (MTTD) and mean time to respond (MTTR) for security incidents.
- Reporting timeliness: percentage of significant incidents with early warning within 24h, notification within 72h, and final report within one month.
- Number of significant incidents and near misses by root cause and trend over time.
- Patch compliance rate and mean time to remediate critical vulnerabilities against SLA.
- MFA coverage across users, privileged accounts, remote access and third-party access.
- Backup success rate and successful restore-test rate (RTO/RPO adherence).
- Percentage of critical suppliers with security clauses and completed risk assessments; overdue reassessments.
- Internal audit findings by severity and percentage of corrective actions closed on time.
- Phishing-simulation click and report rates.
- Open high/critical risks in the register and ageing beyond target treatment dates.
Readiness checklist
- Applicability and essential/important classification confirmed and documented.
- Entity registered with each relevant competent authority and CSIRT contacts recorded.
- Management body has approved the risk-management measures and completed cybersecurity training.
- All ten Article 21 measures documented, implemented and mapped to evidence.
- Information security policy and risk-management methodology approved and current.
- Incident response plan and significance-assessment decision tree in place and tested.
- 24h / 72h / 1-month reporting runbook built and dry-run with the CSIRT path.
- Business continuity, backup and disaster-recovery plans tested with restore evidence.
- Supply-chain security requirements embedded in contracts for critical suppliers.
- Vulnerability management and coordinated disclosure processes operating within SLAs.
- Cryptography and key-management controls implemented and reviewed.
- MFA deployed for users, privileged, remote and third-party access.
- HR security, access-control recertification and asset inventory maintained.
- Control-effectiveness assessment, internal audit and management review scheduled.
- Evidence library maintained and ready for supervisory inspection.
Common gaps and findings
- Failure to self-identify and register - many entities wrongly assume they are out of scope under the size-cap or overlook a size-independent exception.
- No management-body approval or training evidence, leaving personal-liability obligations unmet under Article 20.
- Incident-reporting workflow undefined, causing the 24-hour early-warning clock to be missed during a real crisis.
- No significance-assessment criteria, so teams cannot decide whether an incident is reportable.
- Backups exist but are never restore-tested, and lack offline/immutable copies for ransomware resilience.
- Supply-chain security limited to procurement forms with no contractual security clauses, right-to-audit or ongoing monitoring.
- Vulnerability management lacks enforced remediation SLAs and coordinated disclosure handling.
- MFA deployed only for VPN, leaving privileged and third-party access exposed.
- No effectiveness measurement (Art 21(2)(f)) - controls are implemented but never tested or audited.
- Treating NIS2 as a one-off project rather than a sustained, board-governed programme aligned to the national transposition law.
- Ignoring the Implementing Regulation (EU) 2024/2690 detailed requirements and thresholds for covered digital/ICT sub-sectors.
NIS2 mapped to other frameworks
| NIS2 area | ISO/IEC 27001:2022 | NIST CSF 2.0 | DORA / other |
|---|---|---|---|
| Governance (Art 20) | Clauses 5, 9.3; A.5.1 | GOVERN (GV) | DORA Art 5 ICT governance; management-body accountability. |
| Risk analysis and policies (a) | Clause 6.1; A.5.1 | IDENTIFY (ID.RA, ID.GV) | DORA Art 6-8 ICT risk framework. |
| Incident handling (b) | A.5.24-A.5.28 | RESPOND (RS), DETECT (DE) | DORA Art 17-20 ICT incident management. |
| Business continuity and DR (c) | A.5.29-A.5.30; ISO 22301 | RECOVER (RC) | DORA Art 11-12 resilience and backup. |
| Supply-chain security (d) | A.5.19-A.5.23 | GV.SC / ID.SC | DORA Art 28-30 third-party risk; CER Directive. |
| Secure acquisition/dev and vulnerabilities (e) | A.8.25-A.8.31; A.8.8 | ID.RA-01, PR.PS | DORA Art 8-9; ISO 29147/30111 disclosure. |
| Effectiveness assessment (f) | Clauses 9.1-9.3 | GV.OV, ID.IM | DORA Art 24-25 testing programme. |
| Cyber hygiene and training (g) | A.6.3; A.8 configuration | PR.AT, PR.PS | DORA awareness; CSF PR.AT. |
| Cryptography (h) | A.8.24 | PR.DS-01/02 | PCI DSS Req 3-4; DORA data protection. |
| HR, access control, asset management (i) | A.5.9-A.5.18; A.6.1-A.6.6 | PR.AA, ID.AM | ISO 27001 A.5.15 access control. |
| MFA and secured communications (j) | A.5.17; A.8.5; A.8.20-A.8.21 | PR.AA-03 | PCI DSS Req 8; NYDFS 500.12 MFA. |
| Incident reporting cascade (Art 23) | A.5.24-A.5.26 (reporting) | RS.CO / RS.MA | DORA major-incident reporting; GDPR Art 33 (72h). |
How CyberSigma helps
CyberSigma provides end-to-end NIS2 readiness: applicability and essential/important classification, gap assessment against all ten Article 21 measures and the Article 23 reporting cascade, and a prioritised remediation roadmap mapped to your existing ISO 27001, NIST CSF or DORA controls to avoid duplicate effort. Our CERT-In empanelled and QSA-qualified assessors build your significance-assessment decision tree, dry-run the 24h/72h/1-month reporting runbook with your CSIRT path, harden supply-chain and technical controls (MFA, encryption, backups, vulnerability management), and stand up board-level governance and training so your management body meets its accountability duties. We then maintain an inspection-ready evidence library and run periodic effectiveness assessments so you stay conformant across every Member State in which you operate. Talk to CyberSigma to turn NIS2 from a compliance deadline into durable cyber resilience.
Frequently asked questions
What is the NIS2 reporting deadline?
An early warning within 24 hours of awareness, a fuller notification within 72 hours, and a final report within one month.
Official documents
CyberSigma resources
Need help with NIS2?
CERT-In empanelled, PCI QSA senior auditors can take you from reading about it to compliant — with a scoped, guided programme.