A stolen laptop, a ransomware note, and an exposed cloud database can all be serious. But they do not automatically trigger the same legal response. What makes a cyberattack reportable is not simply whether an attacker got in. It is whether the incident meets a regulatory threshold based on personal-data risk, service disruption, sector obligations, and the organization’s location and role.
For European businesses, the practical challenge is speed. The first hours after an incident are often confusing: facts are incomplete, teams are containing damage, and leadership wants answers. Yet GDPR, NIS2, DORA, and industry-specific rules may start the clock before a full technical investigation is complete.
What makes a cyberattack reportable?
A cyberattack becomes reportable when it crosses the threshold set by the law or regulator that applies to your organization. That threshold can be triggered by a confirmed personal-data breach, a significant disruption to an essential service, or an incident that affects a regulated financial or digital operation.
The key word is risk. Regulators do not only ask, “Was there unauthorized access?” They ask what happened as a result, who may be affected, whether services were interrupted, and how likely the consequences are to cause harm.
A phishing email blocked by security controls may be a security event worth documenting, but it is unlikely to be reportable on its own. A phishing campaign that gives an attacker access to employee records, customer accounts, or a hospital scheduling system is different. Even if the organization quickly restores systems, the exposure or outage may still require notification.
This is why incident reporting cannot sit solely with IT. Security teams establish the technical facts, but legal, privacy, compliance, communications, and business owners all have a role in assessing the real-world impact.
GDPR: when a cyberattack becomes a personal-data breach
Under the GDPR, a reportable breach involves personal data and creates a risk to individuals’ rights and freedoms. Personal data can include obvious identifiers such as names, email addresses, account details, and ID numbers. It can also include less obvious information, from location records to employee performance data and online identifiers.
The breach itself may involve a loss of confidentiality, integrity, or availability. In other words, data may have been accessed or disclosed without authorization, altered or destroyed, or made unavailable when people need it. A ransomware attack can therefore be a GDPR issue even if there is no evidence that data was exfiltrated. If records are encrypted and the organization cannot access them, availability has been compromised.
Organizations must notify the relevant supervisory authority when a breach is likely to pose a risk to people. The notification should normally happen within 72 hours of becoming aware of the breach. The deadline is not an invitation to wait for certainty. It requires a good-faith, evidence-based initial assessment, with further information provided later if necessary.
When the breach is likely to create a high risk to individuals, the organization must also communicate directly with affected people without undue delay. Think of a breach involving passwords, payment information, sensitive health data, identity documents, or records that could expose someone to discrimination, fraud, or reputational harm.
Context matters. A misdirected email containing a name and meeting time is not assessed the same way as an unencrypted spreadsheet containing passport copies and salary information. Encryption, prompt recovery, the sensitivity of the data, and whether an unauthorized recipient can be trusted to delete it all influence the decision.
The processor-controller distinction matters
Many companies process data on behalf of another organization. Under GDPR, a processor that discovers a personal-data breach must notify the controller without undue delay. The controller is generally responsible for deciding whether to notify the supervisory authority and the affected individuals.
That division can create friction during a fast-moving incident. Contracts should make escalation routes clear before a crisis, including who can make decisions outside normal business hours. A supplier’s delayed disclosure can leave a controller with very little room to meet the 72-hour deadline.
NIS2: reportable incidents go beyond personal data
NIS2 expands the conversation from privacy to operational resilience. It applies to covered entities in critical and important sectors, including energy, transport, health, digital infrastructure, public administration, manufacturing, and certain digital services. Its exact application depends on national implementation and an organization’s size, sector, and role.
Under NIS2, a significant incident is one that has caused or is capable of causing severe operational disruption or financial loss, or that has affected or is capable of affecting other people or organizations through considerable material or non-material damage.
This means a cyberattack can be reportable under NIS2 even if no personal data is involved. A prolonged outage at a managed service provider, a disruption to a logistics platform, or a compromise that interrupts hospital operations may meet the threshold because of the service impact.
NIS2 sets a staged reporting model. In broad terms, covered organizations provide an early warning within 24 hours, a more detailed incident notification within 72 hours, and a final report within one month. National rules and competent authorities can add practical details, so organizations should not treat the directive as a one-size-fits-all checklist.
The leadership implication is clear: reporting readiness is a governance issue. NIS2 puts accountability squarely on management bodies, which are expected to approve, oversee, and understand cybersecurity risk-management measures. Cybersecurity is no longer a technical topic that can be delegated without meaningful board-level attention.
Financial services and sector-specific rules
For financial entities, the Digital Operational Resilience Act, or DORA, adds another reporting layer. Banks, insurers, investment firms, payment providers, and many ICT suppliers supporting them face specific requirements for major ICT-related incidents. The assessment considers factors such as the number of affected clients or counterparties, duration, geographic spread, data losses, service criticality, and economic impact.
Other sectors may have their own notification duties as well. Telecom providers, healthcare organizations, public bodies, and operators of critical infrastructure often face rules that overlap with GDPR and NIS2. One attack can therefore create several reporting obligations, directed to different authorities and operating on different timelines.
This overlap is not a reason to report indiscriminately. Over-reporting can confuse regulators and waste valuable response capacity. Under-reporting is riskier, particularly where an organization lacks a documented rationale. The goal is a defensible decision based on the facts known at the time, not a perfect answer produced days too late.
A practical way to assess an incident
A useful first assessment asks four questions. First, was there a security incident with confirmed or reasonably suspected unauthorized access, disclosure, alteration, loss, or disruption? Second, did personal data, critical systems, essential services, or regulated operations play a role? Third, what is the likely impact on people, customers, partners, and the organization’s ability to operate? Fourth, which laws, contracts, and sector rules apply?
From there, create an incident timeline. Record when the organization detected suspicious activity, when it became aware of a likely breach, containment actions, systems affected, data categories, and decision-makers involved. Preserve evidence, but do not let forensic perfection delay urgent notifications.
It also helps to separate three decisions that are often blurred together: whether to notify a regulator, whether to notify affected individuals or customers, and whether to make a public statement. These decisions may align, but they are not identical. A public statement should be accurate and useful, not an improvised substitute for regulatory reporting.
Reporting is also a leadership and trust test
The quality of a cyber incident response is visible long after systems return to normal. Employees notice whether leaders communicate clearly. Customers notice whether they receive timely, practical advice. Partners notice whether facts are shared early enough for them to protect their own operations.
For teams working to build more accountable and inclusive technology organizations, that matters. Security decisions affect real people unevenly, especially when compromised information can expose someone to financial harm, harassment, discrimination, or career consequences. Incident plans should reflect those human impacts, not only uptime metrics and legal minimums.
The best time to decide what makes an attack reportable is before an attacker tests the question. Build a cross-functional response team, rehearse the first 72 hours, and make sure the people authorized to act can reach one another when the stakes are highest.
