NIS2 Directive
NIS2 Chapter IV: Incident Reporting (Article 23)

NIS2 Directive Art.23.1: Notify significant incidents to the CSIRT or competent authority, and warn affected service recipients

The core reporting duty attaches to any incident with a significant impact on the provision of the entity's services. Article 23(3) fixes the threshold: an incident is significant if it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity, or if it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. Capable of causing matters, because it brings in near-miss and contained events that could have gone further. Notification goes to the CSIRT or, where the Member State so provides, the competent authority, without undue delay, and must carry whatever lets the recipient determine cross-border impact. Where appropriate the entity must also tell the recipients of its services about significant incidents likely to affect service delivery. The Directive states that notifying does not of itself increase the notifying entity's liability, which removes one common reason for delay.

Maintained by Gerard BlokdykVerified against the published standard Control text last updated

What else in your programme already covers this

This control maps to 38 controls across 17 other frameworks. If you already hold one of them, the evidence you collected for it is the starting point here rather than new work.

C5 (Germany) · 4 controls

  • C5-OIS-05 Contact with Relevant Government Agencies and Interest Groups
  • C5-OPS-21 Involvement of Cloud Customers in the Event of Incidents
  • C5-SIM-01 Policy for security incident management
  • C5-SIM-03 Documentation and reporting of security incidents

NIST Cybersecurity Framework 2.0 · 4 controls

  • NIST-CSF-DE.AE-08 Incidents are declared when adverse events meet the defined incident criteria
  • NIST-CSF-RC.CO-04 Public updates on incident recovery are shared using approved methods and messaging
  • NIST-CSF-RS.CO-02 Internal and external stakeholders are notified of incidents
  • NIST-CSF-RS.CO-03 Information is shared with designated internal and external stakeholders

DORA · 3 controls

FedRAMP High · 3 controls

  • IR-6 Incident Reporting
  • IR-6(3) Incident Reporting | Supply Chain Coordination (IR-6(3))
  • IR-8 Incident Response Plan

FedRAMP Moderate · 3 controls

  • IR-6 Incident Reporting
  • IR-6(3) Incident Reporting | Supply Chain Coordination (IR-6(3))
  • IR-8 Incident Response Plan

ISO 27001:2022 · 3 controls

  • 5.24 Information security incident management planning and preparation 
  • 5.25 Assessment and decision on information security events
  • 5.5 Contact with authorities

ISO 27002:2022 · 3 controls

  • 5.24 Information security incident management planning and preparation
  • 5.25 Assessment and decision on information security events
  • 5.5 Contact with authorities

CIS Controls v8 · 2 controls

  • CIS-17.2 Establish and Maintain Contact Information for Reporting Security Incidents
  • CIS-17.3 Establish and Maintain an Enterprise Process for Reporting Incidents

Cloud Security Alliance Cloud Controls Matrix (CCM) v4.0.1 · 2 controls

GDPR · 2 controls

  • GDPR-Art.33 Notification of a personal data breach to the supervisory authority
  • GDPR-Art.34 Communication of a personal data breach to the data subject

NIST SP 800-53 Rev 5 · 2 controls

SOC 2 · 2 controls

  • SOC2-CC7.4 CC7.4 Responding to security incidents
  • SOC2-P6.6 P6.6 Notifying breaches and incidents

APRA CPS 234 · 1 control

  • CPS234-35 APRA Notification of Material Incidents within 72 Hours

CMMC 2.0 · 1 control

NIST SP 800-171 Rev 3 · 1 control

  • 03.06.02 Incident Monitoring, Reporting, and Response Assistance

PCI DSS 4.0 · 1 control

  • 12.10.1 12.10.1 Incident response plan ready for activation

Turkey Cybersecurity Law (Law No. 7545) · 1 control

  • 7.1.b-report Article 7(1)(b): report vulnerabilities and cyber incidents to the Presidency without delay

Every mapping shown was judged rather than inferred from wording similarity, and the ones that failed review are published too. See the coverage reports and what was rejected.

Other controls in NIS2 Chapter IV: Incident Reporting (Article 23)

You are reading one control. How much of NIS2 Directive have you already done?

NIS2 Directive Art.23.1 is one control. If you already hold one of the frameworks below, a reviewed crosswalk already says how much of NIS2 Directive your existing evidence covers. Hold DORA and 17 of 28 NIS2 Directive controls already carry evidence.

If you hold DORA60.7% covered · 11 gapsIf you hold C5 (Germany)53.6% covered · 13 gapsIf you hold NIST Cybersecurity Framework 2.050% covered · 14 gapsIf you hold ISO 27001:202242.9% covered · 16 gapsIf you hold ISO 27002:202242.9% covered · 16 gapsIf you hold Cloud Security Alliance Cloud Controls Matrix (CCM) v4.0.139.3% covered · 17 gaps

Each report names every control your existing framework evidences, every one it does not, the reasoning behind each claim, and the claims that were argued against and rejected. 0 were rejected on the DORA pair alone.

See the released pairs, $299 eachBrowse the graph free

Query this from an agent

The graph holds this control, the 38 it maps to, and the evidence behind each claim, over MCP and REST.

MCP endpointAll NIS2 Directive controls