A cyberattack that began on or around 29 July 2026 against eight European warehouses operated by Ceva Logistics has produced one of the clearest recent illustrations of how a single processor incident multiplies into a large number of independent regulatory obligations.
The timeline:
- 29 July 2026 — the attack begins, affecting eight warehouses.
- 1 August 2026 — Ceva confirms the intrusion and notifies affected customers, including Bol.
- 3 August 2026 — the Dutch data protection authority (Autoriteit Persoonsgegevens, AP) is informed.
- 5 August 2026 — retailers email their customers about the possible data leak.
- 7 August 2026 — Valve learns of the breach affecting Steam hardware customers.
- 10 August 2026 — reporting establishes that the AP has received breach reports from at least ten organisations in connection with the incident.
The organisations affected span sectors that share nothing except a logistics provider: ING (banking), Bol and De Bijenkorf (retail), AFC Ajax (football), Ace & Tate (eyewear), and Valve (Steam hardware shipping).
The compromised data is consistent across them: names, home addresses, postcodes, phone numbers, and email addresses. Neither Bol nor De Bijenkorf reported compromise of bank account numbers or passwords.
Ceva has stated that no other CEVA systems globally were affected and that air, ocean, ground and rail transportation management continued without interruption. The company declined to disclose the total volume of stolen data or whether a ransom was demanded.
The structure: one incident, ten controllers
Under the GDPR, Ceva is a processor. It handles personal data on behalf of the retailers, banks, and brands whose goods it warehouses and ships. Those organisations are controllers. They determine why and how the personal data is processed; Ceva executes.
This allocation of roles determines everything about the regulatory response, and it produces an outcome that is frequently misunderstood:
Ceva’s breach is not Ceva’s notification. Article 33(1) places the obligation to notify the supervisory authority on the controller. Article 34 places the obligation to communicate to data subjects on the controller. The processor’s obligation, under Article 33(2), is narrower and different: to notify the controller without undue delay after becoming aware of a personal data breach.
So a single intrusion into a single provider’s warehouse management systems generated:
- One processor obligation — Ceva notifies its customers.
- Ten-plus controller obligations — each affected customer independently assesses, notifies the AP within 72 hours of its own awareness, and determines whether Article 34 communication to data subjects is required.
- Ten-plus separate risk assessments, each reaching its own conclusion about high risk to rights and freedoms.
- Ten-plus separate customer communications, arriving at different times, with different content, describing the same incident.
The AP is therefore investigating one incident through ten filings. That is a structurally difficult supervisory position, and it is one reason processor incidents attract regulatory attention disproportionate to their record counts.
The clock problem in the middle
The most instructive detail is the five-day interval between 1 August — when Ceva confirmed the intrusion and told Bol — and 5 August, when customers were emailed.
Article 33(2) requires the processor to notify the controller “without undue delay.” Article 33(1) then gives the controller 72 hours from its awareness. Article 34 requires communication to data subjects “without undue delay” where the breach is likely to result in a high risk.
Reconstructing against those requirements:
- Ceva told Bol on 1 August. Bol’s 72-hour clock started then.
- The AP was informed on 3 August — within 72 hours of 1 August. That is compliant on its face.
- Customers were emailed on 5 August — four days after the controller became aware.
Whether that satisfies “without undue delay” under Article 34 is a fact question turning on the risk assessment and the practical steps required. But it illustrates the compression that processor incidents produce: the controller’s 72 hours does not begin when the incident begins. It begins when the processor tells them, and every hour the processor spends investigating before notifying is an hour removed from the controller’s window — not added to it.
A processor that takes 48 hours to determine scope before notifying leaves its controllers 24 hours. A processor that takes four days leaves them none. This is why the contractual notification timeframe under Article 28(3)(f) is the single most consequential clause in a data processing agreement, and why “without undue delay” — reproduced verbatim from the Regulation into the contract — is the least useful drafting choice available.
The clause should state hours. Twenty-four hours from awareness of a suspected incident is the emerging standard in well-negotiated agreements. Anything longer transfers the processor’s investigation time out of the controller’s compliance budget.
What Article 28 required, and what to check
Article 28(3) sets out mandatory contents for the controller-processor contract. Several of them are directly implicated here:
Article 28(3)(c) — the processor must take all measures required under Article 32 (security of processing). This is the substantive security obligation, and it is the basis on which a controller can be found liable for engaging a processor that did not provide sufficient guarantees.
Article 28(3)(f) — the processor must assist the controller in ensuring compliance with Articles 32 to 36, which includes breach notification. In practice this means providing the information the controller needs to make its own notification: what was accessed, whose data, what categories, and what mitigations are in place. A controller that cannot describe the nature of the breach in its Article 33 filing because the processor has not provided the detail is in a poor position, and the AP has ten filings against which to compare the quality of that detail.
Article 28(3)(e) and (g) — assistance with data subject rights, and deletion or return of data at the end of the service.
That last one is worth dwelling on, because Valve’s disclosure surfaced it directly: Ceva retained shipping and delivery information for 90 days following an order.
Ninety days is not an unreasonable retention period for logistics data — returns, delivery disputes, and warranty claims all require it. But it is a controller decision that the controller must have made, documented, and justified under Article 5(1)(e). Every day of retention beyond operational necessity is a day of additional breach scope. The organisations whose exposure in this incident was smallest are the ones whose processors held the least historical data, and that is a function of a retention instruction issued at contracting time, not of anything that happened during the incident.
The retention period in your processing agreement is a breach severity control. It is one of the very few controls that reduces impact rather than probability, and it costs nothing to exercise.
The NIS2 dimension
Beyond data protection, this incident sits inside the NIS2 Directive scope in at least two ways.
Ceva itself. Transport is a sector of high criticality under NIS2 Annex I, and postal and courier services appear in Annex II as an other critical sector. A logistics operator of Ceva’s scale operating across multiple Member States falls within the Directive’s scope as an essential or important entity depending on national transposition and its specific activities. That brings incident reporting obligations on the NIS2 timeline — an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month — running to the national CSIRT or competent authority, entirely separately from any GDPR obligation.
The customers. ING is a financial entity subject to DORA, which imposes its own ICT third-party risk management requirements and its own major incident reporting timeline. A logistics provider handling customer data for a bank is an ICT third-party service provider question if the service involves ICT, and a broader operational resilience question regardless.
We covered the parallel structure in the Romania ANCPI incident, where the NIS2 obligations of an essential entity ran alongside data protection duties on incompatible timelines. The pattern is consistent: an EU incident of any scale now generates parallel notification obligations to different authorities, on different clocks, with different content requirements, and organisations that have built a breach response process around GDPR alone will miss the 24-hour NIS2 early warning entirely.
The concentration risk nobody prices
The final observation is the one with the longest tail.
Ten organisations across banking, retail, sport, eyewear, and gaming were exposed by the same incident because they all use the same logistics provider for European fulfilment. None of them had a relationship with each other. Each conducted its own vendor due diligence on Ceva and reached its own conclusion.
None of that due diligence would have revealed the aggregate risk, because concentration risk is invisible from inside a single vendor relationship. From ING’s perspective, Ceva is one provider among many. From the ecosystem’s perspective, Ceva is a single point of failure for a substantial share of Dutch e-commerce fulfilment.
This is the same structure as the Conduent breach in healthcare payments and the Lidl processor incident in retail. A shared service provider concentrates data from many controllers, and when it fails, it fails for all of them simultaneously.
The controls that actually help:
- Name your concentration points. Identify the providers whose failure would affect a material share of your customer base, and treat them as a distinct risk category with board-level visibility rather than as line items in a vendor register.
- Set the notification clause in hours and make it a contractual obligation on suspected incidents, not confirmed breaches.
- Instruct retention explicitly and audit it. The 90-day figure should be a number you chose, know, and can justify.
- Contract for forensic cooperation and evidence access, because your Article 33 filing quality depends on data you do not hold.
- Rehearse the processor-incident scenario. The likely shape is a phone call from a provider with partial information and a clock already running. Most incident response plans do not model this.
- Map your NIS2, DORA and GDPR obligations onto a single timeline so the 24-hour early warning is not discovered on day three.
- Minimise what the processor holds. The most effective severity control available is that the provider never received the data field in the first place.
Two things follow.
For controllers: your 72 hours is whatever the processor leaves you, and the length of that remainder was determined by a contract clause, not by your incident response capability. Ten organisations discovered the size of their remainder simultaneously this month.
For processors: your customers’ regulators will assess your incident through ten filings of varying quality, and the quality of each depends on what you told the controller and how quickly. Article 33(2) is a two-line obligation that determines the regulatory outcome for every organisation downstream of you.
This article is provided for informational purposes only and does not constitute legal advice.
