Sovereignty · Updated 10 November 2026 · 8 min read

What a hosting provider must do after a data breach under the GDPR

Who reports a breach to whom, the 72-hour clock, what a processor owes you, and how Scalingo, Sliplane and Eurobase word breach notice in their DPAs.

View as Markdown

When a hosting provider holds personal data for you, it's your processor, and Article 33(2) of the GDPR gives it one direct duty after a breach: tell you without undue delay once it becomes aware. Article 28(3)(f) adds that it must help you meet your own breach duties. Reporting to the data protection authority, and to the affected people when the risk is high, is your job as controller, with a 72-hour target for the authority. A provider only carries those controller duties itself for data it processes for its own purposes, such as its customer accounts and billing records.

This page explains the rules for developers and small teams. It isn't legal advice.

Who does what at a glance

Step	Who	Deadline in the GDPR	Legal basis
Tell the customer about the breach	Provider as processor	Without undue delay after becoming aware	Article 33(2)
Help assess and handle the breach	Provider as processor	Not fixed, set by the contract	Article 28(3)(f)
Notify the supervisory authority	You as controller, unless the breach is unlikely to result in a risk	Without undue delay, and where feasible within 72 hours of becoming aware	Article 33(1)
Explain a late notification	You as controller	With the notification, if it comes after 72 hours	Article 33(1)
Tell the affected people	You as controller, when the risk is high	Without undue delay	Article 34(1)
Record the breach	You as controller, every breach	Not fixed	Article 33(5)

What counts as a breach

Article 4(12) defines a personal data breach as a security breach that leads to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. The EDPB sorts them into three kinds:

Confidentiality: someone sees data they shouldn't, such as a leaked database dump or a public bucket.
Integrity: data is changed without authorisation.
Availability: data is lost or can't be reached, which includes ransomware that encrypts it.

The third kind matters most for hosting. An outage that destroys data, or makes it unavailable long enough to harm people, can be a breach even when nothing leaked. In the EDPB's own example, a hospital's ransomware attack with no data taken still had to be reported to both the authority and patients, because operations were cancelled while systems were down.

What the provider owes you

The GDPR keeps the processor's side short. Read the DPA for the details that matter in practice.

Notice without undue delay. Article 33(2) sets no number of hours for processors. A contract can, so ask for one if you need to hear early enough to contain the damage.
Enough facts to assess the risk. Your notice to the authority has to describe the nature of the breach, the categories and approximate numbers of people and records, the likely consequences and the measures taken. You'll get most of that from your host.
Help, not a takeover. Article 28(3)(f) asks the processor to assist with Articles 32 to 36, taking into account the information it has. It doesn't move the reporting duty to the host.
Information in phases. Article 33(4) lets details follow later when they aren't all known at once, so an early partial notice from your host is normal.

Breaches of these duties can be fined under Article 83(4): up to €10,000,000, or 2% of worldwide annual turnover for an undertaking, whichever is higher. That ceiling covers both controllers and processors.

What you have to do

Confirm and contain. Act on the first alert and establish whether personal data was affected. Ask your host which systems, which data and which time window.
Assess the risk. Consider the type and sensitivity of the data, how many people are affected and whether the data was usable. The EDPB's example of an encrypted backup on a stolen USB key may not need reporting, as long as the decryption key wasn't compromised and the backup can be restored in good time.
Notify the authority. If the breach is likely to result in a risk, send a first notice within 72 hours even if it's incomplete. Authorities run online forms for this. For cross-border processing, the EDPB points to the lead authority.
Tell the people affected when the risk is high, in clear and plain language, through a channel the breach didn't compromise. Article 34(3) lists exceptions, such as data made unintelligible by encryption.
Write it down. Every breach goes into your own register with its facts, effects and remedy, including the ones you decide not to report.

If your service is also in scope of NIS2, its incident reports run on separate clocks, starting with a 24-hour early warning. The NIS2 and DORA guide sets out those deadlines.

How three hosts word breach notice

Point	Scalingo	Sliplane	Eurobase
When you hear	As soon as possible after it becomes aware	Prompt reporting	Not stated, with help under Articles 33 and 34
Number of hours	Not stated	Not stated	Not stated
What you receive	All necessary information so you can assess the breach	Not stated	Not stated
Who notifies the authority	You, as controller, says the DPA	Not stated	Not stated
Fees for help	Help beyond its legal and contractual duties may be quoted separately	A reasonable fee is possible for support outside the service or not caused by its own errors	Not stated

Each row comes from the provider's own DPA, read on 10 November 2026.

None of the three commits to a fixed number of hours. That doesn't break the GDPR, which sets none for processors either, but it leaves the pace of the first step up to the host, and the people affected wait for it too. If you need a fixed window, ask for it in writing before you sign. For the full list of DPA clauses, see the DPA checklist.

Breach notice on Eurobase

Eurobase, a business registered in Warsaw, Poland, hosts your apps on European infrastructure run by Scaleway, a French provider. Its DPA names Eurobase as processor for workload data and commits it to assist with breach handling under Articles 33 and 34, alongside data subject requests, security and impact assessments. Its listed security measures include logging and incident handling.

Two limits are worth knowing. The DPA doesn't set a fixed number of hours for breach notice, so raise it at privacy@eurobase.dev if your own plan needs one. And there's no ISO 27001 or SOC 2 certificate to show an auditor yet, because both are still being worked on. GitHub and GitLab, both US companies on the subprocessor list, only process your data once you connect a repository from them. Logs help you reconstruct a breach, and the retention table says how long Eurobase keeps them; log retention under the GDPR covers your side.

Frequently asked questions

Does my hosting provider have to report a breach to the authority for me?

No. For data it processes on your behalf, the provider tells you and helps you. The notice to the supervisory authority and any message to affected people are yours as controller. The provider reports on its own only for data it controls, such as its own customer accounts.

How many hours does a processor have to tell me about a breach?

The GDPR sets no number for processors, only "without undue delay". Your own target for the authority is 72 hours where feasible, so put a concrete window in your contract if your provider will agree to one.

When does the 72-hour clock start?

Article 33(1) counts from when you, the controller, become aware of the breach. When your host spots it first, its notice is usually what makes you aware. A slow notice doesn't shorten your 72 hours, but it delays containment and leaves the people affected exposed for longer.

Is an outage or a lost backup a data breach?

It can be. Loss of access to personal data or its destruction is an availability breach. Whether you must report it depends on the risk to people, such as how long the data was unavailable and what that stopped them from doing.

Do I need to report a breach if the data was encrypted?

Often not to individuals: Article 34(3) exempts you when the data was unintelligible to anyone without access, such as strong encryption with a safe key. You still assess the risk for the authority and record the breach in your register.