Incident response plan

A plan worth the name makes decisions in advance so nobody improvises them at three in the morning. It names an incident commander and deputies, defines severity levels with examples, maps escalation paths with current contact details, includes communication templates for customers — with counsel-reviewed language where contracts or regulations require notification — and tells responders what to preserve for later analysis. It closes with the discipline most teams skip: a post-incident review that converts each incident into control improvements. A downloaded template with the company name pasted in does none of this.

Auditors treat the plan as required reading: SOC 2 and ISO 27001 both expect documented incident procedures, a log of incidents actually handled through them, and proof the plan gets exercised. Enterprise buyers read it just as carefully — security questionnaires routinely ask whether a plan exists, when it was last tested, and whether customers are notified within contractual windows. Both audiences apply the same test: does this document describe your company, with named humans and real escalation paths, or could it describe any company?

A tabletop exercise — walking responders through a realistic scenario, decision by decision — is how the plan gets tested without a real breach, and the writeup doubles as the exercise evidence auditors request. Tabletops reliably surface stale contact lists and ambiguous authority. They also surface the harder dependency: detection. A plan only activates when something notices the incident, which is why teams without an around-the-clock security function pair the document with managed detection and response — Agency MDR — so the first step always has someone awake to take it.