# Incident reporting deadlines (FAQ)

> 35 questions on Incident reporting deadlines, in plain language: what to check, what NetSenX shows and what a sensor cannot see.

Source page: https://netsenx.com/en/faq/reporting

## When does the NIS2 24-hour clock start?

When the entity becomes aware of the significant incident, not when the incident began. Article 23(4) counts both the early warning (24 hours) and the incident notification (72 hours) from that moment.

https://netsenx.com/en/faq/when-does-the-nis2-24-hour-clock-start

## What has to be in a NIS2 early warning?

Under Article 23(4)(a), the early warning indicates, where applicable, whether the significant incident is suspected of being caused by unlawful or malicious acts and whether it could have a cross-border impact. The details follow in the 72-hour notification.

https://netsenx.com/en/faq/what-has-to-be-in-a-nis2-early-warning

## Is the final report due one month after the incident?

No: one month after the submission of the incident notification. If the incident is still ongoing at that point, a progress report is due instead, and the final report within one month of the incident being handled.

https://netsenx.com/en/faq/is-the-final-report-due-one-month-after-the-incident

## Are the deadlines different for trust service providers?

Yes. A trust service provider notifies significant incidents that affect the provision of its trust services within 24 hours of becoming aware of them, instead of 72 hours.

https://netsenx.com/en/faq/are-the-deadlines-different-for-trust-service-providers

## How fast must a data breach be reported under the GDPR?

Under Article 33 GDPR, the controller notifies the supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to people. Under Article 34, when the breach is likely to result in a high risk, the people affected must be told without undue delay. NetSenX prepares an Article 33 notification for your DPO; the decision and the submission stay with you.

https://netsenx.com/en/faq/how-fast-must-a-gdpr-breach-be-reported

## What does the CRA require when a vulnerability is exploited?

Article 14 of the Cyber Resilience Act requires manufacturers of products with digital elements to notify actively exploited vulnerabilities in their products, and severe incidents that affect the security of those products, in several stages. For the stages, their deadlines and who receives the notifications, see Regulation (EU) 2024/2847, Article 14. These reporting duties apply from 11 September 2026. They concern manufacturers, not companies that only use the products, although a user's own incident may still have to be reported under NIS2 or the GDPR.

https://netsenx.com/en/faq/what-does-the-cra-require-when-a-vulnerability-is-exploited

## Does DORA apply to us?

Yes, if you are a financial entity, and indirectly if you supply ICT services to one. DORA, the Digital Operational Resilience Act (Regulation (EU) 2022/2554), applies from 17 January 2025 to financial entities such as banks, insurers, investment firms and payment institutions, and to critical ICT third-party providers designated under it. Article 19 requires financial entities to report major ICT-related incidents to their competent authority, with an initial notification, an intermediate report and a final report; the time limits are set in technical standards adopted under Article 20. If you are a financial entity, DORA's rules on ICT incidents take precedence over NIS2's general ones for you. If you supply ICT services to a financial entity, DORA reaches you through your contract: Article 30 lists provisions such contracts must contain, including assistance during incidents, audit rights and exit plans. Expect detailed questions and contract clauses from financial customers.

https://netsenx.com/en/faq/does-dora-apply-to-us

## What counts as a significant incident under NIS2?

One that causes, or could cause, severe disruption, financial loss or considerable damage to others. In the words of Article 23(3), an incident is significant if it has caused or is capable of causing severe operational disruption of your services or financial loss for your company, or if it has affected or can affect other people or organisations by causing considerable material or non-material damage. Only significant incidents must be reported. Capable of means you do not wait for the damage to happen. For certain digital providers, such as cloud, DNS and managed service providers, Implementing Regulation (EU) 2024/2690 sets more precise thresholds; national laws and authorities may publish guidance for others. Decide in advance, in your incident procedure, which criteria you will use, such as services down for a set time, customer data affected or a criminal actor involved, and who makes the call. NetSenX tracks the deadlines once you decide; the decision is yours.

https://netsenx.com/en/faq/what-counts-as-a-significant-incident-under-nis2

## Is a failed or blocked attack reportable under NIS2?

Usually not as a significant incident, but it can be, and you can report it voluntarily. The mandatory duty in Article 23 covers significant incidents: those that caused, or could have caused, severe disruption, financial loss or considerable damage to others. An attack that was stopped before it had any effect normally does not meet that test, although one that came very close, for example ransomware caught after it had reached the backup server, may. NIS2 also distinguishes near misses and significant cyber threats, and Article 30 lets entities notify them voluntarily, which helps the CSIRT warn others. Record every such event in your incident register with your reasoning, so you can explain later why you did or did not report. NetSenX keeps the alerts behind each decision.

https://netsenx.com/en/faq/is-a-blocked-attack-reportable-under-nis2

## How can a small team meet the NIS2 24-hour early-warning deadline?

By preparing the parts that do not depend on the incident before anything happens. The early warning under Article 23(4)(a) is short: it says that a significant incident has occurred and, where applicable, whether it is suspected to be unlawful or malicious and whether it could have a cross-border impact. The details follow in the 72-hour notification. So prepare a one-page template, the reporting channel and login for your national CSIRT or authority, a named person and a deputy who may submit it, and an internal rule for who decides that an incident is significant. Hold one rehearsal a year. Small teams lose most time finding out what happened, so make sure alerts reach someone at night and at weekends. NetSenX starts the deadline clock per incident and keeps the alerts with time, devices and destinations in one place.

https://netsenx.com/en/faq/how-can-a-small-team-meet-the-nis2-24-hour-deadline

## What should we have ready before the NIS2 24-hour deadline arrives?

A short list of facts, a ready channel and a person who may send it. For the early warning itself you need: the time you became aware of the incident; a plain description of what is affected so far; whether you suspect a malicious or unlawful act; and whether other countries could be affected. For the 72-hour notification that follows, start collecting at once: severity and impact, affected systems and services, indicators of compromise such as malicious addresses or file hashes, and the measures taken. Keep a running timeline from the first minute, with who did what. Check whether personal data is involved, because a GDPR notification may run in parallel. NetSenX gives you the network part of that timeline: the first unusual connection, the devices involved, destinations and volumes, and the Article 23 deadlines counted from the moment you record awareness.

https://netsenx.com/en/faq/what-should-we-have-ready-before-the-nis2-24-hour-deadline

## Do we have to tell our own customers about a NIS2 incident?

Sometimes. Under Article 23(1), where appropriate, entities in scope notify the recipients of their services without undue delay of significant incidents that are likely to adversely affect the provision of those services. Under Article 23(2), where applicable, entities also tell recipients potentially affected by a significant cyber threat what they can do in response, and, where appropriate, about the threat itself. Authorities can order such information too. National laws set the detail: in Germany, the BSI can order entities to inform recipients (section 35(1) BSIG), and entities in sectors such as finance, digital infrastructure and ICT service management must inform them about significant cyber threats (section 35(2)). Contracts and the GDPR may add their own duties. Prepare a customer message template as part of the incident plan.

https://netsenx.com/en/faq/do-we-have-to-tell-customers-about-a-nis2-incident

## Do we have to report a ransomware attack under the GDPR?

Often yes, if personal data was affected, even when nothing was stolen. The GDPR defines a personal data breach in Article 4(12) as a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. Encryption by ransomware makes personal data unavailable, which is a breach of availability, and attackers often copy data before encrypting. Under Article 33, the controller notifies the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to people, for example because a recent backup restored everything quickly and nothing left the network. Document the reasoning either way. NetSenX can show whether unusual uploads left monitored devices before the encryption, which matters for that assessment.

https://netsenx.com/en/faq/do-we-have-to-report-ransomware-under-the-gdpr

## If the stolen data was encrypted, must we still notify?

Possibly the authority, but often not the people affected. Article 34(3)(a) of the GDPR says that individuals need not be told about a breach if the controller had applied measures, such as encryption, that render the data unintelligible to anyone not authorised to access it. The notification to the supervisory authority under Article 33 is a separate question: it is needed unless the breach is unlikely to result in a risk to people, and that depends on how strong the encryption was, whether the key was also exposed and whether the data is still available to you. If the key was on the same stolen laptop, or the encryption was weak, the data should be treated as exposed. Record which data was encrypted, how, and where the keys were. Network evidence of what left, and when, helps your data protection officer make the call.

https://netsenx.com/en/faq/if-stolen-data-was-encrypted-must-we-still-notify

## We cannot complete the GDPR notification within 72 hours. Can we notify in phases or late?

Yes, in phases, and late only with reasons. Article 33(4) of the GDPR allows the information to be provided in phases, without undue further delay, where it is not possible to provide it all at the same time, and Article 33(1) requires a notification made after 72 hours to be accompanied by the reasons for the delay. So do not wait for the full picture: send an initial notification within the deadline with what you know, the nature of the breach, likely consequences and measures taken so far, and the contact of your data protection officer, then update as facts arrive. Keep a record of when you became aware and why any part came later. Supervisory authorities usually provide online forms that support follow-ups. NetSenX prepares an Article 33 notification for your DPO from the incident data; submitting it stays with you.

https://netsenx.com/en/faq/we-cannot-meet-72-hours-can-we-notify-in-phases

## When does the GDPR 72-hour notification clock start?

When the controller becomes aware of the personal data breach, not when the breach began. Article 33(1) counts the 72 hours from becoming aware. Guidelines from the European Data Protection Board treat a controller as aware when it has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised. A short initial investigation to establish that is allowed, but it must be prompt; you cannot delay awareness by not looking. A processor that discovers a breach must tell the controller without undue delay (Article 33(2)), and the controller's clock generally starts when it learns of it. So record, in your incident log, the exact time someone concluded that personal data was involved. NetSenX lets you record the awareness time per incident, and keeps the alerts that show when the activity started.

https://netsenx.com/en/faq/when-does-the-gdpr-72-hour-clock-start

## One incident, several reports: how do NIS2, the GDPR and DORA fit together?

Each law has its own report, recipient and clock, and one incident can trigger several. A significant incident at an entity in scope goes to the CSIRT or competent authority under NIS2 Article 23; if personal data is affected, the controller also notifies the data protection authority under GDPR Article 33; a financial entity reports major ICT-related incidents under DORA Article 19 instead of NIS2 for those incidents; and a product manufacturer may have duties under the Cyber Resilience Act, see Regulation (EU) 2024/2847, Article 14. Some national systems offer a single portal, but do not assume one report covers all. Build one incident record and generate each report from it, so the facts match. NIS2 Article 35 also asks NIS2 authorities to inform data protection authorities of breaches they learn about. NetSenX tracks the NIS2 deadlines and prepares a GDPR Article 33 draft from the same incident data.

https://netsenx.com/en/faq/one-incident-several-reports-nis2-gdpr-dora

## What is a major ICT-related incident under DORA?

One that a financial entity classifies as major using the criteria in Article 18 of DORA and the technical standards adopted under it. Article 18 lists criteria such as the number and relevance of clients or financial counterparts affected, the amount or number of transactions affected, reputational impact, duration and service downtime, geographical spread, data losses affecting availability, authenticity, integrity or confidentiality, the criticality of the services affected and economic impact. The standards turn these into thresholds. Only major incidents must be reported under Article 19; significant cyber threats may be reported voluntarily. Build the classification into your incident procedure, so the decision is quick, repeatable and documented, and agree with your ICT providers how they will feed you the facts you need. Financial customers will expect that from their suppliers too.

https://netsenx.com/en/faq/what-is-a-major-ict-incident-under-dora

## What are the DORA incident reporting deadlines?

They are set in the technical standards adopted under Article 20 of DORA, not in the regulation itself. Read those standards and your competent authority's guidance for the exact hours and days. Article 19(4) fixes the sequence: an initial notification, an intermediate report as soon as the status of the original incident has changed significantly or handling has changed based on new information, followed by updated notifications as relevant, and a final report when the root cause analysis has been completed. The standards also set the content and templates. Because the time limits are linked to when the incident is detected and classified as major, the speed of your classification matters as much as the speed of writing. If you are an ICT supplier to a financial entity, expect your contract to require you to notify the customer quickly enough for it to meet these deadlines.

https://netsenx.com/en/faq/what-are-the-dora-incident-reporting-deadlines

## Where are Cyber Resilience Act vulnerability reports submitted?

Through the single reporting platform that ENISA operates for the Cyber Resilience Act. Under Article 14 of Regulation (EU) 2024/2847, manufacturers of products with digital elements notify actively exploited vulnerabilities in their products, and severe incidents affecting the security of those products, through that platform; the notification goes to the CSIRT designated as coordinator in the Member State of the manufacturer's main establishment and to ENISA. For the stages, deadlines and contents, see Regulation (EU) 2024/2847, Article 14. These duties concern manufacturers, including software companies that place products on the EU market, not businesses that only use the products. Users may still have their own NIS2 or GDPR reports to make after the same event. If you develop software, set up a vulnerability-handling process and decide who has access to the platform before you need it.

https://netsenx.com/en/faq/where-are-cra-vulnerability-reports-submitted

## Should we report a cyber incident to the police as well as the regulator?

Often yes, but it is a separate decision from regulatory reporting. A ransomware attack, data theft, fraud or extortion is usually a crime, and a criminal complaint can help with insurance claims, with banks trying to recall a fraudulent transfer, and with investigations that link your case to others; some insurers ask for a police reference. A complaint to the police does not replace notifications to the CSIRT, the competent authority or the data protection authority, and those do not replace a complaint. Many countries have specialised cybercrime units or online forms. Before filing, agree with your lawyers and incident-response firm what evidence to hand over and how to preserve it, so you do not destroy what investigators need. NIS2 early warnings already ask whether you suspect an unlawful or malicious act; your answer and a police report should be consistent.

https://netsenx.com/en/faq/should-we-report-a-cyber-incident-to-the-police

## What information should an incident report to the authorities contain?

The basics are the same everywhere: what happened, when, what was affected, how bad it is, what you have done and whom to contact. Under NIS2 Article 23(4), the early warning says whether the incident is suspected to be malicious or unlawful and whether it could have a cross-border impact; the 72-hour notification adds an initial assessment of severity and impact and, where available, indicators of compromise; and the final report adds a detailed description, the type of threat or root cause, mitigation measures and cross-border impact. Under GDPR Article 33(3), a breach notification describes the nature of the breach, the categories and approximate numbers of people and records, the likely consequences, the measures taken and the data protection officer's contact. Keep facts and assumptions clearly separate. NetSenX supplies times, devices, destinations and volumes from the network.

https://netsenx.com/en/faq/what-should-an-incident-report-contain

## Do we still have to report an incident that is already resolved?

Yes, if it was significant or involved a personal data breach that must be notified; fixing it does not remove the duty. NIS2 Article 23 attaches the reporting duty to a significant incident, whether or not it is still ongoing, and the deadlines run from when you became aware of it. If you discover only now that last month's outage was an attack, the clock starts at that discovery, and you should report promptly, explaining the timeline. Under the GDPR, a breach that is likely to result in a risk to people must be notified even if it has been contained; containment may lower the risk and affect what you write. A resolved incident can usually go straight to a combined notification with the facts already known, but follow your authority's format. Record the dates of occurrence, awareness and resolution separately.

https://netsenx.com/en/faq/can-we-report-an-incident-that-is-already-resolved

## What reduces a GDPR fine after a data breach?

Mostly what you did before and after: prompt notification, real mitigation and cooperation. Article 83(2) of the GDPR lists the factors authorities weigh, including the nature, gravity and duration of the infringement, whether it was intentional or negligent, the action taken to mitigate the damage to people, the technical and organisational measures already in place, previous infringements, the degree of cooperation with the authority, the categories of data affected, and how the authority learned of the breach, in particular whether you notified it. Fines for the most serious infringements can reach EUR 20 million or 4% of worldwide annual turnover under Article 83(5). In practice: notify on time with facts, show the security measures that existed, contain the breach quickly, inform affected people where required and document every step. NetSenX helps with the timeline and with an Article 33 draft for your DPO.

https://netsenx.com/en/faq/what-reduces-a-gdpr-fine-after-a-data-breach

## Can NetSenX prepare a GDPR Article 33 breach notification?

Yes, as a draft for your data protection officer; deciding and submitting stay with you. From the incident data, NetSenX prepares a draft with what the network shows: when the problem was detected and which devices and destinations were involved. Article 33(3) also asks for information only you have, such as the categories and approximate numbers of people and records affected, the likely consequences, the measures taken and the contact details of your DPO. Network evidence has limits: NetSenX sees connections, volumes and destinations, not which files or records left, so the DPO must complete the content from other sources. The draft saves time on Friday evening when the 72-hour clock is running, and keeps the facts consistent with your NIS2 reports. Check it, complete it and file it with your supervisory authority yourself.

https://netsenx.com/en/faq/can-netsenx-prepare-a-gdpr-article-33-notification

## Does a security tool's audit log help with IT general controls?

Yes, for the part of the controls that concerns the tool itself. Financial-statement auditors and ISO or SOC 2 assessors test IT general controls: who has access to systems, how changes are approved and recorded, and how operations and incidents are monitored. A security tool's audit log provides evidence for its own slice: who has accounts, who changed detection settings or notification rules, who closed or decided on each alert, and when. On every plan, NetSenX keeps such an audit log, with retention that grows with the plan. It does not record changes in your ERP, file servers or other systems, so those need their own logs. Export the relevant extract for the audit period, and pair it with your access reviews and change tickets, so the auditor sees one consistent story.

https://netsenx.com/en/faq/does-a-security-tools-audit-log-help-with-it-general-controls

## How do we prove who changed a security setting, and when?

With an audit log that records each change, the person who made it and the time, kept where it cannot be quietly edited. For your own systems, that means enabling change logging on firewalls, directory services, cloud consoles and security tools, sending the logs to a central place with restricted access, and linking changes to approved tickets. Shared administrator accounts make proof impossible, so give each person their own named account with multi-factor authentication. Review the logs for unexpected changes, especially outside working hours. For NetSenX itself, the audit log on every plan records who changed detection settings, notification rules or team members and who decided on alerts, with timestamps; you can export the extract for an auditor. It covers changes made in NetSenX, not settings in your other systems.

https://netsenx.com/en/faq/how-do-we-prove-who-changed-a-security-setting

## How do we show an auditor which parts of our network are monitored?

With a simple coverage statement backed by evidence, including the gaps. List each site and network segment, whether a sensor or agent watches it, since when, and what it covers; then mark what is not watched, such as guest Wi-Fi, a branch office or a cloud environment, and how you handle it instead. Attach evidence: the sensor list, a recent alert from each monitored segment, and the network map. Auditors trust an honest statement with known gaps more than a claim of full coverage that falls apart on the first question. In NetSenX, one agent on a switch's mirror port (SPAN) or a network TAP watches a whole segment, and the dashboard shows which agents run where; traffic on a segment you do not mirror stays out of view, and NetSenX does not pretend otherwise.

https://netsenx.com/en/faq/how-do-we-show-an-auditor-which-parts-of-the-network-are-monitored

## What does network detection miss if a segment is not mirrored?

Everything that happens only inside that segment. A sensor sees the traffic it receives; if a switch port is not mirrored to it and no agent runs on the hosts there, connections between devices on that segment, such as an attacker moving from a PC to a file server next to it, stay invisible. You may still see traffic that leaves the segment through a monitored point, for example to the internet or to another site, but the internal steps of an intrusion are often exactly what you need. Decide by risk: mirror the segments with servers, administration, finance, HR and production first, then the rest. Where mirroring is impractical, run the agent on the important hosts themselves. NetSenX shows which segments its sensors and agents watch, so the gaps are visible.

https://netsenx.com/en/faq/what-does-network-detection-miss-if-a-segment-is-not-mirrored

## What should an incident log contain for a NIS2 audit?

Enough to reconstruct each incident and each decision without asking anyone's memory. For every entry: a unique reference; when the incident started, when it was detected and by what, and when you became aware of it as significant or not; a short description and the systems, services and data affected; the severity assessment and who made it; whether it was reported, to whom and at what times, with copies of the reports; containment, eradication and recovery steps with times and owners; the root cause; and the lessons and changes that followed. Log near misses too, with the reason they were not reported. Keep the log tamper-resistant and access-controlled. NetSenX contributes the network side automatically: alerts with time, devices and destinations, NIS2 deadlines per incident and the audit log of who decided what.

https://netsenx.com/en/faq/what-should-an-incident-log-contain-for-a-nis2-audit

## How do we show an auditor what we decided on each security alert?

With a record that links each alert to a decision, a person, a time and a reason. Auditors want to see that alerts do not disappear: each was looked at, classified as harmless, under investigation or an incident, and closed with an explanation. A spreadsheet can do this for a handful of alerts, but it breaks down as volume grows and is easy to fill in afterwards. Use the tool's own workflow where you can, write short reasons rather than one-word statuses, and review a sample of closed alerts each quarter to check the quality of the decisions. In NetSenX, analyst decisions on alerts are recorded in the audit log on every plan, with who decided and when; from the Starter plan you can export PDF reports for the auditor.

https://netsenx.com/en/faq/how-do-we-show-an-auditor-what-we-decided-on-each-alert

## How long must we keep security incident records?

NIS2 sets no single retention period, so decide one yourself and write down why. Several rules point the same way. The GDPR requires controllers to document every personal data breach (Article 33(5)) so that the authority can verify compliance, which implies keeping the record for as long as that check could reasonably come. NIS2 supervisors can ask for evidence of past incidents and reports, insurers may examine a claim long after the event, and limitation periods for contract and liability claims run for years in many countries. Sector rules and national laws may set their own periods. A common approach is to keep the incident register and reports for several years, and raw logs for a shorter time, deleting personal data that is no longer needed. NetSenX's alert history and audit-log retention depend on the plan; export what you must keep longer.

https://netsenx.com/en/faq/how-long-must-we-keep-security-incident-records

## Can a network map be generated automatically from traffic for an auditor?

Yes, for the segments you monitor, and it is often more accurate than a drawn diagram. A map built from observed traffic shows which devices exist, the names they announce and who talks to whom, including connections nobody documented, such as a workstation that reaches a server it should not or a supplier's remote session. It does not show what never sends traffic, segments without a sensor, or the intended design, so keep your architecture diagram and use the observed map to check it. On every plan, NetSenX builds such a network map from monitored traffic, with each device's first and last seen. Before showing it to an outside auditor, consider what it reveals: device names can contain employees' names and the map describes your internal structure, so share it on screen or under a non-disclosure agreement.

https://netsenx.com/en/faq/can-a-network-map-be-generated-automatically-for-an-auditor

## Must we document data breaches that we decide not to report?

Yes. Article 33(5) of the GDPR requires the controller to document every personal data breach, comprising the facts, its effects and the remedial action taken, whether or not it was notified to the supervisory authority. The point is to let the authority verify compliance later, including your decision that a breach was unlikely to result in a risk to people. So for each breach, record what happened, which data and people were affected, why you concluded that notification was or was not needed, who decided and when, and what you changed. Keep it in a breach register separate from, but linked to, your security incident log. Authorities can ask for it during an inspection or after a complaint, and a missing record of an unreported breach looks worse than the breach itself. NetSenX keeps the alert evidence behind each entry for the retention period of your plan.

https://netsenx.com/en/faq/must-we-document-data-breaches-we-do-not-report

## When must we tell the affected people about a data breach?

When the breach is likely to result in a high risk to their rights and freedoms. Article 34 of the GDPR then requires the controller to communicate it to them without undue delay, in clear and plain language, describing the nature of the breach, the likely consequences, the measures taken or proposed and the contact of the data protection officer. High risk typically means data that can cause real harm, such as identity documents, bank or health data, passwords, or information that enables fraud. Article 34(3) lists exceptions: the data was made unintelligible, for example by strong encryption; later measures mean the high risk is no longer likely; or individual messages would take disproportionate effort, in which case a public communication is used instead. The supervisory authority can also require you to inform people. Tell them what to do, such as changing passwords or watching for phishing.

https://netsenx.com/en/faq/when-must-we-tell-affected-people-about-a-data-breach

General information, not legal advice. National laws can add to the EU texts quoted here, for example deadlines, forms or reporting channels: check your own country's rules.

FAQ: https://netsenx.com/en/faq