Yes, write a short review of your own response, even if the vendor caused the incident. You cannot fix their systems, but you can learn how quickly you heard, how you found your exposure, who decided what, and what you told customers. Scope it to your actions and dependencies.
What to review and what not to
A vendor incident is a test of your detection, inventory and communication. The vendor's root cause is theirs to publish. Yours is a different question: why were you exposed in the way you were, and how did you respond?
Google's guidance says postmortems should be triggered by objective criteria set in advance, and that any stakeholder may request one. Add "third party incident that required action from us" to your triggers. See which security incidents need a postmortem.
Questions for the review
| Area | Question |
|---|---|
| Notice | How and when did we learn? From the vendor, a researcher, the press? |
| Inventory | Could we tell within an hour whether we used the affected service or component? |
| Exposure | What data, credentials or integrations touched the vendor? |
| Containment | Which keys or tokens did we rotate, and how long did it take? |
| Decisions | Who decided, and was it clear who could? |
| Communication | What did we tell customers and when? |
| Evidence | What records did we keep for later questions? |
| Vendor contact | Did we have the right contacts? |
For related checklists, see how to answer "are we affected" after a supply chain incident and the supply chain incident contact sheet.
Keep the facts straight
Be careful about what you claim about the vendor. Use only what they or other reliable sources have published, and mark the rest as unknown. Do not speculate about their cause. Our post on not speculating in public covers the same discipline for your own incidents.
Steps
- Within a week, hold a 30 minute review with the people who responded.
- Build a timeline from your side: first notice, first action, each decision, each customer message. Use UTC.
- Mark the gaps: where you waited, guessed or lacked information.
- Convert gaps to actions of type prevent, detect or mitigate. See prevent, detect, mitigate.
- Reduce reliance: could you replace, isolate or limit the vendor's access?
- Update your vendor inventory and contact list.
- Share a summary widely, as with any postmortem.
Typical actions that come out
- Subscribe to the vendor's status and security notices, and to independent feeds.
- Keep a current inventory of services and components, with owners.
- Shorten the lifetime of credentials shared with vendors.
- Add the vendor to your tabletop scenarios.
- Agree in advance who may approve customer statements.
How Safeguard fits
For vendor incidents involving a software component, an up to date inventory shortens the exposure question. Safeguard's SBOM and dependency scanning supports that, and asset discovery helps find what is in use. A free scan is available at https://gold.safeguard.sh/scan.
Quick check
Should we wait for the vendor's postmortem first?
No. Review your own response while memory is fresh, and add the vendor's findings when they publish.
Is blame for the vendor appropriate in our write-up?
Stick to confirmed facts and focus on your controls. Their cause is theirs to explain.
Sources
Last reviewed: 19 October 2026.
