Stop 5 of 9 · Weekly
The DR runbook and the tabletop
A recovery runbook written from the environment facts, then rehearsed against Claude playing the incident, with every unanswered question folded back in.
Write it from the facts you already have
Hazem has the recovery facts scattered across twelve Projects: hypervisors, backup targets, retention, the Meraki topology, the identity model, who signs what. A runbook is those facts arranged into the order you need them in when the office is dark and somebody is crying.
Claude is good at the arranging and useless at the knowing, so the input is the environment file set from stop 1 plus the backup job report. No credentials go near this, and the runbook that comes out has a line reading obtain break-glass credentials from the safe, which is exactly how it should read.
[attach the Marren Insurance environment sheet, the backup job report and the network diagram with public addresses removed] Write a disaster recovery runbook for Marren Insurance covering ransomware, hypervisor loss and total site loss. Structure it as numbered steps under three phases: contain, assess, recover. Every step must name the console or physical location it happens in, the exact action, what a good result looks like, and the role to escalate to when it is not that. Put decision points in their own numbered steps with the role that decides. Where a fact is missing from my files, write it as a bracketed blank rather than a guess, and list every blank at the end. Never include a credential. Where one is needed, the step says which vault or safe it comes from.
The bracketed blanks are the point. A first draft usually has fifteen, and filling them is a productive afternoon that would otherwise have happened during an outage.
Rehearse it against something that argues back
A tabletop with a facilitator reading from a script is a meeting. A tabletop where the incident responds to what you actually did is an exercise. Claude plays the incident, Hazem plays himself, and the runbook is the thing under test.
You are running a tabletop exercise for me. The scenario is ransomware at Marren Insurance, discovered at 03:10 on a Sunday. You play the incident and the environment, I play the on-call engineer. Rules: give me one injection at a time and wait for my response. Respond realistically to what I actually do, including when it makes things worse. Do not hint at the right answer. Track elapsed time and tell me the clock with every injection. If I claim a capability, ask me where it is written down. Run for twelve injections, then stop and give me the after-action: what worked, what failed, every question I could not answer, and the exact runbook steps that would have changed the outcome.
Take the after-action above and the current runbook. Produce a change list: for each gap, the runbook step to add or rewrite, where it goes in the sequence, and the role that owns it. Then give me the second version of the runbook with those changes applied and a revision line at the top.
The artefact
A versioned runbook with no blanks left, plus a dated after-action report naming the gaps and the steps that closed them.