Short answer: yes, very often it is — or at least it should be treated as such until proven otherwise. When malicious code appears on a WordPress site, the temptation is to consider it a purely technical issue: "the site was hacked, let's clean it up and move on." In reality, if that site collects or manages personal data (and almost all sites do), the infection may constitute a personal data breach under the GDPR, with precise obligations and very tight timeframes to respect.

In this article we explain, in simple words, why malware is almost always a privacy issue as well as a security one, when the notification obligation to the Data Protection Authority is triggered, and what a small business should concretely do when it finds itself in this situation.

What we mean by "malware" on WordPress

WordPress is the most-used system in the world for building websites, and precisely its widespread use makes it a prime target. In the vast majority of cases, infections don't come from WordPress itself, but from vulnerable plugins or themes, weak passwords, or outdated installations.

The most common types of malware include:

  • Web shells and backdoors: hidden files that allow the attacker to re-enter the site whenever they want, even after an initial cleanup.
  • Skimmers and form data theft: code injected into pages (often in checkout or contact forms) that intercepts what users type — emails, personal data, in serious cases even payment data.
  • Redirects and spam injection: redirects to scam sites or insertion of unwanted content that damages reputation and rankings.
  • Creation of fake admin users: the attacker creates privileged access to control the site from within.

A real and emblematic case, by now a classic of WordPress security, is that of the "WP GDPR Compliance" plugin (the vulnerability dates back to 2018): a critical flaw allowed unauthenticated attackers to create new admin accounts and install malicious plugins containing web shells. Paradoxically, a tool born to help GDPR compliance became the entry door to compromise over one hundred thousand sites. It's a useful reminder: security is never something done "once and for all."

Why malware often becomes a data breach

The GDPR defines "personal data breach" (in English, data breach) very broadly. It's not just about data theft: it's also a breach when there's a loss of confidentiality (someone accesses data they shouldn't see), loss of integrity (data is altered), and loss of availability (data becomes inaccessible, for example after a ransomware attack).

Now let's connect the two worlds. A compromised WordPress site almost always means that an unauthorized party has gained access to the system that hosts personal data. And what data does a site typically contain? Much more than one imagines:

  • the email addresses and names of registered users and administrator accounts;
  • data submitted via contact forms or newsletter sign-ups;
  • orders, shipping addresses, and customer data if there's an e-commerce (WooCommerce);
  • comments, user profiles, any restricted areas;
  • in some cases, particularly sensitive data depending on the sector.

The key point is this: when malware gets in, you often don't know for certain what the attacker saw, copied, or modified. A web shell gives access to the entire filesystem and, very often, also to the database. That's why, from a privacy point of view, the event can't be dismissed as "just a virus": you must start from the assumption that personal data may have been exposed, and then verify.

This doesn't mean every infection is automatically a notifiable data breach. A purely aesthetic defacement on a brochure site without any personal data may not entail risks for people. But the assessment must be made case by case, methodically, and not dismissed on instinct.

What the GDPR says: obligations and timing

Here comes the part that scares small businesses the most, but which is actually manageable if known in advance.

Notification to the Data Protection Authority (Article 33). If the breach entails a risk to the rights and freedoms of individuals, the data controller must notify it to the supervisory authority — in Italy the Data Protection Authority — without undue delay and, where possible, within 72 hours of becoming aware of it. If notification happens after 72 hours, the reasons for the delay must be explained. It's possible to send an initial notification even with incomplete information and supplement it later: better a timely and partial notification than a late "perfect" one.

Communication to data subjects (Article 34). If the risk to people is assessed as high, notifying the Authority isn't enough: the affected users must also be informed, without undue delay, so they can protect themselves (for example by changing passwords or watching out for improper uses of their data).

When notification is NOT required. Notification is required only if two conditions are met: the incident involved personal data and the breach entails a risk to the rights and freedoms of individuals. If the risk is unlikely, the notification obligation to the Authority may not exist — but this assessment must still be documented.

The 72 hours count from "awareness." Not from the moment of the attack, but from when there's a reasonable degree of certainty that a breach has occurred. The window for this initial assessment should however be short: you can't hide behind "we weren't sure" for weeks.

Sanctions. Failure to comply with notification obligations can expose you to administrative fines up to €10 million or, for businesses, up to 2% of worldwide annual turnover. Add to this reputational damage and possible claims for damages from data subjects.

An often-overlooked aspect: even if you rely on an agency or hosting to manage the site, the data controller remains you. The vendor is normally the "data processor" and has the obligation to notify you promptly, but responsibility for notification to the Authority falls on those who decide the purposes and means of the processing — that is, almost always, the company that owns the site. That's why it's essential to have clear contracts (so-called art. 28 agreements) that define who does what in case of an incident.

What to do (in order) if you discover malware

Having a procedure decided cold-blooded is worth more than any hasty reaction. Here are the essential steps.

  1. Don't delete everything on impulse. The instinct is to clean up immediately, but destroying the evidence makes it impossible to understand what happened and whether data was exposed. Before intervening, preserve copies and logs.
  2. Isolate and contain. Put the site in maintenance mode or offline if necessary, change the passwords of admin accounts, database, and FTP/hosting access, and revoke any suspicious users.
  3. Preserve the logs. Web server, hosting, and security plugin logs allow reconstruction of when access occurred, from where, and what was touched. They are decisive in assessing whether there was a risk to the data.
  4. Assess data exposure. With the help of a technician, answer the key questions: what personal data was present on the site? Is there evidence that it was read, copied, or modified? How many people are potentially involved? This analysis is the heart of the notification decision.
  5. Involve privacy people immediately. The Data Protection Officer (if appointed) or the privacy consultant must be alerted immediately, because the 72-hour countdown has already begun.
  6. Document everything. The GDPR requires keeping a register of breaches even when it's decided not to notify. Writing down what happened and why the decision was made a certain way is a fundamental safeguard in case of controls.
  7. Clean up and restore securely. Remove the malware, restore from a clean, verified backup, update WordPress, plugins, and themes, and only then put the site back online.

Preventing is much cheaper than fixing

Most WordPress infections are avoided with ordinary and inexpensive measures: always update core, plugins, and themes; delete unused plugins; use strong passwords and two-factor authentication; limit login attempts; install a web application firewall and a reliable security plugin; make regular backups and keep them in a location separate from the site; choose hosting that offers monitoring and isolation.

Organizationally, it's worth preparing in advance a simple incident response procedure — who to call, where the logs are, who decides on notification — so as not to improvise when time is short.

In summary

Malware on a WordPress site isn't "just" an IT problem: in most cases it involves personal data and must therefore be assessed as a potential data breach under the GDPR. This doesn't mean every infection must be notified to the Authority, but that every infection must be analyzed through that lens, within short timeframes and with proper documentation. The practical rule for a small business is simple: treat every compromise as if it had touched personal data, until you have proof it didn't — and prepare beforehand the tools (backups, logs, procedures, contacts) that will let you respond with clarity in the 72 hours that count.

It's worth remembering: a site without a database and without an exposed login panel — like those built with more modern approaches — offers far fewer doors to force. If you're thinking about a new project, we discuss it in the dedicated article, "How to build a website in 2026".

Sources