Skip to content
Guides

NIS2 Article 23: telling your customers about incidents

Most writing on NIS2 incident reporting is about the reports to the authorities. Article 23 also has a sentence about the people who use your service. Here is the text, and which records a status page and its monitoring produce for each part of it.

By · Published Nov 1, 2026

Drafted with AI assistance, reviewed and published by Jose Franco.

What this page is

A reading aid, not legal advice. Whether NIS2 applies to you, whether an incident is significant, and what your national transposition adds are questions for your own compliance owner and your national authority. Every quotation below is from the Directive as published in the Official Journal, Directive (EU) 2022/2555, linked at the end.

What Article 23 says

Customers (Article 23(1), second sentence): “Where appropriate, entities concerned shall notify, without undue delay, the recipients of their services of significant incidents that are likely to adversely affect the provision of those services.”

Threats (Article 23(2)): entities communicate “without undue delay, to the recipients of their services that are potentially affected by a significant cyber threat any measures or remedies that those recipients are able to take in response to that threat. Where appropriate, the entities shall also inform those recipients of the significant cyber threat itself.”

Significant (Article 23(3)): 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 concerned”, or if “it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.”

Authorities (Article 23(4)): to the CSIRT or competent authority, an early warning “without undue delay and in any event within 24 hours of becoming aware of the significant incident”, an incident notification “within 72 hours”, and “a final report not later than one month after the submission of the incident notification”.

Article 21(2) lists the risk-management measures, among them “business continuity, such as backup management and disaster recovery, and crisis management” (point (c)) and “supply chain security” (point (d)).

Requirement by requirement

  • Notify recipients without undue delay (23(1)): a public RealUptime Status page. An incident posted there is shown on the page and emailed to its confirmed subscribers, and each update is timestamped. When a check fails, the incident can open on its own, so the clock starts when the outage does rather than when someone notices.
  • Tell recipients what they can do (23(2)): the same page carries free-text updates, so the measures and remedies go to the same subscribers in the same thread.
  • The 24-hour, 72-hour and one-month reports (23(4)): RealUptime does not file them. What it keeps is the timeline you will write them from: when checks first failed and in which regions, when the incident opened, every update and when it resolved. GET /api/v1/incidents/export?format=json returns every incident with its full update timeline.
  • Backup management (21(2)(c)): a heartbeat monitor on each backup job alerts when a backup does not finish. There are recipes for restic, Borg and borgmatic, Backrest and Proxmox.
  • Supply chain security (21(2)(d)): vendor dependency alerts tell you when a service you depend on reports an incident, and RealUptime Outages keeps a public record of each one. That is monitoring evidence, not a supplier assessment.
  • Who changed what: the account audit log records changes to monitors, status pages, on-call and alert rules with the person who made them, and exports as a file.

What RealUptime does not do

It does not decide whether an incident is significant, does not send anything to a CSIRT or authority, and does not make you compliant. RealUptime itself does not hold a security certification today; the trust page says where it stands. Application errors that never become an outage are in RealUptime Errors, and uptime checks are in RealUptime Monitor. The DORA guide covers the financial sector's equivalent.

Sources