Three ways to read a field manual, what the control codes mean, and an honest account of where everything in here came from.
Who needs this: everyone, once | Read time: 8 min | Maps to: —
There are four reasons someone opens a book like this, and they want completely different things.
You are building a program. Start at Chapter 1 for the shape of the 2026 problem, then Chapter 2 for how a playbook is actually built, then work through Part II in whatever order matches your risk. Finish with Chapter 21, which sequences the whole thing into a first 180 days. Use the master checklist in Appendix A as your backlog — it is assembled automatically from every chapter, so it cannot drift out of sync with the text.
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 the playbooks assume, and Chapter 15 tells you which regulatory clocks just started. Everything else can wait until Thursday. If you are reading this during an incident and you have not yet named an Incident Commander, do that before you read another paragraph.
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 — which works better in a board meeting than any risk register I have ever seen presented.
You hold someone else's keys — or someone else holds yours. Chapter 20 is written for both sides of a managed service relationship: the provider with standing administrative access into estates it does not own, and the customer who granted it. Its checklist is tagged by audience, so each side can run the same list from its own chair.
Every chapter ends with a checklist. Each item carries a domain code and a number — IAM-04, RES-11, PB-RANSOM — that stays stable for the life of the book, so you can reference it in a ticket, an audit response, or an exercise report without ambiguity.
Each control also carries an implementation tier, borrowed from the CIS Implementation Group model:
| Tier | Who it is for |
|---|---|
IG1 | Essential cyber hygiene. Every organization needs this, regardless of size or budget. If you do nothing else, do these. |
IG2 | Organizations with people whose actual job is security. |
IG3 | Organizations facing adversaries willing to spend real money and real time to get in. |
Work down the tiers, not across the chapters. An organization with every IG1 control implemented is in materially better shape than one that has done half of Chapter 4 to IG3 and never touched backups. The most common way a security program fails is not that it did the hard things badly — it is that it did the hard things while the easy things sat undone.
Where a control could be verified against a published framework, it also carries a framework tag — a NIST CSF 2.0 category like PR.AA-01, a CIS Control number, or an ISO/IEC 27001 Annex A reference. Only tags that could be confirmed against the source are present. An untagged control is not a lesser control; it means the mapping was not verified, and I would rather leave it blank than tell you something an auditor will contradict.
A security manual that cannot tell you where its claims come from is a blog post with delusions of grandeur. So, plainly:
Every regulatory deadline, framework version, tool command, and threat statistic in this book was checked against a primary or authoritative source, and each chapter ends with the URLs. Where a claim could not be confirmed — and there are several, because 2026 has a lot of rules in motion — it is marked with a Verify callout rather than asserted. Where reporting is directionally well-attested but lacks a primary source, the text says so. Where two sources disagree, the disagreement is described instead of resolved by picking a favourite.
This matters most in three places. CIRCIA's final rule timing has moved more than once and sources conflict; Chapter 15 gives you the status rather than a date to plan around. Vendor-published statistics about alert fatigue and analyst burnout are widely quoted and mostly unsourced; Chapter 9 uses the peer-reviewed anchor and skips the marketing numbers. Command syntax in containment playbooks is reproduced as the vendor documents it, and where exact syntax could not be confirmed the action is described in words instead. A wrong command in a containment procedure is not a typo; it is an outage, so I would rather be vague than confidently wrong.
This book stands on other people's work, and says so. It also has work of its own, and this is where the line between them is drawn.
What is ours. The Coverage Model in Chapter 3 — six Functions, 29 domains, 145 capabilities — is original to this book, © 2026 Intelligent Automation, LLC, along with the 21 chapters, the 14 scenario playbooks, and the 489 controls in Appendix A that the model is wired to. 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 ours. Use it in your own program. If you republish it, credit it.
The CISO MindMap is a separate and earlier artefact, and it is the creation of Rafeeq Rehman, who has built and updated it annually since 2012. The 2026 edition was published on 11 April 2026 and is © 2012–2026 Rafeeq Rehman. It is not the basis of our model and our model is not a version of it — they are organized differently and answer different questions. Chapter 3 discusses his map on its merits and includes a navigable reconstruction of its structure, kept deliberately as a cross-check: a second opinion against which to test our own scope, on the principle that a branch of his map we have no home for is a finding against us. That reconstruction is a derivative reference for study and gap analysis. It is not the original artefact, it is not endorsed by Rehman, it does not replace it, and the color coding by NIST CSF Function on it is this book's editorial addition, not part of his design. Download the real thing — a single beautifully dense page — from rafeeqrehman.com, and put it on a wall.
CISA's Federal Government Cybersecurity Incident and Vulnerability Response Playbooks (November 2021, published under Executive Order 14028 §6, marked TLP:CLEAR) is the backbone of Chapters 13 and 10. It is a US Government work in the public domain. Chapters 13 and 10 adapt its process for organizations outside the federal civilian executive branch. CISA scoped the document to FCEB agencies and noted only that future iterations may prove useful to organizations outside it; the adaptation here is this book's, not CISA's. Where this book departs from CISA's model, it says so and says why.
Framework and standards references are the property of their respective bodies: the NIST Cybersecurity Framework, SP 800-61, SP 800-53, SP 800-207 and the AI Risk Management Framework (NIST, US Department of Commerce); the CIS Critical Security Controls and CIS Benchmarks (Center for Internet Security); ISO/IEC 27001, 27002, 27035, 22301 and 42001 (ISO/IEC — the standards themselves are copyrighted and must be purchased, and this book paraphrases structure rather than reproducing text); MITRE ATT&CK, D3FEND and ATLAS (© The MITRE Corporation); FAIR and FAIR-CAM (the FAIR Institute); the Cloud Controls Matrix (Cloud Security Alliance); OWASP project material (the OWASP Foundation); SOC 2 Trust Services Criteria (AICPA); PCI DSS (PCI Security Standards Council); and HITRUST CSF (HITRUST Alliance). All trademarks belong to their owners. Naming a framework here is neither an endorsement by its body nor a claim of certification or compliance.
Product and vendor names — AWS, Microsoft, Google, and every security tool named in these pages — appear because a responder needs to know which console to open, not because anything here is a recommendation, a review, or a commercial relationship. Commands and capabilities are cited to vendor documentation. Vendors change their products; verify before you rely on a command in production.
Incident case studies are drawn from published post-incident reviews, regulatory findings, government reports, and sworn testimony — the British Library's cyber incident review, the US Cyber Safety Review Board, GAO reports, and Congressional testimony among them. They are cited so you can read the primary document. They appear here to be learned from, not to be laughed at. Every organization in these pages was doing its best with what it had, which is exactly what makes their lessons worth your attention.
Reference to a 2015 book. Crafting the InfoSec Playbook by Jeff Bollinger, Brandon Enright and Matthew Valites (O'Reilly, 2015) is a genuinely good book and remains worth reading. This is not a second edition of it, is not affiliated with it, and its authors had no part in this. The overlap is the subject matter and the word "playbook."
Author. Written by Daniel Ramos, CTO, Intelligent Automation, LLC — publisher of Cyber Shield Weekly. Opinions here are his and not those of any client, employer, vendor, or standards body.
How to use this material. Localize it. Every playbook in Part III is a starting point that expects you to fill in your own tool names, contacts, thresholds and authorities. An unlocalized playbook fails at 03:00, which is the only time it matters.
Read it in whatever order your week demands, keep a pen near the checklists, and start with Appendix A if you are the sort of person who reads the last page first.