How to Write a Vendor Breach Incident Report When You Had No Visibility Into Their Systems

Start by separating two categories of investigation questions: questions about the vendor's breach (what happened on their systems, how they were compromised, what data was accessed) and questions about your organization's exposure (what data of yours was on their systems, whether that data has been misused, and what your regulatory obligations are).

You will have limited ability to answer the first category. You may have substantial ability to answer the second, and the second category is what your incident report primarily needs to address.

From your own systems and records, you can typically determine: which data categories you transmitted or stored in the vendor's environment (based on your own data classification and data flow documentation), the volume of records or data elements involved (based on your own transfer logs or API call records), the data retention period at the vendor (based on your contract and data processing agreement), whether you have received any signals of your data being misused (credential stuffing attempts using account patterns specific to that vendor's data, dark web mentions of your organization's data in combination with the vendor's breach announcement), and the regulatory classification of the affected data (PII, PHI, payment data, or other regulated categories).

This is the foundation of the incident report: a clear account of what you can verify from your own records, what you are relying on the vendor to confirm, and what remains unknown pending their investigation.

The first hour after receiving a vendor breach notification should be spent determining your notification obligations, because the deadlines run from when you become "aware" of the breach -- and "awareness" in a regulatory context typically means when you received the vendor's notification, not when their internal investigation concludes.

GDPR requires notification to your supervisory authority within 72 hours of becoming aware of a personal data breach, with a full description of likely consequences and measures taken. If EU residents' data was stored with the vendor, this 72-hour clock started when you received their notification. If you cannot complete the full notification within 72 hours, an initial notification with what is known and a commitment to update is compliant -- silence is not.

HIPAA requires breach notification to HHS and affected individuals within 60 days of the discovery of the breach for breaches affecting 500 or more individuals. Your Business Associate Agreement with the vendor determines whether the vendor or you are responsible for the notification, but you should verify rather than assume.

SEC rules (for public companies) require disclosure of material cybersecurity incidents within 4 business days of determining materiality. A vendor breach affecting significant customer data or operational continuity may meet the materiality threshold.

Your vendor contract likely includes breach notification obligations on the vendor's side: timeline for notifying you, minimum information to be provided, and cooperation requirements for your own investigation. Pull this language before your first meeting with the vendor -- it determines what you are entitled to demand from them.

The structure that makes vendor breach reports credible under conditions of partial information has three sections:

Section 1: What We Know covers facts you can state with confidence from your own records and from the vendor's confirmed statements. This section uses precise language: "Based on our data transfer records, we transmitted customer email addresses, account IDs, and subscription status information to [Vendor] between [dates]. The vendor has confirmed that their environment was accessed by an unauthorized party between [dates]." No hedging on facts you have confirmed. No extrapolation.

Section 2: What We Do Not Know and Why is the section most incident reports omit, and its absence is what makes reports look either overconfident or evasive. This section explains what information is unknown, why it is unknown, and when you expect to know it. "We cannot confirm at this time whether specific customer records were exfiltrated versus the broader database being accessed. This determination depends on the vendor's forensic investigation, which they have indicated will complete within [timeframe]. We will update this report when that information is available." Regulators and executives understand the limits of a third-party investigation. Pretending those limits do not exist is what erodes credibility.

Section 3: What We Are Doing covers your own remediation and mitigation actions: enhanced monitoring for credential misuse, customer notification if applicable, additional contractual demands for the vendor, and the review of your third-party risk management process for this vendor category. This section demonstrates active response regardless of the forensic limitations.

The vendor has competing interests during a breach incident: their own regulatory obligations, their legal liability exposure, their reputation, and their business relationship with you. Their legal team will be managing every statement they make. Treat all vendor communications accordingly -- verbal statements are not evidence, written statements are.

Immediately upon receiving the breach notification, request in writing: the specific data categories confirmed to be in scope, the date range of the unauthorized access, the forensic investigation timeline and expected completion date, their commitment to provide you with a copy of the final forensic report, the contact information for their incident response team lead and their legal point of contact for your questions, and confirmation of any law enforcement involvement.

Get these requests in writing via email or a formal incident communication channel. "We discussed this on the call" is not a record you can include in a regulatory filing.

Throughout the investigation, maintain a communication log: every call or message with the vendor, the date and time, who participated, and what was stated. If the vendor provides updated information that contradicts an earlier statement, document both statements and the dates. This log becomes part of your post-incident documentation and may be relevant if regulatory questions arise about whether you acted in good faith based on the information available to you.

If the vendor stops cooperating or significantly delays the investigation beyond their stated timeline, your contract's breach notification provisions may give you grounds to audit their investigation or bring in your own forensic team -- check whether your contract includes this right before the situation arises.

The most consequential decision in a vendor breach response is usually whether and when to notify affected customers. This decision is legally constrained by your notification obligations, but within those constraints it is also a business and ethical decision.

The legal floor is clear: if the breach meets the regulatory notification threshold for the applicable regulation (GDPR, HIPAA, state breach notification laws, SEC), you notify on the regulatory timeline regardless of business impact concerns.

The more difficult decisions arise when the breach falls below a regulatory threshold but still involves your customers' data. A breach of customer email addresses without payment data or credentials may not require GDPR notification to affected individuals if the risk to those individuals is low. But your customers may feel they should know. The decision should account for: the likelihood that affected customers will discover the breach from other sources (news coverage of the vendor's breach, dark web monitoring services), the trust implications of customers learning about the breach from a third party rather than from you, and the contractual obligations in your customer agreements regarding data security incidents.

Notification templates for vendor breaches should acknowledge three facts explicitly: the source of the breach was a third party (protecting your credibility), the data that was involved (being specific about what was and was not affected builds more trust than vague language), and what you are doing to protect those customers going forward. Vague language in customer notifications -- "we became aware of a security incident" without acknowledging the vendor -- is increasingly viewed as evasive and can compound the trust damage.

The post-incident review for a vendor breach covers different ground than a review of an internal incident. The forensic reconstruction of the vendor's breach is the vendor's report to produce, not yours. Your post-incident review focuses on your own third-party risk management process and what it failed to catch or prevent.

Specific questions for the post-incident review:

Was this vendor in scope for your third-party risk assessments? If not, why not? What data category or access level should have triggered inclusion?

What was the most recent assessment date and what did it find? If the vendor had a security assessment within 12 months of the breach, did it address the control area where the breach occurred? If it did and the control was assessed as adequate, that is one outcome. If it did not cover that area, that is a gap in your assessment methodology.

What contractual security requirements did you have for this vendor? Were they specific enough to address the control area where the breach occurred? Were they enforceable through audit rights?

What data minimization opportunities exist? Did the vendor have more of your data than they needed? Could the volume or sensitivity of data shared with this vendor be reduced?

What monitoring did you have on data leaving your environment to this vendor? Data loss prevention, API call logging, and egress monitoring determine what you can reconstruct about your exposure without the vendor's cooperation.

These findings from the post-incident review are what drive changes to your third-party risk management program -- and they are also what you document as the "corrective actions taken" in the final incident report.