A sequenced, dependency-honest plan that turns everything in this book into six months of work a real team can actually finish.
Who needs this: CISO · security lead · IT director · the one person who is "doing security" alongside their day job · Executive Sponsor | Read time: 28 min | Maps to: CSF 2.0 GOVERN (GV.RM, GV.RR, GV.OV, GV.SC), IDENTIFY (ID.AM, ID.RA, ID.IM), PROTECT (PR.AA, PR.DS), DETECT (DE.CM), RECOVER (RC.RP); CIS Controls v8.1 — 1, 2, 5, 6, 8, 11, 17; ISO/IEC 27001:2022 A.5.24, A.5.29, A.5.30
Cyber-friends, this is the last chapter, so let me be blunt about what the previous twenty have done to you: they have handed you roughly four hundred things to do, all of which are correct, and none of which are ordered. That is the standard failure of security books, and of most security programs. A list of good controls is not a plan. A plan has a sequence, an owner per line, and an honest statement of what has to be true before the next thing can start.
Sequence is not a stylistic preference here. It is the difference between a quarter that produces capability and a quarter that produces a slide deck. You cannot engineer detections for telemetry you do not ingest. You cannot move privileged roles to just-in-time elevation when you do not yet know which accounts hold privilege. You cannot perform a clean recovery from backups that authenticate against the identity plane you have just declared compromised. Teams get these three orderings wrong constantly, and the cost is not a mistake you notice — it is a quarter of genuine effort that leaves the organization exactly as exposed as it started.
The plan below is 180 days in three phases: find out what is true, stop the bleeding, build the system. It assumes no specific budget, no specific product, and no dedicated team. It does assume you can get a named executive to say yes to things, because without that you do not have a program, you have a hobby.
One more thing before the calendar starts. Nothing in the first thirty days involves buying anything. That is not asceticism — it is that every purchase made before the inventory exists is a purchase made against a guess, and the discovery phase reliably changes what you would have bought.
Every line has one named owner, and the owner is a person, not a team. "Infrastructure" does not do work. A person does. If two people own a line, nobody owns it.
Every line has a date, and the date is on a calendar someone else can see. The board reads dates. Auditors read dates. Attackers read nothing, but they arrive on their own schedule and do not wait for your roadmap to mature.
Every phase ends with a written artefact you can hand to a stranger. Day 30 produces a baseline document. Day 90 produces a plan, three playbooks, and one after-action report. Day 180 produces a board report with trend lines. If a phase ends with a feeling of progress and no artefact, the phase did not happen.
That is the whole governance overhead. Chapter 16 covers the policy hierarchy, risk register and reporting structures that come after the first 180 days; you do not need them to start, and building them first is one of the more common ways to burn a quarter producing documents about work nobody has begun.
Actionable takeaway: 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.
This is the table to argue about before you sequence anything. Each row states a piece of work, what must exist first, and — the column people skip — what specifically fails if you do it in the wrong order.
| The work | Genuinely requires first | What failure in the wrong order looks like |
|---|---|---|
| Detection engineering (Ch. 9) | Log coverage audit; prioritized asset and identity list | You write rules against telemetry you never ingested. The rule passes review, deploys, and can never fire. DeTT&CT exists precisely because visibility and detection are separate problems (NVISO on DeTT&CT) |
| Just-in-time privileged elevation (Ch. 4) | Complete identity inventory, human and non-human; break-glass accounts that work | You JIT the admins you know about, leave standing privilege on the ones you missed, and lock yourself out of the platform on a Friday |
| Clean recovery (Ch. 12) | Isolated backups with out-of-band credentials; a tested restore | You restore into the identity plane the adversary controls, or discover at hour six that the backup console uses the SSO you cannot log into |
| KEV-driven patching SLA (Ch. 10) | Asset inventory; internet-facing enumeration; named owner per asset | An SLA measured against a denominator you cannot produce. Industry-wide, only 26% of KEV vulnerabilities were fully remediated by polled organizations, and median patching time rose to 43 days (DBIR 2026 via Help Net Security) |
| Scenario playbooks (Ch. 14) | An IR plan with named roles, a severity schema and declaration criteria (Ch. 13) | Playbooks that escalate to roles nobody holds, and a step-14 decision with no authority attached to it |
| A tabletop worth running (Ch. 18) | The plan, at least one playbook, and evaluation criteria written before the exercise (NIST SP 800-84) | A pleasant two-hour discussion that generates no findings, no owners and no due dates |
| Third-party program (Ch. 11) | Vendor inventory including SaaS-to-SaaS and OAuth grants | You assess the twelve vendors procurement knows about while the OAuth integration nobody logged holds standing access to your CRM |
| AI governance (Ch. 7) | AI and agent inventory, including shadow AI | Policy governing the three approved tools, and no visibility of the eleven that people actually use |
| Automation and orchestration (Ch. 17) | Stable playbooks; a defined list of reversible vs. irreversible actions | You automate a procedure that is still changing weekly, and the automation becomes the reason nobody can change it |
| Board reporting and metrics (Ch. 16) | Incident records that capture detection source and timestamps | Numbers you cannot defend under a follow-up question, which is worse than no numbers |
| Tool rationalization (§7) | Control-to-tool map; named owner per tool | You cancel the product that was quietly your only retained evidence source for a log class you are obliged to keep |
Three of these deserve to be said as flat rules, because they are the ones that actually eat quarters.
Telemetry before detection. A detection gap on a technique you have no logs for is an ingest and budget problem, not a detection-engineering problem, and conflating the two is how teams spend a quarter writing rules that can never fire.
Identity inventory before identity controls. Every privileged-access project measures its own success against the population it can see. If that population is incomplete, the project reports 100% coverage and delivers something less.
Isolation before restoration. A restore test that uses your production administrator credentials proves you can restore on a good day. It proves nothing at all about the day you need it.
The deliverable for this month is not a control. It is an honest baseline: ten lists, each dated, each with an owner, each of which you would be willing to show a hostile auditor. Nothing here requires a purchase order. Most of it requires access, a spreadsheet, and the willingness to write down an unflattering number.
| # | Action | Who | Done when | Evidence to capture |
|---|---|---|---|---|
| 1 | Enumerate everything internet-facing: public IPs, DNS records, cloud load balancers, remote-access portals, vendor-hosted properties, forgotten test environments | Infrastructure owner | The list reconciles against two independent sources (registrar/DNS export and cloud provider inventory) and every entry has a named owner | Dated export of both sources plus the reconciled list and unresolved deltas |
| 2 | Build the asset inventory: endpoints, servers, cloud accounts and subscriptions, SaaS tenants — each with business owner and criticality | IT lead | Every asset has an owner; "unknown" is itself a counted, reported category | Inventory export with owner column and the count of unowned assets |
| 3 | Build the identity inventory — human and non-human: service principals, app registrations, workload identities, CI publishing tokens, API keys, agents | IAM owner | A single number exists for total identities, with owner per entry (Chapter 4, IAM-01) | Directory and cloud IAM exports, dated |
| 4 | Enumerate who holds administrative privilege on each platform, and whether it is standing or activated just-in-time | IAM owner | Every privileged role on every platform has a named list, including vendor and contractor accounts | Per-platform privileged-role export and the standing-privilege count |
| 5 | Audit log coverage against a priority order: critical systems, internet-facing services, identity and domain management, then the rest (CISA/ACSC event logging guidance) | Detection owner | For each priority source you can state: collected yes/no, where it lands, retention in days, who can query it | Log-source table with retention values read from configuration, not from memory |
| 6 | Establish what your retention actually is, from the platform, not the assumption | Detection owner | Written figures per platform — for example CloudTrail console Event history is a hard 90-day window for management events (AWS) and Entra ID audit and sign-in retention is 7 days on Free, 30 on P1/P2 | Screenshot or API output per platform, dated |
| 7 | Backup reality check: what is backed up, is any copy immutable, do backup credentials depend on the production identity provider, when was the last successful restore | Backup owner | Each question answered in writing; "we don't know" recorded as the answer where it is the answer | Backup job report, immutability configuration, date of last restore test |
| 8 | AI inventory: every model, assistant, agent and AI-enabled feature in use, who owns it, what data it touches, what it may do without a human — shadow AI included | Application owner | The list includes at least one tool that was not previously approved. If it does not, you have not finished looking | Inventory sheet, plus SaaS/egress evidence used to find unapproved use |
| 9 | Vendor list with data access, integration type and OAuth grants enumerated in each SaaS tenant | Vendor manager | The OAuth grant list is produced from the tenant, not from procurement records | Grant export per tenant, dated, with AllPrincipals-scope grants flagged |
| 10 | Incident readiness check: does a plan exist, is an Incident Commander named, is there an out-of-band communications channel, is there a printed contact list | Security lead | Each answered yes/no with evidence. CISA's guidance is to print the plan and contact list because "internal email, chat, and document storage services may be down or inaccessible" (CISA IRP Basics) | The documents themselves, or a written statement that they do not exist |
Somewhere around the second week, this exercise stops being administrative. A domain administrator account belonging to someone who left eighteen months ago. An internet-facing appliance with no owner and no maintenance window. A backup job that has been failing quietly since a certificate expired. Logging that was enabled on the platform but never routed anywhere with retention. An OAuth grant with tenant-wide mail read access, approved by one person, three years ago.
This is normal. It is so normal that the published post-incident record is largely a catalog of it. GAO found that Equifax's patch notice never reached the people who could act because "the recipient list for the notice was out-of-date," and that an expired digital certificate meant traffic "was not being inspected throughout the breach" (GAO-18-559). UnitedHealth's Change Healthcare intrusion began at a Citrix remote-access portal that did not have MFA enabled, despite company policy requiring it on all external-facing systems (Healthcare Dive). Colonial Pipeline's entry point was "a legacy virtual private network profile that was not intended to be in use," without MFA (Blount testimony). The British Library's published review records that MFA was in place for end-user technologies "but not on certain supplier endpoints" (British Library cyber incident review).
Every one of those organizations had a policy. The gap was at the seam — a supplier, a legacy system, an exception granted for a good reason by someone who has since moved on. Your seams are in the lists you just built, and finding them in week two is a considerably better outcome than finding them in an after-action report.
Actionable takeaway: 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.
Now you spend. This phase is deliberately narrow — five workstreams, ordered so that each one is possible when it starts. The theme is that everything here reduces the severity of an incident you have not detected yet.
| # | Action | Who | Done when | Evidence to capture |
|---|---|---|---|---|
| 1 | Enforce phishing-resistant MFA (FIDO2/WebAuthn or PKI) on every account holding a privileged role, and remove push, SMS and voice as registered methods for those accounts | IAM owner | Zero privileged accounts retain a phishable method; break-glass accounts documented and excluded by design, not by accident | Per-platform authentication-method report before and after, dated |
| 2 | Close the MFA seams found in Phase 1: VPN, firewall management, hypervisor console, backup portal, supplier endpoints, legacy applications | IT lead | Each either federates to the IdP or carries a written exception with a named approver and an expiry date | The exception register, with expiry dates in the future |
| 3 | Stand up KEV-driven remediation with written SLA tiers and a rapid-response lane for actively exploited internet-facing vulnerabilities (Chapter 10 owns the tiers) | Vulnerability owner | The SLA is signed, the clock's start event is defined, and the first cycle has run to completion with exceptions recorded | SLA document, first cycle's remediation report, exception list with owners |
| 4 | Make one backup copy genuinely immutable and move its credentials out of band | Backup owner | Immutability is configured in the platform's enforcing state, and the backup console can be logged into without the production identity provider | Configuration output (for example S3 Object Lock retention mode, or an Azure Backup vault in the Locked immutability state) and the out-of-band credential procedure |
| 5 | Run a real restore test using only the out-of-band credentials, and write down the measured time | Backup owner + IT lead | A defined business service is restored in an isolated environment and validated, with elapsed time recorded | Restore log, validation evidence, measured RTO, list of what failed |
| 6 | Write the IR plan: incident command roles by name, severity schema, declaration criteria, escalation, out-of-band comms, printed contact list (Chapter 13) | Security lead | A person who has never seen it can read it and know who to call and what to do first | Signed plan, printed copies distributed, contact-list test result |
| 7 | Write the first three playbooks: ransomware, business email compromise, account takeover (Chapter 14) | Security lead + platform owners | Each has entry criteria, exit criteria, pre-authorized actions, approval-gated actions and evidence requirements | The playbooks in version control, with owner and last_tested fields populated |
| 8 | Run one operational-level tabletop against one of those playbooks, with evaluation criteria written first | Exercise owner | Findings are captured in an after-action report and improvement plan, each with a named owner and a due date | AAR/IP with owners and dates; measured time-to-declare and time-to-first-decision |
Phishing-resistant MFA on privileged accounts first, everyone else second. Microsoft reports that 97% of identity attacks are password attacks, and that phishing-resistant MFA blocks over 99% of identity-based attacks even when the attacker already holds a valid username and password (Microsoft Digital Defense Report 2025). Note what CISA says plainly and what vendors often blur: number matching is a push-fatigue mitigation, not phishing-resistant MFA (CISA, phishing-resistant MFA resources). If your rollout finishes with number matching enabled and everyone feeling better, you have bought a speed bump and labeled it a wall.
KEV before CVSS. Exploitation is now the top initial breach vector in Verizon's dataset at 31%, overtaking credential abuse for the first time in nineteen years (SecurityWeek on DBIR 2026), and VulnCheck found 23.43% of newly listed KEVs showed evidence of exploitation on or before the day the CVE was published (VulnCheck 1H-2026). Roughly one in four of these vulnerabilities is being used before you could possibly have read about it. A queue sorted by severity score sorts the wrong axis.
Backups, because they are the control that pays. Sophos reports 66% of organizations with encrypted data recovered from backups, up twelve points (Sophos State of Ransomware 2026). The immutability point is specific, not general: on AWS, S3 Object Lock in compliance mode cannot be overridden by any user including the account root, while governance mode is overridable by a principal holding s3:BypassGovernanceRetention — and the S3 console sends that bypass header by default, so governance mode plus a console-capable admin is not immutability (AWS S3 Object Lock). On Azure, vault immutability has two states and the Enabled → Locked transition is one-way (Azure immutable vault). Configure the enforcing state, not the reassuring one.
One tabletop, not four. SP 800-84's rule is that evaluation criteria are written before the exercise so data collectors know what to capture, and that senior-level and operational-level teams exercise separately before they exercise together (NIST SP 800-84). One exercise run properly produces a list of defects. Four run casually produce a sense of having exercised.
Actionable takeaway: put a single date on the calendar in week five for the restore test, invite the Executive Sponsor to observe, and do not move it. A restore test with an audience is the most reliable way to find out what your recovery actually depends on.
Phase 2 bought you time. Phase 3 is where the program stops being a set of fixes and becomes a system that improves on its own.
Detection engineering (Chapter 9). Now that log coverage is known, detections can be written against telemetry that exists. Adopt the coverage triple per prioritized technique — do we have the telemetry, do we have the logic, has it fired on a validated test — and report the three separately rather than as one percentage. Document each detection with something structured; Palantir's Alerting and Detection Strategy framework requires nine sections per detection, of which Blind Spots and Assumptions, False Positives and Validation are the ones teams skip and the ones a responder needs at 03:00 (ADS framework). Start from open content rather than a blank page: SigmaHQ maintains a large body of ATT&CK-mapped rules in a portable format with converters to the major query languages (SigmaHQ).
The remaining playbooks (Chapter 14). Order them by your own inventory, not by the book's numbering. If Phase 1 found sixty SaaS integrations and no OT, write the supply-chain and identity-provider playbooks and leave the OT one for a year when it becomes true.
Third-party program (Chapter 11). Tier vendors by the access they hold rather than by spend, review OAuth grants on a monthly cycle, and get incident-notification obligations into contracts at renewal. Third-party involvement appeared in roughly 48% of breaches in the 2026 DBIR, about a 60% year-over-year increase (Help Net Security on DBIR 2026).
AI governance (Chapter 7). The inventory from Phase 1 becomes a register: owner, data touched, autonomy level, revocation path. Map to ISO/IEC 42001 or the NIST AI RMF if you need an external frame, but the register is the control.
Cryptographic inventory and post-quantum planning (Chapter 8). Start the inventory now because it is the longest-lead item you own — where RSA and ECC are used, in what protocol, with what confidentiality lifetime, and whether the algorithm is configuration or hard-coded. NCSC's timeline expects migration goals defined and a full discovery exercise complete by 2028 (NCSC), and NIST IR 8547 deprecates RSA-2048 and ECC-256 by 2030 (NIST PQC project). Put the vendor PQC question into the standard procurement template in the same 90 days — that costs nothing and stops the inventory growing while you build it.
Exercise cadence (Chapter 18). CISA's guidance is to review the plan quarterly (CISA IRP Basics). Set the annual rhythm now: quarterly plan review, at least one tabletop per quarter rotating scenarios, one functional exercise a year, and purple-team validation of the detections you rely on most. Every finding becomes an issue with an owner and a due date, or the exercise was theatre.
Metrics and the first board report (Chapter 16). Six lines, trended, with the honest ones included: internal-detection rate against the M-Trends benchmark of 52% of organizations detecting malicious activity internally; dwell time for confirmed intrusions against the global median of 14 days — 26 days when an external party notified the victim, 10 when the organization found it itself (M-Trends 2026); mean time to contain for your highest severity class only; material incidents and their business impact; named coverage gaps with owner and cost, including the ones you cannot close; and the date of the last tested restore with its measured recovery time.
That 26-versus-10-day split is the single strongest available argument for investment in internal detection, and it belongs on the slide.
Now the version that matters most, because most organizations are not running a security team. They are running one person who also does infrastructure, or nobody at all and an MSP contract.
The ranking below is by risk reduction per hour of effort, and the hours are the realistic ones — including the arguing, not just the clicking. Everything on it is free or near-free, meaning no new license, only time and possibly a small hardware spend for authenticators.
| Rank | Control | Rough effort | Why it ranks here |
|---|---|---|---|
| 1 | Phishing-resistant MFA on every administrative account, phishable methods removed | 1–2 days plus authenticator cost | Blocks over 99% of identity attacks even with a valid password in hand (Microsoft). Nothing else on this list has that ratio |
| 2 | Reduce the number of standing administrators to the smallest defensible set | 1 day | Every removed admin is an identity that can no longer be phished, vished or inherited. Costs nothing but a conversation |
| 3 | One immutable or offline backup copy, and one restore test with the time written down | 2–3 days | The control that determines whether a bad day is expensive or existential; 66% of encrypted-data cases recovered from backups (Sophos) |
| 4 | Turn on and route the logging you are already licensed for, and write down each retention figure | 1–2 days | Retention is not retroactive. The log you do not collect today is evidence you cannot buy back during an investigation (CISA/ACSC logging guidance) |
| 5 | Patch internet-facing systems against the KEV catalog on a fixed monthly slot | 4 hours/month | Targets the ~23% of KEVs exploited on or before CVE publication day at the assets that are actually reachable (VulnCheck) |
| 6 | Delete or firewall the internet-facing things nobody owns | 1 day | Attack-surface reduction is the only control that is cheaper than the alternative in both directions |
| 7 | A written help-desk verification script for password, MFA and contact-change requests | Half a day | Helpdesk impersonation is a documented primary technique of the most active intrusion set, with vishing at 11% of investigated initial vectors (CISA AA23-320A; M-Trends 2026) |
| 8 | Restrict end-user OAuth consent to a review step | 2 hours | A consented app survives a password reset — resetting credentials "aren't effective" against consented external apps (Microsoft) |
| 9 | A one-page IR plan: who declares, who is Incident Commander, three phone numbers, an out-of-band channel — printed | Half a day | The failure it prevents is the one where the first hour is spent deciding who is in charge |
| 10 | One free tabletop from a published package | Half a day | CISA's Tabletop Exercise Packages and NCSC's Exercise in a Box are free and complete (CISA CTEP; NCSC) |
| 11 | Adopt open detection content instead of writing rules from scratch | 1–2 days | SigmaHQ's rule base plus a converter gets a small team to useful coverage far faster than authoring (SigmaHQ) |
| 12 | Adopt CIS Implementation Group 1 as your written standard | 1 day to map | IG1 is 56 safeguards defined as essential cyber hygiene, and it is a defensible answer to "what framework are you following?" (CIS) |
Two honest notes about this list.
It is not a smaller version of the enterprise plan; it is a different plan. The enterprise plan optimises for coverage and provability. This one optimises for the number of realistic attacks it makes fail. Ranks 1 through 5 alone put a small organization ahead of a meaningful share of larger ones — the DBIR remediation figures are not a small-business phenomenon.
For the team of none, the first move is not technical. It is naming a person — any competent person, in IT or operations — as the accountable owner, and buying them protected time on a recurring calendar. Half a day a week, defended, produces this list in a quarter. Zero defended time produces nothing, regardless of headcount or spend. If the work sits with an MSP, then the first two hours go into reading the contract to find out which of these twelve items they are actually obliged to do, because the answer is usually fewer than everyone assumes.
Actionable takeaway: if you do exactly one thing from this chapter, do rank 1 and rank 3. Administrative MFA and a tested restore. Today. Not after the budget cycle.
Rafeeq Rehman's CISO MindMap places tool consolidation in three separate places — budget, governance, and M&A integration — which Chapter 3 unpacks (rafeeqrehman.com). Here is how you actually run it, and when.
When: in Phase 3, not Phase 1. You cannot judge overlap until you know which controls you have and which telemetry you depend on. But build the tool list itself in Phase 1 — it is one more inventory, it takes an hour, and it is usually the first time anyone has seen the whole estate on one page. And start the audit at least ninety days before your largest renewal, because a rationalization decision you cannot execute until next year is an opinion.
How: one row per tool, six questions, no debate until the table is full.
| # | The question | What a bad answer looks like |
|---|---|---|
| 1 | What control or detection does this uniquely deliver that nothing else in the estate delivers? | A capability list rather than a unique one. If you cannot name the uniqueness, it is overlap |
| 2 | Who is the named owner, and when did they last change its configuration? | No owner, or a configuration untouched since deployment. A tool nobody tunes is a tool nobody trusts |
| 3 | When did someone last take an action because of its output? | Nothing in ninety days. That is a subscription, not a control |
| 4 | What is the all-in annual cost — license, engineer-days to run it, triage hours for the alerts it generates, integration work at each upgrade? | The license figure alone. The license is usually the smaller half |
| 5 | What breaks if it is switched off on Friday, and who notices? | "Nothing immediately" — which is your answer, and "we're not sure" — which is a dependency-mapping task, not a reason to keep it |
| 6 | Is it in the incident path? Would a responder open it at 03:00, and does it hold evidence with retention you depend on? | A tool nobody would open during an incident but everybody defends during a renewal |
Question 6 is the one that saves you from an expensive mistake. A product whose dashboards nobody loves may still be the only place a particular log class is retained. Before you cancel anything, export what it holds and re-point the ingest. Cancelling first and discovering the gap during an investigation is a self-inflicted evidence problem, and evidence problems are not recoverable after the fact.
Then apply four decision rules, in this order:
Chapter 3 makes the concentration-risk argument against collapsing everything into one vendor's suite, and it holds here: rationalize on demonstrated overlap, not on logo count.
Actionable takeaway: cancel one tool this quarter, and pre-allocate the freed budget to a control from your Phase 1 gap list before the saving reaches finance. Savings that reach finance unallocated do not come back.
Chapter 3 argues that team care is a control rather than a sentiment. This section is the roadmap version: what this plan costs in human terms, and how to spend it without producing the outcome where the program succeeds and the people who built it leave.
Be honest about the load. Phase 1 is largely one person's sustained attention for a month plus a few hours each from platform owners; the discovery work is not hard, but it is relentless and it is nobody's favourite. Phase 2 needs a named owner with genuinely protected time, because MFA rollouts and restore tests generate friction with other teams and friction is resolved by presence, not by tickets. Phase 3 is the first phase that can be spread across several people, because by then there are artefacts to hand over. Anyone who tells you all three phases fit into the margins of an existing full-time job has not run them.
Design on-call for the fatigue that is coming, not for the quiet weeks. Sleep-deprived people remain reasonably competent at well-practiced, rule-based tasks; what degrades is handling the unexpected, revising plans, filtering distraction, and communicating clearly (Harrison & Horne, 2000). That is an exact description of what a novel incident demands. Three design rules follow, and all three are free: rotate Incident Commander duty on a published schedule rather than on exhaustion; name a deputy for every authority so no decision waits for one person's phone; and script the handover so the departing shift's mental model transfers rather than evaporating.
Cap detection deployment by triage capacity. High alert volumes with very high false-positive rates desensitize analysts, degrading detection effectiveness and driving turnover (Tariq et al., ACM Computing Surveys 57(9), 2025). If a detection cannot be triaged by the people you actually have, deploying it makes the program measurably worse while making the coverage chart look better. Treat every false activation as a defect logged against the detection, not as noise the analyst absorbs.
Plan the long tail. NCSC observes that incidents "often start with an intense period of activity, but many also have a 'long tail' with the impact lasting for months," and publishes the only government guidance dedicated to responder welfare — including the recommendation to build a culture where staff feel safe saying they are overwhelmed (NCSC). The British Library's own review is more direct still: incident plans should include provisions for staff and user wellbeing, because attacks are deeply upsetting for the people whose data and work they disrupt — and the same review records a technology department already overstretched with staff shortages before the incident (British Library). The pre-incident staffing deficit became the recovery constraint. Understaffing is not a morale issue that surfaces during an incident; it is a recovery-time issue that was decided months earlier.
Run reviews so people tell you the truth. Post-incident review is where the program either learns or ossifies, and it only learns where people can speak. The current practitioner standard is blame-aware rather than merely blameless — acknowledging that everyone works under constraints that often only become visible after the fact — with a calibration document circulated before the meeting so nobody is surprised in the room (Howie guide).
Actionable takeaway: put on-call hours per person per month on the same dashboard as your technical metrics, starting with the first board report. A trend line is an argument that survives a budget meeting. "The team is tired" is not.
The metrics that prove a security program works — dwell time, internal detection rate, incident count — are lagging by construction. They move over years and they are averages over events you hope are rare. If those are your only measures, you will spend eighteen months unable to tell improvement from luck.
So report both, and understand the difference: leading indicators tell you whether the machine is running; lagging indicators tell you whether it worked.
| Leading — moves in weeks, tells you the program is functioning | Lagging — moves in quarters or years, tells you it worked |
|---|---|
| Percentage of privileged accounts on phishing-resistant MFA, with phishable methods removed | Median dwell time for confirmed intrusions |
| Count of assets and identities with no named owner (target: zero, and the trend matters more than the number) | Internal-detection rate: incidents you found versus incidents you were told about |
| Days from KEV listing to remediation on internet-facing assets, as a trend | Mean time to contain for your highest severity class |
| Log sources that stopped reporting, and how many days it took to notice | Number of material incidents and their business impact |
| Date of the last tested restore, and the measured recovery time | Audit and assessment findings, repeat findings especially |
Percentage of playbooks with a last_tested date inside twelve months | Insurance and third-party assessment outcomes |
| After-action findings closed by their due date | |
| Detections with a successful validation run in the last ninety days | |
| Help-desk verification test-call pass rate | |
| On-call hours per person, and weeks with unplanned out-of-hours work |
Three interpretation rules keep this honest.
A leading indicator that is not moving in the first ninety days is telling you the truth. It is not too early. Ownership counts and MFA coverage move within weeks when the work is happening, and do not move at all when it is not.
Some numbers can improve while security gets worse. Mean time to respond is the classic offender — it improves when you close alerts faster, which also happens when you close them wrongly. Detection coverage percentages are the second offender, for the same reason: a mapped technique is not a validated detection. Report those with context on the operational dashboard, not alone on the board slide.
Watch for the pair that moves together. A falling internal-detection rate alongside a falling mean time to detect means you are getting faster at the subset you can see while missing more of what you cannot. That combination is the clearest early signal that a program is quietly going backwards, and it is invisible if you look at either number by itself.
Actionable takeaway: pick five leading indicators today, baseline them this week, and report the same five every month for six months without changing the definitions. Changing a metric's definition mid-year is the most common way a program loses the ability to tell whether it improved.
Here is what I want you to take from twenty chapters and a calendar.
Almost nothing in this book is exotic. The controls that decide whether a bad day is survivable are the same ones that have decided it for a decade: know what you have, control who is privileged, keep logs long enough to answer questions, be able to restore, and have a plan with names on it. What has changed is the tempo. The median hand-off between an initial-access broker and the group that does the damage is 22 seconds, down from more than eight hours in 2022 (M-Trends 2026). There is no longer a comfortable gap between "someone got a credential" and "someone is inside doing harm." That is what makes the ordering in this chapter matter: the work has not changed, but the margin for doing it in the wrong order has gone.
And be suspicious of the pull toward the interesting problem. Every one of us would rather build a detection pipeline than reconcile a DNS export against a cloud inventory, and every published post-incident report keeps landing on the same unglamorous seam — an out-of-date distribution list, a portal that policy said had MFA and didn't, a supplier endpoint outside the standard, a certificate that quietly expired. Nobody gets to present the DNS reconciliation at a conference. It still outranks the detection pipeline, because you cannot detect your way out of not knowing what you own.
You do not need the whole 180 days to begin. You need one afternoon. Check whether your backups restore, and check who holds administrative privilege. Both are free. Both are almost certainly worse than you think. And both are answerable before you go home.
Then put a date next to the second thing. Not a quarter. Not a roadmap slot. A date.
Stay curious, stay sequenced, and remember that the most dangerous system on your network is the one nobody has thought about since the day it was installed.
[IG1] [GV.RR][IG1] [ID.AM] [CIS 1] [CIS 2][IG1] [GV.RM][IG1] [ID.AM] [CIS 1][IG1] [DE.CM] [CIS 8] [A.8.15][IG1] [PR.AA] [CIS 6][IG1] [PR.AA] [CIS 6][IG1] [ID.RA] [CIS 7][IG1] [PR.DS] [CIS 11][IG1] [RC.RP] [CIS 11] [A.5.30][IG1] [RS.MA] [CIS 17] [A.5.24][IG1] [RS.MA] [CIS 17][IG1] [ID.IM-02] [CIS 17] [A.5.24][IG1] [ID.IM] [A.5.27][IG1] [RS.MI] [GV.RR][IG2] [DE.CM] [ID.IM][IG2] [GV.RM] [ID.AM][IG2] [DE.CM] [CIS 8][IG1] [GV.RR] [RS.MA][IG2] [RS.MA][IG2] [GV.OV] [GV.RR][IG2] [ID.IM-03] [A.5.27][IG2] [GV.OV] [ID.IM][IG2] [GV.OV] [RC.RP][IG1] [GV.RR] [GV.PO][IG2] [ID.AM][IG2] [GV.SC]