Ransomware Playbook

## What lands on you An extortion incident announces itself late. In the shape this playbook is written for, an intruder reached the virtualisation management plane of a manufacturing estate, used it to encrypt the datastores holding hundreds of virtual machines, and left a note. Two things follow from that. First, the encryption happened *below* the guest operating systems, so agents inside those virtual machines saw nothing before they stopped existing. Second, the theft happened days earlier — modern extortion is *double extortion*: copy the data out first, encrypt second, and hold both the restore and the publication over the victim. Within hours the organisation's name appears on the actor's leak site with a countdown timer. So the first hour of the response is not an investigation. It is a queue of decisions that a security team is not empowered to make. ## What a playbook actually is here It is tempting to write a ransomware playbook as a technical procedure. It is not one. Its value is that it records, in advance and with signatures, **who may decide what** — decision rights, not commands. The recurring items are: - **Authority to disconnect.** Who may sever the virtualisation management network, or a plant's network, without an executive on the call — and what they may never touch. - **The ransom position.** The organisation's standing answer to the payment question, what it will never pay for, who may override the standing answer, and who signs. - **The insurer trigger.** At what point the cyber insurer is notified, by whom. Policies commonly require prompt notice and the use of approved (panel) vendors and counsel; hiring your favourite forensics firm at 02:00 can leave that spend uncovered, and most policies require the insurer's consent before any extortion payment. - **The counsel trigger.** When outside counsel is engaged, and that the response is run in a way that protects legal position from the start rather than retroactively. - **Deadline ownership.** Who monitors the leak-site listing and its timer, and who is briefed on what the timer does and does not mean. ## Why in advance Three reasons, and they are worth being able to say out loud. **The clock is the adversary's, not yours.** The countdown is set by the party that stole the data. Every hour spent locating a decision-maker is an hour taken off whatever time you actually have. **The decision-makers are not in the room.** A tier-1 analyst cannot authorise stopping a production line, and should never be the person deciding whether the company pays. If the playbook does not name a person, the default is escalation through a phone tree at 03:00 while datastores encrypt. **Duress is not a good decision environment.** The pay-or-refuse question is emotionally loaded, expensive and legally constrained. An organisation that first considers it while a timer runs will consider it badly. The point of pre-deciding is that the hard thinking — sanctions exposure, insurer consent, what a deletion promise is actually worth — was done in daylight. ## What cannot be pre-decided A good playbook is honest about its limits. It cannot decide facts it does not have: whether *this* production line must stop, what *this* stolen data set contains, what to tell *this* named customer. It pre-decides **authority and position**; scope-dependent calls still have to be made live, but by a named person against pre-agreed criteria rather than by improvisation. ## How to tell a real one from a paper one A real playbook names individuals and roles, not committees. It states an action a third party may take without asking. It carries a signature from someone who can spend money and stop production. It says what will never be disconnected. And it says what the organisation will not buy at any price — which is the sentence that saves the most time when the note lands, because it converts the loudest question in the room into a decision that was already made. The failure mode to avoid: treating extortion as a restore exercise. Restoring solves encryption. It does nothing at all about the copy of your data sitting on someone else's infrastructure with a timer attached, and that half of the problem is the half the playbook exists to pre-decide.