The playbooks: deploying the five controls

Foundations · Part 2 of the 80/20 series · 14 min read · Reviewed June 2026

Part 1 made the argument: a vital few controls eliminate most of your breach risk, and your job is to deploy them completely before touching anything else. This article is the execution half — each control as a playbook you can hand to whoever is doing the work.

Every playbook has the same shape: why it's in the vital few, who owns it, what it costs in time and money, the steps in order, the pitfalls that actually derail people, an explicit definition of done, and the evidence that proves the control to an auditor, a customer, or an insurer. The "done means" line matters most, because a Pareto strategy only works at full coverage: five controls at 100% beat twenty at 40%.

The five at a glance

Playbook 1: MFA on everything, email and admins first

Why it's first: compromised credentials showed up in 38% of opportunistic attacks in Verizon's 2026 DBIR, and stolen credentials typically precede the ransomware event by weeks. MFA is the single highest-return action available to you.

Owner: whoever holds identity admin. Approver for exceptions: leadership, in writing.

1. List your authentication surfaces, straight from the two inventories: email/identity provider, VPN and remote access, admin consoles (cloud, firewall, backup, DNS, registrar), finance and payroll systems, the password manager itself.
2. Pick methods deliberately. Authenticator app as the baseline for everyone; phishing-resistant methods (FIDO2 keys or passkeys) for admins and finance. SMS only where nothing else works — it's weak, but it still beats a bare password.
3. Pilot for one week with IT plus one friendly department. You're testing your instructions and your reset process, not the technology.
4. Enforce by policy, not by invitation. Use enforcement (M365: Security Defaults, or Conditional Access if licensed; Google Workspace: 2-Step Verification enforcement per organizational unit). Voluntary rollouts plateau far short of full coverage, and partial coverage is what attackers look for.
5. No executive exemptions. Executives are the most-targeted accounts in the building; an exempted CEO is the open window next to your locked door.
6. Sweep the stragglers: block interactive sign-in for shared mailboxes and service accounts; give every remaining exception an owner, a reason, and an expiry date.

Pitfalls: rolling out by request instead of policy; leaving legacy auth enabled (playbook 2 — without it, this playbook is theater); SMS for admin accounts; skipping the one-paragraph "why" message to staff, which costs you goodwill you'll want later; discovering an app that can't do modern auth after enforcement day — find them in the pilot.

Done means: enforcement applies to 100% of human accounts; the exception list fits on one screen, and every entry has an expiry date.

Evidence that counts: export or screenshot of the enforcement policy; a coverage report; the exception list with dates.

Playbook 2: kill legacy authentication

Why it's inseparable from playbook 1: old protocols — IMAP, POP, SMTP basic auth, anything that sends just a username and password — bypass MFA entirely. Attackers know this and aim password-spraying directly at them. An MFA rollout with legacy auth still enabled is a locked front door next to an open window.

Owner: same as playbook 1 — run them as one project.

1. Measure before you block. M365: filter the sign-in logs for legacy authentication clients over 30 days. Google Workspace: check for app passwords and IMAP access still in use. The log tells you exactly what will break.
2. Identify the dependents. It's nearly always the same short list: multifunction printers that scan-to-email, an old line-of-business app, one veteran's ancient mail client.
3. Remediate each one: point devices at an authenticated relay or connector with restrictions, upgrade the client, or replace the dependency. Document anything that genuinely can't move.
4. Block it: Security Defaults does this automatically; otherwise a Conditional Access policy or per-protocol mailbox settings. Older tenants predate secure defaults — verify, don't assume.
5. Watch the logs for two weeks and fix stragglers. Silence in the legacy-auth log is the finish line.

Pitfalls: blocking before measuring — breaking the scanner on day one costs you the political capital the rest of the program needs; forgetting app passwords; assuming a setting enabled by default for new tenants is enabled on yours.

Done means: zero successful legacy-auth sign-ins in 30 days of logs, with the block enforced by policy.

Evidence that counts: the policy export; a dated sign-in log query showing none.

Playbook 3: separate admin from daily life

Why: human behavior contributed to 62% of breaches in the 2026 DBIR. You will not phish-proof your people — you can make sure the account that gets phished can't administer your environment. Admin separation converts "someone clicked" from a catastrophe into an incident.

Owner: identity admin. Decider on who keeps privilege: leadership — this is an access decision, not a technical one.

1. Export every privileged role membership — global/super admins and the powerful second-tier roles. This list is always longer than anyone expects; that's the "who can touch it" inventory doing its job.
2. Cut to 2–4 named humans. No shared admin accounts. Vendors and MSPs get scoped roles, time-limited where the platform supports it — never a standing global admin "for convenience."
3. Create separate admin accounts for those people: no mailbox, no daily-use licenses, phishing-resistant MFA, used only for admin work. Nobody reads email or browses the web on an account that can administer the environment.
4. Strip privilege from the daily accounts those same people use for email and documents. Same human, two identities, very different blast radii.
5. Create one break-glass account: excluded from your enforcement policies so a bad policy can't lock everyone out, secured with a long random password stored offline (sealed envelope or password-manager emergency access), and alerting on any use. Test it once a year.
6. Apply the same idea to laptops: users shouldn't be local administrators of their own machines where you can avoid it. Same principle, endpoint edition.

Pitfalls: admin accounts with mailboxes (you've just created a phishable admin); forgetting the break-glass account and locking yourself out with your own Conditional Access policy; granting global admin where a narrow role would do; the MSP that quietly re-adds itself — re-run the export quarterly.

Done means: the privileged list fits on one hand, every name on it is justified in writing, and no daily-driver account holds admin rights.

Evidence that counts: dated role-membership export; break-glass test note.

Playbook 4: backups you have actually restored

Why: this is the control that ends ransomware as a business model — 69% of small organizations hit by ransomware in the 2026 DBIR refused to pay because their backups held. A backup you've never restored is a hope, not a control.

Owner: IT. Decider on what must survive and how fast: leadership — recovery priorities are a business decision.

1. Decide what must survive. From the asset inventory, name the systems and data whose loss would end the company. For each, get leadership to answer two questions in plain words: how long can we be down, and how much data can we afford to lose? Those answers size everything else.
2. Map what's actually backed up today — where it goes, how often, and who would notice a failure. Include SaaS: Microsoft 365 and Google Workspace retention is not backup. Either add third-party SaaS backup or have leadership accept that risk in writing.
3. Get to 3-2-1 with one copy unreachable: three copies, two media, one offsite — and at least one copy offline or immutable (object-lock or an immutability flag). Ransomware operators hunt down and delete reachable backups before they encrypt anything; a backup your admin account can delete is a backup the attacker who owns that account can delete too.
4. Treat the backup console as your most attacked admin surface: MFA, separate admin account (playbook 3), alerts on retention changes and job deletions.
5. Restore something for real. One file is not a test. Restore a full critical system, time it, compare against the answer from step 1, and write down what worked and what didn't. Schedule it quarterly — the second test is where the real learning happens.
6. Write the one-page recovery order: what comes back first, who decides, and where the list lives off-network — it's useless on a server that's encrypted.

Pitfalls: backups reachable with production credentials on the production network; trusting the green checkmark ("job succeeded" is not "data restorable"); testing file restores but never a full system; retention shorter than attacker dwell time — keep some long-cycle copies; nobody explicitly owning the daily check.

Done means: a successful, timed, documented restore of a critical system within the last quarter, and one copy that a fully compromised admin account provably cannot touch.

Evidence that counts: the restore test log — date, duration, outcome, gaps; a screenshot of the immutability or offline configuration.

Playbook 5: patch the edge first

Why: exploitation of vulnerabilities is now the #1 initial access vector in the DBIR data, and unpatched internet-facing devices featured in 29% of opportunistic attacks. Edge devices — VPN appliances, firewalls, mail gateways — get exploited within days of a vulnerability disclosure. Internal patching matters; edge patching is urgent.

Owner: IT — and if an MSP manages the firewall, this playbook is mostly about verifying their work.

1. Enumerate everything internet-reachable from the asset list: firewall, VPN, mail gateway, web servers, remote-access tools, anything with a public IP. Then verify from the outside — check your own public ranges so the internet's view matches your inventory. The difference between the two lists is your most urgent finding.
2. Remove what shouldn't be there. Exposed RDP, a NAS admin panel, the "temporary" port-forward from 2023, the forgotten test box. Every service you remove from the edge is patching you never have to do again — exposure reduction is the cheapest patch.
3. Subscribe to your vendors' security advisories plus CISA's Known Exploited Vulnerabilities catalog, filtered to products you actually run. Ten minutes a week, not a threat-intel platform.
4. Set the SLA and pre-book the windows: critical or actively-exploited edge vulnerabilities patched within 7 days — 48–72 hours when it's being exploited in the wild. Schedule monthly maintenance windows in advance so emergency patching is routine, not a negotiation.
5. Retire out-of-support gear. An end-of-life firewall cannot be patched; it's a standing invitation with your name on it. Put replacement on the budget cycle now, not after the advisory.
6. Track it simply: one sheet — device, firmware version, current vendor version, date last checked. That sheet is simultaneously your work queue and your evidence.

Pitfalls: assuming the MSP patches the firewall — get it in writing, then verify a version number anyway; running the edge on the same monthly cadence as desktops (a month at the edge is an eternity); counting only what you remembered to inventory rather than what's actually exposed.

Done means: the outside view matches the inventory, nothing internet-facing is out of support, and the oldest unpatched critical on the edge is younger than 7 days.

Evidence that counts: the edge inventory with versions and check dates; advisory subscriptions; the patch log.

Sequencing the five

Run playbooks 1 and 2 as a single project — they're one control with two halves. Playbook 3 is the quick win: half a day, and it caps the blast radius of everything else while you work. Playbook 4 has the longest lead time, so start the mapping conversation in week one even though testing lands later. Playbook 5 starts as a one-day cleanup and becomes a one-hour weekly habit.

If you're doing this with a team — or need to show leadership a plan with dates on it — part 3 turns these playbooks into a 90-day execution plan with ownership, cadence, and an interactive checklist. And when someone asks how you'll know it worked, that's part 4.