Hosting Provider Data Breach: What GDPR Actually Requires You to Do Next

Sitting down to write this after reviewing a client's incident file this week, the pattern was familiar. Picture the scene, because a version of it lands in somebody's inbox most weeks. The physiotherapist running a clinic outside Carrick-on-Shannon opens her email between patients and finds a subject line that stops her cold: "Notice of Security Incident." Her hosting provider is telling her that a server was compromised, and that client booking records, which include health information, may have been accessed. She has never had to think about what happens next, and nobody has ever told her. The email explains what happened to the server. It says nothing about what she is now legally required to do.

That gap, between being told and knowing what to do about it, is where this article lives.

When Your Host's Problem Becomes Your Problem

Under GDPR, your hosting provider is what the regulation calls a processor. They hold and process personal data on your behalf, but the legal relationship runs through you, the controller. That distinction is not academic. Every hosting agreement of any substance includes a Data Processing Agreement, and buried inside it is a clause requiring the processor to notify the controller "without undue delay" the moment they become aware of a breach, a duty Article 28 of the regulation sets out plainly.

Here is the practical consequence. Your host telling you about the breach is not them handling it. It is them handing you the clock and stepping back.

A few years ago I sat in on a breach response call where the business owner spent the first forty minutes arguing with the hosting company about whose fault the breach was, instead of starting the assessment the Data Protection Commission actually cares about. Blame does not appear anywhere in Article 33. Time does.

A breach response is a narrow, single-incident process. It is worth separately verifying the wider GDPR compliance gaps most Irish business sites carry, ideally before a notification email forces the issue, not during one.

The 72-Hour Clock Nobody Explains Properly

Article 33 requires you, as controller, to notify the Data Protection Commission without undue delay and, where feasible, within 72 hours of becoming aware of a breach, unless you can show it is unlikely to result in a risk to the people affected. The clock starts when you have enough information to know a breach has probably happened. It does not wait for you to finish investigating.

The notification itself has to cover specific ground: the nature of the breach, the categories and rough number of people and records affected, the contact details of your DPO or another contact point, the likely consequences, and the measures you have taken or plan to take. If you cannot gather all of that inside 72 hours, phased reporting is allowed. You submit what you know, then follow up as the picture becomes clearer. Miss the window entirely and you are not automatically in breach of the rule, but you do need to explain the delay, in writing, and that explanation needs to hold up.

Most of what triggers this process is unremarkable. The Data Protection Commission's 2025 annual report put the number of valid breach notifications it processed that year at a little over 6,500, itself down against the year before, and noted that close to half of all notifications trace back to something as mundane as correspondence sent to the wrong recipient, not a hacker in a hoodie. The clock does not care how ordinary the cause was. A misconfigured server backup exposed to the wrong place still starts it.

	Notify the DPC (Article 33)	Notify your customers (Article 34)
Trigger threshold	Likely to result in a risk	Likely to result in a high risk
Deadline	Within 72 hours of becoming aware	Without undue delay, no fixed hour count
Who decides	You, as controller, ideally with advice	You, as controller, against the higher bar
Main exemption	Assessed as unlikely to cause risk	Data was encrypted, risk was neutralised, or notifying individually would be disproportionate

Do You Have to Tell Your Own Customers?

Article 34 sits above Article 33, not alongside it. Notifying the DPC applies whenever a breach is likely to cause a risk. Notifying the individuals whose data was involved only kicks in when that risk is high, a narrower and more serious bar. There is no fixed 72-hour figure here. The requirement is "without undue delay," which in practice means as soon as you reasonably can, not whenever suits you.

There are genuine exemptions. You do not have to notify individuals directly if the data was encrypted in a way that makes it unintelligible to whoever accessed it, if you have since taken steps that mean the high risk no longer applies, or if individual notification would involve disproportionate effort, in which case a public communication can stand in instead. None of that is a licence to decide for yourself, though. Get advice specific to your situation from a solicitor or your Data Protection Officer if you have one. The exemptions are narrower in practice than they read on paper, and the DPC's own guidance is blunt about that.

For a clinic holding health records, the kind involved in the scenario at the top of this piece, the high-risk bar is cleared far more easily than it would be for, say, a mailing list of names and email addresses. Special category data changes the maths. It is worth knowing that before the email arrives, not after.

The First 24 Hours, Step by Step

Confirm. Get written confirmation from your host of what happened, when it happened, and which categories of data were involved. A vague notification email is a starting point, not a full account, and you cannot assess risk on guesswork.

Assess. Work through, with your DPO or an adviser if you have one, whether the breach clears the "likely to result in a risk" bar for Article 33, and separately, the higher "high risk" bar for Article 34. These are two different questions with two different answers.

Document. Record your reasoning even if you conclude no notification is required. The DPC can ask to see that record later, and an undocumented judgement call does not hold up well under review.

Notify. If the Article 33 threshold is met, submit to the DPC within 72 hours of when your host told you, not 72 hours from when your investigation wraps up. Partial, honest information beats a late, complete report.

Review. Once things are resolved, verify what your Data Processing Agreement actually promised about notification, and ask your host what is changing so this does not repeat.

What Good Hosting Actually Buys You Here

None of this makes the breach itself less real, but where your infrastructure sits changes how complicated the response gets. If your data has been sitting on servers outside the EU, you are now untangling which supervisory authority even has jurisdiction before you can properly start the clock. Web60's sovereign Irish cloud infrastructure keeps that question simple: the data stays in Ireland, the Data Protection Commission is unambiguously the relevant authority, and that is one fewer argument to have while the clock is running.

Good infrastructure also lowers the odds you are ever in this position in the first place. Server-level security hardening, fail2ban intrusion prevention, and automatic malware scanning do not make a breach impossible, but they close off the routine, automated attacks that account for a large share of the incidents the DPC processes every year. That is the same ground covered in more depth in our complete guide to WordPress security and backups. Web60 runs all three as standard, alongside automatic nightly backups, so a scenario that could mean rebuilding a site from nothing more often means restoring yesterday's clean copy and moving on with your afternoon.

None of that removes your obligations as controller, and it would be dishonest to pretend it does. A hosting provider's security posture cannot decide how long you retain client records, what categories of data your booking form collects, or whether you needed that health information in the first place. Those decisions are yours, and the DPC will ask about them regardless of who hosts the site. If you already run in-house legal counsel and a dedicated DPO tracking every processor relationship, you likely have most of this playbook internalised already. Most businesses this size do not, which is where an Irish-based support team who can talk you through what a notification actually means, in plain terms, earns its keep.

If you are weighing up whether your current host would even know what to tell you on the wrong Tuesday morning, it is worth looking at how Web60 approaches security and Irish hosting before you need the answer, not after.

Conclusion

A breach notification email is not the crisis itself. It is the start of a process most business owners have never had to run, and the DPC does not grade on effort. The next time an email like the one that landed in that Leitrim clinic's inbox turns up, wherever it lands, the difference between a manageable week and a genuinely bad one comes down to whether someone already knows the five things Article 33 asks for, and where to find them. Ask your current host what their Data Processing Agreement actually promises about notification. Do that this week, not the week you need the answer.

Frequently Asked Questions

Do I have to tell my customers if my hosting provider is breached?

Only if the breach is likely to result in a high risk to their rights and freedoms under Article 34. Lower-risk breaches typically only require notifying the Data Protection Commission. Get advice specific to your case before deciding either way.

What is the 72-hour rule and when does it start?

Article 33 requires controllers to notify the DPC within 72 hours of becoming aware of a breach that is likely to result in risk. The clock starts when you have enough information to know a breach has probably happened, not once your investigation is finished.

Is my hosting provider legally responsible if they are breached?

They carry processor obligations under Article 28, including notifying you without undue delay and assisting your response. The notification duty to the DPC, and to customers where required, rests with you as the controller.

What happens if I miss the 72-hour deadline?

Late notification is not automatically a violation, but you must explain the reasons for the delay. Documenting your timeline from the moment your host told you matters more than hitting the deadline to the minute.

Do I need a Data Processing Agreement with my hosting provider?

Yes. GDPR requires one wherever a processor handles personal data on your behalf. Check that it specifies breach notification timelines and responsibilities clearly, not just in general terms.

Can better hosting security actually reduce my GDPR risk?

It reduces the odds of the routine, automated breaches that make up a large share of incidents. It does not remove your obligations as controller for decisions like data retention and what personal data you collect in the first place.

Sources

Data Protection Commission Ireland - Breach Notification

GDPR Article 33 - Notification of a personal data breach to the supervisory authority

Data Protection Commission - 2025 Annual Report