Check your incident response plan.

What usually gets written. A wiki page last edited two years ago by someone who has since left.

Name an owner, and put a version number and a review date on the first page. Length is not the point: six pages someone can follow at 3am beat forty nobody opens. If you are starting from nothing, write four things first, in this order: who declares an incident, how severity is graded, who to call, and what notification deadlines you are on. Everything else can follow later.

What usually gets written. "Engineering handles it", or a security@ alias with nobody on the other end.

Write down three people and a deputy for each: who declares, who runs the technical response, who talks to customers. If you retain a firm, put the contract reference and the hotline in the plan itself, not in a procurement folder. If you have neither, answer no on the questionnaire. A claimed team that cannot be produced on request is worse than an honest gap.

What usually gets written. "Someone always has their phone", which is a habit rather than a capability.

If you page, name the tool and the escalation policy, including what happens when the first person does not acknowledge. If you do not, answer no and state your actual coverage instead. Buyers accept “business hours, with an out-of-hours page for Sev 1” far more readily than a yes that falls apart on the follow-up call, and the follow-up call always comes.

What usually gets written. A RACI chart that lists departments rather than people.

Three lines is enough: X declares, Y runs the response, Z owns customer and regulator communications. Give each one a deputy. The failure mode is rarely that the role is undefined; it is that the single person holding it is on a plane, and nobody knows who is allowed to decide in their absence.

What usually gets written. "Sev 1 = critical business impact", which just moves the judgement call one word along.

Pin each level to something countable: customer data confirmed exposed, production unavailable to all customers, a regulatory clock started, recovery expected to exceed the RTO. Then test the wording. Ask two people to grade last quarter’s worst incident separately, without discussing it. If they disagree, your thresholds are still adjectives, and they will be argued about while the clock runs.

What usually gets written. "We will notify affected parties as required", which defers the question to the worst possible moment.

Build one table: deadline, who it is owed to, and where it comes from. Populate it from your largest customer contracts (notification windows are usually in the security addendum or DPA, commonly 24 to 72 hours), any regulator you answer to, and your cyber insurance policy, which typically requires notification within a set window and where a late call can affect cover. Do this now, because nobody reads an MSA at 3am.

What usually gets written. An internal email alias, and a vendor name with no account number.

Phone numbers, not aliases: email is the first thing you lose in an identity or ransomware incident, and it may be the thing the attacker is reading. Include how to raise a Sev 1 with your cloud provider (which depends on your support tier, so check what you actually pay for), your EDR vendor, outside counsel, and the insurer hotline. Then ring two of them this quarter and write the date next to the number.

What usually gets written. "Reviewed annually" with no artifact, which answers half the question and skips the half being asked.

Two different obligations are hiding in one sentence. Reviewing the document is a diff and an approval date. Testing the response is people making decisions against a scenario, with a record of what they decided. You owe both, and the test is the half that usually does not exist. Put a date in the calendar before you need it; an exercise run the week the auditor asks is visible as one.

What usually gets written. A slide deck summarising the discussion, written the following week.

A usable record has four parts: when it ran and for how long, who was in the room and in what role, what was decided and at what time, and what it surfaced. Write it during the exercise rather than afterwards. In a reconstruction, timings and attribution are the first things to disappear, and those two are precisely what separate evidence from an assertion. There is a free template on this site that lays the four parts out for you.

What usually gets written. Findings phrased as sentiment: "communication could be improved".

Write each finding as what the plan says against what the room actually did, then attach a named owner and a due date, and put it in the tracker you already use rather than leaving it in the exercise document where it will not be looked at again. The question after “did you test it” is always “what did you find and what did you do about it”. An exercise that found nothing reads as an exercise nobody took seriously, and an open finding with an owner and a date is stronger than a closed one nobody can evidence.