Every security leader knows the call: it's 11pm, a vendor you depend on has had an incident, and the coordination between their IR team and yours is about to become the most important project of the week. How this coordination runs — what you demand, what you give, how cadence gets set — often determines whether your organisation emerges from the incident faster or slower than your peers using the same vendor. The work is specific enough that it deserves its own playbook, and most organisations learn it by accident during the third or fourth vendor incident they coordinate. This post is the condensed version of that learning.
The first communication sets the tone
Your vendor's first communication to you will be vague by design. Real-time incident facts are scarce, legal teams are reviewing wording, and the vendor doesn't yet know what they don't know. Your job on receipt of that first communication is not to demand more detail immediately — it is to establish the coordination channel.
The three-message response:
- Acknowledge receipt. Name the communication, confirm you've escalated internally, and identify the single named person on your side who owns the coordination.
- Request a direct technical channel. A Slack Connect, a shared war-room, or an encrypted email thread with your IR lead and their IR lead. Not the general account rep. Not the support portal.
- State your immediate decision criteria. What information do you need from them in the next 24 hours to decide whether to disconnect, contain, or continue? Make this concrete.
Vendors handle dozens of parallel customer coordinations during a large incident. The customers who establish clear channels and decision criteria in the first hour are the ones who get useful information first.
What to demand, ranked by importance
Five items, in order:
- Indicators of compromise. Hashes, IPs, domains, user-agent strings, specific commands or API patterns. Everything you'd need to check your own environment for evidence.
- Timeline bounds. Earliest possible compromise time; earliest known malicious activity time. Be specific: "sometime in 2024" is not a timeline.
- Scope. Which products, services, tenants, or customer classes are confirmed affected. Which are confirmed unaffected. Which are still under investigation.
- Actions taken. What the vendor has already done — keys rotated, services isolated, customer-side remediation pushed. So you don't duplicate work.
- Expected next milestones. When the next meaningful update is coming. Not "we'll keep you informed" — a specific time or condition.
If you get the first three within 24 hours, the vendor's IR is working. If you can't extract them, something is wrong with either their process or your escalation.
Cadence management is underrated
During a live incident, status calls are tempting but expensive for the vendor's IR team. Every call is time not spent investigating. Establish a written update cadence (daily at a specific time, plus ad-hoc for significant developments) and hold your side to it strictly.
Avoid the anti-pattern of the senior exec on your side calling the senior exec on their side for updates. This fragments the information flow and distracts the IR leads on both sides. Centralise all coordination through the named contacts.
Customer communication discipline
You will be tempted to communicate with your own customers based on the vendor's partial information. Resist this until the vendor has either authorised a customer-side disclosure or enough time has passed that you must communicate independently.
When you do communicate, be specific about what is your vendor's incident (external factor) versus what is your response (internal control). Customers forgive "our vendor was compromised and here is what we did about it" more readily than "there was an incident" framed ambiguously.
Three-line template:
"Our vendor [name] disclosed an incident on [date]. Based on our investigation, the impact on [your product] is [specific scope]. The actions we have taken are [list]. We will follow up with further detail by [date]."
Contracts that make the coordination possible
Most vendor contracts signed pre-2022 do not include explicit incident notification and coordination clauses. Adding these during renewal is now standard. The provisions worth negotiating:
- Notification timeline: specific hours after vendor confirms an incident (24 hours is becoming baseline; 72 is weakly defensible).
- Direct technical contact: vendor must provide a named technical contact during incidents, not just an account manager.
- IoC sharing: vendor must share indicators with you during an active incident, not gate them behind a post-incident report.
- Post-incident review participation: vendor must allow your team to participate in or receive the post-incident review.
These clauses are increasingly negotiable; five years ago they often were not.
Third-party coordination amplifies the problem
Your vendor's incident may involve their vendor. A Slack incident involving a compromised Twilio account involves two vendor relationships; the information flow is now two-hop. Ask explicitly about fourth-party involvement during the scoping conversation, and factor it into your timeline expectations.
Supply chain attacks specifically tend to have this structure: the attacker compromises a vendor of a vendor. The coordination work compounds accordingly.
Post-incident review is the payoff
The value of good coordination during the incident is realised in the post-incident review. A well-run review captures:
- Detailed timeline from initial compromise to resolution
- Attack path with enough specificity to check your own environment
- Controls that worked and failed on both vendor and customer sides
- Specific commitments from the vendor for preventive improvements
Request the post-incident review as a specific deliverable with a specific timeline. Many vendors default to public blog posts as their review; these are insufficient for your internal learning. A dedicated customer-facing review, even under NDA, is a higher-quality artifact.
Build the relationship before the incident
The customers who coordinate most effectively during vendor incidents usually had a working relationship with the vendor's security team before the incident — through a bug bounty program, a shared conference, a security-specific sales conversation. This relationship pays off exactly when it's needed.
For critical vendors, invest in this relationship. A 30-minute introductory call with the vendor's CISO during a calm week is worth 10 hours of confused coordination during a crisis.
How Safeguard Helps
Safeguard's TPRM module tracks vendor incident notification clauses, current risk posture, and previous incident handling quality as durable vendor metadata. During an active vendor incident, Griffin AI pre-populates the coordination workspace with the vendor's expected response posture, historical IR performance, and your organisation's specific exposure scope. Policy gates can require updated incident-coordination clauses at contract renewal for vendors with high blast-radius access. For security leaders who have coordinated through three vendor incidents and don't want to rebuild the playbook a fourth time, Safeguard makes the vendor coordination work a structured capability rather than a per-incident improvisation.