A Vendor Got Breached: Your First 72 Hours of Third Party Breach Response

By ScruteXPublished 05-11-2026

You learn about it from a news alert, a customer email or a ransomware leak site. The vendor's own notice, if it comes at all, arrives later and says less. By then the attacker may have had your data for weeks. Your regulator's clock may already be running too.

What is third party breach response? Third party breach response is the set of actions your security team takes when a vendor, supplier or service provider that holds your data or connects to your systems is compromised. It covers scoping your exposure, cutting the vendor's access, getting facts from the vendor, meeting regulator deadlines and deciding whether to keep the vendor.

This playbook runs hour by hour through the first 72 hours. It includes the questions to send the vendor at each stage.

Why are vendor breaches now the common case?

Vendor breaches are no longer the edge case most incident plans treat them as. Verizon's 2026 Data Breach Investigations Report found a third party involved in 48% of breaches, up from 30% in the 2025 report. In financial services, a third party figured in 34% of breaches.

The 2025 Salesloft Drift campaign shows how one vendor becomes hundreds of incidents. Salesloft said the attacker had access to its GitHub account from March to June 2025. Mandiant found the attacker then reached Drift's AWS environment and took OAuth tokens for customers' integrations. From August 8 to 18, the attacker used those tokens to export data from customers' Salesforce instances. Early estimates put the number of affected organisations at around 700.

The pattern repeated in 2026. In June, the Icarus extortion group got into Klue, a competitive intelligence platform, and took the OAuth tokens that linked Klue to its customers' Salesforce environments. Huntress traced the entry point to a long-disused but still active credential that Klue had created for an integration it later abandoned. LastPass, Recorded Future, Tanium, Jamf, Gong and Huntress were among the companies whose CRM data was taken.

A vendor breach is now a routine scenario. It needs its own playbook.

Hour 0 to 1: confirm, own and start the clock

The first hour is about three facts. Is this really your vendor? Who owns the response? When did your clock start?

Confirm the match. Vendor names collide. Check the legal entity, the product line and the region against your contract register. A breach at a vendor's marketing site is a different event from a breach at the platform holding your customer data.

Name one owner. Third party incidents fall between procurement, the business owner, legal and security. Pick one incident lead on the security side. The business owner of the relationship joins as the person who knows how the service is used.

Write down two timestamps. Record when the vendor detected the incident (if known) and when you learned of it. Under some rules, the first timestamp is the one that counts. RBI's IT outsourcing directions require service providers to report cyber incidents to the regulated entity without undue delay, so that the entity can report to RBI within six hours of detection by the service provider. If your vendor sat on the news for five hours, you may have one hour left.

The Klue case shows how far apart those timestamps can drift. Klue spotted unusual activity on June 12 and sent a general alert on June 13 that named no affected customers. Huntress staff received extortion emails on June 16. Icarus listed Klue on its leak site on June 19. A customer that waited for a named notice learned of its exposure from the attacker.

Open one incident record. Every later report, internal or regulatory, should come from the same record. Indian regulators now accept staged filings, which makes this easier. SEBI's August 2026 circular aligned its incident portal with the Financial Stability Board's FIRE format: an initial report on what is known, intermediate updates, then a final closure report.

Hours 1 to 4: map the blast radius

Now answer one question: what did this vendor have of yours? Work through four layers.

Layer	What to list	Where to find it
Data	Which data sets the vendor stores or processes, and whether they include personal data	Contract, data map, DPIA
Access into you	OAuth grants, API keys, service accounts, VPN or VDI accounts, SSO apps, shared credentials	IdP, SaaS admin consoles, PAM, secrets vault
Secrets stored with them	API keys, tokens or passwords your staff pasted into the vendor's tool	Support tickets, notes fields, integration configs
Their vendors	Sub-processors that may also be in scope	Vendor's sub-processor list

The third layer is the one teams miss. In the Drift campaign, Google's threat intelligence team found the attacker searching exported Salesforce data for AWS access keys, passwords and Snowflake tokens left in records. Cloudflare said the attacker reached its Salesforce support cases and that 104 Cloudflare API tokens sat in that data. Cloudflare rotated all of them. A vendor holding your support tickets may be holding your keys.

Questions to send the vendor at hour 2

Which of your products, environments and regions are affected?
Is our tenant, account or data in the affected scope? Answer yes, no or not yet known.
What is your earliest known date of attacker access?
Have you revoked or rotated tokens, keys or credentials that connect to our environment?
Who is our single point of contact, and how often will you update us?

Keep the first message to five questions. A vendor in the middle of an incident answers five questions in hours. Forty questions can take days.

Hours 4 to 12: cut access and send the next questions

Contain on your side without waiting for the vendor's answer.

Revoke and reissue every credential the vendor holds into your estate. Start with OAuth grants and API keys, because they skip MFA. In the Drift case, Salesforce worked with Salesloft to revoke all active Drift access and refresh tokens, which forced every customer to re-authenticate. Do the same on your side even if the vendor says you are not affected.
Revoke sessions, not only the integration. Huntress advised Klue customers to kill all active sessions for affected services, because the attack ran on harvested credentials.
Disable the integration if the business can live without it for a day. You can re-enable it in minutes once you trust it again. A stolen token can drain your data in the same minutes.
Rotate any secret that sat in data the vendor held. That includes keys in support tickets, shared mailboxes and notes fields.
Raise monitoring on vendor-linked identities. Watch service accounts, integration users and named vendor staff accounts for unusual hours, new IPs and bulk exports.
Warn your own staff and customers about phishing in the vendor's name. Stolen contact and case data feeds targeted phishing, and attackers can quote real ticket numbers.

Questions to send the vendor at hour 8

What attacker techniques have you confirmed (stolen credentials, exploited vulnerability, insider, malware)?
What indicators of compromise can you share now: IPs, user agents, file hashes, domains?
What data types were accessed or exfiltrated, and for which customers?
Have you engaged an external forensics firm, and which one?
Have you received an extortion demand or seen a leak-site post?
Have you notified law enforcement or a regulator?

Hours 12 to 24: hunt in your own logs and file what you must

Hunt from the vendor's earliest access date, not from today. If the vendor says attackers got in three months ago, your log search starts three months ago. Look for vendor-linked identities doing new things. In the Drift campaign, the attacker deleted query jobs to hide activity, but the underlying logs stayed intact. Klue published four attacker IP addresses that customers could search for in their Salesforce and connected-app logs. Ask your vendor for the same, and for any access logs you cannot pull yourself. Huntress told Klue customers to state plainly that the request is part of an active security investigation.

Decide what to file. Make this decision with legal, on facts that are still incomplete. Indian rules don't let you wait for certainty. The CERT-In directions of April 2022 require listed cyber incidents to be reported within six hours of noticing them or being told about them. SEBI-regulated entities must email SEBI within six hours and report on the incident portal within 24 hours. In the EU, DORA's initial notification is due within four hours of classifying an incident as major, and no later than 24 hours after becoming aware of it.

Agree in advance who signs off a six-hour report that says "facts not yet known". If that sign-off waits for a meeting, the deadline passes.

Tell your board and business owners what you know and don't know. Use three columns: confirmed, suspected, unknown. Update all three at a fixed time every day.

Hours 24 to 48: check the vendor's story against outside evidence

Vendors under pressure report what they have confirmed. That is usually less than what happened. Early statements often say "no evidence of customer data access", and later updates often walk that back. Check the vendor's account against what you can see yourself.

Leak sites and dark web forums. Has a ransomware or extortion group named the vendor, or posted samples that include your data? Icarus posted Klue victims' data on June 22, three days after listing Klue. Huntress also warned that leaked archives may carry malware, so let your incident team or an intelligence partner confirm exposure rather than opening raw files.
Credential exposure. Have your staff credentials, session cookies or API keys appeared in stealer logs or breach dumps since the vendor's earliest access date?
Lookalike domains. Has someone registered domains that copy the vendor's name to run phishing or fake "breach support" pages?
The vendor's external posture. Do exposed services, expired certificates or known exploited vulnerabilities on its internet-facing assets match the attack story it tells?

None of these replaces the vendor's forensic report. They tell you whether that report is complete.

Questions to send the vendor at hour 36

What is the root cause, and has it been closed?
Which persistence mechanisms did you find and remove?
Will you share the forensic report or an executive summary under NDA?
Which sub-processors were involved or affected?
What has changed since your last update, and what is still unknown?

Hours 48 to 72: restore, restrict or exit

By hour 72 you need a decision on the relationship, even if it is provisional.

Decision	When it fits	What to require
Restore	Root cause closed, your data not in scope, credentials rotated on both sides	Written confirmation, new credentials, tighter scopes
Restrict	Vendor still investigating, or your data was in scope	Reduced data sharing, read-only integration, more frequent updates
Exit	Vendor can't answer basic scope questions, or root cause is still open	Data return and deletion certificate, transition plan per contract

Prepare the next filings. DORA's intermediate report is due within 72 hours of the initial notification. GDPR requires notice of a personal data breach to the supervisory authority within 72 hours of awareness, unless the breach is unlikely to put people at risk. In India, Rule 7 of the DPDP Rules will require a detailed report to the Data Protection Board within 72 hours. That duty takes effect in May 2027, so build the process now.

Write down what you learned while it is fresh. List which questions the vendor couldn't answer, which contract clauses helped and which data you didn't know the vendor held. That list becomes next year's due diligence questionnaire.

The regulator clocks in one table

Regime	Who	First report	Later reports
RBI IT outsourcing directions (2023)	Regulated entities using IT outsourcing	To RBI within 6 hours of detection by the service provider	Per RBI direction
RBI cybersecurity directions (July 2026)	Regulated entities in scope of each direction	On DAKSH within 6 hours of detection, with notice to CERT-In	Per direction
CERT-In directions (2022)	Service providers, intermediaries, data centres, body corporates	Within 6 hours of noticing or being told	As CERT-In requests
SEBI CSCRF and FIRE-aligned portal (2026)	SEBI-regulated entities	Email within 6 hours	Portal within 24 hours, then intermediate and final reports
DORA	EU financial entities	4 hours from classification as major, 24 hours from awareness at the latest	Intermediate within 72 hours, final within one month
GDPR	Controllers	72 hours from awareness	As facts develop
DPDP Rules (from May 2027)	Data fiduciaries	Without delay	Detailed report within 72 hours

Note what triggers each clock. For RBI outsourcing, detection by the vendor can start your clock. DORA's clock starts at classification. For CERT-In, it starts when you notice or are told. One vendor breach can run four clocks at once, each starting at a different moment.

This table is a planning aid, not legal advice. Confirm your obligations with counsel.

What is the vendor going through?

Fair treatment of the vendor gets you better answers. In the first 72 hours, the vendor's team is containing the attack, working with forensics, briefing its own regulators and answering hundreds of customers at once. It often does not know the answers yet. It may be under legal advice to say little.

Three habits help both sides:

Ask for structured answers. "Yes, no or not yet known" moves faster than open questions.
Join a shared channel where one exists. When many customers ask one vendor the same questions, a joint briefing through an industry group or ISAC saves the vendor hours it can spend on containment.
Separate urgent from important. Scope and credentials come first. Root cause and contract remedies can wait until week two.

Vendors that handle this well publish IOCs, name a contact and share attacker activity logs. Klue's published IP list is the kind of thing that lets customers hunt the same day. Vendors that go silent tell you something too.

Who else pays when a vendor is breached?

The people at the end of the chain are your customers, and they rarely know the vendor exists. When attackers took LastPass's CRM data through Klue, the records covered customer names, phone numbers, email and physical addresses, and support case details. LastPass said customer vaults were not affected. Data like that still feeds convincing phishing: a real case reference, a real support history, a real name.

So your third party breach response should include a customer step. Tell affected customers what was taken and what scams to expect. Tell them how you will and won't contact them. Monitor for lookalike domains that copy your brand or the vendor's. The breach happened at the vendor, but your customers will judge your response.

Are the 72 hours decided at contract time?

Mostly, yes. The questions you can get answered in the first 72 hours depend on what the contract already requires.

Notification terms with a clock. RBI's outsourcing directions expect the contract to list the incidents a provider must report. Write a fixed number of hours into the contract, not "promptly".
A named security contact and an escalation path, reachable outside office hours.
Rights to logs and forensic summaries for incidents that touch your data.
A sub-processor list that the vendor keeps current.
Credential hygiene on the vendor's side. Ask how the vendor retires credentials for abandoned integrations. Klue's attacker came in through one.
Exit and data deletion terms you can trigger after a material incident.

Recognised frameworks cover this ground. NIST SP 800-161 Rev. 1 sets out cyber supply chain risk management practices, including supplier incident handling. The ISO/IEC 27036 series covers information security in supplier relationships. Shared Assessments' SIG questionnaire includes incident management controls you can map to contract clauses. Teams that use one of these at onboarding have most of the hour-2 answers on file before the breach.

Questionnaires and contracts tell you what a vendor promised at signing. External monitoring tells you how the vendor looks from outside today. Large teams often run both: a security ratings platform for breadth and a questionnaire process for depth. Smaller teams get more from one connected view than from two tools nobody reads. Either way, the goal is to learn about the vendor's breach before the vendor's notice arrives.

Key takeaways

Third parties featured in 48% of breaches in Verizon's 2026 DBIR. Treat a vendor breach as a standard incident type with its own playbook.
Record two timestamps in hour one. Under RBI's outsourcing rules, the vendor's detection time can start your six-hour clock.
Revoke and reissue every credential the vendor holds into your estate, and kill active sessions, before the vendor confirms anything.
Hunt from the vendor's earliest access date, and look for your secrets inside data the vendor stored.
Send five questions at a time, in stages. Check the answers against outside evidence.
Decide by hour 72 whether to restore, restrict or exit, and feed the gaps into next year's contract.

Am I exposed?

Check these today. You don't need ScruteX for any of them.

☐ Can you list every vendor holding an OAuth grant, API key or service account in your SaaS and identity platforms, with a named owner for each?
☐ Do your top 20 vendor contracts state incident notification in hours, and does that fit your regulator's clock?
☐ Search your support tool and CRM for API keys, passwords or tokens pasted into tickets. Would a vendor breach expose them?
☐ Do you have a pre-approved template for a six-hour regulatory report that says "facts not yet known"?
☐ For your three most critical vendors, do you have a named security contact you can reach tonight?

What ScruteX finds here

Vendor Insights scores a vendor from its domain using external signals, such as exposed services and certificate problems. It also sends and tracks security questionnaires, so your hour-2 questions go out from a template rather than a blank email. Threat Insights tracks ransomware and extortion group activity, so a vendor on your list that appears on a leak site surfaces as an alert. Data Exposure Insights watches stealer logs, paste sites and breach data for credentials tied to your domains, which tells you whether the vendor's breach has leaked your staff accounts.

What that looks like

Sample alert layout. Values are illustrative, not from a customer.

Score the vendor in today's news

Is a vendor in this week's breach headlines also one of yours? Enter its domain to see its external risk score. Domain only, no signup.

Score a vendor

ScruteX sees vendors from the outside only. It can't see inside a vendor's network, and it doesn't replace the vendor's forensic report or your contract rights. It tells you what is visible on the internet so you can test what the vendor tells you.

Where to go next

Vendor Insights: start here if you need a risk score and questionnaire workflow across your vendor list.
Threat Insights: read this if you want ransomware and leak-site claims about your vendors as alerts rather than headlines.
How to run a third party risk assessment: goes deeper on the onboarding work that decides how fast this 72-hour playbook runs.
Vendor security assessment template: gives you the questions to ask before a breach, so the hour-2 answers are already on file.

FAQ

Q: What should I do first when a vendor is breached? A: Confirm that the affected entity is your vendor and name one incident owner. Then record when the vendor detected the breach and when you learned of it. Some regulators, including RBI, measure your deadline from the vendor's detection time.

Q: What questions should I ask a breached vendor? A: Start with five: which products are affected, whether your data is in scope, the earliest date of attacker access, whether credentials into your environment were rotated, and who your contact is. Ask about techniques, IOCs, root cause and forensic reports in later rounds.

Q: Do I need to report a vendor's breach to my regulator? A: Often, yes, if the incident affects your services or data. RBI regulated entities using IT outsourcing must report within six hours of detection by the service provider. SEBI entities have six hours by email and 24 on the portal. DORA's initial notice is due within four hours of classifying the incident as major.

Q: Should I cut off a breached vendor immediately? A: Cut its access into your systems first: revoke OAuth grants, API keys, service accounts and active sessions. Decide whether to end the relationship by around hour 72, based on whether the vendor can confirm scope and close the root cause.

Q: How do I check whether a vendor's breach statement is accurate? A: Compare it with outside evidence. Look at leak-site posts, credentials tied to your domains in stealer logs and breach dumps, lookalike domains, and the vendor's exposed internet-facing assets. Ask for attacker activity logs, IOCs and a forensic summary.