Processor Data Breach Notification for eCommerce (2026)

Key Takeaways

When a processor is breached, the processor notifies you and you notify the supervisory authority. The EDPB is explicit that "the legal responsibility to notify remains with the controller" even where a processor files on your behalf.
Your 72-hour clock does not start when the intruder got in, or when your processor discovered it. The EDPB's position is that "the controller should be considered as 'aware' once the processor has informed it of the breach."
One processor breach produces many separate notifications. EDPB Guidelines 9/2022 state that where a processor "provides services to multiple controllers that are all affected by the same incident, the processor will have to report details of the incident to each controller."
That fan-out is not theoretical. Twelve companies had filed notifications with the Dutch supervisory authority over the CEVA Logistics incident by 12 August 2026 — up from ten just two days earlier.
Article 33(2) gives your processor no deadline beyond "without undue delay". If your data processing agreement repeats that phrase instead of naming a number of hours, you have contracted for nothing enforceable.

Introduction

The email arrives on a Saturday from your fulfilment partner's account manager. There has been "a security incident affecting certain systems". No detail on which systems, no numbers, no indication of whether your customers are in scope. Your own infrastructure is untouched — every dashboard is green.

You are now, on the EDPB's reading, aware of a personal data breach, and you have 72 hours.

This guide covers the scenario that generic breach articles skip: the breach happened somewhere you do not control, to a vendor who also serves your competitors, and the obligation to tell the regulator is still yours. It sets out when the clock starts, what your processor owes you, what to file when you know almost nothing, and how the contract you signed months ago determines how much of this you can survive.

This is informational content, not legal advice.

Who Notifies the Regulator When Your Processor Is Breached?

You do. Under Article 33(1), the controller must notify the supervisory authority "without undue delay and, where feasible, not later than 72 hours after having become aware of it." The processor's duty is separate and narrower: Article 33(2) says, in full, that "the processor shall notify the controller without undue delay after becoming aware of a personal data breach." Your processor tells you. You tell the regulator.

The EDPB frames the division of labour in Guidelines 9/2022 on personal data breach notification, version 2.0, adopted 28 March 2023. Its paragraph 43 opens: "The controller retains overall responsibility for the protection of personal data, but the processor has an important role to play to enable the controller to comply with its obligations; and this includes breach notification."

A processor can file for you — but the accountability does not travel with the paperwork. Paragraph 48 permits a processor to "make a notification on behalf of the controller, if the controller has given the processor the proper authorisation and this is part of the contractual arrangements", then adds the line that matters: "the legal responsibility to notify remains with the controller."

There is a practical consequence worth stating plainly. If your fulfilment provider handles the filing and does it late, badly, or not at all, the supervisory authority's file has your name on it.

When Does Your 72-Hour Clock Actually Start?

It starts when your processor informs you. The EDPB's paragraph 44 states that "the controller uses the processor to achieve its purposes; therefore, in principle, the controller should be considered as 'aware' once the processor has informed it of the breach." The date the attacker got in, and the date your processor's own security team confirmed the intrusion, do not start your clock — the notification to you does.

The general test sits in paragraph 31: a controller is "aware" once it "has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised." Paragraph 34 allows a short period of initial investigation to reach that certainty. Paragraph 40 sets the limit on how generously you may read that allowance: if a controller "fails to act in a timely manner and it becomes apparent that a breach did occur, this could be considered as a failure to notify in accordance with Article 33 GDPR."

The gap between those two dates can be substantial, and it is the single most misunderstood part of this scenario. It is also the part that makes the phrasing of your vendor contract load-bearing rather than boilerplate.

What Your Processor Must Do — and What It Cannot Do for You

Your processor's job is deliberately limited. Paragraph 44 continues: the processor "does not need to first assess the likelihood of risk arising from a breach before notifying the controller; it is the controller that must make this assessment on becoming aware of the breach. The processor just needs to establish whether a breach has occurred and then notify the controller."

That means the risk assessment — the judgement that decides whether you notify the regulator at all, and whether you must also tell your customers — is not something you can outsource, delegate, or wait for your vendor to perform. It is yours, and you have to make it on whatever facts exist within 72 hours.

Article 28(3) requires the processing relationship to be "governed by a contract or other legal act". Two sub-paragraphs do the work here: 28(3)(f) requires the processor to assist "the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36", and 28(3)(h) requires it to make "available to the controller all information necessary to demonstrate compliance with the obligations laid down in this Article."

Our recommendation, stated plainly: your data processing agreement should name a number of hours, not repeat the statute. Article 33(2)'s "without undue delay" carries no explicit time limit, and the EDPB confirms it in paragraph 45 — the GDPR "does not provide an explicit time limit within which the processor must alert the controller." The EDPB's own remedy is contractual: paragraph 46 says the contract "should specify how the requirements expressed in Article 33(2) should be met", and that this "can include requirements for early notification by the processor that in turn support the controller's obligations to report to the supervisory authority within 72 hours." A clause that says "promptly" transfers the risk to you and gives you nothing to enforce. The trade-off is real — smaller merchants have limited leverage to negotiate terms with a large logistics provider — but a 24-hour clause you asked for and did not get is still better intelligence than a vague one you never questioned. Our fuller treatment of these clauses sits in the guide to data processing agreements.

One Breach, Twelve Notifications: What the CEVA Incident Showed

The clearest recent illustration of the fan-out is the intrusion at CEVA Logistics, a contract-logistics provider whose European warehouses ship for a long list of retailers.

The facts, as publicly reported: TechCrunch reported on 10 August 2026 that "on Aug. 1, CEVA Logistics confirmed to affected customers that a cyber intrusion was impacting part of its European contract logistics operations", affecting eight European warehouses, and that CEVA stated "no other CEVA systems globally were affected."

What followed is the pattern this article is about. Each retailer had to run its own assessment and file its own notification. By 12 August 2026, Dutch outlet Accountant reported the supervisory authority's confirmation that twelve companies had filed: "Twaalf bedrijven hebben inmiddels bij de Autoriteit Persoonsgegevens (AP) melding gemaakt van mogelijk gelekte klantengegevens, door een samenwerking met logistiek partner CEVA. Dat bevestigt de AP." The authority declined to name them — "Om welke bedrijven het gaat wil de toezichthouder niet zeggen." Two days earlier, TechCrunch had quoted AP spokesperson Mark Schenkel putting the count at ten. Organisations reported as affected include bol, De Bijenkorf, Zalando, Ace & Tate, Ajax, ING and Valve.

This is exactly what EDPB paragraph 47 describes: "Where the processor provides services to multiple controllers that are all affected by the same incident, the processor will have to report details of the incident to each controller." Twelve controllers, one incident, twelve independent judgement calls about risk — and twelve separate filings with the same regulator.

Two details from the public record are worth extracting, because both are transferable.

Your systems being clean is not a defence. The Dutch retailer bol published an incident notice on its partner platform on 5 August 2026, updated on 7 and 13 August. It states that bol was informed on 1 August — "Op 1 augustus is bol geïnformeerd over een cyberincident bij de logistiek warehousing partner" — and that the incident concerned two systems used to process orders from one of bol's distribution centres, adding "Er zijn geen systemen van bol geraakt": no bol systems were affected. bol still notified the Dutch authority and informed affected customers directly. Nothing about a clean internal estate reduces a controller's obligations when the data sat with a processor.

Your processor's retention period defines your notification population. Valve, which ships Steam hardware in Europe through CEVA, learned on 7 August 2026 that data had been taken and notified customers on 10 August. Per Help Net Security's reporting of that notice, the exposed fields were "names, street addresses, postal codes, cities, countries, phone numbers, and the email addresses tied to Steam accounts", along with the type and price of the hardware ordered; Valve stated that "CEVA does not have access to your payment information, passwords, Steam Guard codes or other information", and said it was notifying data protection authorities in the countries affected. The scope of who had to be told was set by a fact about the vendor: CEVA retains delivery information for up to 90 days after an order. If you cannot state your processor's retention period from memory, you cannot size your own notification population on the day you need to.

One further point, and it is the uncomfortable one. On 11 August 2026, The Record reported that "Ceva has not publicly disclosed the attack and did not respond to a request for comment." Your processor is under no obligation to publish anything. Your obligation to notify runs regardless of whether the vendor ever makes a statement you can point to.

Your First 72 Hours: A Step-by-Step Response

Timestamp the notification you received. Record the date and time your processor informed you, and keep the message. That timestamp is the start of your 72 hours under the EDPB's paragraph 44 reading, and it is the first thing a supervisory authority will ask you to evidence.
Pull the processor's entry from your record of processing activities. You need the data categories, the volumes, and the retention period before you can assess risk. This is what a maintained record of processing activities is for; assembling one during an incident is how 72 hours becomes 72 hours of archaeology.
Send the processor a written scoping request. Cite Article 28(3)(h) and ask for the specific fields, the affected date range, and the number of your records involved. Ask in writing so the request and any delay are documented.
Run the Article 33(1) risk assessment yourself. The threshold for notifying the authority is that the breach is not "unlikely to result in a risk to the rights and freedoms of natural persons." Note the double negative: risk is the default, and no-notification is the exception you must justify.
File within 72 hours, even if the picture is incomplete. Article 33(3) sets the minimum content — the nature of the breach including categories and approximate numbers of data subjects and records, your DPO or contact point, the likely consequences, and the measures taken or proposed. Article 33(4) then permits phased notification: "where, and in so far as, it is not possible to provide the information at the same time, the information may be provided in phases without undue further delay." A partial filing on time beats a complete one on day five. If you do file late, Article 33(1) requires the notification to be "accompanied by reasons for the delay."
Assess the Article 34 question separately. Communication to individuals is required where the breach "is likely to result in a high risk to the rights and freedoms of natural persons" — a higher bar than the regulator threshold. Article 34(3) sets three routes out: data rendered unintelligible by measures such as encryption, subsequent measures that mean the high risk is no longer likely, or disproportionate effort, which requires a public communication instead.
If you do communicate, send a dedicated message. EDPB paragraph 89 says breach communications "should not be sent with other information, such as regular updates, newsletters, or standard messages", and paragraph 90 states that "a notification solely confined within a press release or corporate blog would not be an effective means of communicating a breach to an individual."
Log it whatever you decide. Article 33(5) requires you to "document any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken", and that documentation must "enable the supervisory authority to verify compliance with this Article." The EDPB's footnote 47 permits this to live inside your Article 30 record rather than a separate register, "provided the information relevant to the breach is clearly identifiable as such and can be extracted upon request."

Common Mistakes eCommerce Controllers Make

1. Waiting for the vendor's final report before filing. This is the costliest error, and the most sympathetic. The instinct to file something complete is professional; it is also, on the EDPB's paragraph 40 reading, a route to a failure-to-notify finding. Article 33(4) exists precisely because full details are rarely available in 72 hours.

2. Treating the vendor's discovery date as your start date. Some incident timelines circulate a "breach began" date, and it is tempting to measure your own 72 hours against it and conclude you are already late — or, worse, that the window has closed and there is no point filing. Your clock runs from when the processor informed you.

3. Assuming a clean internal estate means no obligation. Every dashboard green, no alerts, nothing to see. The data was at the processor, and so is your exposure. bol's own notice records that no bol systems were affected — and bol notified the authority anyway.

4. Relying on the processor to notify on your behalf without a written authorisation. EDPB paragraph 48 allows it only where the controller "has given the processor the proper authorisation and this is part of the contractual arrangements". Absent that, an assumption that the vendor is handling it is not a defence, and the vendor may reasonably assume the same about you.

5. Not knowing which processors hold what. If answering "which of our customers' data sat in that warehouse system, and for how long?" takes three days of internal email, the deadline has effectively already passed. This is a data-mapping failure that only ever presents as a breach-response failure.

6. Confusing joint controllership with processorship. They are different regimes with different notification mechanics. For genuine joint controllers, EDPB paragraph 42 recommends the arrangement "include provisions that determine which controller will take the lead on, or be responsible for, compliance with the GDPR's breach notification obligations." A logistics provider processing on your instructions is a processor, not a joint controller, and Article 33(2) governs.

How PrivacyForge Helps

The 72-hour window is mostly a data-retrieval problem wearing an incident-response costume. Three things determine whether it is survivable, and all three are built before the email arrives.

A processor inventory you can query. PrivacyForge's data mapping module maintains your Article 30 record with processors, data categories, and retention periods attached — so "what did this vendor hold, for whom, and for how long" is a lookup rather than an investigation.

A breach workflow with the clock built in. Recording the date and time you were informed, tracking the Article 33(1) assessment against it, and keeping the Article 33(5) documentation as you go means the audit trail is a by-product of responding rather than a reconstruction afterwards.

Contract terms surfaced where you can see them. Knowing which of your processor agreements specify a notification deadline in hours — and which fall back on "without undue delay" — tells you in advance which vendors will cost you the first day of your window.

For the general controller-side obligations that apply whatever the source of a breach, see our GDPR data breach notification guide for eCommerce.

Frequently Asked Questions

Who notifies the supervisory authority when a processor is breached?

The controller does. Article 33(2) requires the processor to notify the controller without undue delay, and Article 33(1) then requires the controller to notify the supervisory authority within 72 hours. A processor may file on the controller's behalf where properly authorised in the contract, but EDPB Guidelines 9/2022 state that "the legal responsibility to notify remains with the controller."

When does the 72-hour clock start if my processor was breached?

When the processor informs you. EDPB Guidelines 9/2022, paragraph 44, states that "the controller should be considered as 'aware' once the processor has informed it of the breach." Neither the date the intrusion began nor the date the processor's own team discovered it starts your clock. Record the timestamp of the notification you received, as that is the date you will need to evidence.

Does one processor breach mean every affected retailer files separately?

Yes. EDPB Guidelines 9/2022, paragraph 47, states that where a processor "provides services to multiple controllers that are all affected by the same incident, the processor will have to report details of the incident to each controller." Each controller then runs its own risk assessment and files its own notification. Twelve companies had filed with the Dutch authority over the CEVA Logistics incident by 12 August 2026.

What if my processor will not give me the details in time?

File anyway. Article 33(4) permits notification in phases where it is not possible to provide all information at once, and Article 33(3) sets only a minimum: the nature of the breach, approximate numbers where possible, a contact point, likely consequences, and measures taken. Request the details in writing citing Article 28(3)(h), so any delay on the processor's side is documented.

Do I have to tell my customers when it was my processor's systems that were breached?

Only if the breach is likely to result in a high risk to their rights and freedoms, which is a higher threshold than the one for notifying the regulator. Article 34(3) provides three exemptions: data protected by measures such as encryption, subsequent measures that remove the high risk, or disproportionate effort, which requires a public communication instead. Where you do communicate, the EDPB says it must be a dedicated message, not a newsletter item.

Conclusion

The uncomfortable arithmetic of a processor breach is that the vendor controls the facts, controls the timing of what you learn, and controls how much detail you get — while you hold the obligation, the deadline, and the regulator's attention. The CEVA incident put twelve controllers in that position simultaneously, each answering for data that sat in someone else's warehouse system.

You cannot make a vendor faster during an incident. You can make three decisions before one happens: negotiate a notification deadline expressed in hours, keep a processor inventory you can query in minutes, and accept in advance that you will file an incomplete notification on time rather than a complete one late.

Start with the inventory. Map your processors and what they hold — it is the one piece of this you can finish today, and the one piece that will not be available to build on the Saturday the email arrives.

Sources

#data breach #processors #incident response #vendor management #data mapping