Reporting Deadlines for Cyber Incidents Under the GDPR, BSIG, and CRA—Every Hour Counts

After a cyber incident, companies have only 24 or 72 hours to file their initial report with the authorities.

A single incident can trigger multiple reporting obligations. While the various reporting regimes may provide for comparable deadlines in some cases, they differ fundamentally in terms of their scope of application, reporting thresholds, triggers for deadlines, and intended recipients. Relying indiscriminately on a supposedly uniform “72-hour rule” is therefore insufficient. Instead, companies should determine at an early stage which criteria are met, at what point knowledge is deemed to exist in the legal sense, and what information must be disclosed based on the available facts at that time.

An emergency plan is a good idea in this situation. After all, if you wait until an emergency arises to check which reporting requirements apply, you’ll lose valuable time.

It is often during the first 24 hours that it becomes clear which reporting regime applies. The often-cited 72-hour deadline applies only to a subset of potential cyber incidents.

Key Reporting Deadlines for Cyber Incidents at a Glance

What reporting requirements apply in the event of a cyber incident?

The applicable reporting requirements depend on the interests being protected in each case and the legally defined thresholds:

• The BSIG and the NIS-2reporting requirements are intended to ensure the cybersecurity of particularly important and increasingly critical facilities and to protect the services they provide.

• The Cyber Resilience Act (CRA) focuses on the security of products with digital components and the management of their vulnerabilities.
• The GDPR protects the rights and freedoms of individuals in the event of personal data breaches.

The result is a variety of reporting processes, which can often run in parallel.

GDPR Reporting Obligation: When Does the 72-Hour Deadline Apply?

The most well-known notification requirement is found in Article 33 of the GDPR. Data controllers must generally report a personal data breach to the competent data protection supervisory authority within 72 hours of becoming aware of it, provided that the breach is likely to result in a risk to the rights and freedoms of natural persons.

The 72-hour deadline begins as soon as the responsible party can assume with reasonable certainty that a security breach has resulted in a personal data breach. A full forensic investigation is not required. Initially, mere suspicions may be investigated. However, an organization must not artificially delay becoming aware of the breach through sluggish internal communication channels or delayed escalation. Processors must notify the controller without delay in accordance with Article 33(2) of the GDPR so that the controller’s deadline can be met in practice. Missing information may be provided in stages in accordance with Article 33(4) of the GDPR, provided this is done without undue delay.

The risk assessment is a two-step process: Notification to the supervisory authority is not required unless the breach is likely to pose a risk to the rights and freedoms of natural persons. In contrast, notification of the data subjects pursuant to Article 34 of the GDPR is required only if there is a likely high risk and must, as a general rule, be provided without undue delay. Particular consideration must be given to the nature and sensitivity of the data, the scope and identifiability of the data subjects, possible consequences, and risk-mitigating measures such as effective encryption. Regardless of the outcome, the controller must document every data breach, its impact, and the remedial measures taken in accordance with Article 33(5) of the GDPR. In particular, a justified decision not to report a breach should therefore be documented in a transparent manner.

The notification is not optional in terms of content either: According to Article 33(3) of the GDPR, it must include at least the nature of the breach, including, where possible, the categories and approximate number of data subjects and data records affected, the name and contact details of the data protection officer or another point of contact, the likely consequences of the breach, and the corrective measures taken or proposed by the controller, including any measures to mitigate potential adverse effects. If not all information can be provided at once, it may, pursuant to Article 33(4) of the GDPR, be provided in phases without extending the deadline for the initial notification.

Key Features of the GDPR Notification

• Notification to the Data Protection Supervisory Authority
• Deadline: 72 hours from the time of becoming aware
• Focus on Personal Data
• Risk to affected individuals as a key criterion
• Required information: Type of breach, contact information for the data protection officer, likely consequences, corrective measures

BSIG and NIS-2: The Tiered Reporting Process

The BSIG, which was amended to implement the NIS 2 Directive and has been in effect since December 6, 2025, provides for a tiered reporting system for critical and important facilities.

Significant security incidents must be reported. According to Section 2(11) of the BSIG, the determining factor is whether the incident has caused or could cause serious operational disruptions to the services or financial losses for the affected organization, or has caused or could cause significant material or immaterial harm to other natural or legal persons. The assessment is thus broader than under the GDPR: even an incident involving no personal data can be significant. For certain digital services, Implementing Regulation (EU) 2024/2690 specifies the criteria for determining materiality based on sector-specific criteria. These directly applicable criteria cover only the types of organizations expressly listed therein. For organizations in other sectors, the criteria of the Implementing Regulation are not directly binding. However, the BSI assumes that a significant security incident generally exists if at least one of the criteria set forth in Article 3(1) of the Implementing Regulation is met. Furthermore, a disruption to critical services is a strong indication of a significant security incident, but it does not replace an independent assessment of whether the legal threshold for significance has been met.

Unlike the GDPR, the BSIG provides for a multi-stage process. The reporting requirement under § 32(1) BSIG applies at the earliest upon establishment of the statutory reporting channel:

1. Early warning within 24 hours

The initial report must be submitted immediately, no later than 24 hours after becoming aware of the incident. In particular, it should indicate whether the incident is suspected to be the result of unlawful or malicious acts and whether there may be cross-border implications. A definitive analysis of the causes is not expected at this stage. Rather, what is required is a reliable assessment of the situation that accurately characterizes the incident and enables an initial evaluation by the authorities.

2. Report the incident within 72 hours

A more detailed report is required no later than 72 hours after the incident. This report should include an initial assessment of the impact, the severity of the incident, and any indicators of compromise, if applicable.

3. Final report after one month

As a general rule, a final report must be submitted no later than one month after the 72-hour report. It must contain a detailed description of the incident, including its severity and impact, the nature of the threat or underlying cause, and the corrective measures that have been implemented and are currently underway. If the incident is still ongoing at that time, a progress report will initially replace the final report. The final report will follow once the incident has been resolved. The phased process is therefore not a matter of filling out the same form three times, but rather a progressive consolidation of the current state of knowledge.

Key Features of the BSIG Regime

• Report to the joint reporting center of the BSI and the Federal Office for Civil Protection and Disaster Assistance
• Three reporting intervals (24 hours, 72 hours, 1 month)
• Focus on Security Incidents and Operational Disruptions
• Protection of services provided by facilities of particular importance and importance, as well as—in the case of operators of critical infrastructure—critical services

Cyber Resilience Act (CRA): Prompt Reporting of Actively Exploited Vulnerabilities

The Cyber Resilience Act introduces another European reporting system specifically aimed at manufacturers of products containing digital components.

Starting September 11, 2026, manufacturers must report actively exploited vulnerabilities and serious security incidents that affect the security of a product containing digital elements. This requirement takes effect one year before the general applicability of key CRA provisions on December 11, 2027. Reports are submitted via the central reporting platform established by ENISA, which notifies the responsible CSIRT and ENISA. The platform also enables the information to be forwarded to other affected entities—in particular, other CSIRTs—in accordance with the statutory mechanism. Open-source software stewards may also be included, provided they are involved in the development of the relevant products.

A phased approach is used here as well.

These elements must be strictly distinguished: An “actively exploited vulnerability” requires that a malicious actor actually exploit the vulnerability. The mere disclosure of a vulnerability, a proof-of-concept, or a high CVSS score is not sufficient in and of itself. A “serious security incident,” on the other hand, must significantly compromise the security of the product. The CRA specifically cites impacts on availability, authenticity, integrity, or confidentiality and links the severity to factors such as scope, duration, and impact on users. An event may fall into both categories and must then be assessed according to both criteria.

Report on Actively Exploited Vulnerabilities

The following deadlines apply to actively exploited vulnerabilities:

• Early warning within 24 hours of becoming aware of the situation
• Full report within 72 hours
• Final report no later than 14 days after a corrective or remedial measure has been provided. If no such measure is available within this timeframe, a status report must be submitted first, and the report must be supplemented once the measure is provided.

Reporting Serious Security Incidents

The following also apply in the event of serious security incidents:

• Early warning within 24 hours
• Detailed report within 72 hours
• Final report within one month

In addition to reporting to the authorities, there are recipient-specific disclosure obligations: Manufacturers must, where appropriate, immediately inform affected users of a serious security incident and the necessary risk mitigation measures. In cases of actively exploited vulnerabilities, affected users must be notified immediately of the vulnerability and, if necessary, of measures to mitigate or resolve the risk. Companies should therefore coordinate technical remediation, legal reporting, and external communication based on a unified assessment of the situation—without making hasty or contradictory statements.

Key Features of the CRA Regime

• Reporting to CSIRTs and ENISA via the central reporting platform
• Focus on products with digital elements
• Focus on Vulnerability Management
• Partially Overlapping Obligations to Provide Information to Users

Multiple Reporting Requirements: When the GDPR, BSIG, and CRA Apply Simultaneously

In practice, more than one legal act is often affected.

For example, an attack on a networked component in a hospital could compromise the availability of patient data, disrupt hospital operations, and be based on an actively exploited product vulnerability. However, a blanket triple reporting would still be incorrect. First, it must be determined whether the affected product falls within the CRA’s scope of application at all. Medical devices are generally excluded from the CRA to the extent that they are subject to specific product regulations under Union law. However, the same attack may affect another network or software component that is not excluded. Only then should the respective thresholds be assessed separately:

• GDPR: Has there been a breach of the confidentiality, integrity, or availability of personal data, and is it likely to pose a risk to data subjects?
• BSIG: Is the organization a particularly important or important entity—subject to additional obligations, if applicable, specifically as an operator of critical infrastructure—and does the incident meet the materiality threshold?
• CRA: Is a product with digital elements within the scope of application affected, and is there an actively exploited vulnerability or a serious security incident related to the product?

In such a case, various authorities would need to be notified, each with different reporting requirements and, in some cases, overlapping deadlines.

It is therefore crucial that companies do not organize incident management, data protection management, and product safety processes in isolation. Today, decisions regarding reporting must often be made within the first 24 hours.

What Should Happen in the First 24 Hours After an Incident

An effective process organizationally separates technical containment and incident investigation, but brings both strands together under a single incident lead. For the first 24 hours, the following minimum approach is recommended:

1. Record the timeline: Document the receipt of the first reliable information, escalations, and assessment decisions, including the time. Knowledge must not be confused with the completion of the forensic analysis.
2. Determine the scope of impact: Identify legal entities, services, products, data categories, user groups, and countries. For corporate groups, each responsible or regulated entity must be considered separately.
3. Assess three categories simultaneously: data breach and risk to individuals, significant security incident, and disruption of services; also evaluate product relevance, active exploitation, and severity.
4. Prepare an initial report that meets the deadline: Clearly distinguish between established facts, assumptions, and open questions. Where phased reporting is permitted, uncertainties may be transparently acknowledged and updated later.
5. Synchronize communications: Review official announcements, information for users and affected parties, customer communications, and communications with insurers and law enforcement agencies for inconsistencies and confidentiality risks.
6. Schedule follow-ups: Immediately define 72-hour, monthly, and, if necessary, 14-day deadlines as fixed work packages with assigned responsibilities and approval processes.

Common Misconceptions

• “No data breach, no GDPR notification”: Even the loss, alteration, or temporary unavailability of personal data can constitute a data breach.
• “One report covers all requirements”: The relevant authorities, legal provisions, and mandatory content vary. The CRA’s Single Reporting Platform does not replace the requirement to report to either the BSI or the data protection supervisory authority.
• “Report only once the cause has been determined”: The systems are deliberately tiered. Initial reports are based on the information available at the time. Follow-up reports serve to provide further details.
• “Every known vulnerability must be reported to the CRA”: For a vulnerability to be classified as “actively exploited,” it must actually be exploited by a malicious actor. In addition, the manufacturer’s general vulnerability management process remains in effect.

Conclusion

The GDPR, BSIG, and CRA address different risks: the protection of natural persons, the operational functionality of regulated services, and the security of digital products. This is precisely why their legal classification must be carried out in parallel. The 24-hour threshold becomes the decisive organizational benchmark, without every technical anomaly automatically being subject to reporting requirements.

Companies should therefore define responsibilities, contact information, reporting channels, legal review criteria, and approved templates before an emergency occurs. A central decision-making document is particularly effective, as it consolidates technical facts, fact-finding, risk assessments, reports, and addenda in a manner that stands up to audit scrutiny. Such a process prevents contradictory communication, provides a robust rationale for decisions to report or not to report, and at the same time accelerates the operational response to the incident.

From a strategic perspective, it is advisable not to wait until an incident occurs to determine the legally required reporting content for the three regimes, but rather to integrate it into the decision-making file in advance as standardized reporting templates. This involves pre-structuring the required information—such as the mandatory details under Article 33(3) of the GDPR or the indicators of compromise under Section 32 of the BSIG—as form fields. This significantly shortens the response time within the tight reporting deadlines and prevents individual mandatory details from being overlooked under time pressure.

See also: Embedding Digital Sovereignty in the Enterprise—Legal Requirements for IT Systems