NIS2
cyber risk measures, incident reporting, and supervisor evidence
The NIS2 Directive (EU 2022/2555) raises the cyber baseline across essential and important entities in 18 sectors. Run NIS2 risk assessments, log significant incidents on the 24-hour and 72-hour clocks, manage supply chain security, and produce competent authority evidence from one platform.
No credit card required. Free plan available forever.
NIS2 in context: a wider net, a higher floor, and real personal accountability
The NIS2 Directive (Directive EU 2022/2555) replaced the original NIS Directive in 2023 and had to be transposed into national law by Member States by 17 October 2024. NIS2 broadens the sectoral scope (18 sectors split between Annex I essential entities and Annex II important entities), raises the cyber baseline through Article 21 risk-management measures, tightens incident reporting through Article 23, and introduces personal accountability for the management body. Fines reach up to 10 million euro or 2 percent of global turnover for essential entities and up to 7 million euro or 1.4 percent of global turnover for important entities, alongside supervisory and corrective powers that include suspension of certification and temporary prohibition of management functions.
For most security and risk teams the practical question is not whether the directive matters; it is how to evidence the programme without rebuilding the artefact pack at every review. NIS2 favours continuity over snapshots, so the work is to keep the risk-management measures, testing programme, supplier register, incident records, and management body evidence linked and live, not exported once a year.
Who is in scope, and where the size cap kicks in
Scope is decided by sector first, then by size. Annex I lists the essential entities, Annex II lists the important entities, and the medium-large size threshold (50+ employees or 10 million euro turnover) is the default cut-off, with the size cap pulling sole or systemic providers in regardless of size. Member States can extend scope through national rules, which is why the entity-of-establishment principle matters: a multi-country entity follows the rules of its main establishment in the EU and notifies in that country.
Essential entities, Annex I sectors
Energy (electricity, district heating and cooling, oil, gas, hydrogen), transport (air, rail, water, road), banking, financial market infrastructures, health, drinking water, waste water, digital infrastructure (DNS, TLD registries, cloud, data centres, content delivery, trust services, electronic communications), ICT service management business-to-business, public administration, and space. Essential entities face the strictest supervisory regime, including ex-ante supervision and the highest fining range.
Important entities, Annex II sectors
Postal and courier services, waste management, manufacture, production, and distribution of chemicals, food production, processing, and distribution, manufacturing (medical devices, computers and electronics, machinery, motor vehicles, transport equipment), digital providers (online marketplaces, search engines, social networks), and research. Important entities face ex-post supervision but the same set of risk-management measures.
Size thresholds and the size cap exception
NIS2 generally applies to medium-sized and large entities (50+ employees or 10 million euro turnover) in the listed sectors, with a size cap rule that pulls smaller entities into scope when they are sole providers, critical for a sector, or have systemic effects. Member States can add further entities, so always check the national transposition for the country of establishment.
ICT third parties supporting in-scope entities
NIS2 makes supply chain security a direct obligation of the in-scope entity, not the supplier. Critical suppliers, managed service providers, and ICT third parties supporting essential and important entities are pulled into scope through contractual flow-down, security clauses, and the in-scope entity vulnerability handling and incident reporting expectations.
Article 21: the ten cybersecurity risk-management measures
Article 21(2) lists ten measures every essential and important entity must adopt as a floor. The measures are technology-neutral and proportionate, but the supervisor expects each one to be documented, owned, reviewed, and demonstrably effective. The good news is that they map cleanly to existing programmes: a workspace already running ISO 27001 Annex A, SOC 2 Trust Services Criteria, or NIST SP 800-53 controls is most of the way there. The gap is usually evidence linkage, not the controls themselves.
- Policies on risk analysis and information system security, with documented owner, review cycle, and management body approval
- Incident handling procedures covering detection, analysis, containment, eradication, recovery, and post-incident review
- Business continuity, including backup management, disaster recovery, and crisis management with tested fallback solutions
- Supply chain security, including security-related aspects of relationships with direct suppliers and service providers
- 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 (the audit and testing dimension)
- Basic cyber hygiene practices and cybersecurity training for all staff, with role-specific deepening for technical and management roles
- Policies and procedures regarding the use of cryptography and, where appropriate, encryption
- Human resources security, access control policies, and asset management consistent with the risk profile
- Multi-factor authentication or continuous authentication solutions, secured voice, video, and text communications, and secured emergency communication systems
Mapping is faster when the underlying programme is well structured. The ISO 27001 framework page covers the Annex A control families and how to evidence them, and the NIST 800-53 framework page covers the same ground for entities with a US footprint. NIS2 Article 21 sits comfortably on top of either baseline.
Article 23: classifying and reporting significant incidents
Article 23 obliges essential and important entities to notify significant incidents to the national CSIRT or competent authority. A significant incident is one that has caused or is capable of causing severe operational disruption, financial loss, or considerable material or non-material damage to other natural or legal persons. The threshold is intentionally broad, so document the classification logic and apply it consistently rather than improving it per incident.
- A significant incident causes or is capable of causing severe operational disruption of the services or financial loss for the entity concerned
- A significant incident affects or is capable of affecting other natural or legal persons by causing considerable material or non-material damage
- Member States and ENISA may issue further guidance on quantitative thresholds, and national CSIRTs publish reporting forms each entity should map to internally
- Apply the threshold consistently with documented evidence: the same incident, classified the same way, every time, with the rationale visible to the assessor
The reporting clock: 24 hours, 72 hours, one month
Once an incident is classified as significant, NIS2 sets a layered reporting timeline. Hitting the deadlines is a function of pre-built templates, a clear handoff between detection and reporting, and a single source of truth for the incident record. Pulling the early warning together while the incident is still being contained is the part that breaks most teams, so make the template, the contacts, and the recipient address part of the runbook rather than a separate task.
- Early warning within 24 hours of becoming aware of a significant incident, indicating whether it is suspected to be caused by unlawful or malicious acts and whether it could have cross-border impact
- Incident notification within 72 hours of awareness, updating the early warning, providing an initial assessment of the incident including its severity and impact, and where available the indicators of compromise
- Intermediate report on request from the CSIRT or competent authority on the status of the incident
- Final report not later than one month after the incident notification, covering a detailed description of the incident, the type of threat or root cause, applied and ongoing mitigation measures, and the cross-border impact, where applicable
- Progress report when the incident is still ongoing at the one-month mark, with a final report submitted one month after handling has been concluded
For the operational side of incident management, the incident response workflow keeps triage, containment, recovery, and post-incident review tied to the same record the regulator report references, so the technical timeline and the supervisor narrative tell the same story.
Supply chain security: from policy clause to live register
Supply chain security is one of the most heavily-emphasised parts of NIS2. The directive specifically calls out the need to address security-related aspects of relationships with direct suppliers and service providers, and ENISA publishes specific guidance on supplier risk management. The supervisor expects a register that is more than a procurement list: it has to show concentration, criticality, due diligence, contractual posture, and recent incident history per supplier.
- Maintain a register of suppliers and service providers that support information systems supporting essential or important services, including sub-outsourcing chains
- Classify suppliers by criticality (sole provider, hard to substitute, sensitive data access, deep network access) and apply proportionate due diligence to each tier
- Embed security clauses in contracts: vulnerability handling, incident notification timelines, audit and access rights, sub-processor approval, and exit assistance
- Track supplier-side findings, vulnerabilities, and incidents against the register entry they belong to, so concentration and trend are visible per supplier
- Run periodic supplier reviews, capture the result of any audit or attestation (ISO 27001, SOC 2, PCI DSS), and feed them into the entity risk register
- Require co-ordinated vulnerability disclosure expectations from suppliers, aligned to ISO/IEC 29147 and 30111, so a vendor flaw turns into a managed remediation rather than a surprise
NIS2 supply chain security interlocks with the EU Cyber Resilience Act on the supplier side: a vendor selling a product with digital elements into an essential or important entity carries the manufacturer obligations under CRA, including conformity assessment, vulnerability handling, SBOM evidence, and severe incident reporting through the ENISA single reporting platform. The buyer-side NIS2 supplier register and the seller-side CRA conformity pack are the two ends of the same supply chain conversation, so coordinating the two records prevents the same vulnerability and incident facts being captured twice.
Testing, audit, and continuous coverage
Article 21(2)(f) requires policies and procedures to assess the effectiveness of cybersecurity risk-management measures, which translates into a structured testing and audit programme. NIS2 favours continuity, so a one-off annual penetration test does not satisfy the obligation; the supervisor wants to see vulnerability assessments, penetration tests, scenario exercises, and independent audits running on a documented cadence with linked evidence.
Vulnerability assessments and scanning
Run continuous external and authenticated scanning across in-scope assets so the supervisor sees coverage rather than a single annual snapshot. Capture scan cadence, scope, raw output, and remediation linkage per asset and per critical service.
Penetration testing on critical services
Penetration tests are required where they are proportionate to the entity and the service. Scope tests against the systems supporting essential or important services, document the test plan, capture findings against assets, and track remediation against agreed deadlines through to re-test.
Scenario-based exercises and crisis tests
Test the incident handling, business continuity, and crisis management procedures with table-top and live exercises that include the management body, communications, and operational teams. Record actions, decisions, and lessons learned as evidence the procedures actually work.
Independent audit and effectiveness review
Article 21 requires policies and procedures to assess the effectiveness of risk-management measures. Schedule independent audit cycles, link findings to the relevant Article 21 measure, and feed remediation actions into the wider corrective action plan.
The penetration testing workflow and the vulnerability assessment workflow are designed for this kind of programme: scope, log findings against assets, track remediation against deadlines, and re-test before closure. Tagging findings by tactic and technique using the MITRE ATT&CK framework tightens the report and makes the supervisor narrative more concrete.
Vulnerability handling and co-ordinated disclosure
Article 12 introduces a European vulnerability database run by ENISA, and Article 21 expects entities to handle vulnerabilities in their own products and services in a co-ordinated way. The practical setup is a published vulnerability disclosure policy, a triage workflow, and a closing loop that ties any disclosed weakness to a remediation record and, where it crosses the threshold, a significant incident report. Aligning to ISO and IEC 29147 and 30111 is the standard reference here.
The vulnerability disclosure programme setup guide walks through the policy, scope, safe harbour, and SLA model used in coordinated disclosure programmes, and the findings deduplication guide covers how to keep external reports merged with internal scanner output cleanly.
Management body accountability and training
Article 20 makes the management body responsible for approving the cybersecurity risk-management measures, overseeing their implementation, and taking cybersecurity training. Member States may impose personal liability for breaches, including temporary prohibition from management functions in essential entities. The evidence pack therefore has to include board approvals, training completion records, and the regular reporting the management body receives on the cybersecurity programme.
Transposition, registration, and national variation
NIS2 is a directive, so the operative legal text is the national transposition. National rules vary on points like notification routes, minor sectoral additions, and quantitative incident thresholds. Track the national CSIRT or competent authority publication for the country of establishment and treat ENISA guidance and Commission implementing acts as the EU-level floor.
- Member States had to transpose NIS2 into national law by 17 October 2024, so the operative regime is the national transposition for the country of establishment, not the directive text alone
- Some Member States published national authority registers, sectoral guidance, and reporting forms after the transposition deadline; track the national CSIRT or competent authority website for the form that applies to your entity
- Entities had to notify themselves to the competent authority where the national rules require self-notification, with sector, contact, and IP/CIDR information per the national template
- The European Commission and ENISA publish guidance on Article 21 measures, supply chain security, and incident classification thresholds; treat them as the floor, not the ceiling
NIS2 next to DORA and other regimes
NIS2 is a horizontal regulation across 18 sectors, while the DORA regulation is the lex specialis for EU financial entities. Where DORA applies, the financial entity follows the DORA regime for the matters covered by DORA (ICT risk management, ICT-related incident reporting, resilience testing including TLPT, and ICT third-party risk). Outside those matters, NIS2 still applies. Many essential entities in scope of NIS2 also operate ISO 27001, SOC 2, or PCI DSS programmes; mapping NIS2 measures onto those frameworks avoids parallel evidence packs. Where personal data is involved, the GDPR Article 32 security obligations sit alongside NIS2 Article 21 measures, and the 72-hour breach notification clock under GDPR runs in parallel with the NIS2 incident reporting deadlines.
UK groups operating across the EU should also map NIS2 onto their domestic UK obligations. The NCSC Cyber Assessment Framework is the assessment backbone the UK NIS Regulations apply to Operators of Essential Services and Relevant Digital Service Providers, with sector regulators inheriting the framework. The contributing outcomes underneath the four CAF objectives map cleanly against the NIS2 Article 21 risk management measures, so a single underlying body of evidence usually satisfies both the UK CAF cycle and the EU NIS2 reporting obligation when the engagement record is structured against outcomes rather than against a single submission template.
Evidence the competent authority (and your board) actually want
Programmes that fail review usually fail because the artefacts are scattered across drives, ticket systems, and screenshots. Build the evidence pack as the work happens, retain raw scanner output and test reports alongside the summary, and tie every artefact back to an Article 21 measure, an asset, and an owner. The supervisor narrative writes itself when the underlying record is consistent.
- Risk-management measures policy set, approved by the management body, with review cycles and Article 21 mapping
- Asset register and dependency map covering essential and important services and the information systems that support them
- Risk register, treatment plan, and residual risk acceptance with the named accountable owner per item
- Test plan, raw scan output, penetration test reports, and re-test evidence for each testing cycle
- Significant incident records, classification rationale, and the early warning, incident notification, intermediate, and final reports
- Supplier register, contractual security clauses, due diligence outcomes, and supplier incident history
- Co-ordinated vulnerability disclosure policy, triage records, and acknowledgement timelines
- Management body approval records, training completion records, and board reporting on the cybersecurity programme
Where SecPortal fits in the NIS2 workflow
SecPortal is the operating layer for the NIS2 programme, not a replacement for the management body, the competent authority, or the testers. The platform handles scope, scans, findings, control mapping, incident records, the supplier register, and the assessor-ready output, so the work runs as a structured workflow rather than a long email thread. Compliance tracking covers NIS2 alongside the other frameworks the same entity has to satisfy, including ISO 27001, SOC 2, NIST 800-53, and DORA.
- Compliance tracking that maps every finding to NIS2 Article 21 measures alongside ISO 27001 Annex A, SOC 2 Trust Services Criteria, NIST 800-53 control families, PCI DSS requirements, and DORA articles for entities under multiple regimes
- Engagement management for vulnerability assessments, penetration tests, scenario exercises, and audits, with scope, status, evidence, and re-test all on one record
- Findings management with CVSS 3.1 scoring, 300+ templates, and Nessus or Burp Suite imports so existing tooling feeds the same workflow
- 16-module external scanning and 17-module authenticated scanning to evidence boundary, configuration, and authenticated weakness between manual tests
- Continuous monitoring with scheduled scans (daily, weekly, monthly) so the competent authority sees coverage rather than a one-off snapshot
- Attack surface management to keep the in-scope asset boundary defensible as the estate changes
- AI report generation that turns risk findings, test results, and remediation actions into board and supervisor-ready narratives without manual rewriting
NIS2 is a multi-year programme, not a one-off project. The first year of national application focuses on scope confirmation, registration, the risk-management measures baseline, and the incident reporting setup. Subsequent years tighten the supplier register, deepen the testing programme, and integrate management body reporting with day-to-day operations. Running the work as a managed workflow pays off most over time: historical findings, classified incidents, supplier records, and remediation timelines stay linked, so each supervisory engagement is a refresh rather than a rebuild. For consultants delivering NIS2 readiness work to multiple clients, the security consultants workspace bundles that with branded client portals and AI report generation, so the deliverable looks as polished as the work behind it.
For programmes that want continuous detection and trend evidence between manual tests, the continuous monitoring capability and external scanning capability produce the cadence and coverage record NIS2 testing programmes are expected to keep.
Key control areas
SecPortal helps you track and manage compliance across these domains.
Cybersecurity risk-management measures (Article 21)
Cover the ten minimum measures every entity must adopt: risk analysis and information system security policies, incident handling, business continuity and crisis management, supply chain security, security in network and information system acquisition and development, policies to assess effectiveness, basic cyber hygiene and training, cryptography and encryption, human resources security and access control, and multi-factor authentication and secured communications.
Significant incident reporting (Article 23)
Capture incidents from detection through classification against the NIS2 thresholds (operational disruption, financial loss, material or non-material damage to others) and meet the 24-hour early warning, 72-hour incident notification, and one-month final report deadlines on the CSIRT or competent authority template.
Supply chain and ICT third-party security
Maintain a register of critical suppliers and service providers, document due diligence, contractual security clauses, and vulnerability handling expectations. Tie supplier-side findings, assessments, and incidents to the supplier record they belong to so concentration and exposure are visible at a glance.
Vulnerability disclosure and handling
Run a coordinated vulnerability disclosure programme aligned to ENISA guidance and ISO/IEC 29147 and 30111. Track reports, internal triage, fixes, and acknowledgements, and feed the same data into your incident workflow when a disclosed vulnerability becomes a significant incident.
Testing, audit, and effectiveness assessment
Run a documented programme of vulnerability assessments, penetration tests, scenario exercises, and independent audits proportionate to the entity. Capture scope, evidence, findings, and re-test for each cycle so the supervisor sees a continuous programme rather than a single annual export.
Management body accountability and training
Evidence that the management body has approved the risk-management measures, oversees their implementation, and has completed the cybersecurity training expected under Article 20. Keep training records, board minutes, and approval signatures linked to the NIS2 evidence pack.
Related features
Run a defensible NIS2 programme without spreadsheets
Bring risk measures, incident reporting, supply chain security, and evidence into one workflow. Start free.
No credit card required. Free plan available forever.