Vendor data breach: what to do in the first 72 hours

A vendor data breach response is the set of steps you take, from the moment you learn a vendor was breached, to establish whether your data and services are affected, meet your own obligations and decide what happens to the relationship. The first 72 hours matter most, because several notification clocks, yours and the vendor's, may already be running.

This post gives a practical timeline for those first three days, the questions to ask the vendor, the notification duties that may apply to you, and what to do when the breach is one step further down the chain.

What does a 72-hour vendor breach timeline look like?

The exact steps depend on the vendor's tier, the data it holds and the regimes you operate under. This timeline is a common starting point; adapt it to your own incident response plan.

How do you confirm the breach affects you?

Start by making sure the report is about your vendor. Similar company names cause false alarms, and a ransomware group's leak-site claim is a claim, not a confirmed breach. Match the event to the legal entity you contract with, its parent and its subsidiaries.

Then pull what you already know from the vendor record: its tier, the services it supports, the data types it processes, any system access or integrations it has, and its last assessment and open findings. A breach at a vendor that holds regulated personal data and has API access to production is a different event from a breach at a vendor that hosts your marketing newsletter. This is where good tiering and due diligence pay off: the facts are on file before anything happens.

What should you ask the vendor?

Contact the vendor through the channel named in the contract, and keep the questions short and written.

1. Is our data, or any system connected to ours, in scope of the incident?
2. Which data types and how many records of ours may be involved?
3. Is the incident contained, and is the service we use still safe to use?
4. Were any credentials, keys or tokens that connect to our environment exposed?
5. Is a subcontractor or subservice organization involved?
6. When will you send a formal notice and your next update?

Check the contract at the same time. Most well-drafted agreements set out when and how the vendor must disclose security breaches, what information it must provide, and your audit and cooperation rights. The US Interagency Guidance on Third-Party Relationships lists timely disclosure of information security breaches among the contract provisions banking organizations should consider. If your contract is silent, note it as a gap to fix at renewal.

Which notification duties might apply to you?

A vendor's breach can start your own clock. The duties vary by regime, sector and your role, so treat the points below as prompts for a conversation with counsel, not as advice.

• GDPR. Under Article 33, a controller must notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, unless the breach is unlikely to result in a risk to individuals. A processor must notify the controller without undue delay. If your vendor is your processor, its notice to you may be what starts your clock.
• US banking. The computer-security incident notification rule requires banking organizations to notify their primary federal regulator no later than 36 hours after determining that a notification incident has occurred. It also requires bank service providers to notify affected bank customers as soon as possible when an incident has disrupted, or is reasonably likely to disrupt, covered services for four or more hours.
• Public company disclosures. Listed companies must disclose material cybersecurity incidents on Form 8-K Item 1.05, generally within four business days of determining that the incident is material. A public vendor's filing may reach you before its customer notice does.
• Other regimes. State breach laws, sector regulators and contracts with your own customers may add duties. Check each one that applies.

What if the breach is at a fourth party?

Some of the most disruptive breaches happen at a provider your vendors share: a processor, a hosting platform or a widely used software product. You may have no contract with it, and no vendor may tell you promptly.

Work it from the provider outward. Identify which of your vendors rely on the breached provider, directly or as a subservice organization, then rank them by tier and data type and contact the most critical first. This is only quick if your fourth parties are mapped to one record per provider before the incident. If they are not, add the question "do you use this provider?" to your outreach and record the answers.

How should you record decisions and trigger reassessment?

Write down every decision, its reason, who made it and when. That includes decisions to do nothing, such as concluding that no notification was required. Regulators and auditors look for a clear trail from the first report to the outcome.

Then decide what happens to the relationship. A confirmed breach at a vendor that holds your data is a common trigger for event-driven reassessment: bring the next assessment forward, raise findings for the control gaps the breach exposed, and agree remediation with owners and dates. For lower-impact cases, a targeted follow-up on the affected controls may be enough.

VendRisk360 vendor data breach alerts match SEC cyber incident filings, state breach notices, ransomware leak-site claims and breach databases to the vendors on your register. Verified breaches alert the people who own those vendors, while unverified reports and claims are held for checking. The alert sits on the vendor record beside its tier, data and assessment history, and decisions about your own notification obligations stay with your organization and its advisers.

Frequently asked questions

What should I do first when a vendor has a data breach?

Confirm the report is about your vendor, not a similarly named company, and treat leak-site claims as unconfirmed. Then pull the vendor's tier, services, data types and system access from your records to see what may be exposed, open an incident record and alert the vendor owner and security lead.

Does GDPR's 72-hour rule apply to a vendor breach?

It can. GDPR Article 33 requires a controller to notify its supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of a personal data breach, unless it is unlikely to result in risk to individuals. If your vendor is your processor, its notice may start your clock. Confirm with counsel.

What questions should I ask a vendor after a breach?

Ask whether your data or connected systems are in scope, which data types and how many records are involved, whether the incident is contained, whether credentials linking to your environment were exposed, whether a subcontractor is involved, and when the formal notice and next update will arrive.

Should a vendor breach trigger a reassessment?

Often, yes. A confirmed breach at a vendor that holds your data or supports a critical service is a common event-driven trigger. Bring the next assessment forward, raise findings for the control gaps the breach exposed, and agree remediation with owners and target dates.