A third-party security incident can affect your systems, customers, and reporting obligations before the vendor has complete answers. This guide provides a reusable vendor breach questionnaire, tracking table, escalation matrix, and evidence log so security, procurement, legal, and business teams can turn incomplete updates into a controlled response.
Overview
When a supplier, software provider, cloud platform, managed service, or business partner reports a cyber incident, the first response should not be an unstructured search for reassurance. Your team needs a consistent way to establish what happened, what may be affected, what remains unknown, and which decisions cannot wait.
A vendor’s incident may be isolated to its internal environment, or it may involve an integration, shared credentials, support tools, hosted data, software updates, or administrative access into your network. Until those boundaries are confirmed, treat the notification as an active third-party risk issue rather than a completed breach notice.
Assign one incident owner and create a shared record before contacting multiple vendor representatives. The owner should coordinate questions, preserve communications, record assumptions, and route decisions to the right internal teams. Security can assess technical exposure; procurement can locate contract terms; legal and privacy teams can assess notification duties; business owners can determine operational impact.
Keep separate labels for confirmed facts, vendor statements that have not been independently verified, working assumptions, and open questions. This distinction prevents an early vendor update from becoming an inaccurate internal conclusion.
What to track
Use a single incident tracker with one row for each affected service, integration, system, or data set. The following comparison table is a practical starting point:
| Variable | Questions to ask | Evidence to request | Internal owner |
|---|---|---|---|
| Affected systems | Which products, environments, accounts, regions, and interfaces were involved? Is our tenant or account included? | System names, tenant identifiers, architecture notes, affected-service list | Security or IT |
| Data types | What data was stored, processed, viewed, copied, altered, or deleted? Were credentials, tokens, payment data, personal data, or confidential files involved? | Data inventory, field-level description, access logs, retention details | Data owner and privacy |
| Attack timeline | When did suspected access begin? When was it detected, contained, and eradicated? When did the vendor notify customers? | Timeline with time zone, detection records, incident updates | Incident owner |
| Containment status | Is the attack still active? Have accounts, keys, sessions, endpoints, or integrations been disabled or rotated? | Containment summary, rotation confirmation, monitoring plan | Security or IT |
| Customer impact | Could our operations, users, customers, transactions, or connected systems be affected? Is there evidence of misuse? | Customer-impact assessment, service-status records, indicators of compromise | Business owner |
| Forensic confidence | Are conclusions based on completed forensics, preliminary review, or absence of evidence? What visibility limitations remain? | Investigation status, scope assumptions, unresolved questions | Security and legal |
| Notification duties | Which contract clauses, internal procedures, or applicable requirements may be triggered, and who is evaluating them? | Contract extracts, notification language, legal assessment | Legal and privacy |
| Remediation commitments | What corrective actions are promised, who owns them, and when will completion be verified? | Action plan, target dates, validation or attestation records | Vendor manager |
Vendor breach questionnaire
Send questions in a structured format and request a response owner and next-update time. Ask:
- What incident category is being investigated, and when was it first identified?
- Which of our services, accounts, environments, data stores, integrations, or users are in scope?
- What data could have been accessed, downloaded, changed, or destroyed?
- Is there evidence that our organization or customers were specifically targeted?
- What indicators of compromise, suspicious IP addresses, file hashes, domains, or access patterns can you share safely?
- What containment actions are complete, and what actions remain in progress?
- Have credentials, API keys, certificates, tokens, service accounts, or privileged sessions been revoked or rotated?
- What independent investigation or forensic review is underway, and what is its current confidence level?
- What service limitations, workarounds, or operational risks should we plan for?
- What customer communications are planned, through which authenticated channel, and on what schedule?
- What contractual or regulatory notification process does the vendor believe applies? Treat this as input, not a substitute for your own review.
- Which remediation actions will be completed, by whom, and how will customers receive confirmation?
Do not send sensitive customer records, credentials, or internal investigative details through an unverified reply address. Confirm the vendor contact through a known contract channel or established account portal. If the incident involves suspicious messages or payment requests, use the verification approach in this smishing verification decision tree before responding.
Evidence log template
For every update, record the date and time, source, sender, communication channel, exact statement or attachment, facts confirmed, assumptions made, actions assigned, owner, due date, and follow-up question. Preserve original emails, portal notices, meeting notes, screenshots, exported logs, and contract excerpts in a controlled location. Hashes or chain-of-custody procedures may be appropriate for formal investigations, but the basic requirement is traceability: another reviewer should be able to understand what was known and when.
Cadence and checkpoints
Use urgency and business impact to set the communication cadence rather than waiting for the vendor’s standard update cycle.
| Stage | Checkpoint | Action |
|---|---|---|
| First notice | Within the initial response window | Confirm authenticity, open the tracker, identify affected services, preserve the notice, and notify the incident owner. |
| Initial assessment | After the first vendor briefing | Compare the vendor’s scope with your asset, data, identity, and integration inventories. Identify immediate credential or access-control decisions. |
| Active investigation | At each agreed update | Require changes since the last update, unresolved questions, containment progress, customer impact, and the next checkpoint. |
| Recovery | Before restoring normal trust | Verify remediation, credential rotation, monitoring, service integrity, and any compensating controls. |
| Closure | After evidence is sufficient | Document final scope, decisions, notification analysis, lessons learned, and vendor follow-up obligations. |
For a high-impact incident, establish a short recurring call or written update with a fixed agenda. For a lower-risk event, a daily or periodic written checkpoint may be sufficient. Each checkpoint should answer four questions: what changed, what is confirmed, what remains unknown, and what decision is needed next.
Escalation matrix
Escalate internally when the vendor cannot establish scope, when privileged access or sensitive data may be involved, when operations are degraded, or when a deadline may affect notification or contractual commitments.
- Security lead: suspected compromise, indicators of compromise, active access, credential exposure, or inadequate containment.
- IT and identity teams: shared accounts, API connections, federated access, endpoint agents, certificates, or network paths require review or rotation.
- Privacy and legal: personal data, regulated information, contractual notice clauses, cross-border considerations, or uncertainty about affected individuals.
- Procurement and vendor management: missed updates, disputed scope, remediation commitments, service credits, audit rights, or renewal implications.
- Business leadership: material service interruption, customer-facing impact, financial exposure, or a decision to suspend the vendor.
- Communications and support: customers, employees, or partners may receive questions or misleading messages related to the incident.
How to interpret changes
A changing vendor narrative is not automatically evidence of bad faith. Early incident information is often incomplete. However, every material change should be logged and tested against prior statements.
Pay close attention to changes from “no evidence of access” to “access cannot be ruled out,” from a named system to a broader environment, or from a confirmed date range to an extended timeline. These changes can alter your risk assessment even when the vendor still cannot confirm misuse.
Separate absence of evidence from evidence of absence. A vendor may have no evidence that your data was accessed because logs are incomplete, retention periods have expired, or the investigation is still underway. Ask what visibility supports the conclusion and what limitations remain.
Compare the vendor’s answers with your own records: authentication logs, data-flow diagrams, access reviews, firewall or proxy records, help-desk reports, and customer complaints. A mismatch does not prove compromise, but it should generate a specific question and an owner.
Risk can increase even without confirmed data theft. Continued access, unrotated credentials, service instability, an unresolved vulnerability, or unreliable communication may justify compensating controls. These can include disabling an integration, limiting permissions, increasing monitoring, temporarily routing work elsewhere, or requiring additional approval for sensitive transactions.
When to revisit
Revisit this tracker on a monthly or quarterly cadence for important vendors, not only after an incident. At minimum, review critical suppliers when contracts renew, services change, new integrations are introduced, data classifications change, or a vendor reports a security incident.
During each review, confirm the vendor’s current contacts and authenticated communication channels; refresh the list of systems, data types, and privileged connections; verify notification and escalation clauses; check whether remediation commitments remain open; and test whether your team can reach the right people without relying on an individual employee’s inbox.
Update this article and your internal template when contractual notification examples, regulatory references, or major cloud-provider communication practices change. Avoid copying a vendor’s general incident page into your playbook without confirming that it covers your specific service, tenant, data, and contract.
When an incident occurs, take these practical steps:
- Verify the notice through a known vendor channel.
- Open one controlled incident record and assign an owner.
- Map the vendor’s affected scope to your systems, identities, integrations, and data.
- Send the questionnaire and request a dated next update.
- Escalate access, operational, privacy, and contractual risks to named internal owners.
- Record every change in scope and preserve the supporting evidence.
- Close only after remediation, notification analysis, monitoring, and lessons learned are documented.
For related internal response work, use the business security incident response checklist and the small business incident response plan. If personal information may be involved, the privacy law and breach notification tracker can help organize the separate legal review.
