Reporting a Data Breach: When Website Hacks and Malware Are Notifiable

The call usually comes on a Friday afternoon. The website redirects to a stranger’s page, an admin account nobody created has appeared in the backend, and somewhere in the uploads directory there are PHP files with cryptic names. The first question is almost always: how do we get the site clean again, quickly? The second question is one hardly anyone asks at that moment, and it has a clock already running: did personal data end up in the wrong hands?

This is exactly where an IT security incident turns into a data breach. What matters is whether personal data was destroyed, lost, altered, disclosed without authorisation or made accessible without authorisation. If so, the controller has to assess the situation, document it and, in some cases, report it to the data protection authority within 72 hours.

The short answer: not every hack is notifiable — a breach that is likely to result in a risk to the people affected is. If customer, prospect or employee data could have been leaked, viewed or altered, a prompt assessment is part of the job. Where the risk is high, informing the people affected is added. This article covers the technical and organisational side; assessing a specific case belongs with your data protection officer or legal counsel.

When does a data breach have to be reported?

The GDPR defines the term broadly. Article 4(12) covers not only a demonstrable data leak but also unauthorised access, loss, destruction or alteration of personal data. On a website, that means hijacked user accounts, readable form submissions, openly reachable backups or manipulated databases.

Article 33 GDPR requires notification to the competent supervisory authority as soon as the breach is likely to result in a risk to the rights and freedoms of natural persons. It should happen without undue delay, and at the latest within 72 hours of becoming aware. And even where you conclude, with good reason, that there is no risk and therefore do not notify: the incident still has to be documented.

Malware alone does not answer the question. What matters is what the attacker was able to reach and which data was sitting there. This classification helps as a first orientation:

Situation	Assessment under data protection law	Next step
The website was altered; after a robust review, personal data was not reachable.	Not automatically a notifiable data breach.	Secure the technology, document the review and its reasoning.
Attackers could potentially access contact forms, customer accounts, log files or databases.	A risk to the people affected is possible.	Assess scope and consequences promptly; review notification under Art. 33 GDPR.
Access credentials, payment data, ID scans, health data or large volumes of contact data are affected.	High risk is likely.	Notify the authority and review whether to inform the people affected under Art. 34 GDPR.

A robust answer needs technical facts: which systems were affected? Which time window is relevant? Was data encrypted? Do the logs narrow down the access? Was there any personal data sitting there at all — passwords, enquiries, files?

Often that is exactly what is missing. The host keeps access logs for only 14 days, the security plugin was installed after the incident, and when the malicious code was actually uploaded can only be estimated from file timestamps the attacker may have set themselves. These gaps do not push the decision back. They belong in the risk assessment as open points, and they move the investigation up.

72 hours: what operators should do after a website hack

The clock starts when you become aware, not when the forensics are complete. This is where most businesses stumble: you want to understand properly what happened first, and on the third day you notice the clock has been running. Article 33 explicitly allows information to be provided in phases if not everything is clear at the time of the first notification. A late notification, by contrast, needs a justification.

For a first structured sequence, these steps make sense:

1. Contain the affected website or compromised access without hastily destroying evidence.
2. Record the time of discovery, alerts, screenshots, log extracts and initial measures.
3. Review credentials, administrators, plugins, server access and data storage.
4. Involve the data protection officer, management and, where needed, hosting or IT partners.
5. Assess the categories of data, groups of people, possible access and conceivable consequences.
6. Document the notification decision and its reasoning, and involve the competent authority on time if there is a risk.
7. Implement protective measures: lock compromised access, install security updates, remove malicious code and check backups.

For larger incidents, plan the technical clean-up and the preservation of evidence separately. The reflex to restore a clean backup immediately is understandable and sometimes right. But it may overwrite exactly the traces that would later show whether any data was actually taken. Take an image of the compromised state first, then clean up, and you have both.

The organisational BSI checklist for IT security incidents likewise points to involving the competent data protection authority for a relevant breach. As a first technical and organisational response, it is a useful companion.

Where does a data breach have to be reported?

For most private-sector website operators in Germany, the competent authority is the data protection supervisory authority of the federal state where the main establishment is located. The Datenschutzkonferenz maintains an overview of the federal and state authorities. Many state authorities provide their own online notification forms.

Businesses based in Berlin, for example, use the data breach form of the Berlin Commissioner for Data Protection and Freedom of Information. Different rules apply to federal authorities and certain special sectors. Anyone operating multiple entities, international locations or regulated services is better off clarifying the lead authority in advance rather than searching when it counts.

Incidentally, the BSI is not the notification body for an ordinary GDPR website incident. Depending on the sector and legal classification, additional security or reporting duties may exist that are independent of the GDPR. This article deals with the GDPR notification duty.

What has to go into the notification?

The notification does not have to answer every technical question conclusively. It does need the minimum content from Article 33(3) GDPR:

• the nature of the breach and, where possible, the categories and approximate number of people and records affected
• contact details of the data protection officer or another point of contact
• the likely consequences for the people affected
• measures taken or planned to address the breach and mitigate possible adverse effects

The Berlin data protection authority explains these details and provides an online form. Its structure works well as a template, even if a different authority is competent for you.

The allocation of roles matters: the controller notifies the authority. A hosting provider, an agency or another service provider processing data on your behalf must inform the controller without undue delay under Article 33(2) GDPR. In practice, the 72-hour deadline rarely fails because of the form. It fails because on a Friday evening nobody knows who to call at the service provider and who signs off the notification in-house. A data processing agreement should therefore not merely exist, but name concrete escalation paths and reachable contacts.

When do the people affected have to be informed?

In addition to notifying the authority, Article 34 GDPR governs informing the people affected. It becomes due when the breach is likely to result in a high risk to their rights and freedoms: compromised credentials, financial data, special categories of personal data, or a constellation from which identity theft and fraud can arise.

The information has to explain clearly and plainly what happened, which consequences are possible, who is available as a contact and which protective measures you recommend. It can be omitted if appropriate protective measures such as effective encryption render the data unintelligible to unauthorised parties, or if subsequent measures effectively remove the high risk. This weighing belongs in the documentation too.

Which duties website operators have before an incident

The notification question usually only arises once the website is already compromised. But Article 32 GDPR requires appropriate technical and organisational measures beforehand. For websites, these are recurring operational tasks:

• keep WordPress, themes, plugins, PHP and server-side components up to date
• remove plugins, themes, user accounts and access you no longer need
• use individual admin accounts, strong passwords and two-factor authentication
• create backups, test restores and limit access rights
• evaluate security advisories, unusual changes and relevant logs
• define a reachable escalation path for data protection, hosting and IT

The case on outdated shop software summarised by Kolb Blickhan Partner shows why unmaintained systems are more than a technical problem: missing security updates enlarge the attack surface and raise the question of appropriate protective measures.

For WordPress websites, regular WordPress maintenance covers exactly this operation: updates, backup and restore logic, monitoring and checking unusual changes. If the cause of an incident is unclear or a system is already compromised, WordPress first aid or a WordPress inspection is the appropriate technical entry point.

The Bajorat Media Cockpit also offers a WordPress security check. It identifies known vulnerabilities, outdated components and maintenance gaps in a WordPress installation including its plugins, and ranks them by urgency. That lets you see open risks before they turn into an incident.

Conclusion: the technical response and the privacy process have to run together

Anyone treating a website hack purely as a technical problem overlooks the duties towards the authority and the people affected. A formal notification on its own helps just as little, though, as long as access stays open, updates are missing or the cause remains in the dark.

The order that has proven itself: contain the incident, secure the facts, assess personal data and risks, document the decision and, where notification is required, involve the competent authority on time. It does not make the Friday afternoon any more pleasant. But it makes it manageable, if you know in advance who to call.