Defensive Playbooks for Common Incidents

Lesson Overview

The three lessons before this taught the response cycle as a whole: preparing before the bad day, detecting and analysing an event, and the work of containment, eradication, and recovery. This lesson makes that cycle concrete. It gives you a small set of ready-made playbooks, short ordered drills, for the incidents a small humanitarian home-defence force is most likely to actually meet. When the report turns out to be real and the pressure is on, you do not want to be reasoning from first principles. You want a checklist you have read, trained, and trust, so that the response is fast, calm, and complete.

A playbook is not a substitute for thought. It is the opposite: it captures good thinking done in advance, in a quiet moment, so that the noisy moment does not have to. Each playbook here follows the same shape you already know, contain or limit the harm first, remove the threat, restore service from something clean, preserve evidence as you go, and notify the people who need to know. The four covered are the common ones for the Principality: phishing and account compromise, malware and ransomware, a lost or stolen device, and a data breach. Every one of them is strictly defensive and lawful. The aim is always to limit harm, restore service, protect the nationals whose data is at stake, and learn. It is never to retaliate, to hunt the attacker, or to "hack back," which are neither taught nor sanctioned.

This is the knowledge layer. It teaches you what each drill is and why each step is in the order it is in. The hands-on parts, revoking a session in the identity service, isolating a host, running a restore from an offline backup, filing the report that involves the proper authority, are practised and signed off in person and on exercise where supervision allows, on systems you have the appointment to touch. Access follows appointment, not a certificate: reading this lesson does not by itself authorise you to act on a live system. By the end you will be able to run the account-compromise playbook from reset to notify, run the ransomware playbook from isolation to clean restore, handle a lost or stolen device by revoking its access and certificates, respond to a data breach by containing and assessing what data and whose and notifying honestly, and explain why every one of these drills is defensive, lawful, and evidence-preserving.

Key Terms

• Playbook: a short, ordered drill for a specific type of incident, written and rehearsed in advance so the response is fast and complete under pressure.
• Account compromise: an account being used by someone other than its rightful owner, usually after a password was phished, guessed, reused, or stolen.
• Session: an active signed-in connection an account holds with a service; revoking sessions signs the intruder out even if they still know the password.
• Token: a credential a service issues so an app or device can act for an account without re-entering the password; like sessions, tokens must be revoked when an account is compromised.
• Mail-forwarding rule: a setting that silently copies or forwards a mailbox's messages elsewhere; a common trick an intruder leaves behind to keep reading mail after they are locked out.
• Recovery method: a backup way to regain an account, such as a phone number or secondary email; an intruder may add their own so they can take the account back.
• Isolation (containment): cutting an affected device off from the network so a threat cannot spread, while leaving the device itself intact for evidence.
• Ransomware: malware that encrypts or locks data and demands payment; the planned answer is a clean restore, not a payment.
• Offline (clean) backup: a backup kept disconnected from the live systems, so malware cannot reach and corrupt it; the thing you restore from.
• Remote wipe: erasing a lost or stolen device over the network so its data cannot be read by whoever holds it.
• Certificate / key revocation: withdrawing a device's or user's certificate or key (for example a per-user TAK .p12) so it can no longer be used to access systems.
• Data breach: confidential information being exposed to, or taken by, someone not authorised to have it.
• Notification duty: the obligation, set by policy and law, to tell the affected people and the proper authority about a breach honestly and in good time.
• Evidence preservation: capturing and protecting logs, images, and records of an incident, with times, without altering or destroying them, so the team can learn and any authority can act.

How to Use a Playbook

Before the individual drills, a word on how playbooks are meant to be used, because a misused checklist can do harm.

First, a playbook is a starting point, not a straitjacket. It lists the steps that almost always apply, in the order that almost always works. Real incidents have edges the checklist did not foresee. If a step is plainly wrong for the situation in front of you, you raise it with the incident lead rather than following it off a cliff. The plan from Lesson 01 names who leads and who decides; the playbook serves that structure, it does not replace it.

Second, act within your appointment. Many playbook steps, disabling an account, isolating a server, triggering a remote wipe, require access and authority that only some members hold. If a step is beyond your appointment, your part of the playbook is to report fast and clearly to someone who can act, and to do the things you are authorised to do. Doing nothing because "someone else handles that" is a failure; acting beyond your authority on a live system is also a failure. Know your lane and fill it completely.

Third, preserve evidence as you go, not afterwards. Every playbook below has evidence steps woven through it rather than bolted on at the end, because the moment of response is when evidence is most easily destroyed. Note the time you noticed, the time you acted, and what you saw and did. Do not "tidy up," delete the suspicious email, or wipe the machine before its evidence is captured. As Lesson 02 taught, you cannot rebuild a timeline from evidence you threw away.

Fourth, notify honestly. The last step of every playbook is some form of telling people. The discipline that runs through all of it is honesty: report a mistake as help, not failure, and never hide, minimise, or spin what happened. A breach concealed is far worse than a breach reported.

Playbook One: Phishing and Account Compromise

This is the most common incident a small force will meet, because phishing is the commonest way attackers get in, and an account is the usual prize. The trigger is any sign that an account is in the wrong hands: a member reports clicking a phishing link and entering their password, the identity service flags a sign-in from a strange place, a national reports messages they did not send, or unexpected password-reset or recovery-change emails arrive.

The aim is to get the intruder out and keep them out, then make sure they left nothing behind. Note that locking the password alone is not enough, because an intruder who is already signed in keeps their active session, and one who added a recovery method can simply take the account back. The order below closes all of those doors.

ACCOUNT-COMPROMISE PLAYBOOK  (phishing / takeover)

  [ SUSPECT AN ACCOUNT IS COMPROMISED ]
                |
                v
  1. CONTAIN -- reset the password to a new, unique passphrase
                |   (lock the door the intruder came through)
                v
  2. CONTAIN -- revoke ALL active sessions and tokens
                |   (sign the intruder out even if they knew the pw)
                v
  3. VERIFY  -- confirm MFA is on and is the owner's
                |   (an authenticator/passkey the real owner holds)
                v
  4. HUNT    -- check for sneaky changes the intruder left:
                |     - mail-forwarding / auto-copy rules?  remove
                |     - added recovery email / phone?        remove
                |     - new app passwords / API tokens?      revoke
                |     - changed reply-to / signature / name?  fix
                v
  5. ASSESS  -- what could they have seen or done from this account?
                |   (mail read, data accessed, messages sent, other
                |    accounts reachable from it -> may open a breach)
                v
  6. PRESERVE-- save the phishing message + sign-in logs, with times
                |   (do NOT delete the lure; it is evidence)
                v
  7. NOTIFY  -- tell the incident lead; tell the account owner;
                |   warn others if the same lure was sent widely;
                v   if nationals' data was exposed -> Playbook Four
  [ ACCOUNT RECOVERED, INTRUDER OUT, LESSON LOGGED ]

Two steps deserve emphasis because they are the ones people forget under pressure. Step 2, revoking sessions and tokens, is what actually evicts an intruder who is already inside; without it, a fresh password is a lock changed while the burglar is still in the house. Step 4, the hunt for sneaky changes, is what stops the intruder walking back in: a hidden mail-forwarding rule keeps them reading the mailbox after they are locked out, and an added recovery method lets them reset the password themselves later. Always look for both. Finally, treat step 5 honestly: if the compromised account could read nationals' personal data, you may now have a data breach as well, and you move to Playbook Four in parallel.

Playbook Two: Malware and Ransomware

Malware is hostile software on a device; ransomware is the variety that encrypts or locks your data and demands payment to release it. For a small force this is the incident that the whole backup discipline exists to answer. The trigger is a device behaving wrongly, files renamed or unreadable, a ransom note on screen, anti-malware alerts, a machine suddenly slow or reaching out to strange addresses.

The instinct under a ransom note is to panic, or to pay. The drill is the opposite of both. You isolate to stop the spread, you restore from a clean offline backup rather than paying, you report it because it is usually a crime and the proper authorities should be involved, and you preserve the evidence throughout. Paying is avoided wherever it can be: it funds the crime, it is no guarantee the data comes back, and it marks the force as willing to pay again. The reason offline backups exist is precisely so that you never have to.

RANSOMWARE / MALWARE PLAYBOOK

  [ MALWARE OR RANSOM NOTE SUSPECTED ]
                |
                v
  1. ISOLATE -- disconnect the host from the network NOW
                |   (pull the cable / disable Wi-Fi; do NOT power
                |    it off if memory evidence may matter -- ask lead)
                v
  2. CONTAIN -- stop the spread: check what else it touched,
                |   isolate other affected hosts, disable any
                |   compromised accounts the malware used
                v
  3. PRESERVE-- capture evidence before changing the machine:
                |   logs, an image if you can, the ransom note,
                |   times of everything (Lesson 02 method)
                v
  4. DECIDE  -- DO NOT PAY if it can at all be avoided.
                |   Recovery comes from backups, not the attacker.
                v
  5. ERADICATE- when in doubt, REBUILD rather than clean;
                |   patch the hole that let it in; rotate any
                |   credentials or keys that were on the host
                v
  6. RECOVER -- restore data from a KNOWN-GOOD OFFLINE backup;
                |   validate integrity; bring the host back clean
                v
  7. MONITOR -- watch closely after return to service;
                |   confirm the hole is closed and it has not returned
                v
  8. REPORT  -- it is usually a CRIME: report to the incident lead
                |   and involve the proper authorities; record fully
                v   if nationals' data was taken -> Playbook Four
  [ SERVICE RESTORED CLEAN FROM BACKUP, AUTHORITIES INVOLVED ]

Three points anchor this drill. First, isolation is the immediate move, but how you isolate matters: pulling the host off the network stops the spread, while ripping out the power can destroy memory evidence the team may need, so isolate from the network and ask the lead before powering down. Second, the recovery is only as good as the backup it comes from, which is the whole reason for the 3-2-1 rule and tested restores from CIS 201 and Lesson 01: a backup that turns out to be infected, or that has never been test-restored, is not a backup you can lean on at the worst possible moment. Third, this is usually a crime. Reporting it and involving the proper authorities is not optional and not an admission of weakness; it is the lawful, responsible course, and it is how the wider community learns to stop the same attacker.

Playbook Three: Lost or Stolen Device

A small, mobile, digitally organised force carries its access in its pockets: phones, tablets, laptops, and the per-user certificates and keys that ride on them, such as a TAK .p12. A lost or stolen device is therefore not just lost hardware, it is a potential foothold into the Principality's systems for whoever now holds it. The trigger is simple and the response must be fast: a member reports a device lost or stolen.

The aim is to make the device useless to whoever has it before they can use it, by cutting off everything it could reach. Speed matters more here than in almost any other playbook, because the window between loss and abuse can be short. The good news is that the preparation from Lesson 01, full-disk encryption, a screen lock, an inventory of who holds what, and the ability to revoke and remote-wipe, is what makes a fast response possible.

The drill is short:

1. Report immediately. The member tells the incident lead the moment a device is missing, without waiting to be sure it is truly gone rather than mislaid. A device reported missing and then found is a non-event; a device abused because the report was delayed is an incident. Reporting early is help, not failure.
2. Revoke its access and certificates. Withdraw the device's sessions, tokens, certificates, and keys in the identity service and any system it could reach, including the per-user .p12 or equivalent. This is the core step: once revoked, the device's stored credentials are dead even if the thief unlocks it.
3. Remote-wipe if possible. If the device supports it, trigger a remote wipe so its data and any cached credentials are erased. Encryption plus a screen lock buys the time for this to work.
4. Change related credentials. Reset passwords for accounts the device was signed into, and rotate any keys it held, on the assumption that anything stored on it may be exposed.
5. Assess and preserve. Note what the device held and could reach, and whether any of it was nationals' personal data, in which case you move to Playbook Four. Record the loss, the times, and every action taken.

The discipline is to assume the worst: treat the device as if it is already in hostile hands and act to make that harmless, rather than hoping it merely fell behind a seat. Revocation is the step that does the real protecting, because it works whether or not the remote wipe ever reaches the device.

Playbook Four: Data Breach

A data breach is confidential information reaching someone not authorised to have it, whether taken by an intruder, exposed by a misconfiguration, or carried off on a lost device. For the Principality this is the gravest category, because the whole speciality exists to protect nationals' data, and a breach is the failure it most exists to prevent and, when it happens, to handle well. A breach is frequently the consequence of one of the other three incidents, which is why each of those playbooks ends by pointing here.

The aim is to limit the exposure, understand it honestly, and meet the duty to tell the people affected and the proper authority. This is the playbook where honesty matters most and where the temptation to minimise is strongest. The drill resists that temptation by design.

1. Contain. Stop the exposure continuing: close the open access, revoke the compromised account or device, take down the misconfigured share. The first job is to ensure the breach is not still leaking while you investigate.
2. Assess what data and whose. Establish, as precisely as the evidence allows, what information was exposed and which people it belongs to. The response and the duty to notify both depend on knowing whose data, and how sensitive it was. Resist guessing; work from evidence.
3. Preserve evidence. Capture the logs, access records, and timeline that show what happened and what left, with times, before anything is changed or cleaned. This both supports any authority and protects the force's honest account of events.
4. Notify as duty requires. Tell the affected nationals and the proper authority as policy and law require, honestly and in good time. The duty to notify is not discretionary public relations; it is an obligation to the people whose data it was, so they can protect themselves.
5. Be honest. Throughout, tell the truth plainly: what happened, what data, whose, and what is being done. Do not downplay, delay to look better, or hide. A breach handled with honesty protects trust; a breach concealed destroys it and usually compounds the harm.
6. Learn and close. Feed the breach into the blameless review of the next lesson and back into the Govern, Identify, and Protect work, so the gap that allowed it does not recur.

The shape here is deliberately the same as the others, contain, assess, preserve, notify, but the weight falls on assessment and honest notification, because a breach is judged less by the fact that it happened, which no force fully escapes, than by whether those responsible told the truth and protected the people affected.

In Practice: A Corporal Runs the Account-Compromise Playbook

A systems assistant, Private Osei, reports to Corporal Adeyemi that she clicked a link in an email that looked like an identity-service security warning, entered her password on the page it opened, and only then noticed the sender address was wrong. She reported it within minutes rather than hiding it, which Adeyemi makes a point of acknowledging, because that early honest report is what makes everything that follows possible.

Adeyemi opens the account-compromise playbook and works it in order, doing the steps within his appointment and calling the on-call administrator for the ones beyond it. The password is reset to a new passphrase. Crucially, he does not stop there: all active sessions and tokens on the account are revoked, which signs out a session the playbook assumes may already be the intruder's. They confirm Osei's authenticator app is still hers and still the only second factor. Then comes the hunt for what an intruder might have left: they find, and remove, a newly created mail-forwarding rule quietly copying Osei's inbox to an outside address, and they check the account's recovery methods and find no added phone or email, removing nothing but glad they looked. App passwords and tokens are reviewed and the stale ones revoked.

With the intruder out and the back doors shut, Adeyemi assesses the harm honestly. Osei's mailbox held some correspondence containing nationals' personal details, and the forwarding rule means an intruder may have received copies. That makes this a potential data breach as well, so Adeyemi escalates in parallel to Playbook Four: the exposure is contained, the team assesses exactly whose data the forwarded mail could have carried, the phishing email and the sign-in logs are preserved with times rather than deleted, and the duty to notify the affected nationals and the proper authority is set in motion through the incident lead. Nothing is downplayed. The same phishing lure is found to have been sent to several other members, who are warned at once before anyone else clicks. At no point does Adeyemi try to trace or strike back at whoever sent the email; the entire response stays defensive, lawful, and aimed at limiting harm. The event is logged in full for the blameless review, where the lesson, a forwarding rule almost missed, will sharpen the playbook for next time.

Check Your Understanding

1. In the account-compromise playbook, resetting the password is not enough on its own. Name the two steps that respectively evict an intruder who is already signed in and stop an intruder walking back in later, and explain what each one does.
2. A device shows a ransom note. State, in order, the first three things the playbook has you do, and explain why you isolate the host from the network rather than immediately switching it off, and why the force aims not to pay.
3. A lost device and a data breach both end by considering the same follow-on. Explain why three of the four playbooks point to the data-breach playbook, and state the two things the data-breach drill weighs most heavily and why.

Reflection (write a short paragraph): Pick one of the four playbooks and imagine it triggered for your own section tomorrow. Walk through which steps you personally would be authorised to carry out under your appointment, which you would have to hand to someone with more access, and where you think the response would be slowest or most likely to miss something. What one piece of preparation, decided now in the quiet, would most improve how that playbook would run on the bad day?

Summary

• A playbook captures good thinking done in advance so the noisy moment does not have to; each one contains or limits harm first, removes the threat, restores from something clean, preserves evidence throughout, and notifies honestly.
• Account compromise: reset the password, revoke all active sessions and tokens, confirm MFA, hunt for sneaky changes (mail-forwarding rules, added recovery methods, stray tokens), assess and preserve, then notify; revoking sessions evicts an intruder already inside, and the hunt stops them returning.
• Ransomware and malware: isolate from the network, contain the spread, preserve evidence, do not pay if it can be avoided, eradicate (rebuild rather than clean, patch the hole, rotate credentials), recover from a known-good offline backup, monitor, and report it as the crime it usually is.
• Lost or stolen device: report at once, revoke its access and certificates (including per-user keys such as a TAK .p12), remote-wipe if possible, change related credentials, and assess what it held; revocation protects whether or not the wipe ever lands.
• Data breach: contain the exposure, assess what data and whose from evidence, preserve evidence, notify the affected nationals and the proper authority as duty requires, and be honest throughout; a breach is judged by honesty and care for the affected, not merely by having happened.
• Every playbook is defensive and lawful: limit harm, restore, protect nationals' data, involve the proper authorities, and learn. Never trace, retaliate against, or "hack back" an attacker. Act within your appointment, not merely your qualification.
• Builds on Lesson 01 (Preparing for the Bad Day, where the plan, roles, and clean backups come from), Lesson 02 (Detection and Analysis, the evidence and timeline method), and Lesson 03 (Containment, Eradication, and Recovery, the underlying cycle); feeds Lesson 10 (After the Incident, the blameless review and the duty to disclose).
• Cross-references CIS 201 (the "recognise and report" first line and the 3-2-1 backup rule), CIS 220 (Identity, Access, and Records Security, where sessions, tokens, recovery methods, and revocation live), SIG 220 (Communications Security and Digital Discipline), PME 210 (records and reporting), and HCR 220 (continuity and resilience).

Crown Copyright © 2026 | Published by Authority of H.R.H. The Prince of Kaharagia