Current situation: PHP2Shell. Two critical PHP vulnerabilities (CVSS 9.2) allow malicious code without login. Patches since 21 October 2026.What to do now →

GDPR Reporting Obligation: 72 Hours After the Incident

After an attack on a web server, a duty to notify the supervisory authority may apply. This page explains in general terms when the 72 hours start and what belongs in a report.

Last updated 4 min readLegal & Compliance

In short: If the protection of personal data is breached in an attack, Art. 33 GDPR requires a notification to the supervisory authority, where possible within 72 hours of becoming aware, provided there is a risk to the data subjects. In case of high risk, Art. 34 adds notifying the data subjects. Regardless of this, you must document every breach. This page is general information and not legal advice.

Important

Not legal advice: whether and when a reporting obligation exists in an individual case is assessed by your data protection officer or a lawyer. We supply the technical facts on which this assessment is based.

Data breach notification in 72 hours: what Art. 33 regulates

Art. 33 GDPR concerns the "personal data breach". This means any breach of security leading to the destruction, loss, alteration, unauthorized disclosure of, or unauthorized access to personal data. A compromised web server with a customer database, contact forms or applicant data can fall under it.

The notification to the supervisory authority is to be made without undue delay and, where feasible, within 72 hours after the controller became aware of the breach. It is not required if the breach is unlikely to result in a risk to the rights and freedoms of natural persons. Anyone who notifies later than 72 hours must justify the delay. Information may be provided in phases.

What a notification should contain

Art. 33(3) GDPR names minimum content. You should prepare these points even if not everything is established yet:

  • the nature of the breach, if possible with categories and approximate number of data subjects and records concerned
  • the name and contact details of the data protection officer or another contact point
  • the likely consequences of the breach
  • the measures taken or proposed to address the breach and to mitigate its possible adverse effects

With attacks on web servers in particular, the extent is often unclear at first. In that case, an honest initial notification with the known state and the announcement that further findings will follow helps.

When does the deadline start after a server attack?

The deadline is tied to awareness, not to the time of the attack. In practice the distinction is often difficult: a report about a vulnerability such as PHP2Shell does not by itself establish awareness of a data protection breach. But if you find concrete indications of a break-in, such as a web shell or suspicious database queries, the situation may look different.

So document from the start, with the time, who received which information when and which steps followed. This timeline helps with the legal assessment and with queries from the authority. A careful technical investigation, for example through IT forensics, clarifies whether and which data was actually affected.

Notifying data subjects under Art. 34

If the breach is likely to result in a high risk to personal rights and freedoms, the data subjects must also be notified without undue delay. This may be the case with access credentials, bank details or health data, for example. The notification should describe in clear and plain language what happened and name at least the contact point, the likely consequences and the measures taken.

Art. 34 provides for exceptions, for example if the data was rendered unintelligible to unauthorized persons, such as through encryption. If notifying every single person would involve disproportionate effort, a public communication or a similarly effective measure may be considered instead. Whether an exception applies is part of the legal assessment. How to inform customers in an understandable way is described in Crisis communication after an attack.

Documentation duty under Art. 33(5)

Regardless of the reporting obligation, Art. 33(5) GDPR requires every breach to be documented: the facts, the effects and the remedial action taken. This documentation must enable the supervisory authority to verify compliance. This applies even if, after review, you conclude that no notification is necessary.

For web servers, this means in practice: save logs before they are rotated, record findings with the time, and note decisions and their reasons. For PHP2Shell, the trade press recommends keeping server logs from 20 October 2026 onward. A patch also does not remove malware that has already been planted and does not prove that nothing happened beforehand.

Practical sequence in the first hours

  1. Report the suspicion internally to a fixed point and involve the data protection officer.
  2. Preserve evidence: logs, file lists, database extracts, before anything is deleted or rebuilt.
  3. Clarify technically whether personal data may be affected.
  4. Legal assessment of the notification and communication obligations, if necessary with a lawyer and the insurer.
  5. Notification through the form of the competent supervisory authority, with supplements as new findings emerge.

A prepared IT emergency plan shortens these steps considerably.

How does PHP SOS help?

  • We preserve logs and system states so that they remain usable for the assessment and a later review.
  • We clarify technically whether and which data was reachable, and provide an understandable summary for data protection officers and lawyers.
  • We keep a timeline of technical findings that you can use for the notification and documentation.
  • If a break-in is confirmed, we take over incident response and cleanup.

Frequently asked questions

When do the 72 hours start?

Under Art. 33 GDPR, from the moment the controller became aware of the breach. When that can be assumed in an individual case is a legal assessment. So document precisely who had which information and when.

Does every security vulnerability have to be reported?

No. A vulnerability alone is not yet a personal data breach. A report can become mandatory if there are indications that unauthorized persons had or could have had access to such data, and a risk to data subjects results from it.

What if I still do not know everything after 72 hours?

Art. 33(4) GDPR allows information to be provided in phases if it cannot be provided at the same time. A late notification must be justified. Waiting for complete clarity is therefore generally no reason to let the deadline pass.

Who reports if the host was affected?

The controller is obliged to report, so generally the company that operates the website. A processor such as the host must inform the controller without undue delay under Art. 33(2) GDPR.

Where do I report a data breach?

To the competent data protection supervisory authority, which for companies is usually the authority of the German federal state where they have their seat. Most authorities offer online forms for this.

Sources

Immediate contact

Every hour counts. Write to us now.

Briefly describe your system, PHP version and observation. We will get back to you, clarify the situation and work remotely until the incident is closed and documented.

Immediate help