Hacked Site and GDPR: When a Data Breach Must Be Notified to the Garante

When a WordPress site is compromised, the first concern is technical: remove the malware, shut the door, get back online. But if the site holds customer accounts, orders, requests submitted through contact forms or newsletter subscribers, there is a second question that cannot wait until the cleanup is over: did the attack involve personal data, and if so, must it be notified to the Italian Data Protection Authority (Garante)?

The answer depends on specific facts, and those facts come precisely from forensic analysis: which data was reachable, whether anyone read or exported it, how long the attacker stayed inside. In this article we look at what the European regulation (GDPR) provides for personal data breaches, who has to do what when the site is run by an agency or a hosting provider, and how the evidence collected on the server helps you reach a reasoned decision within the required time.

This article is for information purposes only and does not constitute legal advice. Assessing a breach and deciding whether to notify it is the responsibility of the data controller, with the support of its data protection officer (DPO), if appointed, or of a qualified professional.

Is a hacked site always a data breach?

Article 4(12) of the GDPR defines a personal data breach as “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed”. Both are required: a security incident and personal data involved.

Not every compromise, then, is a data breach. A brochure site with no users or forms that save data, infected with SEO spam links, might not touch any personal data. Conversely, a backdoor on an online store generally gives the attacker access to the database and therefore to customer data: the concrete possibility of access has to be considered even without proof that anything was read.

The European Data Protection Board (EDPB) Guidelines 9/2022, in version 2.0 adopted on March 28, 2023, restate a classification that is also useful from a technical standpoint. A confidentiality breach occurs when data is disclosed or accessed without authorization, an integrity breach when it is altered, an availability breach when access to it is lost or it is destroyed. Ransomware that encrypts the database violates availability, a skimmer that copies checkout data violates confidentiality; a single incident can fall into more than one category.

What personal data a WordPress site holds

To assess the risk you first need to know what is in the database, and often even the people running the site do not know precisely. A typical WordPress installation contains more personal data than it seems:

• wp_users and wp_usermeta: usernames, email addresses, display names, password hashes (computed with bcrypt since WordPress 6.8) and, for WooCommerce customers, billing and shipping addresses and phone numbers;
• wp_comments: name, email and IP address of commenters, even from years ago;
• WooCommerce orders: with high-performance order storage (HPOS) they are in the wp_wc_orders and wp_wc_order_addresses tables, in earlier versions in wp_posts and wp_postmeta, and they include personal details, addresses, purchased products and the customer’s IP;
• requests submitted through forms, which many plugins save in the database: Gravity Forms, for example, in the wp_gf_entry and wp_gf_entry_meta tables;
• newsletter subscribers, bookings, job applications with a résumé attached in wp-content/uploads, activity logs from security or statistics plugins with visitor IPs.

Payment card numbers are usually not on the site, because gateways collect them with forms hosted on their own servers. But a JavaScript skimmer in the checkout intercepts them in the customer’s browser before they reach the gateway: in that case the data was never in the database, but it was stolen all the same, and the breach exists.

Controller and processor: who has to do what

The duty to notify falls on the data controller, that is the company, professional or association that decides why and how the data is processed: for a business site, usually the company that owns the site. The web agency that manages it, the hosting provider that administers the server or the consultant who handles maintenance are typically data processors under Article 28, and their role is defined by the contract or the appointment deed.

Article 33(2) states that the processor “shall notify the controller without undue delay after becoming aware of a personal data breach”. The EDPB guidelines clarify that the processor does not need to assess the risk before alerting the controller: it only has to establish that the breach occurred and report it, possibly providing the details in several stages as they emerge. The assessment and the decision to notify remain with the controller, even when the contract authorizes the processor to file the notification on its behalf.

In practice, this means that an agency that discovers an infection on a client’s site cannot just clean it and send the invoice: it must alert the client in time, with the information it has, because the controller’s clock generally starts running from that very communication. If the same incident affects several clients, the processor must inform each of them.

The 72 hours: from when you become “aware”

Article 33(1) requires the controller to notify the breach to the supervisory authority “without undue delay and, where feasible, not later than 72 hours after having become aware of it, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons”. After 72 hours, the notification must be accompanied by the reasons for the delay.

The delicate point is the moment from which the hours are counted. According to the EDPB guidelines, the controller becomes aware when it has “a reasonable degree of certainty” that a security incident has occurred that has compromised personal data. After an initial report, a short period of investigation is allowed to establish whether a breach has really occurred, but the investigation must begin immediately: analysis cannot be postponed in order to push the clock forward. If the analysis confirms that an attacker had access to the database, awareness exists from that moment.

Article 33(4) also provides that, if it is not possible to provide all the information at the same time, it may be provided “in phases without undue further delay”. This is the normal situation in a cyber incident: within 72 hours you notify what you know, stating that the analysis is ongoing, and you supplement the notification when the reconstruction is complete. Waiting until the end of the cleanup to have a perfect picture is a mistake.

Assessing risk with forensic evidence

Assessing risk takes facts, not impressions, and this is where the technical work becomes decisive. If, as we recommend in the article on the first two hours after an attack, a forensic copy of files, database and logs was made before cleaning, the main questions have verifiable answers.

Since when was the attacker inside? The date of the first malicious file, of the first anomalous access to the panel or of the creation of a ghost administrator bounds the exposure window. A file timeline with modification and status-change dates, compared with the server access logs, lets you place the events:

# Timeline of files modified during the suspect period (on the forensic copy)
find ./copia/public_html -newermt '2026-08-01' -printf '%T+ %C+ %u %s %p\n' | sort

# Administrators with registration date
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

Was the data read or exported? Some traces point to extraction with good probability: SQL dumps or archives that appeared in the public folder and were downloaded, database management tools such as Adminer uploaded by the attacker, mass calls to the WooCommerce REST APIs for customers and orders, abnormally large responses to a single IP address.

# Dumps and archives created in the document root during the suspect period
find ./copia/public_html -newermt '2026-08-01' -type f \
  \( -name '*.sql' -o -name '*.sql.gz' -o -name '*.zip' -o -name '*.tar.gz' \)

# Who downloaded them, with status and bytes transferred (combined log format)
grep -E '\.(sql|sql\.gz|zip|tar\.gz) HTTP' ./copia/log/access.log* \
  | awk '{print $1, $4, $7, $9, $10}'

# Requests to the WooCommerce REST APIs for customers and orders
grep -E '/wp-json/wc/v[0-9]+/(customers|orders)' ./copia/log/access.log* \
  | awk '{print $1}' | sort | uniq -c | sort -rn | head

The absence of traces, however, is not proof of absence. A webshell that queries the database directly and returns the output in a POST response leaves only one line in the logs, with the response size, and many hosts keep logs for only a few days. In these cases the assessment must start from what the attacker could do: with PHP code execution access, they could read the entire database. In our interventions, log analysis is assisted by AI models run locally, without the client’s data leaving the infrastructure, but the conclusion remains a judgment that must be justified in writing.

What data and how many people? The number of users, orders and form entries within the exposure window is essential for the notification. The factors the guidelines list for assessing severity are the type of breach, the nature and volume of the data, how easily individuals can be identified, the severity of the consequences, any vulnerable categories such as minors, and the number of data subjects.

Notifying the Garante: the online procedure

In Italy the supervisory authority is the Italian Data Protection Authority (Garante per la protezione dei dati personali). Under the decision of May 27, 2021, since July 1, 2021 the notification is submitted exclusively through the online procedure available on the Garante’s online services portal. The Garante’s data breach page collects the instructions, the notification template (to be used only as a preview, not for submission) and a self-assessment tool that helps you understand which obligations are triggered after an incident.

The minimum content of the notification is set by Article 33(3): the nature of the breach, with the categories and approximate number of data subjects and records concerned; the name and contact details of the DPO or another contact point; the likely consequences; the measures taken or proposed to address it and mitigate its effects. For a site, the measures taken are the cleanup, the change of credentials and the subsequent hardening.

A practical tip: keep a shared document between the technical staff and the privacy contact in which every established fact is recorded with date, time and source.

Communicating to data subjects when the risk is high

Notification to the Garante and communication to the people involved are two separate obligations, with different thresholds. Article 34 provides that, when the breach is likely to result in a high risk to the rights and freedoms of individuals, the controller must communicate it to the data subjects without undue delay, in plain and clear language, describing at least the likely consequences, the measures taken and a contact point.

The same article lists three cases in which communication is not required: if the data was protected by measures that render it unintelligible to anyone not authorized to access it, such as encryption; if the measures taken after the breach make the high risk unlikely; if individual communication would involve disproportionate effort, in which case a public communication is made instead. Note that password hashes are not equivalent to encrypted data: a strong hash slows down an attack, but weak passwords remain recoverable, and it is prudent to ask users to change them anyway.

For an online store hit by a skimmer, where names, addresses and card data were stolen, a high risk is hard to rule out: people must be able to block their cards and recognize fraud attempts.

The breach register, even without notification

There is one obligation that always applies, whatever the outcome of the assessment. Article 33(5) requires the controller to document “any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken”. The EDPB guidelines encourage keeping an internal register of breaches, notified or not, in which the reasoning followed is also recorded: if the conclusion was that the risk was unlikely, the register must explain why.

This is where technical documentation shows its value over time. A line like “site compromised, no data involved” will not stand up to an inspection; a reconstruction that says which file was uploaded, from which address, on which date, with which privileges, which tables were reachable and which log checks ruled out an export, will. The technical report of the cleanup, with the timeline and the list of indicators of compromise, is the natural attachment to the register entry.

It is also worth keeping the forensic copy, in a protected place and for a defined period, because it may be needed if new elements emerge. The copy also contains personal data, and must be handled with the same care as the site.

The most frequent mistakes come from haste. The first is restoring a backup before analyzing: the site comes back online, but the evidence needed to understand whether the data was read is overwritten, and malware can survive the restore. The second is considering the matter closed once the site is clean, without anyone having done the privacy assessment, perhaps because the vendor fixed it without alerting the controller.

When we work on a compromised site, the guaranteed cleanup in 6, 12 or 24 hours for every WordPress installation includes evidence preservation and a technical report with the reconstruction of the attack: entry vector, time window, reachable data, traces of export found or ruled out. It does not replace the assessment by the controller and its consultant, but it provides the facts to base it on, in time for the 72 hours. If you have an incident in progress and personal data potentially involved, contact us before restoring or deleting anything.