6 Immediate Questions to ask After a Vendor Data Breach
Tabla de contenido
A vendor data breach is a security incident at a supplier, service provider, or software platform that exposes your data or gives attackers a route into your environment. Your response clock starts when you become aware of it, not when the vendor finishes its investigation. This guide covers the six questions to answer in the first 72 hours, the notification deadlines that can apply, and how to learn about a vendor breach before the vendor tells you.
Key takeaways
- Third parties played a role in 48% of confirmed breaches in Verizon’s 2026 DBIR, up 60% from 30% the year before.
- IBM’s 2026 report ranks supply chain compromise as the second most common attack vector. Those breaches took 258 days to identify and contain, against a 247-day average.
- Your notification clock can start before the vendor confirms anything: 72 hours under GDPR, a 24-hour early warning under NIS2, four hours for major incidents under DORA, and four business days for SEC-registered companies once an incident is material.
- Work through six questions in order: containment, entry point, scope, data type, obligations, and communications.
- A questionnaire cannot tell you a vendor was breached last week. Monitoring the open, deep, and dark web can.
¿Qué es una violación de datos de un proveedor?
A vendor data breach, also called a third-party data breach, happens when attackers compromise a company that holds your data or connects to your systems. The breach is the vendor’s. The exposure, the regulatory clock, and the customer fallout are often yours.
Verizon splits third-party exposure into three archetypes: a vendor in your software supply chain, a vendor hosting your data, and a vendor connected into your environment. The 2026 cases below map to each one.
| Archetype | 2026 example | What attackers reached |
|---|---|---|
| Vendor hosting your data | EY’s third-party IT service management platform (March 28 to April 12) | Support tickets that may include documents with client tax information |
| Vendor connected into your environment | Manchester Airports Group and a customer engagement platform (disclosed August 27) | Customer records held in a third-party database |
| Vendor in your software supply chain | LiteLLM, exposed through the Trivy security scanner (March) | Credentials and secrets in build environments |
How common and how costly are vendor data breaches in 2026?
Vendor breaches are now close to a coin flip for any confirmed breach, and they cost more and last longer than most other paths. The 2026 benchmarks:
- 48% third-party involvement. Verizon’s 2026 DBIR, published May 19, found third parties in 48% of confirmed breaches, up 60% from 30% in the 2025 edition.
- $4.99 million average breach cost. IBM’s 2026 Cost of a Data Breach report put the global average at $4.99 million and the time to identify and contain at 247 days, reversing five straight years of decline.
- 258 days for supply chain breaches. Supply chain compromise was the second most common initial attack vector behind phishing. Those breaches averaged $4.96 million and took 11 days longer than the overall average to identify and contain.
- The biggest cost amplifier. Of the 30 cost factors IBM analyzed, business partner or supply chain compromise added the most, about $227,250 per breach above the global average, according to Cycode’s analysis of the report.
- 286 vendors per organization. The average organization works with 286 vendors, up 21% year over year, according to CybelAngel’s 2026 Supply Chain Cyber Risk Report.
Detection speed is the part you control. A breach that takes 258 days to find has been exposing your data for most of a year.
The 6 questions to ask in the first 72 hours of a vendor data breach
Run these in order. Each one gives you the question, the action, and what you need in hand to answer it.
1. Is the attacker still active, and is the data still exposed?
Ask the vendor for a plain answer on containment, then verify it yourself. Revoke the vendor’s access to your systems, suspend integrations, and rotate every API key, OAuth token, and service account the vendor holds. Treat anything the compromised system could read as exposed: rotating a single key is not enough when the attacker sat inside an environment that held many. You need: a list of every credential and integration you share with the vendor.
2. How did they get in, and are you on the same path?
Entry points repeat. FulcrumSec says it found Manchester Airports Group’s Iterable API credentials in client-side JavaScript, where anyone with browser developer tools could read them. MAG has not confirmed that account. EY has not said how attackers reached its vendor’s platform. Ask your vendor which path was used: stolen credentials, an exposed key or token, or an unpatched system. Then check whether you share it, starting with a scan of your own public JavaScript and repositories for secrets. You need: the vendor’s root-cause statement and your own secret-scan results.
3. What exactly of ours did they touch?
Scope is where vendor statements run thin. EY said support tickets on the compromised platform may include documents containing client tax information, and the attacker downloaded documents belonging to a number of clients. Data you never meant to store at a vendor often ends up there as attachments, exports, and ticket threads. Ask for the affected tenant, date range, record counts, and data fields in writing, then compare them with what you actually sent. You need: an inventory of what each vendor holds, including attachments.
4. What type of data is it, and is it already circulating?
Classify the data first: personal data, payment data, credentials, health records, or source code. Then check whether it is for sale or already published. FulcrumSec leaked the Manchester Airports data after the company refused to pay, and the AfD data appeared on a forum and in a searchable archive. Search leak sites, paste sites, dark web forums, and Telegram channels for your organization’s name, domains, and employee emails. CybelAngel Dark Web Monitoring analyzes millions of posts in more than 200 languages for this. You need: a search of external sources for your names, domains, and email addresses.
5. What are we legally required to do, and by when?
Start the clock when you become aware. A vendor’s silence does not pause it, and one incident can trigger several deadlines at once.
| Rule | Who notifies whom | Deadline | What to know |
|---|---|---|---|
| GDPR Article 33 | Controller to supervisory authority | Without undue delay and, where feasible, within 72 hours of becoming aware | Notice can be phased, and late notice needs reasons. Processors must tell the controller without undue delay, and contracts often set 24 to 48 hours. |
| Artículo 34 del RGPD | Controller to affected individuals | Without undue delay when the risk to individuals is high | Runs separately from the authority notice. |
| NIS2 | Essential and important entities to the national authority | 24-hour early warning, 72-hour incident notification, final report within one month | Counts from awareness of a significant incident. |
| DORA | EU financial entities to their supervisor | Initial notification within four hours for major incidents | The tightest clock in EU rules. An intermediate report follows at 72 hours and a final report within a month. |
| SEC Form 8-K, Item 1.05 | US public companies to the SEC | Within four business days of determining the incident is material | The clock starts at the materiality decision. |
| HIPAA | Covered entities to affected individuals | Within 60 days of discovering the breach | State laws can set shorter deadlines. |
This is general information, not legal advice. Confirm your obligations with outside counsel who specialize in data privacy law, and compare regulations side by side in our supply chain risk report.
You need: a notification owner and counsel on the phone before hour 24.
6. Who do we tell, what do we say, and what do we lock down next?
Tell your incident response lead, outside counsel, and insurer early, then regulators and affected individuals on the deadlines above. Update your crisis communications plan with facts you can verify, and label vendor claims as vendor claims. Then review encryption: data at a vendor should be encrypted at rest and in transit, and sensitive attachments should not sit in ticket systems at all. Log the incident, review the contract, and decide what changes before the vendor keeps your data. You need: one approved statement and a decision on what data the vendor keeps.
Four 2026 vendor breaches and what each one teaches
EY: the helpdesk that stored the tax files
An unauthorized party accessed a third-party IT service management platform used by EY’s tax practice between March 28 and April 12, 2026. EY detected anomalous activity on April 23, and its notification letters were dated July 13. That is an 81-day gap between detection and notification. EY has not named the vendor. The lesson: support tickets become shadow document stores, so audit what your staff attach to them.
Manchester Airports Group: an API key in the page source
MAG disclosed a breach on August 27 affecting about 8.7 million customers, most of whom had only their email address exposed. MAG says the data sat in a third-party database. FulcrumSec says it got in with API credentials exposed in client-side JavaScript, and it published the data after MAG refused to pay. The lesson: refusing to pay does not stop a leak, and your own web code can hand an attacker the keys to a vendor’s platform.
The AfD leak: dormant accounts at a hosting provider
On October 19, an actor calling itself hexane_cc published about 420,000 emails tied to Germany’s Alternative for Germany (AfD). The AfD says the attack hit its hosting provider in September and that the copied accounts were mostly unused for years. Our analysts tracked the post and the actor’s archive. The lesson: dormant accounts at a vendor are still your data, so close them.
LiteLLM: a security scanner as the way in
A compromised vulnerability scanner exposed credentials from LiteLLM’s build environment, and researchers linked the campaign to more than 2,500 organizations. Researcher Kevin Beaumont said terabytes of credentials were circulating online and that he had confirmed the data was legitimate at multiple victim organizations. The lesson: vendor tooling with read access is a vendor breach waiting to happen, so pin versions and limit what each tool can read.
How to learn about a vendor breach before the vendor tells you
Vendors do not always know, and they rarely tell you first. IBM’s 2026 data shows supply chain breaches run 258 days before they are identified and contained. Three ways to find out, compared:
| Approach | What it tells you | Typical gap |
|---|---|---|
| Annual vendor questionnaire | What the vendor says about its controls at a point in time | A breach this month does not appear until the next cycle |
| Vendor breach notice | What the vendor chooses to disclose, after it knows | Months: EY detected the activity on April 23 and notified clients in July |
| Continuous external monitoring | What is exposed or circulating now: leaked files, stolen credentials, forum posts | Daily scans, with alerts on detection |
CybelAngel combs through 6 billion data points every day. Each product covers a part of the vendor breach problem:
- Prevención de fugas de datos sources leaked data outside your IT perimeter, such as public connected storage devices, cloud storage, cloud applications, and databases.
- Inteligencia de Credenciales detects stolen credentials and PII across data breaches, paste sites, and dark web forums, with graded reports managed by a dedicated analyst.
- Monitoreo de la Dark Web infiltrates closed hacker communities and analyzes millions of posts in more than 200 languages.
- Gestión de la Superficie de Ataque detects vulnerable APIs and internet-facing assets, and extends your perimeter to partners and suppliers.
- Remediation services handle the takedown. CybelAngel states they reduce time to take down by 85%.
- Análisis exhaustivo de riesgos combines continuous monitoring with in-depth risk assessments of third parties.
Sanofi’s Global Head of Cybersecurity, Jean-Yves Poichotte, puts the problem plainly: “Third- and fourth-parties are our weak point.” Detecting exposure and reacting fast is how Sanofi limits the damage, and the incident reports let its team contact the third party immediately to start remediation.
What to ask any exposure monitoring provider before you buy
- Does it cover your suppliers and their suppliers, or only your own domains?
- Which sources does it monitor: the open, deep, and dark web, plus connected storage and cloud applications?
- Who triages the alerts, and what is the false positive rate? CybelAngel assigns a dedicated analyst, scores alerts to your needs, and reports low false positives.
- Do incident reports include file paths, document classification, threat actor profiles, and TTPs?
- Who handles the takedown and the vendor contact?
- How quickly do alerts reach your team, and how do they map to your notification deadlines?
We expand on this checklist in External Threat Detection for Lean Security Teams: 5 Questions to Ask Before You Buy. If you want to see what is exposed at your vendors today, reach out.
Can you prevent a vendor data breach?
No. You can shrink the exposure and shorten the time to detection, and those two moves decide the cost. Before the next incident:
- Write the clock into the contract. Require breach notice within 24 to 48 hours, audit rights, sub-processor disclosure, and data deletion at exit.
- Send less. Strip attachments and exports from tickets, and share the minimum data each vendor needs.
- Keep secrets out of client-side code. Scan your public JavaScript and repositories for keys and tokens, and rotate any you find.
- Inventory every vendor, including fourth parties. The average organization has 286, and the list is never complete.
- Watch from the outside. Monitor the open, deep, and dark web for your data at your vendors.
Prevention pays. The Harvard Business Review cited a study of 5,882 US hospitals that found hospitals that substantively integrated IT security into their processes, rather than adopting it symbolically, reduced data breaches by 37.8%. Data leaks are inevitable. Damage is optional.
Preguntas frecuentes
Una violación de datos de un proveedor es un incidente en un proveedor, proveedor de servicios o plataforma de software que expone tus datos o proporciona a los atacantes un acceso a tus sistemas. Verizon los clasifica en tres tipos: un proveedor en tu cadena de suministro de software, un proveedor que aloja tus datos y un proveedor conectado a tu entorno. La violación corresponde al proveedor, pero las consecuencias suelen recaer en ti.
Ambos de formas distintas. Bajo el RGPD, el procesador debe notificar a la entidad de control sin demora indebida, y la entidad de control sigue siendo la propietaria del plazo de 72 horas para notificar a la autoridad reguladora. Más allá de eso, la responsabilidad depende de su contrato, de su rol y de la legislación local. Solucione el problema antes de que ocurra un incidente: escriba los plazos de notificación, la distribución de costos y los derechos de auditoría, y pida a un asesor jurídico que los revise.
GDPR sets no fixed number of hours for a processor, only without undue delay, and contracts commonly set 24 to 48 hours. Do not rely on the vendor’s pace. EY detected anomalous activity on April 23, 2026, and its notification letters were dated July 13. Negotiate a short notice window now, then monitor externally so you are not waiting on a letter.
Como mínimo: la naturaleza de la vulneración, las categorías y número aproximado de personas y registros afectados, las consecuencias probables y las medidas adoptadas o propuestas. Solicite más información. Solicite al inquilino afectado, el periodo de tiempo, los campos de datos, la causa raíz y la confirmación de que el atacante ya no tiene acceso. Una notificación que no pueda responder a estas preguntas es en sí misma un indicio.
Revoke the vendor’s access, suspend integrations, and rotate the API keys, OAuth tokens, and service accounts you share with them. Preserve logs and evidence before anyone cleans anything up. Alert outside counsel and your incident response lead, and find out what the vendor holds on you. Then work through the six questions in this guide.
No de forma automática. Deshacerse de un proveedor puede destruir su visibilidad en el momento en que más lo necesita. Calcule la rapidez con la que le informó, la especificidad de la causa raíz y si modificó los controles. Reemplace el proveedor si no puede responder a las seis preguntas o si almacenó datos que nunca debería haber guardado. De cualquier manera, reduzca lo que mantiene.
Look from the outside. Search leak sites, paste sites, dark web forums, and Telegram channels for your organization’s name, domains, and employee email addresses, and check for exposed files in public storage and cloud applications. CybelAngel automates this: Data Breach Prevention, Credential Intelligence, and Dark Web Monitoring watch those sources daily and alert you on detection.
Fourth-party risk is the exposure created by your vendors’ own vendors. You have no contract with them and no audit right, yet they can breach data you entrusted to someone else. Sanofi’s Global Head of Cybersecurity describes third and fourth parties as the weak point. Ask vendors to disclose their sub-processors, and monitor for exposures that reach beyond your direct suppliers.
Start with whatever the compromised system could read: API keys, OAuth tokens, service account passwords, SSH keys, and CI/CD secrets, then anything the vendor held for your integrations. The Manchester Airports case started with API credentials in public code, and the LiteLLM compromise exposed credentials inside build environments. Rotate the whole set, not only the key named in the vendor’s notice.
It depends on the policy. Many policies treat incidents at third parties differently from direct ones, and most set notice deadlines. Read the language on third-party and dependent business interruption coverage, tell your insurer early, and confirm in writing before you hire forensic or legal help whether those costs are covered.
No. A questionnaire records what a vendor says about its controls on the day it answers. It cannot show that a vendor was breached last week or that your files sit in an exposed bucket. Use questionnaires as the starting point, then add continuous external monitoring for the vendors that hold your most sensitive data.
CybelAngel’s REACT Team runs Special Threat Investigations to establish what was exposed, map the threat actor, and deliver a confidential report with next steps. The platform finds leaked data, stolen credentials, and dark web mentions tied to your organization, and Remediation services handle takedowns. Request a demo to see what is exposed at your vendors today.
See what is exposed at your vendors
The next vendor breach will not wait for your questionnaire cycle. Investigación de Amenazas Especiales gives you the REACT Team when an incident goes beyond the routine, and the platform shows you what is exposed before an attacker finds it.
Sobre el autor
