Why Are Third-Party Breaches Harder to Respond to?
Third-party breaches compound the difficulty of standard incident response in four ways: you have no direct access to the forensic evidence (it lives on the vendor's systems); you depend on the vendor's timeline and candor for facts you need to meet your own regulatory deadlines; your notification clock may be running before you have enough information to scope the impact; and the vendor's legal interests may not align with your need for disclosure. According to IBM's Cost of a Data Breach Report 2024, breaches with a third-party attack vector cost an average of $4.61 million—$370,000 more than the overall average—and take 26 days longer to identify and contain.
No Direct Forensic Access
You cannot image the vendor's servers. Your IR firm must work from artifacts the vendor chooses to share, unless your contract includes audit rights.
Your Clock, Their Facts
Your 72-hour or 60-day notification deadlines run from when you discovered the breach—not when the vendor tells you the complete story.
Misaligned Incentives
Vendors may minimize scope, delay forensic findings, or withhold information that implicates them in inadequate security practices.
What Types of Supply Chain Attacks Should You Prepare For?
"Third-party breach" encompasses a wide range of attack vectors. Software supply chain attacks—where malicious code is introduced into software your organization trusts and installs—have become one of the most consequential attack categories since the SolarWinds compromise in 2020 and the Log4Shell vulnerability in 2021. Understanding which type you are dealing with determines the IR approach, the blast radius assessment, and the required notifications.
| Attack Type | How It Works | Example | Key IR Consideration |
|---|---|---|---|
| SaaS Vendor Breach | Attacker compromises the vendor's SaaS platform; tenant data is exfiltrated | Snowflake customer data theft (2024) | Determine which of your data was in the vendor's environment; review data minimization |
| Software Supply Chain (Build) | Malicious code is injected into a software build pipeline or dependency before it reaches you | SolarWinds Orion (2020), XZ Utils backdoor (2024) | Identify all systems running the compromised software version; assume full access from install date |
| Open-Source Dependency Compromise | A widely-used library is compromised, typosquatted, or abandoned and republished with malicious code | Log4Shell (2021), event-stream NPM package (2018) | Run software composition analysis (SCA) to find every use of the affected library across all products |
| MSP / MSSP Compromise | Attacker breaches a managed service or security provider to reach all of their clients simultaneously | Kaseya VSA ransomware (2021) | Assume lateral movement to all managed endpoints; sever MSP access immediately; treat as insider-level access |
| Data Processor Breach | A vendor that processes your customer data (payroll, benefits, CRM) is breached and your data is exposed | MOVEit Transfer (2023), various payroll processors | You (the controller) own the notification obligation; do not wait for the vendor to notify your customers |
| Hardware / Firmware Compromise | Malicious code is introduced in hardware or firmware before delivery | Nation-state interdiction of network equipment | Replace affected hardware; forensic imaging before disposal; notify NSA/CISA if nation-state suspected |
What Should You Do in the First 24 Hours?
The first 24 hours of a third-party breach are primarily about containment and information gathering—isolating the vendor relationship to stop ongoing exposure while extracting enough facts from the vendor to assess your notification obligations. Do both in parallel. Waiting for vendor confirmation before containing the connection is the most common mistake in third-party breach response.
1. Sever the Active Connection
If you have an active integration with the vendor (API credentials, VPN access, shared data feed, agent software), sever it immediately until the vendor confirms their environment is clean. Every minute the connection is live is a minute the attacker potentially has in your environment too.
2. Review the Contract
Pull the Master Services Agreement (MSA) and Data Processing Agreement (DPA). Look for: notification clauses (typically 24–72 hours), right-to-audit provisions, indemnification caps, limitation of liability carve-outs for data breaches, and cyber insurance requirements.
3. Inventory Your Data at the Vendor
Document precisely what data you shared with this vendor: data types, fields, volume, time range, and which of your customers or employees are affected. This determines your notification scope and statutory obligations.
4. Send the Demand Letter
Send formal written notice to the vendor's Legal and Security teams within hours, not days. This establishes your discovery date on the record, triggers their contractual notification obligation, and signals that you intend to enforce your audit and indemnification rights.
Vendor Demand Letter Template
Send this formal notice to the vendor's Legal and Security teams within the first few hours of learning of the incident. It documents your discovery date, triggers their contractual obligations, and creates a paper trail for any subsequent indemnification or insurance claim.
TEMPLATE: Notice_of_Breach_Inquiry.docx
URGENT: NOTICE OF SECURITY INCIDENT INQUIRY
To: [Vendor Name] Legal & Security Team
From: [Your Name], [Your Title], [Your Company]
Date: [Date and Time]
We have become aware of a security incident affecting your systems. As a customer and data controller, [Your Company] requires immediate written clarification regarding the impact on our data and your obligations under our Data Processing Agreement (DPA) dated [Date of DPA].
Pursuant to our DPA and applicable law (including but not limited to GDPR Article 33, CCPA, and [applicable state breach statute]), please provide written responses to the following within 24 hours of this notice:
- Has [Your Company]'s data been accessed, viewed, exfiltrated, or encrypted?
- If yes: precisely which data elements (fields and record types) were involved, and the approximate number of records?
- When did the incident begin, and when did you first discover it?
- Has the vulnerability or attack vector been fully remediated?
- Are you engaging external forensics or a PFI? If so, who, and will you share their preliminary report with us?
Please preserve all logs, access records, and evidence related to our account and data. We reserve all rights to audit your systems and seek full indemnification for damages, regulatory fines, customer notification costs, and legal expenses resulting from this incident.
Direct all further communications to [Your Email] and [Legal Counsel Email].
Sincerely,
[Your Name]
[Your Title]
[Your Company]
Vendor Incident Response Checklist
Use this checklist when managing a breach caused by a vendor, MSP, or software supplier. It covers both the vendor-management track (demanding information and enforcing contractual rights) and the internal-response track (containing exposure, scoping notification, and managing regulators). Work both tracks in parallel from Day 1.
Hours 0–6: Contain and Document
- Sever all active connections to the vendor (APIs, VPNs, agent software, shared portals)
- Rotate any shared credentials or API keys the vendor had access to
- Capture the timestamp of when you first learned of the incident — this is your discovery date for regulatory purposes
- Send the vendor demand letter (see template above)
- Assemble internal incident response team: CISO, Legal, Privacy Officer, Communications
- Open a secure incident log — document all vendor communications with timestamps
- Review your cyber insurance policy — notify your broker if coverage may apply
Hours 6–48: Scope and Assess
- Compile a complete data inventory: what data types did the vendor hold, in which systems, for how long?
- Identify all individuals (customers, employees, partners) whose data may be affected
- Review the vendor's DPA and MSA for notification timing obligations, indemnification caps, and audit rights
- Engage outside legal counsel specializing in privacy and data breach response
- If software supply chain: run software composition analysis (SCA) to identify all instances of the compromised component across your environment
- If MSP compromise: audit all endpoints the MSP had management access to; assume lateral movement until proven otherwise
- Determine applicable notification obligations (state laws, GDPR 72-hour window, sector-specific rules)
- Demand written vendor status update with specific findings — do not accept verbal updates
Days 2–7: Notify and Remediate
- File any required regulatory notifications (GDPR supervisory authority within 72 hours; state AG per applicable law; sector regulators)
- Prepare and send customer notification letters — do not delegate this to the vendor
- If 500+ individuals affected under GLBA or HIPAA: file required federal regulator notice
- Patch or replace any compromised software components identified in Step 6 above
- Rotate all credentials that the vendor's systems had access to
- Engage a third-party IR firm to verify vendor's remediation claims — see IR firms with third-party specialization
- Review and update your Vendor Risk Management (VRM) program and DPA template
Days 7–30: Recovery and Legal Track
- Obtain and review the vendor's forensic report (demand a copy per your DPA audit rights)
- Assess indemnification claim — document all costs incurred: notification, credit monitoring, legal fees, IR firm fees, regulatory fines
- Evaluate whether to terminate the vendor relationship or require remediation certification before reconnecting
- Conduct post-incident review: what due diligence gaps allowed this vendor in? Update vendor security questionnaire and approval process
- Brief Board and senior leadership on total incident cost and vendor risk posture
Who Is Responsible for What?
In a third-party breach, responsibility is divided between you (the data controller under GDPR, or the entity with customer relationships under US law) and the vendor (the data processor or service provider). The table below maps each major response activity to the responsible party. Note that being able to recover costs from the vendor later does not eliminate your obligation to act first.
| Activity | Responsible Party | Notes |
|---|---|---|
| Notifying regulators (GDPR SA, state AG, sector regulators) | YOU (Controller) | The vendor must notify you; you must notify regulators. Do not assume the vendor has filed on your behalf. |
| Notifying affected individuals (customers, employees) | YOU (Controller) | Your customers have no relationship with your vendor. Notification must come from you. |
| Notifying you (controller) of the breach | Vendor (Processor) | GDPR Art. 33(2): processor must notify controller "without undue delay." Your DPA should specify 24–72 hours. |
| Forensic investigation of vendor's systems | Vendor | They must investigate their own systems. You have a right to demand and review findings per your DPA audit clause. |
| Forensic investigation of your own environment | YOU | Determine if the vendor's compromise extended into your environment via shared credentials, APIs, or installed software. |
| Credit monitoring for affected individuals | Negotiable | You typically pay upfront to protect your customers; pursue reimbursement from vendor via indemnification clause. |
| Regulatory fines imposed on you | Negotiable | Recover from vendor if your DPA covers consequential damages and the vendor's negligence caused the fine. Many DPAs cap this. |
| Remediation of vendor's systems | Vendor | Vendor must fix their own systems. You should verify remediation before reconnecting—do not take their word for it. |
Frequently Asked Questions
Am I liable if my vendor gets breached?
Generally, yes. Under GDPR and most US state privacy laws, you (the Data Controller) are responsible for the data you entrust to a vendor (the Data Processor). You can pursue indemnification from the vendor later, but you are responsible for notifying your customers and responding to any regulatory inquiry. Ignorance of the vendor's security posture is not a legal defense.
What should I ask my vendor immediately after a breach?
Demand written answers to five questions within 24 hours: (1) Is our data involved? (2) What specific data elements were compromised? (3) When did the breach start and when was it discovered? (4) Has the vulnerability been patched? (5) Are you engaging a PFI or external forensics firm, and can we review their report? Do not accept verbal answers or vague assurances.
What is a software supply chain attack?
A software supply chain attack compromises code or infrastructure your organization trusts and uses—such as a third-party library, a CI/CD pipeline, an MSP management tool, or a SaaS vendor's update mechanism. The attacker reaches you through a trusted intermediary rather than attacking you directly. Response requires identifying every system running the compromised component and treating all of them as potentially compromised from the date of the malicious version's release.
Should I notify my customers if a vendor breach exposed their data?
Yes, in most cases. Even though the vendor caused the breach, the notification obligation belongs to you because your customers have a relationship with you, not your vendor. Waiting for the vendor to notify on your behalf is legally risky and typically not permitted under GDPR, CCPA, or US state breach laws. Notification letters should come from you, with your contact information for questions.
Related Resources
Need Help With a Vendor Breach?
Third-party breach response requires both vendor management expertise and the ability to independently verify forensic claims. Connect with IR firms that specialize in supply chain incidents and third-party risk assessments.