The Vendor Incident Playbook

4 MIN READ

Picture the vendor incident playbook that the GRC team printed, laminated, and filed in the shared drive last year. The procurement lead has signed it. The CISO office has approved it. The third party risk team has reminded everyone it exists. Then the vendor emails at 2am to say the production environment was breached, and the playbook amounts to the document nobody opens until the postmortem, by which point the contact tree is out of date, the severity matrix lacks the new vendor product line, and the response timeline in the contract said 72 hours, which now lands 67 hours too late. The honest framing is this: a vendor incident playbook serves as a useful artefact, but a useful artefact only works when someone reads it before the incident, not after.

Lineage worth knowing. SolarWinds in 2020 exposed the supply chain angle, Okta in 2022 and 2023 exposed the access broker angle, LastPass in 2022 exposed the encrypted vault angle, MOVEit in 2023 exposed the file transfer angle. The pattern repeats. The vendor had a playbook. The vendor’s customers had their own playbooks. Both parties had signed contracts that promised notification in 24 or 48 or 72 hours. Both parties learned that the promise and the actual notification land in different places, and the gap between the two amounts to where the customer feels it.

What the playbook actually is

Three artefacts, each doing one job. The contact tree lists the named people at the vendor who take the call when the breach hits, with the security lead, the account manager, the legal contact, and the executive sponsor on the customer side mirrored against them. The severity matrix maps the breach type (data exfiltration, credential exposure, service outage, supply chain compromise) against the response tier (low, medium, high, critical) so the procurement lead does not have to invent a category at 3am. The response timeline sits as the contract clause that says the vendor has to notify within a stated window, the same window the customer has built into its own regulatory escalation path. None of the three are exotic. All three are usually wrong on the day they get used, because the contact tree dates from last year’s vendor review and the account manager left six months ago.

What the typical plan misses

Three gaps, in roughly the order they cause the most damage. The secondary contact amounts to the person at the vendor who takes the call when the primary cannot, and the typical plan tests the primary in the drill and skips the secondary. Then the secondary does not answer on the day, because the secondary never gets a drill call, and the procurement lead finds out the named contact was a vendor acquired nine months ago. The out of band channel runs as the second gap, and it matters more than people think. The plan assumes the vendor’s email and the vendor’s status page remain reliable during a breach. They do not. The vendor’s email sits inside the breached environment, the vendor’s status page amounts to the public version, and the actual notification arrives through a personal Gmail from a CISO who knows the customer lead on LinkedIn. The third gap serves as the regulatory escalation, which almost every playbook delegates to the vendor. The vendor files with its own regulator, the customer assumes the regulator on the customer side gets covered too, and the CISO office finds out at the audit that the disclosure the vendor filed was the vendor’s filing, not the customer’s. The customer remains on the hook.

How to make the playbook work

Test the contact tree. The third party risk team calls the named contact at the vendor every quarter, confirms the person still works there, confirms the backup still works there, and updates the tree in the same change ticket. A half day per vendor per quarter covers the list. Build the out of band channel. The CISO office and the procurement lead agree on a notification path that does not depend on the vendor’s own infrastructure: a shared Signal thread with the vendor CISO, a personal email address kept on file, a phone number that a human answers during a breach. The channel can be set up in a day and tested in an afternoon. Document the regulatory escalation. The GRC team writes down the regulator, the timeline, the content, the format, and the person on the customer side who owns the filing. A template that the IR team can drop into the regulator’s portal in the first 24 hours, reusable across vendors, and the time saved amounts to the difference between a clean disclosure and a late one.

The bottom line

Test the contact tree, build the out of band channel, document the regulatory escalation. The vendor that breaches the customer at 2am serves as the test the playbook was written for, and the GRC team that has run the drill becomes the one that takes the call without scrambling.