When a vendor data breach exposes information you handed over, treat it as your own incident: confirm the scope in writing, inventory what you shared, rotate any shared credentials, and engage counsel on notification. Your customers’ data stays your legal responsibility even when someone else is the one who lost it.
The CEVA Logistics cyberattack disclosed in early August 2026 is a clean, current example of why. A logistics giant most of its customers had never heard of was breached — and it was the retailers who used CEVA, not CEVA itself, who had to tell shoppers their data was gone. Here is how a small or mid-sized business should respond when a vendor data breach lands on you.
What happened at CEVA Logistics?
CEVA Logistics is a contract-logistics giant — $18.3 billion in 2025 revenue and more than 1,000 warehouses worldwide. According to reporting, a cyberattack that began around July 29, 2026 affected eight of CEVA’s warehouses in Europe. CEVA notified affected business customers around August 1. The attack was later claimed by the Qilin ransomware group, which exfiltrated a reported 157 GB of data and now ranks as the most active ransomware operation in the world — we break down how Qilin breaks into manufacturers and 3PLs.
The data exposed was personal, not financial: names, home and street addresses, postal codes, phone numbers, email addresses, order numbers, tracking numbers, and purchase information. Per the reporting, no payment-card data or account credentials were reported as exposed.
The telling part is who broke the news. CEVA itself has not publicly disclosed the incident. The companies that used CEVA for fulfillment did the notifying — reported downstream victims include Bol, De Bijenkorf, Ace & Tate, Ajax, ING, and Valve (its Steam hardware customers in the EU). The Dutch data-protection authority reportedly received breach reports from 10 organizations. One shared vendor, ten separate notification obligations landing on ten separate brands. That is the whole lesson in one sentence.
Note what this incident is not: no group has claimed the attack, and reporting has not confirmed that ransomware was deployed. Treat it as a data breach, not a ransomware event — the response below is the same either way. (If your own systems are ever encrypted, that is a different playbook — see what to do after a ransomware attack.)
Why is a vendor data breach your data breach?
Because the data is still legally yours. When you collect a customer’s name, address, and order and then hand it to a fulfillment, shipping, or SaaS provider, you remain the party your customers and regulators look to. The vendor is a processor acting on your behalf; the relationship — and the duty to protect that data — never left you. The FTC’s data breach response guide for business walks the same confirm, notify, and document steps you owe once your data is exposed.
CEVA is the proof. Bol and Valve did not lose the data themselves, but they are the ones who had to email their customers, because those customers are theirs. A vendor data breach becomes your data breach the moment your customers’ information is in the exposed set — regardless of whose server it sat on.
Two ideas make this concrete:
- Downstream notification duties. Whether you must notify your customers, how fast, and which regulators to inform depends on the data involved, where those customers live, and your contracts. In plain English: the clock and the thresholds vary, and getting them wrong is expensive. This is a question for your attorney, not your IT provider — confirm your specific obligations with counsel.
- Fourth-party risk. It is not just your vendors — it is your vendors’ vendors. The subprocessor a logistics firm quietly uses for its warehouse software is a company you never signed with but whose breach can still expose your customers.
What should you do in the first week after a vendor breach?
Move deliberately, and document as you go. Here is the sequence we walk clients through in the first seven days of a vendor data breach.
1. Confirm the scope in writing
Get the vendor to state — in writing — what data was affected, which of your records were in it, when it happened, and what they have done. A phone call is not a record. If the vendor is vague (as CEVA has been publicly), that silence is itself information: assume the exposed set is at least as broad as the categories other victims reported.
2. Inventory what data you shared with that vendor
Independently of what the vendor tells you, list what you sent them: which fields, how many customers, over what period, and through which integration. You cannot assess a breach you cannot measure — and your own record of what you shared is often more complete than the vendor’s.
3. Cut or rotate integration credentials
If you connect to the vendor by API key, SFTP account, shared login, or webhook, rotate or suspend those credentials now. A breach of the vendor can expose the keys that reach back into your systems. This is the one step that limits the blast radius from spreading toward you.
4. Engage counsel on notification
Before you draft a single customer email, talk to a lawyer. Breach-notification law is jurisdiction-specific and deadline-driven, and the wording of a notice has legal consequences. QOS MSP runs the technical response; your attorney owns the notification decision. Do not let an IT vendor — including us — tell you whom you are legally required to notify.
5. Brief staff for follow-on phishing and invoice fraud
Exposed order numbers, tracking numbers, and shipping details are gift-wrapped material for targeted phishing. An attacker who knows a real order was placed can craft a “delivery problem” email that is far more convincing than spam. Warn staff and customers, and watch especially for redirected-payment scams — the same pattern we break down in freight invoice fraud and business email compromise. Logistics data in the wrong hands is fuel for exactly that.
6. Document everything for your insurer and customers
Keep a timestamped log: when you learned of the breach, what the vendor said, what you shared, what you rotated, and who you engaged. Your cyber-insurance policy likely has its own notice window, and a clean record is what turns a claim into a payout and a customer notice into a defensible one. This is also where your business continuity plan earns its keep — you already know who does what.
How do you vet a logistics vendor before you sign?
The cheapest breach to survive is the one you priced out at contract time. Vetting a vendor is simply the security questionnaire from the other side of the table — instead of answering one, you are the one asking. Three things matter more than a glossy trust page:
- A SOC 2 report is not immunity. It is a point-in-time attestation that certain controls existed when an auditor looked. It does not guarantee the vendor is secure today, and it says nothing about the subprocessors they use. Read the report — including the exceptions — rather than treating the logo as a checkmark.
- Practice data minimization. The safest field is the one you never sent. Share the minimum a vendor needs to do its job — a shipper needs a name and address, not a full purchase history — so that a vendor data breach exposes less of your customers.
- Ask who else touches the data. Get the subprocessor list in writing. If the vendor cannot name its fourth parties, you cannot assess your real exposure. A structured cyber risk assessment is where we map that supply chain before it becomes a headline.
Which contract clauses actually protect you?
When CEVA’s own customers went looking for their rights, those rights were whatever the contract said — no more. The clauses below are what to ask your counsel to draft; this is a checklist for that conversation, not legal advice.
| Clause | What it should require |
|---|---|
| Breach-notification window | A defined deadline — e.g. notify you within 72 hours of discovery — not “promptly” or “without undue delay.” |
| Data-processing terms (DPA) | Exactly which data the vendor may process, for what purpose, and where it is stored. |
| Audit rights | Your right to request evidence of controls (SOC 2, pen-test summaries) on a set cadence. |
| Cooperation and cost allocation | The vendor cooperates with your investigation and who pays for notification, credit monitoring, and forensics. |
| Subprocessor disclosure | The vendor must name its fourth parties and get consent before adding new ones. |
| Data return and deletion | On termination, your data is returned or destroyed on a stated timeline, with proof. |
How do you keep watching a vendor after onboarding?
Vendor risk is not a one-time gate at signing — it decays. A vendor that was solid at onboarding can be acquired, cut staff, or swap subprocessors. Keep the relationship monitored:
- Annual re-attestation. Re-request the current SOC 2 or security summary every year, and re-run the questionnaire when anything material changes.
- Least-privilege integrations. The API key or account that connects you to the vendor should have the narrowest scope and shortest life that still works — reviewed, not set-and-forgotten. Ongoing security administration is exactly this discipline, applied continuously.
- Watch the order flow, not just the ping. Knowing a vendor’s endpoint is “up” tells you nothing about whether your orders are flowing correctly — a point we make in why uptime monitoring isn’t enough. Monitor the business transaction, not the heartbeat.
Frequently asked questions
Do I have to notify my customers if my vendor was breached?
Often yes. If your customers’ personal data was in the exposed set, notification duties can fall on you as the business that collected it, not on the vendor that lost it. The timing, thresholds, and exact recipients vary by the data involved, where your customers live, and your contract. Confirm your specific obligations with counsel before you send anything.
Was the CEVA Logistics attack ransomware?
It is unconfirmed. As of the reporting, no group has claimed the attack and it has not been confirmed that ransomware was deployed. Treat it as a data breach affecting personal information rather than a ransomware event. The first-week response is the same either way: confirm scope, rotate shared credentials, and engage counsel.
What is fourth-party risk?
Fourth-party risk is the risk from your vendors’ vendors. When your logistics or SaaS provider hands your data to its own subcontractor for storage or processing, that subcontractor is a company you never signed with but whose breach can still expose your customers. You manage it by requiring your vendors to disclose and control their subprocessors.
Does a SOC 2 report guarantee my vendor is secure?
No. A SOC 2 report is a point-in-time attestation that specific controls existed when an auditor examined them. It is evidence of a security program, not a guarantee of current safety, and it does not cover the subprocessors your vendor relies on. Read the report and its exceptions rather than treating the badge as proof.
What should a vendor breach-notification clause require?
A strong clause sets a defined notice window, such as notifying you within 72 hours of discovery, and states the scope of affected data the vendor must report. It should also require the vendor to cooperate with your investigation and specify who pays for notification, credit monitoring, and forensics. Ask your counsel to draft these terms before you sign.
What we own — and what stays yours
Here is the honest division of labor. QOS MSP runs the vendor-risk process — assessing who touches your data, tightening integrations, monitoring the connections, and keeping you ready to respond fast when a vendor data breach hits. What we do not do is practice law. Breach-notification obligations belong to your attorney, every time — we will hand your counsel a clean technical record, but we will never tell you whom you are legally required to notify.
And you may not need a formal third-party risk program at all. If you share little or no customer data with outside vendors — a handful of low-risk tools, nothing sensitive flowing outward — a heavyweight TPRM process is overkill. The controls scale to your actual exposure. If you are not sure where that line falls for your business, that is the conversation to have before an incident, not during one.
Want a clear picture of which vendors could turn into your next breach? Start with a cyber risk assessment, or talk to us about running vendor risk as part of your managed IT.
