Intelligent Automation, LLC · Field Edition
A field manual for the year the old playbook stopped working.
Why this book exists
What actually changed between 2024 and 2026, why the playbook you already have will fail against it, and how to read the rest of this book.
Not that the threat landscape got worse — it always gets worse, and that is neither news nor help. The argument is narrower and more useful: you can name the broken assumptions one at a time, and each one breaks a specific step in the procedure you already have.
The test
Open your incident response documentation and find the step that handles an OAuth refresh token stolen from a vendor you authorized years ago. Not “contain the threat” — the actual step. No host to isolate, no password to reset, no patch to deploy. If that branch is missing, it is not a slightly outdated playbook. It is a playbook for a different decade.
How to read it
They want completely different things, so start in different places.
You are building a program
Chapter 1 for the shape of the problem, Chapter 2 for how a playbook is actually built, then Part II in whatever order matches your risk. Chapter 20 sequences it into a first 180 days.
Something is happening right now
Go straight to Chapter 14, find the playbook that matches, and run it. Chapter 13 gives you the roles and severity vocabulary those playbooks assume. Chapter 15 tells you which regulatory clocks just started. Everything else can wait until Thursday.
You have to prove coverage
Appendix A is the master checklist with framework tags. Chapter 16 covers framework selection and the crosswalk. Chapter 3 gives you the Coverage Model — one page of everything you are accountable for, wired to those same controls.
Every control carries a tier
IG1 Essential hygiene. Every organization, regardless of size.
IG2 Organizations with people whose actual job is security.
IG3 Organizations facing adversaries who will spend real money.
Work down the tiers, not across the chapters. Programmes fail because the easy things sat undone while the hard things were done well.
Chapter 3
One page of everything you are accountable for, wired to the control set.
Its spine is the six NIST CSF 2.0 Functions, which NIST publishes freely and intends to be used exactly this way. The domains, the capability decomposition, the control set and the mapping between them are original to this book.
It works better in a board meeting than any risk register I have ever seen presented — because it answers “what are we accountable for” before it answers “what are we worried about”.
What actually changed between 2024 and 2026, why the playbook you already have will fail against it, and how to read the rest of this book.
Actionable takeaways
stop measuring mean time to respond as a single number. Split your metric into internally-detected and externally-notified, and report both to the board every quarter. If the second number is larger than the first — and it will be — that gap is your actual detection debt, and it is the number Chapter 9 exists to close.
rewrite the first trigger in your ransomware playbook. It should not be "malware detected." It should be "an identity event we cannot explain" — a help-desk-initiated MFA re-enrolment, an impossible-travel token use, a new OAuth grant, or a hit on an infostealer credential dump. And your containment step is revoke sessions and tokens first, reset the password second. Reversing that order leaves a valid token in the attacker's hands for the remainder of its lifetime.
How to write incident documentation that a tired person can execute at 03:00 without stopping to work out who is allowed to decide.
Actionable takeaways
Write one plan of no more than fifteen pages that a senior leader can actually read and sign, then move every step, command and decision out of it into playbooks and runbooks. If a page of your plan contains a command, it is in the wrong document — cut it out today and give it an owner.
Add owner, last_exercised, next_review_due, status and on_playbook_failure to every playbook you already have, this week, before writing a single new one. If you cannot fill in last_exercised, set status: Draft and let the gap be visible.
A one-page model of everything a 2026 security program is accountable for — six NIST CSF 2.0 Functions, 29 domains, every one wired to a testable control and a named owner — so you can find the work nobody owns before an incident finds it for you.
Actionable takeaways
before you score anything, read all 29 domain names out loud with your team and mark each one we do this / we have decided not to do this / we have never discussed this. The third pile is the point of the exercise, and it is always larger than anyone expects.
walk the six Functions with your team in one sitting, in order, and stop at every domain where nobody in the room can name the person who owns it. Write those names down as you go. That list — not the scores — is the output.
How to build an identity control plane that a modern adversary cannot phish, socially engineer, or replay — and how to take it back in the right order when they get in anyway.
Actionable takeaways
Before you buy anything, produce one number — the total count of identities in your environment, human and non-human, with an owner named for each. If you cannot produce it in a week, that gap is your first project, not your third.
Set a calendar date for killing push and SMS on privileged accounts, put a named owner against it, and enrol break-glass accounts before that date arrives. Not "eventually." A date, on a calendar, with an owner.
How to build an access architecture where every request is verified regardless of network location, score yourself honestly against CISA's maturity model, and turn "isolate that host" into a policy change instead of a desk visit.
Actionable takeaways
Before you buy anything else, produce a one-page diagram naming every Policy Decision Point and Policy Enforcement Point you operate, and mark in red every resource that has neither. That page is your real baseline, and it costs a whiteboard and an afternoon.
Book three hours this month with identity, network, endpoint and cloud engineering in one room, score all five pillars and all three cross-cutting capabilities, and write the evidence next to each score. Re-run it every six months and put the scorecards side by side. A maturity model you score once is a poster.
How to configure a cloud control plane so it produces evidence, detect the identity and misconfiguration attacks that actually happen there, and contain a compromised account, instance, cluster or workload without destroying the only proof you will ever get.
Actionable takeaways
Build a one-page responsibility matrix per service, not per provider, and make "who owns the logs, and for how long" a mandatory row. Any service in production without an owner named in that row is an unowned service — assign it this week or turn it off.
This week, run one query per provider — "what is our oldest retained control-plane event?" — and write the answer on the risk register. If the answer is under twelve months, you have an evidence gap, not a logging strategy. Fix the retention before you buy another detection tool, because a detection you cannot investigate is a notification you cannot scope.
Inventory every AI system touching your data, govern it against a standard an auditor recognises, use it in the SOC where it is actually good, and build the human process checks that stop an AI-enabled attacker — because the technology ones do not.
Actionable takeaways
Split your AI work into Secure / Govern / Defend / Thwart on one page, name a single accountable owner per row, and refuse any AI initiative that cannot say which row it belongs in. Programs that treat "AI security" as one bucket end up funding the exciting quarter of it and none of the boring three.
Run the six discovery passes this month and publish the inventory with a "last verified" date in the header. Then give the business a sanctioned tool with a real data agreement — because every hour a sanctioned option does not exist is an hour your data spends somewhere you cannot see.
How to know what data you hold, hold less of it, encrypt what remains under keys you actually control, and get your cryptography off algorithms that have a published expiry date.
Actionable takeaways
Ship a three-tier scheme plus a regulatory flag and a confidentiality-lifetime field this quarter, and require the lifetime number on every Restricted data set before you accept the inventory as complete. If a data owner cannot say how many years their data must stay secret, they do not yet own it.
Pick your single most sensitive data store and, within 30 days, give it its own credentials, its own network path, and a bulk-read alert with a numeric threshold. Then repeat on the next one. Compartmentalization is done one store at a time or it is not done at all.
How to build a logging, detection and triage capability that finds the adversary yourself instead of waiting for someone else to call you — and how to prove honestly what it does and does not cover.
Actionable takeaways
Write down your retention period for each of the top five log-source priorities, next to the dwell time you are designing against, and get a named executive to sign the gap. If identity logs are retained for less than twelve months, that is your first budget ask this year — before any new tool.
Build a source-health dashboard listing every log source, its expected event rate, its last-seen timestamp, and its owner — and page on silence from any source in priority tiers 1 through 3. A dead sensor is an unattended detection failure that has already started.
How to find what you expose, decide what to fix first using evidence of real exploitation rather than a severity score, hit a deadline you can defend, and prove the fix actually landed.
Actionable takeaways
Rebuild your vulnerability ticket schema this quarter so every ticket carries a per-asset state from that six-value list, plus an applicability decision and an exposure flag. If your tooling only reports per-CVE counts, you have a scoreboard, not a program.
Publish your asset-inventory coverage percentage next to every remediation percentage on every report, forever. A remediation rate without a denominator statement is a marketing claim, and once the two numbers sit side by side, the inventory gap starts getting funded.
How to know who is inside your estate, rank them by the access they hold rather than the money they cost, verify their claims properly, write terms that still bite at renewal, and survive the day the breach is theirs.
Actionable takeaways
Produce a single reconciled vendor register from AP data, your IdP application list, OAuth grants, egress DNS and the contract repository — this quarter, in a spreadsheet if necessary — and refuse to accept any row where the business owner field says a department name instead of a person.
Re-tier your whole register against data access and operational dependency this quarter, ignore contract value entirely while you do it, and expect the top tier to shrink and change membership. A program that reviews everything reviews nothing well.
How to build a backup and recovery capability that survives an adversary who is specifically hunting it — immutable storage, credentials that live outside the domain you are restoring, restore tests with a stopwatch, and an identity-first recovery order.
Actionable takeaways
For every backup repository you own, write down which mode in the table above it is actually in — not which one it was procured as. Any repository in an overridable mode gets a dated migration plan to the non-overridable mode this quarter, or a signed risk acceptance naming the executive who owns the outcome.
Today, answer one question in writing: if the production directory is encrypted right now, which specific credential logs into the backup console, where is it stored, and who has physically held it in the last 90 days? If the answer involves the word "SSO," you do not have backups. You have copies the attacker also controls.
The canonical model, vocabulary, roles and gates that every scenario playbook in this book assumes you already have.
Actionable takeaways
Pick one lifecycle model, write it into your incident response plan, and make every playbook use its phase names verbatim. Two teams describing one incident in two vocabularies is not a documentation problem. It is a handover failure waiting for a Saturday.
Assign each of the fifteen rows an owner and a date, then verify five this week by testing them rather than asking whether they are true. Start with row 9 — try to reach your war room without SSO. Today. Not after the next tabletop.
Fourteen executable scenario playbooks, plus the rules for reading them, choosing between them, and running more than one of them at the same time.
Actionable takeaways
make two passes over each playbook you adopt. First, fill every placeholder. Second, delete every step your organization genuinely cannot perform, and replace it with the one it can — a short playbook you can execute beats a complete one you cannot. Do it before you need it. Not during. Before.
if you can fund one cohort this quarter, fund the people who can move money — and set the date before you close this incident.
Who says what, to whom, on which clock — and the legal machinery that decides whether your incident becomes a footnote or an exhibit.
Actionable takeaways
Write the authority table and the cadence into the plan today, with named deputies and out-of-hours numbers, and print it. Both fit on one page. Neither can be invented at 03:00.
Print the contact card this week. Dial the bridge from your own phone before you leave the office. If you cannot join in ninety seconds with no laptop, it does not exist.
How to pick the two frameworks you actually need, run a risk register a business will use, quantify cyber risk in money, and walk into a board meeting with three slides, a trend and one decision.
Actionable takeaways
if you do one thing from this section, write GV.RM-02. A single page: what loss we are willing to absorb annually without escalation, what loss requires the executive team, what loss requires the board, and who signs. Most organizations have never written one, which means every risk acceptance in the register was made against an unstated standard.
do not build a Current Profile until you have a Target Profile to compare it against. Pull a Community Profile — 800-61r3 for incident response, or a sector one if it exists for you — adjust it to your context, and only then assess. A gap analysis you can finish in a week beats a beautiful assessment you never act on.
How to write a playbook that a machine can execute and a human can take over mid-step, where to put the approval gates, and which automations will quietly hurt you.
Actionable takeaways
rewrite one existing playbook this week with the five-column discipline — Action / Who / Precondition / Done when / Evidence — and mark every step AUTO, AUTO+GATE, or HUMAN. You will find that a third of your steps cannot be converted because they were never really steps. Those are the ones failing at 03:00 too.
list every automation you currently run and sort each one into three columns — read-only, reversible, irreversible. Anything sitting in the irreversible column with no human on it comes out of production this week. And if enrichment is not your largest category by volume, you built the exciting automations before the profitable ones.
How to design, run, score and close out the exercises that turn a plausible-looking playbook into one you know works — for the price of a conference room and three hours, not a seven-figure tool.
Actionable takeaways
Write the ladder into your plan with a named frequency per rung, then check which rungs you climbed in the last twelve months. Most programs find they did rung 3 once and rungs 4–6 never. The gap between "we do tabletops" and "we have measured our restore time" is where incidents live.
Before your next exercise, write the objectives and the scoring sheet and get both signed off by the plan owner — with the scenario still unwritten. If you cannot get sign-off on the objectives, the scenario was never going to save you.
Seven one-page playbooks — Finance, HR, Legal, Communications, Sales/CS, Engineering, Executive and Board — that give the people outside security a role they can actually perform, and that plug cleanly into the central incident response plan.
Actionable takeaways
print the six-step procedure, tape it inside the AP cabinet, and run one unannounced test payment-change request per quarter against your own AP team. If a clerk releases it, you found a training gap for the price of an afternoon instead of the price of a wire.
measure one number and report it to the board — median minutes from termination time to session revocation, across the last twenty leavers. If you cannot compute it, that is the finding.
A sequenced, dependency-honest plan that turns everything in this book into six months of work a real team can actually finish.
Actionable takeaways
open a spreadsheet today with four columns — task, owner, due date, artefact — and put the ten Day 1–30 actions from §3 into it before you finish this chapter. That spreadsheet is your program until it earns something better.
run action 7 first, not last. The backup and restore question takes an afternoon, and it is the one whose bad answer changes your entire budget conversation.
Chapter 14
Fourteen procedures, each written to be run at 2 a.m. by somebody who did not write it.
Ransomware with Data Exfiltration
Business Email Compromise and Payment Fraud
Chapter 14 · continued
SaaS and Cloud Account Takeover
Identity Provider and Privileged Credential Compromise
Chapter 14 · continued
Third-Party and Supply Chain Breach
Insider Threat
Chapter 14 · continued
Data Breach with Regulatory Obligations
DDoS and Service Unavailability
Chapter 14 · continued
Deepfake and AI-Enabled Social Engineering
Kubernetes and Container Compromise
Chapter 14 · continued
AI System Compromise
Edge Device and Perimeter Appliance Exploitation
Chapter 14 · continued
Web Application Compromise and Mass Exploitation
OT and ICS Incident
Reference
Sourcing
A security manual that cannot tell you where its claims come from is a blog post with delusions of grandeur.
Every regulatory deadline, framework version, tool command and threat statistic was checked against a primary or authoritative source, and each chapter ends with the URLs. Where a claim could not be confirmed it is marked Verify rather than asserted. Where two sources disagree, the disagreement is described instead of resolved by picking a favourite.
This is not legal advice
Chapter 15 and Appendix C summarise notification obligations across a dozen regimes to help you build a response process. They are a starting point for a conversation with counsel, not a substitute for one. Get a lawyer — before the incident, so you are not interviewing firms at 2 a.m.
“The attacker doesn’t break in any more. They log in, using a credential or an app-permission we granted, and our tools cannot tell the difference between them and an employee.”
Chapter 1 — saying it to a non-technical audience
Read the full manual
This edition is the brief. The complete text — twenty chapters, fourteen scenario playbooks, eight appendices and every source link — is published free and in full.
intelamation.com/InfoSec-Playbook-2026-Full.html