Use this to write or rewrite the plan, not during a live incident (use the triage skill then). You get a new folder, ./incident-response-plan-drafting/, holding: the incident response plan itself, under ten pages, for the owner to approve (incident-response-plan.md); a one-page cheat sheet people can follow at 3am (quick-reference.md); a list of who to call, by role, with blanks for names and numbers (contact-tree.md); and one single-page step-by-step guide per likely incident, such as ransomware or a lost laptop (one file each in playbooks/). This skill drafts for a human to review and sign; this skill never marks a control effective.

Inputs to gather

Read the existing plan if any, past incident tickets and post-incident reviews, the risk register, the on-call setup, the vendor list, customer contracts and processing agreements with notification clauses, the cyber insurance policy, and any retainer with a forensics or managed security provider. Ask the reader, in one message: how many people are in engineering and IT, who can authorise shutting down production or spending on outside help at night, which regulations apply (personal data, health data, NIS 2 scope) and in which role (controller or processor; covered entity or business associate), and what went badly in the last real incident.

Step 1: size the plan to the company

A 30-person company does not have a security operations centre and a crisis committee; a plan that names them fails on the first night. Keep the plan under ten pages and the quick reference to one. Use the roles the company can staff, and name a deputy for every role: plans most often fail because the one person who knows is on holiday.

Step 2: define roles, severity and decisions

Roles: incident lead, technical lead, scribe, communications lead, legal and privacy contact, executive decision maker. One person may hold two roles in a small company, never incident lead and scribe at once.
Severity scale: four levels anchored on customer, data and operational impact, with the response time and call list per level. Reuse the scale from triage so both documents agree. Any level that touches personal data, health data or services in NIS 2 scope opens the notification check at once, and the scribe's first task is to record the awareness time.
Decisions that need named authority: shutting down production, isolating a customer, engaging outside forensics, paying for anything, talking to press, contacting law enforcement. Write who decides each.

Step 3: build the contact tree

In the call list (contact-tree.md), list by role: internal on-call, executives, legal and privacy, the insurer's notification line, the forensics retainer, key suppliers' security contacts, the relevant authorities and computer emergency teams, and law enforcement. Leave names and numbers as placeholders for the reader to fill in their own copy. Add an out-of-band channel (phones, a separate messaging group) for when email or chat is compromised. Check the insurance policy: many require notice within a short time and use of the insurer's panel; missing that can void cover.