Run the technical response under Rev. 3 while a separate legal workstream determines NIS2 scope, significance, recipients, content, and deadlines.
NIS2's Directive-level sequence starts from awareness of a significant incident, but national implementing law and sector-specific EU rules can change the controlling route.
Use both for a covered entity's cyber incident: Rev. 3 structures the operational response, while NIS2 and the applicable Member State law determine legal risk-management and reporting duties. Do not wait for complete technical certainty before opening the NIS2 assessment. At Directive level, the clock starts when an essential or important entity becomes aware of a , not when the investigation closes.
NIST SP 800-61 Rev. 3 is incident-response guidance: use it to structure preparation, detection, response, recovery, evidence, and lessons-learned work before mapping any separate legal duty.
Second framework
NIS2 incident reporting
NIS2 is an EU directive implemented through Member State law. Covered essential and important entities must assess significance and follow the applicable legally timed reporting sequence.
SP 800-61 Rev. 3 structures incident response as risk management guidance. Use NIST SP 800-61 Rev. 3 to define the in-scope system, product, service, supplier, release, incident, or governance process before mapping evidence.
NIS2 applies through Member State law to essential and important entities in covered Annex I and II sectors. The general rule covers medium-sized and larger entities providing services or activities in the Union; Article 2 also lists regardless-of-size and nationally identified cases. Article 3 generally treats large Annex I entities as essential and other in-scope Annex I or II entities as important, subject to specific classifications and national decisions. Sector-specific EU law can displace NIS2 provisions where its requirements are at least equivalent in effect.
Document the legal entity, services, sector, Member State, staff and financial calculation including partner or linked enterprises, special inclusion or exclusion, essential-or-important classification, competent authority, and any sector-specific EU regime before applying the reporting sequence.
Rev. 3 distributes operational work across leadership, incident handlers, technical and asset owners, legal, communications, providers, and recovery participants as needed.
Management bodies of essential and important entities must approve the Article 21 cybersecurity risk-management measures and oversee implementation. The entity makes the Article 23 notification to its CSIRT or competent authority; national law should identify the filing channel and responsible authority.
Name the management-body owner, incident lead, legal significance decision-maker, filing owner, authority contact, service-recipient communications owner, and an alternate for out-of-hours reporting.
NIST SP 800-61 Rev. 3 work starts when an organization needs to prepare for, detect, respond to, recover from, or learn from a cybersecurity incident within its risk-management program.
Article 23 treats an incident as significant when it has caused or can cause severe operational disruption of services or financial loss for the entity, or has affected or can affect other persons through considerable material or non-material damage. The reporting sequence starts when the covered entity becomes aware of that .
Record the first defensible awareness time, services and recipients affected, actual and potential disruption, financial loss, harm to others, cross-border impact, suspected malicious cause, and the decision rationale. Reassess significance as facts change.
NIST SP 800-61 Rev. 3 asks teams to prepare, detect, analyze, respond, recover, document, and improve. Use it to build incident-response procedures, logging, evidence handling, and lessons-learned actions.
Article 21 requires appropriate and proportionate technical, operational, and organizational risk-management measures, including incident handling, business continuity and crisis management, supply-chain security, vulnerability handling and disclosure, effectiveness assessment, cyber hygiene and training, cryptography, access control, asset management, and appropriate authentication and secure communications.
Map Rev. 3 procedures and evidence to the relevant Article 21 measure, but keep the legal proportionality assessment and any national technical requirements explicit. Operational use of Rev. 3 does not by itself prove NIS2 compliance.
The NIS2 record should preserve the scope decision, awareness timestamp, significance assessment, early warning, incident notification, authority feedback, requested intermediate reports, final or progress report, service-recipient communications, filing receipts, and the facts supporting every update.
Link technical evidence from the response file into the legal reporting record without changing the original. Record what was known at each filing time so later findings do not obscure why an earlier statement was made.
Rev. 3 is April 2025 guidance and creates no notification clock. Use organization-defined operational targets while tracking NIS2 and other applicable legal or contractual clocks separately.
At Directive level, an in-scope entity must submit an early warning without undue delay and within 24 hours of awareness, then an incident notification without undue delay and within 72 hours. A final report is due within one month after that notification. If the incident is still ongoing, a progress report is due then and the final report follows within one month after handling ends. Trust service providers have a 24-hour incident-notification derogation.
Open the reporting timeline as soon as awareness and significance may coincide. Confirm the national filing route, sector-specific rule, time-zone convention, and any authority request; do not use an internal NIST severity label as a substitute for the legal significance test.
Rev. 3 is not a certification or enforcement regime; it may be reviewed through internal governance, federal requirements, contracts, or customer assurance where incorporated.
Member States implement supervision and enforcement through national law and competent authorities. NIS2 requires effective supervisory powers and administrative-fine frameworks, but the applicable procedure, authority, remedies, and penalty decision depend on entity category, national law, and the facts.
Treat Rev. 3 evidence as operational support. Only the applicable national law, sector-specific regime, and competent authority determine legal scope, filing compliance, supervision, liability, and penalties.
Rev. 3 records can support NIS2 incident handling and reporting by preserving incident criteria, scope and impact estimates, provenance, decisions, communications, mitigation, recovery, and lessons learned.
The NIS2 record adds legal-entity scope, national jurisdiction, the significance test, awareness time, staged filing content, authority interaction, and service-recipient duties that Rev. 3 does not determine.
Share the factual incident record, but keep legal conclusions, reporting approvals, filings, and receipts in a controlled reporting record. Add a bridge note when system and legal-entity boundaries differ.
Choose Rev. 3 when the task is operational incident preparation, handling, evidence, communications, recovery, or improvement without treating it as the source of a legal clock.
For an in-scope event, start both workstreams at once: Rev. 3 for operational response and NIS2 for legal assessment and reporting. A pending technical investigation does not pause a legal deadline.
SP 800-61 Rev. 3 structures incident response as risk management guidance. Use NIST SP 800-61 Rev. 3 to define the in-scope system, product, service, supplier, release, incident, or governance process before mapping evidence.
NIS2 applies through Member State law to essential and important entities in covered Annex I and II sectors. The general rule covers medium-sized and larger entities providing services or activities in the Union; Article 2 also lists regardless-of-size and nationally identified cases. Article 3 generally treats large Annex I entities as essential and other in-scope Annex I or II entities as important, subject to specific classifications and national decisions. Sector-specific EU law can displace NIS2 provisions where its requirements are at least equivalent in effect.
Document the legal entity, services, sector, Member State, staff and financial calculation including partner or linked enterprises, special inclusion or exclusion, essential-or-important classification, competent authority, and any sector-specific EU regime before applying the reporting sequence.
Rev. 3 distributes operational work across leadership, incident handlers, technical and asset owners, legal, communications, providers, and recovery participants as needed.
Management bodies of essential and important entities must approve the Article 21 cybersecurity risk-management measures and oversee implementation. The entity makes the Article 23 notification to its CSIRT or competent authority; national law should identify the filing channel and responsible authority.
Name the management-body owner, incident lead, legal significance decision-maker, filing owner, authority contact, service-recipient communications owner, and an alternate for out-of-hours reporting.
NIST SP 800-61 Rev. 3 work starts when an organization needs to prepare for, detect, respond to, recover from, or learn from a cybersecurity incident within its risk-management program.
Article 23 treats an incident as significant when it has caused or can cause severe operational disruption of services or financial loss for the entity, or has affected or can affect other persons through considerable material or non-material damage. The reporting sequence starts when the covered entity becomes aware of that .
Record the first defensible awareness time, services and recipients affected, actual and potential disruption, financial loss, harm to others, cross-border impact, suspected malicious cause, and the decision rationale. Reassess significance as facts change.
NIST SP 800-61 Rev. 3 asks teams to prepare, detect, analyze, respond, recover, document, and improve. Use it to build incident-response procedures, logging, evidence handling, and lessons-learned actions.
Article 21 requires appropriate and proportionate technical, operational, and organizational risk-management measures, including incident handling, business continuity and crisis management, supply-chain security, vulnerability handling and disclosure, effectiveness assessment, cyber hygiene and training, cryptography, access control, asset management, and appropriate authentication and secure communications.
Map Rev. 3 procedures and evidence to the relevant Article 21 measure, but keep the legal proportionality assessment and any national technical requirements explicit. Operational use of Rev. 3 does not by itself prove NIS2 compliance.
The NIS2 record should preserve the scope decision, awareness timestamp, significance assessment, early warning, incident notification, authority feedback, requested intermediate reports, final or progress report, service-recipient communications, filing receipts, and the facts supporting every update.
Link technical evidence from the response file into the legal reporting record without changing the original. Record what was known at each filing time so later findings do not obscure why an earlier statement was made.
Rev. 3 is April 2025 guidance and creates no notification clock. Use organization-defined operational targets while tracking NIS2 and other applicable legal or contractual clocks separately.
At Directive level, an in-scope entity must submit an early warning without undue delay and within 24 hours of awareness, then an incident notification without undue delay and within 72 hours. A final report is due within one month after that notification. If the incident is still ongoing, a progress report is due then and the final report follows within one month after handling ends. Trust service providers have a 24-hour incident-notification derogation.
Open the reporting timeline as soon as awareness and significance may coincide. Confirm the national filing route, sector-specific rule, time-zone convention, and any authority request; do not use an internal NIST severity label as a substitute for the legal significance test.
Rev. 3 is not a certification or enforcement regime; it may be reviewed through internal governance, federal requirements, contracts, or customer assurance where incorporated.
Member States implement supervision and enforcement through national law and competent authorities. NIS2 requires effective supervisory powers and administrative-fine frameworks, but the applicable procedure, authority, remedies, and penalty decision depend on entity category, national law, and the facts.
Treat Rev. 3 evidence as operational support. Only the applicable national law, sector-specific regime, and competent authority determine legal scope, filing compliance, supervision, liability, and penalties.
Rev. 3 records can support NIS2 incident handling and reporting by preserving incident criteria, scope and impact estimates, provenance, decisions, communications, mitigation, recovery, and lessons learned.
The NIS2 record adds legal-entity scope, national jurisdiction, the significance test, awareness time, staged filing content, authority interaction, and service-recipient duties that Rev. 3 does not determine.
Share the factual incident record, but keep legal conclusions, reporting approvals, filings, and receipts in a controlled reporting record. Add a bridge note when system and legal-entity boundaries differ.
Choose Rev. 3 when the task is operational incident preparation, handling, evidence, communications, recovery, or improvement without treating it as the source of a legal clock.
For an in-scope event, start both workstreams at once: Rev. 3 for operational response and NIS2 for legal assessment and reporting. A pending technical investigation does not pause a legal deadline.
When should teams use NIST SP 800-61 Rev. 3 first versus NIS2 incident reporting first?
Use NIST SP 800-61 Rev. 3 first when the task is to build or test incident response preparation, detection, response, recovery, evidence handling, or lessons learned.
Use NIS2 incident reporting first when the task is to meet a statutory duty: determine whether the entity is in scope, whether the incident is significant, and whether the 24-hour, 72-hour, or one-month report clock applies.
Use both when one fact pattern supports both the operational response file and the NIS2 reporting record.
How should teams keep NIST response work and NIS2 reporting duties separate?
Run two linked workstreams. The incident lead should detect, analyze, contain, eradicate, recover, preserve evidence, and communicate under the response plan. The legal or compliance owner should confirm entity scope, the competent CSIRT or authority, significance, awareness time, national forms, sector-specific rules, and whether service recipients must be informed.
Start the Directive-level scope test with the legal entity and its Annex I or II service in the Union. The general size-cap rule covers an entity that qualifies as medium-sized or exceeds that ceiling. The SME ceiling is fewer than 250 staff plus annual turnover no more than EUR 50 million and/or an annual balance-sheet total no more than EUR 43 million. A small enterprise has fewer than 50 staff and turnover and/or balance-sheet total no more than EUR 10 million; a microenterprise has fewer than 10 staff and no more than EUR 2 million. Small and microenterprises are therefore outside the general size-cap rule, but Article 2 can still bring specified entity types into scope regardless of size or through national identification on listed criticality grounds. Include partner and linked-enterprise data under Recommendation 2003/361/EC. Article 3 then separates essential from important entities; large Annex I entities are generally essential, while other in-scope Annex I and II entities are generally important unless a specific essential-entity rule or national identification applies.
Check size, group relationships, sector and service, establishment or service territory, regardless-of-size inclusions, national identifications, public-administration rules, national-security exclusions, and any sector-specific EU act before classifying the entity.
Reassess scope and essential-or-important status when staff or financial data, group relationships, services, territory, critical-entity status, or national identification changes. Member States had to establish their entity lists by 17 April 2025 and review them at least every two years; check national information-submission and update duties.
Record awareness time and significance facts immediately; keep later technical findings as updates rather than reasons to delay the first assessment.
At Directive level, plan for an early warning within 24 hours, an incident notification within 72 hours, requested intermediate reports, and a final report within one month after the incident notification.
Member States were required to transpose NIS2 by 17 October 2024 and apply those measures from 18 October 2024. Check the current national law and filing route rather than treating the Directive text alone as the complete local procedure.
Check national law and sector-specific EU acts before filing. Some sector rules displace NIS2 provisions when their risk-management or reporting requirements are at least equivalent in effect.
Article 23(4) establishes the 24-hour early warning, 72-hour incident notification, intermediate reporting on request, one-month final report, ongoing-incident progress report, and trust-service-provider derogation.
The Directive's incident-handling and reporting duties can use operational evidence but add legal scope, significance, timing, content, and authority requirements.
Supports the NIST side by identifying SP 800-61 Rev. 3 as April 2025 guidance for incident preparation, detection, response, recovery, and lessons learned.
"incident response recommendations and considerations"