Case Study 1: Meridian Goes to the Board

"I have nine days, thirty-seven documents, and one decision to ask for. The work was building it. The job is making them see it." — Dana Okafor, CISO, Meridian Regional Bank (constructed)

Executive Summary

This case study follows CISO Dana Okafor and her team through the nine days before the most consequential meeting of Meridian's security program: the presentation to the board's Audit Committee that will fund — or starve — the next two years of work. It is the payoff of the entire book. Every component the team assembles was built in an earlier chapter's Project Checkpoint; here, we watch those components become a program, the program become a roadmap and a business case, and the case become a board deck and a decision. You will see the difference between having good security and being able to defend it, and you will see Meridian complete its arc from the reactive posture of Chapter 1 — one hardware key standing between a near-miss and disaster — to a managed, risk-driven, funded program. All figures and the scenario are constructed for teaching (Tier 3); the shape of every decision is exactly what a real CISO faces.

Skills applied: program assembly under the CSF functions; risk × cost roadmap prioritization; ALE-based business case construction (🔗 Chapter 27); board-deck structuring and executive translation (🔗 Chapter 36); residual-risk honesty; reconciling the SOC, Engineer, and GRC views; integrating the bluekit toolkit into a single program view.

Background

Eighteen months ago, a phishing email nearly compromised Meridian Regional Bank, and failed only because a loan officer was holding a FIDO2 hardware key the fake portal could not trick her into bypassing (🔗 Chapter 1). Dana used that near-miss — a real incident that cost nothing and proved everything — to win support for a security-program maturation initiative. Since then, chapter by chapter, the team has built: a risk register and asset inventory; a threat model; a control framework; cryptographic standards; a segmented network with perimeter controls; wireless, DNS, and email defenses; host-hardening baselines; a secure SDLC and web-app controls; mobile/IoT and cloud baselines; the full identity stack from authentication through privileged access and machine identity; a SIEM and detection program; an IR plan tested in a ransomware tabletop; forensics readiness; a governance structure and policy set; an enterprise risk assessment with a risk-appetite statement; compliance mappings; third-party risk management; a security awareness program; a secure pipeline; a zero-trust roadmap; OT/facilities segmentation; a UEBA pilot; an emerging-threat watch; a metrics pack; and an org and SOC operating model.

It is, by any measure, a lot of excellent work. And nine days before the board meeting, it is also a problem, because it lives as thirty-seven separate documents and no single story. Dana's challenge is the chapter's challenge: turn the components into a program the board can fund. She gives the team one week and one rule, the same rule she gave at the very first risk assessment: "Be honest. A confident-nonsense program loses the room the moment a director asks one real question. A true, modest one survives."

The Work

Day 1–2 — Assembling the program (Milestone 1)

Elena Vasquez, the GRC analyst, owns the assembly, because the GRC seat sees the whole. Her first move is not to summarize thirty-seven documents — it is to choose a structure the board can hold in mind. She picks the six NIST CSF 2.0 functions, because the bank's controls are already mapped to the framework (🔗 Chapter 28) and because examiners and auditors read the same map. Then she places every component under the function it serves, producing the program-on-a-page.

   MERIDIAN SECURITY PROGRAM — ON A PAGE (for the board)
   ===========================================================================
   GOVERN     governance + policies (Ch.26) · risk assessment + appetite (Ch.27)
              compliance map: GLBA/PCI/SOX/FFIEC (Ch.28) · TPRM/SBOM (Ch.29)
              metrics pack (Ch.36) · org/SOC model (Ch.37)
   IDENTIFY   asset inventory + risk register (Ch.1) · threat model (Ch.2)
              control framework (Ch.3) · vuln-mgmt + SLAs (Ch.23)
   PROTECT    crypto/data (Ch.4-5) · network + segmentation (Ch.6-7)
              wireless/DNS/email (Ch.8-9) · hardening (Ch.11) · appsec (Ch.12-13)
              mobile/IoT (Ch.14) · cloud (Ch.15) · identity stack (Ch.16-20)
              pipeline + zero-trust roadmap (Ch.31-32) · OT (Ch.33) · awareness (Ch.30)
   DETECT     network monitoring (Ch.10) · SIEM + detection (Ch.21-22) · UEBA (Ch.34)
   RESPOND    IR plan + playbooks + tabletop (Ch.24)
   RECOVER    forensics readiness (Ch.25) · backup/restore + lessons learned (Ch.24-25)
   CROSS-CUT  emerging-threat watch + crypto-agility (Ch.35)
   ===========================================================================

🔗 Connection: Notice Elena did not re-derive a single control — every one was designed and defended in its chapter. Assembly is placement and connection, not redesign. The value she adds is coherence: a board member can now see, on one page, that the program is complete across all six functions, and a gap in any function would be visible as a thin row. This is the §38.2 lesson in practice — a program is the coherence among components, not the components.

There is a second decision in the assembly that beginners miss, and Elena makes it deliberately: what to leave out of the board version. The full program document runs to roughly forty pages — every standard, every owner, every status, every risk it addresses, drawn from thirty-seven Project Checkpoints. The board will never read forty pages. So Elena builds the program in two registers at once: the complete document (which lives in the appendix and answers any examiner who wants to go deep) and the program-on-a- page (which is what the board sees). The skill is deciding what rises to the page. Her rule: the page shows the structure and completeness — that all six functions are populated and nothing is missing — while the depth waits in the appendix for anyone who asks. A board member's confidence comes from seeing the shape of a complete program, not from reading its forty pages; a director who wants the forty pages can have them, but offering them unbidden buries the signal.

Theo Brandt, now eighteen months into the job, audits the assembled program for balance using the Chapter 3 control taxonomy. He counts roughly twice as many preventive controls as detective ones and flags it: "We're strong on walls, lighter on watchtowers." Dana keeps the note — it will shape the roadmap (the Detect investments in Phase 2) and it is exactly the kind of honest self-assessment that plays well with a board, because it shows the team grading its own work. He also runs a second check that turns out to matter in the boardroom nine days later: for each of the five top risks on the register, he traces the chain of controls that addresses it, confirming every risk maps to something built and every major build maps to a risk. One risk — after-hours detection latency — traces to a control that is only partly built, which becomes the honest gap on slide 4. The traceability audit is not busywork; it is how the team guarantees that when a director asks "and what protects us from that?", the answer is never a blank look.

⚠️ Common Pitfall: Confusing the complete program document with the board presentation. They are different artifacts for different audiences, and trying to make one serve both produces a deck too deep for the board and a document too shallow for the examiner. Elena builds both from the same assembled material — the page is a view of the document, not a replacement for it. The most common failure mode is presenting the forty-page document to the board (who tune out) or presenting only the one-pager to the examiner (who needs the evidence). Build once, present twice, at the right depth for each.

Day 3–4 — Prioritizing the roadmap (Milestone 2)

Sam Whitfield, the engineer, and Elena now turn the program (a destination) into a roadmap (a journey). They list every initiative still outstanding, estimate the annualized risk each removes and its cost, and compute the risk-reduction-per-cost ratio — the "bang for the buck" that prevents the classic failure of spending the whole budget on one slow megaproject.

A disagreement surfaces, and it is the right disagreement — the one the chapter says is the leadership work. Sam, in the Engineer seat, wants to sequence by dependency: "Segmentation has to come before zero trust, full stop." Elena, in the GRC seat, wants to sequence by risk-per-cost: "MFA and the access cleanup first — best ratio, no dependencies." Marcus Reyes, the SOC manager, argues from the detection gap Theo found: "We're blind after hours; 24×7 should be sooner." Dana reconciles them, and the reconciliation is the roadmap:

   PHASE 1 "Stop the bleeding"  (Q1-Q2, ~$0.5M) — GRC view leads: ratio + no deps
     MFA bank-wide · access reviews/disable orphaned · email auth · KEV-backlog patch
   PHASE 2 "Walls & watchtower"  (Q3-Q4, ~$1.2M) — Engineer + SOC views
     CDE segmentation (PCI) · SIEM to 24x7-ready + coverage · PAM · IR re-test
   PHASE 3 "Mature & modernize"  (Y2, ~$4.0M) — deps now satisfied
     24x7 SOC (build vs MDR) · zero-trust phase 1 · UEBA to production · PQC inventory

Each item maps to a risk-register row, so when the board asks "why this?", the answer is always a risk. Marcus's detection concern is honored — 24×7 readiness work begins in Phase 2 even though full coverage is Phase 3, because the SIEM maturity it depends on lands in Phase 2. Sam's dependency holds — zero trust waits for its foundations. Elena's ratio leads Phase 1. Nobody "won"; the program did.

The reconciliation deserves a closer look, because it is the part of the job no certification teaches. Sam's dependency argument is not negotiable in the way the others are — it is a physical constraint. You cannot operate a zero-trust policy engine that makes per-request access decisions (🔗 Chapter 32) if the identity stack it queries is incomplete and the network it segments is still flat; the migration would have nothing to stand on. So Sam's constraint sets the outer bound of the schedule: zero trust cannot precede its prerequisites, full stop. Within that bound, Elena's risk-per-cost ranking decides order, and Marcus's detection gap decides emphasis — which Phase 2 items get resourced first. Dana's insight is that these are not three competing priorities to be averaged; they are three different kinds of constraint — a hard dependency, an efficiency ranking, and an operational-risk emphasis — that compose into a single schedule when you stop treating them as rivals. A weaker CISO would have picked the loudest voice or split the difference; Dana sequenced so that each constraint governs the decision it is actually about.

🔄 Check Your Understanding: Marcus argued the after-hours detection gap should pull 24×7 SOC coverage earlier. Dana kept full coverage in Phase 3 but moved readiness work into Phase 2. What distinction is she drawing, and why is it more honest than either "do it now" or "do it last"? (Hint: consider what 24×7 coverage depends on, and what partial progress in Phase 2 actually buys.)

🛡️ Defender's Lens: This is what reconciling the three capstone tracks looks like in a real team. The SOC's coverage map, the Engineer's dependency graph, and the GRC's risk-and-cost ranking each wanted a different Phase 1, and each was correct from its seat. A roadmap that ignored any of the three would have a real flaw: skip the dependency and zero trust collapses; skip the ratio and the budget burns on slow work; skip the detection gap and the bank stays blind after hours. The CISO's job is not to pick a winner but to find the sequence that respects all three.

Day 5–6 — Building the business case (Milestone 3)

Now the part that decides everything: translating the roadmap into the board's language. Elena builds the four-part case (§38.4), and she insists every number be traceable, because Dana will be challenged on them in the room.

Part 1 — the cost of doing nothing. Using Chapter 27's ALE method (SLE × ARO), the team computes the annualized expected loss of the top three untreated risks:

That ~$6M is the cost of doing nothing — the number the entire case hangs from, and not a scare figure: it is SLE × ARO on three named register rows, each input listed so a skeptical director can challenge it.

Part 2 — the investment and the risk it buys down. The Phase 1–2 investment of ~$1.7M is projected to reduce that annualized risk to ~$0.9M. Stated as the board hears it: *we propose spending $1.7M to remove ~$5.1M of annual expected loss, taking residual annualized risk from ~$6M to ~$0.9M.*

Part 3 — the obligations. CDE segmentation is not optional — it is a PCI-DSS requirement (🔗 Chapter 28), and FFIEC/OCC expectations cover much of the rest. Elena frames the compliance-driven portions as the floor the bank is legally required to stand on, separate from the risk-return argument. This moves part of the budget from "discretionary" to "mandatory."

Part 4 — the alternatives and the ask. Three options: do nothing (accept ~$6M annual risk plus exam exposure — not viable for a regulated bank); do the compliance minimum only (cheaper, leaves large risk untreated); fund the risk-driven roadmap (the recommendation). The ask is specific: approve $1.7M for Phases 1–2 now; Phase 3 returns for decision after Phase 2 results are measured in Q4.

Theo runs the numbers through the bluekit capstone to sanity-check the story the deck will tell:

from program_dashboard import program_dashboard

meridian = {
    "risks": [{"id": "R1", "score": 20}, {"id": "R2", "score": 15},
              {"id": "R3", "score": 9},  {"id": "R4", "score": 6}],
    "ale_now": 6_000_000.0, "ale_target": 900_000.0,
    "coverage": 0.72, "mttd_h": 4.0, "mttr_h": 12.0,
    "appetite": 1_000_000.0,
}
print(program_dashboard(meridian))

# Expected output:
# MERIDIAN SECURITY PROGRAM — DASHBOARD
#   Risks: 4 tracked, 2 CRITICAL
#   Annualized risk: $6.0M -> $0.9M  (burning down $5.1M)
#   Detection coverage: 72%  |  MTTD 4h  MTTR 12h
#   Residual vs appetite: within appetite

The dashboard confirms the case's spine in one screen: $6M burning down to $0.9M, and crucially, $0.9M is below the $1.0M appetite the board itself set. That single fact — residual risk within the board's own appetite — is the most powerful sentence in the deck, because it lets the board own the decision rather than merely approve a request.

⚖️ Authorization & Ethics: During Day 5, a well-meaning finance liaison suggests rounding the $6M up to "about $10M — it photographs better." Dana refuses flatly, and her reasoning is the chapter's ethics note: an inflated number wins one cycle and loses all credibility the first time reality fails to match the fear, after which every future ask is discounted to nothing. Credibility is the only durable currency a CISO has. The honest case — defensible numbers, stated assumptions, an owned residual — is also the effective case over any horizon longer than one meeting.

Day 7 — Building the deck (Milestone 4)

Dana writes the deck herself, because the board presentation is the one artifact she cannot delegate. She follows the stable structure (Figure 38.3), and she enforces one rule on every slide: if it does not answer "are we exposed, are we competent, are we compliant, or what do you need," it goes in the appendix.

• Slide 1 — The ask. "We request approval of $1.7M for Phases 1–2 to reduce annual cyber risk from ~$6M to within our $1M appetite." The board reads it first and judges everything against it.
• Slide 2 — The risk story. The top three risks in dollars and plain language; the $6M cost of doing nothing.
• Slide 3 — What we've built. The program-on-a-page, framed as "the maturity journey since the near-miss." Confidence-building, one slide.
• Slide 4 — What's left. Honest. Two risks still above appetite (after-hours detection blindness; incomplete privileged-access controls) and the plan to close them. Dana spends real time here on purpose.
• Slide 5 — The roadmap. Three phases, costs, risk burned down per phase.
• Slide 6 — The business case. $1.7M removes $5.1M; residual ~$0.9M within appetite; PCI/FFIEC obligations called out.
• Slide 7 — Are we improving. Four trending KRIs: MTTD, MTTR, detection coverage, risk burndown (🔗 Chapter 36). Operational SOC metrics — alert volumes, tuning rates — are deliberately absent.
• Slide 8 — The decision. Slide 1 again, as a motion to approve.

The detailed control list, the framework crosswalk, the incident history, and the full assumptions log go into an appendix she will have but not show — ready for any director who wants to go deep, invisible to the ones who do not.

Day 9 — The boardroom

The meeting runs twenty-five minutes. Dana opens with the ask, not the build-up, and a director visibly relaxes — she knows where this is going. The risk story lands because it is in dollars. On slide 4, a skeptical director (a retired bank examiner) leans forward when Dana names the after-hours detection gap: "You're telling us your weaknesses." "I am," Dana says. "You'd find them anyway, and you should trust a program that finds them first." He nods; the room's posture shifts from interrogation to deliberation.

The pressure comes, as it always does, on cost. "$1.7M is a lot of money." Dana's answer is the chapter distilled: "It is. It removes $5.1M of annual expected loss and brings our residual risk to $0.9M — below the $1M appetite this committee set last year. Doing nothing keeps us at $6M and exposed on the PCI exam. I'm asking you to approve the $1.7M for Phases 1 and 2; I'll bring Phase 3 back once you've seen Phase 2's results." The examiner asks where the $6M comes from; Dana shows the SLE × ARO table; he is satisfied.

A second director, the committee's finance chair, presses on a different axis: "How do we know this $1.7M actually buys what you say? Security spending feels like a black hole." It is the fairest question in the room and the one the metrics slide exists to answer. Dana turns to slide 7: "We don't ask you to take it on faith. These four indicators — time to detect, time to respond, detection coverage, and risk burned down — are how you'll watch the money work. They're trending the right way already; if Phase 2 doesn't move them, you'll see it before you approve Phase 3. That's the contingency I built into the ask." The finance chair nods slowly; she has just been handed the thing finance people want most, which is not a promise but a measurement — a way to verify the return rather than trust it. This is the §38.5 lesson that operational metrics belong in the SOC and executive metrics belong in the boardroom: the four KRIs are not there to impress, they are there to let the board hold the program accountable in their own units.

The vote is not unanimous in enthusiasm — one director would have preferred to fund only the PCI-mandated segmentation and defer the rest — but the structure of the ask makes even the skeptic's preferred path part of the proposal rather than an alternative to it: the compliance floor is funded in Phase 2 regardless, and Phase 3 is already deferred for a later decision. There is, in the end, nothing left to defer, because Dana deferred the deferrable parts herself. The committee approves $1.7M for Phases 1–2 and asks for a Phase 2 results review in Q4.

Walking out, Theo asks Dana what made the difference, given that the program had been done for days. "The program was the easy part," she says. "Nine days ago we had thirty-seven documents. Today they're one decision a board could own. That translation — that's the job." She pauses at the elevator. "Remember the phishing email, your third week? One hardware key stood between us and a very bad year. Today we have seven layers behind that key, a SOC that would catch what the key missed, a plan for the morning after, and a board that funded all of it on purpose instead of after a disaster. That's what a program is. The key was luck made permanent. This is the permanence."

📟 War Story: A constructed contrast Dana keeps in mind. A CISO at a peer bank presented a comparable program the same quarter — twenty slides of architecture and threat feeds, no dollar figure for the risk, closing with "we'd like to increase the security budget." The board "took it under advisement" and funded a fraction, late. The programs were of similar quality. The translation was not. The best security program in the world is unfunded if its leader cannot tell its story in the board's language.

Discussion Questions

1. Elena chose the CSF functions as the program's structure rather than, say, listing controls by team or by purchase date. What did that structural choice buy, and who besides the board benefits from it?
2. Three team members wanted three different Phase 1s, each correct from their seat. Was Dana's reconciliation the right one, or can you defend a different Phase 1? What would you trade off?
3. Dana spent real time on slide 4 (the gaps) on purpose. Argue both sides: when, if ever, could emphasizing weaknesses to a board backfire, and how would you mitigate that risk?
4. The residual risk ($0.9M) landing just below the appetite ($1.0M) was "the most powerful sentence in the deck." Why is within the board's own appetite so much stronger than a large risk reduction?
5. The finance liaison's suggestion to inflate the $6M was refused on both ethical and strategic grounds. Separate the two arguments: which would still hold if inflating the number carried no risk of being caught?

Your Turn

Take an organization you know (your employer, school, or a constructed small business) and run the nine-day sprint in miniature, one page per milestone. (1) Assemble a program-on-a-page under the six CSF functions — even a small org has something under each. (2) List four to six roadmap candidates, estimate risk-reduced and cost, compute the ratios, and phase them, justifying any override. (3) Build a four-part business case with at least one ALE computed from a stated SLE and ARO, ending in one specific ask. (4) Outline an eight-slide board (or "leadership") deck that leads with the ask and owns one real gap. If you cannot make a number traceable, that is the signal to go find the input — exactly as Dana required.

Key Takeaways

• Assembly is placement and connection, not redesign. Every component was built earlier; the value of assembly is coherence — placing each under the CSF function it serves so the whole is legible and any gap is visible.
• Reconciling the three views is the leadership work. The SOC (detection gap), Engineer (dependencies), and GRC (risk-per-cost) each correctly want a different Phase 1; the roadmap is the sequence that respects all three, not a winner among them.
• The business case runs on traceable ALE, not fear. The "cost of doing nothing" is SLE × ARO on named register rows, every input defensible — because a confident-nonsense number loses the room and an honest one survives it.
• Residual within the board's own appetite is the strongest sentence in the deck. It lets the board own the decision rather than merely approve a request.
• Owning the gaps builds confidence. A program presented as flawless signals concealment; naming the weaknesses plainly proves clear sight — especially to an examiner on the board.
• The translation is the job. The program was done days early; the work that won the budget was turning thirty-seven documents into one decision a board could own. That is Meridian's arc from Chapter 1 complete: from one control between a near-miss and disaster to a managed, funded, defensible program.