#Chapter 3 — The Coverage Model

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.

Who needs this: CISO, security leaders, program managers, anyone writing next year's plan | Read time: 20 min | Maps to: CSF 2.0 GOVERN (GV.OC, GV.RM, GV.RR, GV.OV), IDENTIFY (ID.AM, ID.IM), CIS Controls v8.1 1–2, ISO/IEC 27001:2022 A.5.2

Fellow defenders of the digital realm, there is a moment that arrives for every security leader, usually about four months in, usually at 11pm. You are trying to write next year's plan and you realize you cannot answer a question a competent thirteen-year-old could ask: what, exactly, are you responsible for?

Not what you are working on. Not what is in the SIEM. The full list — everything that would land on your desk if it went wrong, including the parts you have never once discussed, the parts that live in Legal's head, the parts that arrived with an acquisition and were never formally handed to anyone. You cannot assign work you have not written down. You cannot budget for it. And you certainly cannot admit to a gap in it, because a gap requires a boundary, and you do not have one.

So every security leader eventually builds the same artefact: one page showing the whole job. Most of them build it badly, and I include myself in that. The usual failure is an inventory of topics — a poster of nouns arranged by whatever taxonomy felt natural on the day, with no connection to any control anyone can test and no way to tell whether the green things are green because someone did the work or because green is a nice color. It goes on the wall. Nobody looks at it again.

This chapter gives you the version that survives contact. It is called the Coverage Model, it is this book's own, and what follows is how to run it, how to argue with it, and how to check it against the best-known independent map of the same territory.

#What the Coverage Model is, and the three things that make it different

The Coverage Model, edition 2026.1, is a scope and accountability model for a security program: six Functions, 29 domains, 145 named capabilities, published by Intelligent Automation, LLC as part of this book. Every domain has a status bar. Every bar reports something real.

Three design decisions make it useful rather than decorative, and they are worth stating plainly because each one is a rejection of how these things are normally built.

1. It stands on a free public spine. The top level is not ours and was never going to be. It is the six NIST CSF 2.0 Functions — GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND, RECOVER — as published in NIST CSWP 29 on 26 February 2024 (NIST CSWP 29). That buys three things at zero cost: your auditors already speak it, your regulators already reference it, and your board has probably already seen a slide with those six words on it — so you are not spending the first ten minutes of a budget meeting teaching a taxonomy you invented. It also means the model inherits CSF's own logic — GOVERN above the rest because accountability is a precondition, not a control; RECOVER separate from RESPOND because coming back is a different discipline from stopping the bleeding — rather than an arrangement we thought looked balanced.

2. Every node is wired to a testable control. Under the 29 domains sit 145 capabilities, and each domain is bound to the real control codes in this book — 463 controls across the chapter checklists, which assemble into Appendix A. That changes the artefact's nature. A domain is not green because the person who drew the map felt it was covered. It is green because a named human answered a specific, checkable statement — "phishing-resistant MFA is enforced for every account holding a privileged role, with no exception group" — and said yes, on a date, with an evidence artefact behind it. A poster tells you what exists in the world. This one tells you what is true in your organization, and it changes when the truth does.

3. It is navigable. Every domain points at the chapter that tells you how to do the thing. That is not a convenience feature; it is the difference between a scope statement and a plan. When a domain comes back red the next question is always "so what do we do about it," and a model that cannot answer that has handed you an anxiety generator. The crosswalk at the end of this chapter is the full index — the model is the table of contents for this book.

The model does not tell you what to do first. It tells you what exists, who owns it, and whether anyone can prove it. Sequencing is Chapter 21's job. Governing it is Chapter 16's. This chapter draws the boundary.

It helps to be precise about which question this artefact answers, because the other frameworks in this book answer different ones and readers routinely mash them together.

That last question sounds trivial until you try to answer it from memory with a CFO looking at you. CSF 2.0 gives you six Functions and 22 Categories — the right altitude for board reporting and precisely the wrong altitude for noticing that nobody has ever thought about firmware updates for the devices in your warehouse. The Coverage Model operates one storey down, where things get forgotten.

Actionable takeaway: 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.

#A guided tour of the six Functions

Here is the shape of the thing. I am not going to list all 145 capabilities — you have them on the model itself. What follows is what is notable, commonly neglected, or genuinely surprising in each Function.

#GOVERN — someone is accountable, and can prove it

Six domains: Program Governance, Playbook Discipline, Legal and Regulatory, Third-Party Governance, AI Governance, and Organizational Readiness.

Two things stand out. The first is that Playbook Discipline is a governance domain, not an operations one. Whether your plan, playbooks and runbooks are separated, versioned, and carry a severity schema tied to real business impact is a question about how your organization decides under pressure, not about tooling. Put it under DETECT or RESPOND and it quietly becomes the SOC's problem, which is how you end up with fourteen excellent playbooks nobody has the authority to invoke. Chapter 2.

The second is Legal and Regulatory: notification obligations mapped and current, attorney-client privilege posture, legal hold and evidence discipline, ransom payment authority with sanctions screening, regulator and law-enforcement engagement. In most organizations nobody inside the security function owns a single one of those. They are assumed to belong to General Counsel; General Counsel assumes the technical detail belongs to security; and the gap between those two assumptions is where privilege gets waived at 02:00 by a well-meaning engineer typing an incident summary into a shared document. Chapter 15 has the mechanics. This chapter's job is to get a name against the domain before you need it.

Also here: Organizational Readiness, which carries staffing sustainability and burnout as an explicit capability. Not as a wellness initiative. As scope.

#IDENTIFY — you know what you have and what is coming for it

Four domains: Asset and Attack Surface, Threat Model, Data Discovery, and Coverage and Gap Analysis.

Asset and Attack Surface is the domain everybody claims and almost nobody has. Its capabilities separate authoritative asset inventory from external attack surface discovery from shadow IT and unmanaged estate deliberately, because those three fail independently. A CMDB that is 94% accurate for managed laptops tells you nothing about the marketing subdomain still pointed at an expired storage bucket.

Threat Model is the domain most programs skip, and its first capability explains why it matters: current adversary behavior, not last year's. A threat model written at program inception and never refreshed is a document describing a world that has moved on.

And note that Coverage and Gap Analysis — this chapter, domain code MAP — sits inside IDENTIFY as a domain of its own. The model contains the practice of maintaining the model. That is not cuteness: an unmaintained scope statement is worse than none, because it launders staleness as diligence.

#PROTECT — the controls that actually stop it

The largest Function: seven domains and 40 capabilities. Identity and Access, Zero Trust, Cloud and Container, Data and Cryptography, Vulnerability and Exposure, Supply Chain Assurance, AI System Security.

Identity and Access is the biggest single domain at nine capabilities, and that is a statement about 2026. Three of the nine did not meaningfully exist five years ago: machine and non-human identity inventory, AI agent identity, scoping and revocation, and OAuth grant and app-consent control. An AI agent is a principal — it authenticates, holds authorization, can be over-permissioned, and somebody has to be able to revoke it on a Tuesday afternoon without filing a ticket with a vendor. That is an identity problem with an AI flavour, not an AI problem with an identity flavour, which is why it lives in Chapter 4 and not Chapter 7.

Two capabilities here are chronically under-read. Break-glass accounts, tested — most organizations have break-glass accounts and have never once used them, which means they have credentials, not a capability. And help-desk verification procedure, a single line in a model and also the entire initial access route for several of the most expensive intrusions of the last two years.

Data and Cryptography keeps post-quantum migration plan and crypto-agility and cryptographic inventory as separate capabilities, and the separation is the point: the plan is a project, agility is a structural property of your estate. NIST's deprecation frame — RSA-2048 and ECC-256 deprecated by 2030, disallowed after 2035 — is what turns this from research into maintenance (NIST PQC project). Chapter 8.

Vulnerability and Exposure includes one capability that reads like pedantry and is not: patch verification, not patch assumption. Your patch console reporting compliance is a claim by the same system that failed to patch.

#DETECT — you would actually know

Four domains: Telemetry and Logging, Detection Engineering, Identity Threat Detection, Triage and On-Call.

Telemetry's capabilities are ordered by how they fail. Coverage across identity, endpoint and cloud control plane first, because a detection you have no data for is a hypothesis. Retention longer than your dwell time second — if your logs roll at 30 days and intrusions sit undetected longer than that, you have bought a system that guarantees you cannot investigate the incidents that matter most. Logs shipped beyond the adversary's reach third, which people skip until the first time they watch an attacker with domain admin delete the evidence of how they got in.

Identity Threat Detection is split out from Detection Engineering on purpose, and reports into two chapters (4 and 9) because it is genuinely joint custody — which is exactly where things fall through.

Triage and On-Call carries the model's most opinionated line: alert fatigue treated as a defect. Not a fact of life, not a staffing complaint. A defect, with a ticket, an owner and a fix. High alert volumes with very high false-positive rates measurably degrade detection effectiveness and drive turnover (Tariq et al., ACM Computing Surveys 57(9), 2025). A tuning backlog is a detection outage in slow motion.

#RESPOND — you can act under pressure without improvising

Four domains: Incident Command, Scenario Playbooks, Communications, Orchestration.

The first capability under Incident Command is Incident Commander who does no technical work, and it is first because it is what breaks first: the best engineer in the room becomes IC, gets pulled into a terminal, and for the next forty minutes nobody is running the incident. Re-scope on every new indicator is the other line worth memorizing — most bad incidents are ordinary incidents whose scope nobody revisited.

Communications leads with out-of-band channel that exists before you need it. Standing up a secure comms channel while your identity provider is compromised is not a plan, it is a coin flip. It costs nothing in advance, which makes it the highest-return line in this Function for a small team.

Orchestration carries the cleanest guardrail in the model: rollback for every automated containment. Automation that can isolate 4,000 endpoints and cannot un-isolate them has not reduced your risk, it has changed which way it points. Chapter 17.

#RECOVER — you come back, and you come back clean

Four domains: Backup and Immutability, Recovery Execution, Business Continuity, Learning.

Read the first capability of Backup and Immutability carefully: immutable copies, not merely offsite copies. Offsite is a geography answer to an authorization question. If your backup platform trusts the same directory your production estate trusts, an attacker with that directory has your backups too — which is why backup credentials isolated from the production domain is the very next line, and why ransomware operators increasingly target backup infrastructure, identity services and virtualization management planes rather than only your ability to operate (M-Trends 2026).

Recovery Execution leads with identity-first recovery ordering, the most commonly inverted sequence in this book. Restore the file servers before you have rebuilt trustworthy identity and you have restored the attacker's access along with the data. Order of operations is content. Chapter 12.

Learning sits under RECOVER rather than in an appendix, and its last capability decides whether any of this compounds: findings reach a playbook change. A post-incident review that produces insight and no diff is a therapy session.

Actionable takeaway: 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.

#Running the gap analysis

Here is the method. One prepared afternoon, six to ten people, and an artefact you will use for a year.

You score each domain on two independent axes, then record an owner. Two axes, because coverage and confidence fail differently, and the interesting information lives in the disagreement between them.

The cell everyone under-reads is green coverage with red confidence. That is not a documentation problem, and treating it as one is how it survives. It is a belief you have never tested — the backup job that has run green for two years and has never been restored from, the access review that happens reliably and produces no record of what was revoked. Post-incident reviews find their nastiest surprises in that cell, every time.

Who is in the room: the CISO, the executive sponsor, every candidate domain owner, one person from Legal, one person from whichever business function owns your most regulated data, and — the attendee everyone cuts — at least one competent sceptic from outside the security team, whose job that afternoon is to ask "how do you know?" and not stop asking.

The order of these steps matters, and getting it wrong wastes the whole exercise.

Assign owners before scoring. Not after. Reverse those two steps and the same two failures happen every time. Unowned domains get scored optimistically, because no individual feels the score reflects on them — the domain nobody owns is precisely the one that collects a comfortable amber. Then, once scores exist, owner assignment becomes a negotiation about who is willing to inherit a red, and that is a negotiation nobody wins. Owner first. Score second. Every. Single. Time.

And now the punchline: the domains with no owner are more dangerous than the domains scored red. A red score is a known gap with a person attached. It shows up in someone's objectives, it gets a budget ask, it gets argued about. An unowned domain appears nowhere — no advocate, no line item, nobody who notices when it fails. In practice the unowned set is depressingly consistent: Legal and Regulatory, Third-Party Governance, AI Governance, Supply Chain Assurance, Business Continuity, and the security content of anything involving an acquisition. Every one of those has produced a headline incident in the last two years.

Actionable takeaway: finish the session with a one-page list of unowned domains and take it to your executive sponsor as an ownership question, not a funding question. "Who owns this?" is a decision an executive can make in the room, that afternoon. "Fund this" goes into a cycle and comes back next year, in a worse mood.

#Using it in a budget conversation

The same page does org design. Overlay your actual team structure on the 29 domains and the true shape of your organization appears: which domains have three people quietly competing over them, which have one exhausted person spanning five, and which are carried informally by somebody whose job title says something else entirely. When you next open a role, the model tells you what that role is for in a way a job description assembled from the last occupant's duties never will.

It is also a scope-defense tool. When new work arrives — a regulation, a platform, an acquisition — put it on the model, show which domain it lands in, and show what that domain's owner is already carrying. The conversation becomes an explicit trade instead of a silent accumulation.

Actionable takeaway: never present the model without also presenting what comes off it. A scope statement used only to add work trains everyone around you to stop reading it.

#The map that got here first

I would be writing dishonestly if I presented the idea of a one-page map of the security profession as ours. It is not. It belongs to Rafeeq Rehman, and he got there fourteen years before we did.

Since 2012, Rehman has built and annually updated the CISO MindMap, subtitled exactly the right question: What do Security Professionals Really do? The 2026 edition was last updated 11 April 2026, carries a printed expiration date of 30 September 2027, and is © 2012–2026 Rafeeq Rehman. You can download it, free, from rafeeqrehman.com.

Go and do that. Print it at a size you can genuinely read and put it on a wall. Twelve top-level branches and roughly three hundred and sixty nodes, on which attorney-client privilege sits next to SCADA HMIs, cyber insurance, AI agent identity, staff burnout prevention, and corporate politics — because all of those really are somewhere in the job, and the map does not care that your team is four people. The first time you read it properly it is uncomfortable, and that discomfort is the artefact working.

The Coverage Model is better for our purposes: public framework spine, controls you can hand an auditor, an index into a specific book. It is not better in general. Rehman's map is broader than ours in places we deliberately narrowed, it is maintained by someone with no product to sell you, and it has been continuously revised for over a decade — a track record neither this book nor any vendor poster can claim.

That is an interactive reconstruction of the CISO MindMap's structure, included here as a cross-check on our own scope — a second opinion on whether we drew the boundary in the right place. Three things you must know about it. It is derivative: it reproduces the map's branch and node structure for study and gap analysis, and it is not the original artefact. It is not endorsed by Rehman. And the NIST CSF color coding on its branches is this book's editorial addition, not his — with one exception, noted below, where he supplies the mapping himself. If you want the real thing, and you should, get it from rafeeqrehman.com.

#What is notable in the 2026 edition

Rehman's 2026 revision made four kinds of change: a category was removed, the AI material was substantially expanded, legacy items were consolidated, and the visuals were improved.

The removal is the most instructive. Remote Work is gone as a category — not because the risk evaporated, but because work-from-anywhere is now simply work, and a category that describes everything describes nothing. Its substance did not vanish; it dissolved into identity, endpoint, architecture and SASE, where it always belonged. Steal that discipline wholesale. A domain list that only ever grows stops being a scope statement and becomes a museum.

The additions tell you where the profession actually moved:

• Using and Securing AI is now a 28-node branch with a deliberate two-way split — Securing AI (13 leaves, covering AI policy and governance, AI frameworks, ethical and responsible use, LLMs/chatbots/agents/RAG, IP protection, agentic AI frameworks, AI application security testing, AI sovereignty, human-in-the-loop strategies, RAG and vector database security, third-party AI tools) and Using AI (9 leaves, the first of which is train InfoSec teams on AI technologies, ahead of any tool). Defending AI systems and defending with them are two jobs, and the split says so.
• AI Agent Identity now appears under Identity and Access Management, not under AI. Same conclusion our model reaches, arrived at independently.
• Quantum Safe Encryption appears appended to an existing threat-prevention leaf — Encryption, SSL, PKI, Quantum Safe Encryption — rather than as a new branch. Translation: post-quantum is now maintenance on your cryptographic estate, not a research project.
• Legacy items were consolidated, the unglamorous half of the removal discipline: once-distinct concerns collapse into one leaf as the industry stops treating them separately.

One structural detail worth borrowing: for Security Operations — 130 nodes, roughly 36% of the map — Rehman supplies the CSF mapping himself: Threat Prevention (Identify and Protect), Threat Detection (Detect), Incident Management (Respond and Recover). Where he maps, we use his.

#The four focus areas for 2026-27

The map carries a callout with four focus areas for the coming cycle. They are not branches; they are his read on where attention should go. Taken together they make a defensible annual plan for almost any security team.

1. Embrace and adapt to AI. The evidence for taking this seriously is specific. Anthropic disclosed GTG-1002, a campaign it assesses with high confidence to be Chinese state-sponsored, in which AI performed 80–90% of an intrusion campaign against roughly 30 targets with sporadic human intervention at decision gates (Anthropic). Google's threat intelligence group documented malware families that call an LLM at runtime to rewrite themselves (GTIG). The evidence for not losing your head is equally specific: Mandiant concluded from its 2025 investigations that most intrusions still stem from human and systemic failures rather than AI (M-Trends 2026), and VulnCheck found that of 1,061 vulnerabilities attributable to AI-assisted discovery, only 14 — 1.3% — have been confirmed exploited in the wild (VulnCheck). AI is inflating your patch queue considerably faster than it is inflating your risk.

2. Consolidate and rationalize security tools. Rehman places this obligation in three separate places, which is deliberate: retire redundant and under-utilized tools under the Team Management budget node, tools and vendors consolidation under Governance, and security tools rationalization under the M&A sub-branch. Budget, governance, integration — three reasons for the same work. The operative principle is ruthless and simple: no tool should cost more than the risk reduction it delivers. Cost is not the license line. It is license plus the engineer-days to run it, plus the alerts someone must triage, plus the integration it breaks on upgrade, plus the attention it steals from the tool that actually works.

Run the rationalization as a table, not a debate. Per tool: annual all-in cost, named owner, the detections or controls it uniquely delivers, the date someone last acted on its output, and what breaks if it is switched off on Friday. A tool with no named owner is unmanaged; a tool whose output nobody has acted on in ninety days is a subscription, not a control.

3. Old threats have not disappeared. This is the focus area that protects you from the first two. Ransomware and extortion appeared in 48% of confirmed breaches in the 2026 DBIR, up from 44% (SecurityWeek). Phishing and its variants accounted for around 60% of all initial infection vectors across 4,875 EU incidents in ENISA's current threat landscape (ENISA ETL 2025). Third-party involvement appeared in roughly 48% of breaches, a ~60% year-over-year increase, and only 26% of CISA KEV vulnerabilities were fully remediated by polled organizations, down from 38%, with median patching time up to 43 days from 32 (Help Net Security). The Salesloft Drift compromise turned OAuth refresh tokens issued to one vendor into data access across 700+ organizations, with no customer-side vulnerability to patch (AppOmni). Meanwhile the boring control keeps paying: 66% of organizations with encrypted data recovered from backups, up 12 points (Sophos). None of that is an AI problem, and none of it waits while you build an AI program.

4. Take good care of your teams. I want to give this one the weight Rehman gives it, because it is the focus area most likely to be read as a soft closing sentiment and skipped. It is not soft. It is a control, and its failure mode is measurable.

Start with the mechanism. Sleep-deprived people stay reasonably good at well-practiced, rule-based tasks. What degrades is handling the unexpected, revising plans, filtering distraction and communicating clearly (Harrison & Horne, 2000) — which is a precise description of what a novel incident demands. Alert fatigue compounds it (Tariq et al., 2025).

Then look at what a real incident does to real people. The British Library published, as an explicit lesson from its own review, that incident management plans should include provisions for managing staff and user wellbeing, because attacks are deeply upsetting for staff whose data is compromised and whose work is disrupted. The same review recorded that its technology department was already overstretched with staff shortages before the incident (British Library cyber incident review). The pre-incident staffing deficit became the post-incident recovery constraint. That is the whole argument in one sentence.

NCSC publishes the only government guidance dedicated to responder welfare, and its recommendations are concrete enough to implement this month: include all staff in the IR plan with deputy arrangements and out-of-hours coverage; build a culture where people feel safe saying they are overwhelmed and safe raising concerns about colleagues; plan internal communications; be conscious of staff concerns about personal impact and job security; and practice your response. NCSC also names the part nobody plans for — incidents "often start with an intense period of activity, but many also have a 'long tail' with the impact lasting for months" (NCSC).

The 2026-specific piece is that fourth recommendation, aimed squarely at AI. Your team is reading the same headlines you are, and a good share of them are being told their function is about to be automated. You cannot honestly promise nobody's role changes — some will. What you can do is be specific, early, and repeatedly: name which tasks you intend to automate, name what you expect people to do with the reclaimed time, fund the training as a budget line rather than in someone's evenings, and never let an AI capability arrive by surprise inside a tool rollout. Ambiguity burns people out faster than workload does. Most of what gets called emotional intelligence during technological disruption is telling people the truth on a predictable schedule.

And almost none of it needs budget. Rotating incident command duty on a schedule rather than on exhaustion costs nothing. Naming a deputy for every authority costs nothing. Running post-incident reviews as blame-aware investigations costs nothing but discipline, and the practitioner-standard process is published free (Howie guide). Reporting on-call load and unplanned-work hours to your executive sponsor costs one row on a slide — and it is the most effective way to make understaffing visible before it becomes an outage.

Actionable takeaway: put three human metrics on the same dashboard as MTTD and MTTR — on-call hours per person per month, percentage of weeks with unplanned out-of-hours work, and vacancy days for open roles. Report them every time you report the technical ones. A trend line is an argument. "The team is tired" is not.

#How to use two maps without going mad

They do different jobs, so run them on different clocks.

Ours is for accountability and status. It has owners against it, controls behind it, and a color that changes when your assessment changes. It is what you take to a budget meeting and refresh on a cadence.

His is for a scope challenge. Once a year, walk his twelve branches against our 29 domains, asking exactly one question: is there anything on his map that has no home on ours? Not "do we do this" — "does our model even have a place to put it."

And here is the part that has to be honest to be worth anything: if his map has a branch ours has no home for, that is a finding against us, not against him. I already know of two. Our model has no first-class home for physical security, which he carries under Risk Management, and its coverage of IoT, AR/VR and edge computing is oblique at best — reachable only through asset inventory in Chapter 10 and the OT playbook in Chapter 14.14. If either is genuinely in scope for you, this book is not your only source, and pretending otherwise would be the exact failure this chapter is about.

#Honest limitations of the Coverage Model

Overselling this thing is the fastest way to get it thrown out of your organization, so here are the caveats I would want if I were reading someone else's model.

1. It is not a control framework. The model contains no safeguards. The controls live in the chapter checklists and in Appendix A; the model is the index over them. You cannot certify against a scope statement.
2. It is not a maturity model. No tiers, no defined "good." The red/amber/green rubric in this chapter is a rubric, not a standard — do not report it as a CSF Tier, because CSF Tiers are explicitly not a maturity model either (NIST CSWP 29).
3. A green bar means someone asserted a control is implemented. It does not mean it was audited. This is the limitation that matters most, because the model's greatest strength — reading live status from your own assessment — is also the mechanism by which it can lie to you fluently and in color. Self-assessment is exactly as good as the person filling it in and the sceptic sitting across from them. That is why confidence is scored separately, why every green demands a named evidence artefact, and why the outside sceptic is not an optional attendee.
4. It does not prioritize. Every domain is drawn the same size. Right for a scope statement, wrong for your Monday morning. Sequencing is Chapter 21.
5. Applicability varies enormously by industry. A regional credit union and a pipeline operator will legitimately descope different halves of this model. Descoping is supported — but do it in writing, with a named accepting executive and a date, or it is not descoping, it is forgetting.
6. A model maintained by the people it grades has an obvious failure mode. We wrote the model, we wrote the controls, and we wrote the book it indexes. Every incentive points toward a model whose shape flatters the material. Three defenses, and hold us to all of them: the spine is NIST's, so the top level cannot be quietly reshaped to suit a chapter; the annual scope challenge against Rehman's independent map exists precisely to catch what we left out; and the model carries a review date after which it is presumed wrong. Apply the same three tests to your own instance. If your model has never produced a finding that embarrassed the people who maintain it, it is not being used.

Actionable takeaway: use the Coverage Model to find the work and the frameworks in Chapter 16 to govern it. Anyone who tries to make a scope model do CSF's job produces a document that satisfies neither the engineer nor the auditor.

#Crosswalk: the model to this book

Print the model. Assign the owners before you score anything. Find the domains with nobody's name on them — and put a name on them before an incident does it for you.

Stay scoped, stay owned, stay unsurprised.

#Chapter checklist

• MAP-01A documented coverage model covering the full scope of the security program exists, is dated, and is accessible to the whole security team. [IG1] [GV.OC]
• MAP-02Every domain in the coverage model has exactly one accountable owning role recorded, or is explicitly recorded as unowned. [IG1] [GV.RR]
• MAP-03Owners were assigned before any coverage scoring took place, and the assignment record predates the scoring record. [IG2] [GV.RR]
• MAP-04Every domain is marked in-scope or out-of-scope, each with a one-line written rationale approved by the executive sponsor. [IG1] [GV.OC]
• MAP-05Each in-scope domain carries two independent scores — coverage and confidence — refreshed within the last 12 months. [IG2] [ID.IM]
• MAP-06Every domain scored green for confidence names a specific evidence artefact that a third party could inspect. [IG2] [GV.OV]
• MAP-07Every domain scored green for coverage and red for confidence has a dated remediation action with a named owner. [IG2] [ID.IM]
• MAP-08The scoring session included at least one participant from outside the security function whose stated role was to challenge evidence. [IG2] [GV.OV]
• MAP-09A current one-page list of unowned domains exists and has been presented to the executive sponsor with a dated decision against each line (owner assigned, funded, risk accepted, or descoped). [IG1] [GV.RR]
• MAP-10The Legal and Regulatory domain — notification obligations, attorney-client privilege posture, legal hold, ransom payment authority, regulator engagement — has a named owning role and a named legal counterpart. [IG1] [GV.OC]
• MAP-11Coverage-model status is derived from the control checklist responses in the master checklist, not from independent freehand judgement. [IG2] [GV.OV]
• MAP-12Domain scores are reported as a list of specific findings; no aggregate maturity score or average is reported to leadership. [IG2] [GV.OV]
• MAP-13The coverage model has been checked within the last 12 months against at least one independent external scope model, and any branch with no home in our model was recorded as a finding. [IG2] [ID.IM]
• MAP-14Where a domain is descoped, the descoping decision names the accepting executive role and the date it was accepted. [IG2] [GV.RM]
• MAP-15The coverage model carries an explicit expiration or review date, and a calendar entry exists to refresh it before that date. [IG1] [GV.OV]
• MAP-16At least one domain or category has been removed or merged in the last review cycle, or the review record states explicitly that none warranted removal. [IG3] [ID.IM]
• MAP-17New scope arriving from regulation, acquisition or platform change is mapped to a domain and an owner before implementation work begins. [IG3] [GV.OC]
• MAP-18A complete inventory of security tools exists, recording annual all-in cost, owning role, the unique control or detection each delivers, and the date its output was last acted upon. [IG1] [CIS 2] [ID.AM]
• MAP-19Every security tool with no named owner, or with no acted-upon output in the last 90 days, has a documented retain-or-retire decision. [IG2] [ID.AM]
• MAP-20At least one redundant or under-utilized tool has been retired in the last 12 months, with the released budget explicitly reallocated. [IG2] [GV.RM]
• MAP-21An inventory of AI systems, tools and agents in use exists, recording owner, data touched, autonomous actions permitted, and upstream model or vendor. [IG1] [ID.AM] [GV.SC]
• MAP-22The incident response plan includes staff welfare provisions: named deputies for every authority, a duty rotation schedule, and out-of-hours coverage arrangements. [IG1] [GV.RR] [A.5.24]
• MAP-23On-call hours per person, unplanned out-of-hours work, and vacancy days are reported to executive leadership alongside technical security metrics. [IG2] [GV.OV]
• MAP-24Training budget for the security team is a protected, named line item rather than a residual, and includes AI skills development. [IG2] [PR.AT]
• MAP-25Post-incident reviews are run as blame-aware investigations producing documented insights, and each insight is traced to a playbook or control change. [IG2] [ID.IM] [A.5.27]

#Sources

1. NIST, The NIST Cybersecurity Framework (CSF) 2.0, CSWP 29 (26 February 2024) — https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final
2. NIST, CSF 2.0 PDF — https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
3. Rafeeq Rehman — CISO MindMap 2026 (last update 11 April 2026; expiration 30 September 2027; © 2012–2026 Rafeeq Rehman) — https://rafeeqrehman.com
4. CIS, Critical Security Controls v8.1 — https://www.cisecurity.org/controls/v8-1
5. CIS, Implementation Groups — https://www.cisecurity.org/controls/implementation-groups
6. CISA, Zero Trust Maturity Model v2.0 — https://www.cisa.gov/zero-trust-maturity-model
7. NIST Post-Quantum Cryptography project — https://csrc.nist.gov/projects/post-quantum-cryptography
8. SecurityWeek on the Verizon 2026 DBIR — https://www.securityweek.com/verizon-dbir-2026-vulnerability-exploitation-overtakes-credential-theft-as-top-breach-vector/
9. Help Net Security on the Verizon 2026 DBIR — https://www.helpnetsecurity.com/2026/05/20/verizon-2026-dbir-findings/
10. Mandiant / Google Cloud, M-Trends 2026 — https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026
11. Sophos, State of Ransomware 2026 — https://www.sophos.com/en-us/blog/sophos-state-of-ransomware-2026
12. VulnCheck, State of Exploitation 1H-2026 — https://www.vulncheck.com/blog/state-of-exploitation-1h-2026
13. Anthropic, Disrupting AI espionage (GTG-1002) — https://www.anthropic.com/news/disrupting-AI-espionage
14. Google Threat Intelligence Group, threat actor usage of AI tools — https://cloud.google.com/blog/topics/threat-intelligence/threat-actor-usage-of-ai-tools
15. ENISA Threat Landscape 2025 — https://www.enisa.europa.eu/sites/default/files/2026-01/ENISA%20Threat%20Landscape%202025_v1.2.pdf
16. AppOmni, Salesloft Drift / Salesforce (UNC6395) analysis — https://appomni.com/blog/drift-breach-salesforce-unc6395-saas-prevention/
17. NCSC, Putting staff welfare at the heart of incident response — https://www.ncsc.gov.uk/guidance/putting-staff-welfare-at-the-heart-of-incident-response
18. British Library, Cyber Incident Review (8 March 2024) — https://www.bl.uk/home/british-library-cyber-incident-review-8-march-2024.pdf/
19. Harrison & Horne, The Impact of Sleep Deprivation on Decision Making (2000) — https://fatiguemanagersnetwork.org/wp-content/uploads/Harrison-et-al.2000_-The-Impact-of-Sleep-Deprivation-on-Decision-Making.pdf
20. Tariq, Baruwal Chhetri, Nepal & Paris, Alert Fatigue in Security Operations Centres, ACM Computing Surveys 57(9), 2025 — https://dl.acm.org/doi/10.1145/3723158
21. Howie: The Post-Incident Guide (PagerDuty) — https://howie-guide.pagerduty.com/