Case Study 2: The Budget That Got Away
"We had the better security and we lost the room. I spent two years learning that those are different skills." — Ravi Desai, CISO, Northwind Health Systems (constructed)
Executive Summary
Case Study 1 showed a board presentation that won. This one shows one that lost — and then, a year later, one that won, at a different kind of organization, run by a CISO who had to learn the chapter's lessons the hard way. Northwind Health Systems is a regional hospital network, not a bank; its crown jewels are patient safety and protected health information, not cardholder data, and its regulator is HIPAA rather than PCI. The security program Ravi Desai built was, by technical measures, better than the one the board had funded the year before. He still walked out of his first board meeting with a fraction of what he asked for, a stalled roadmap, and — eleven months later — a ransomware incident that hit exactly the gap the unfunded work would have closed. This case is a teaching autopsy: we diagnose precisely how a strong program failed to get funded, map each failure to the chapter's rubric, and then watch Ravi's second attempt succeed. The contrast with Meridian is the point — same skills, different sector, and a vivid picture of the negative space around §38.4 and §38.5. All figures and the scenario are constructed for teaching (Tier 3).
Skills applied (by their absence, then their presence): business-case framing (🔗 Chapter 27 ALE); risk-story vs. status-report communication (🔗 Chapter 36); leading with the ask; owning gaps; quantifying in the board's units; the cost of a stalled roadmap; the difference between having security and defending it.
Background
Northwind Health Systems runs four hospitals and roughly thirty clinics across a single state. Like most healthcare organizations, it is a target-rich environment: a sprawling fleet of medical devices that cannot be patched on a normal cycle (🔗 the OT/IoT realities of Chapters 14 and 33), a workforce of clinicians who — rightly — prioritize patient care over security friction, and a regulatory obligation under HIPAA to protect electronic protected health information (ePHI). When Ravi Desai arrived as Northwind's first true CISO, he inherited a program that was mostly compliance theater: a binder that passed audits and a network that would not survive a determined attacker.
The healthcare context matters because it changes the shape of every artifact in this book's capstone. At Meridian, a bank, the crown jewels are cardholder data and account integrity, and impact is measured in dollars, fines, and reputation. At Northwind, the crown jewel is patient safety, and the worst-case impact is not a data-breach headline but a hospital that cannot deliver care — diverted ambulances, an emergency department reverting to paper, surgeries postponed because the imaging systems are encrypted. The device fleet is the heart of the problem: infusion pumps, imaging systems, monitors, and lab analyzers that run unpatchable embedded software, often cannot tolerate active scanning, and frequently sit on the same flat network as clinical workstations. They are simultaneously the highest-impact assets (they touch patients directly) and the hardest to protect by conventional means (you cannot simply patch or reimage a CT scanner). This is exactly the OT/IoT bind from Chapters 14 and 33, and it is why Ravi correctly identified device-fleet segmentation and monitoring as the program's single most important initiative. He had the analysis right. What he got wrong was everything about turning that analysis into a funded decision.
Ravi was a strong engineer and a careful risk manager. Over his first year he built genuinely good security: network segmentation between clinical and corporate zones, phishing-resistant MFA for administrators, a real SIEM with detection content, an IR plan, and — the centerpiece — a multi-year plan to segment and monitor the unpatched medical-device fleet, the organization's single largest unmanaged risk. By the technical rubric of this entire book, his target program was excellent and his roadmap was sound. Then he went to the board to fund it, and everything that could go wrong in a presentation did.
It is worth dwelling on why a person this capable failed this badly at the presentation, because the reason is structural, not personal, and it will be your reason too if you are not careful. Ravi had spent fifteen years being rewarded for technical depth — for knowing more, explaining more thoroughly, showing his work. Every promotion, every peer's respect, every successful project had reinforced the instinct that more detail equals more credibility. That instinct is correct almost everywhere in a security career — with one catastrophic exception: the boardroom, where the relationship inverts. To a board, detail beyond the decision is not evidence of competence; it is evidence that the presenter cannot distinguish what matters from what does not. The very habit that made Ravi excellent at his job made him terrible in that room. He was not unprepared; he was over-prepared in the wrong dimension, bringing an engineer's depth to an audience that needed a leader's altitude.
The First Presentation — A Teaching Autopsy
Ravi's deck had forty-one slides. Here is how it failed, mapped to the §38.7 rubric and the §38.5 principles.
Failure 1 — He buried the ask (audience fit)
The deck opened with Northwind's threat landscape, then moved through the architecture, the SIEM detection content, the device-fleet analysis, and arrived — on slide 38 — at "and so we are requesting an increase in the security budget." The board spent thirty-seven slides not knowing what decision they were being asked to make, and a board that does not know the ask cannot evaluate anything against it. By the time the number appeared, two directors were on their phones.
⚠️ Common Pitfall: Narrating chronologically and arriving at the point. Engineers build up to a conclusion; boards read the conclusion first and spend the meeting deciding whether they believe it. Ravi's instinct — "let me give them the context so the ask makes sense" — is exactly backwards for this audience. Lead with the ask, then earn it.
Failure 2 — He gave a status report, not a risk story (business framing)
Slide after slide listed activities: "deployed segmentation across three zones," "authored 60 SIEM detections," "completed device inventory: 14,200 devices." All true, all impressive to a security person, all answering a question no board member asked. Nowhere did Ravi say what the unmanaged risk cost the organization in terms a board weighs. He never put a dollar figure on the device-fleet exposure. The board heard a competent team doing a lot of work and could not connect any of it to a business decision.
🛡️ Defender's Lens: A board remembers a narrative of risk — "here is what could hurt patients and the organization, here is what we've done, here is the gap and what closing it costs" — far better than a list of completed tasks. Ravi had a devastating risk story available: an unpatched, unsegmented medical-device fleet is exactly the entry point ransomware uses against hospitals, and a ransomware outage in a hospital is a patient-safety event, not just a data event. He told a project-status story instead, and the most compelling argument in the room went unspoken.
The deeper failure beneath the activity list is that Ravi never translated the device-fleet risk into a number the board could weigh. In a hospital, "impact" is not primarily dollars — it is diverted ambulances, postponed surgeries, and patient harm — and there was a defensible way to express that exposure as annualized risk (an event likelihood drawn from the rate of healthcare ransomware, multiplied by an impact that includes both recovery cost and the operational/clinical toll). Had he put even a rough, clearly-labeled "annualized expected loss of the device-fleet gap" on a slide, the board would have had something to decide about. Instead he gave them a device count — 14,200 — which sounds like progress ("we inventoried everything") rather than exposure ("14,200 unmonitored ways in"). The same fact, framed as accomplishment instead of risk, argued against his own ask.
Failure 3 — He presented a flawless program (honesty)
Ravi, wanting to project competence, presented the program as comprehensive and the team as on top of everything. There was no "here is what we cannot yet do" slide. To the one director with security experience, this read as either naïveté or concealment — because she knew no program is gapless — and it quietly discredited the rest. The single most important risk (the device fleet) was framed as "a planned initiative" rather than "an open, serious exposure we have not yet closed," which made it sound optional.
🔗 Connection: This is the inverse of Dana's slide 4 in Case Study 1. She spent real time on the after-hours detection gap on purpose, and an examiner on her board visibly came to trust her because she named her weaknesses. Owning the gap (🔗 Chapter 27's residual-risk honesty, delivered to the people who own the residual) builds confidence; hiding it destroys it.
Failure 4 — He quantified in the wrong units (audience fit)
Where Ravi did show numbers, they were operational: alert volumes, detection counts, device totals, mean alerts per analyst. His one "metrics" slide was a SOC dashboard, not a board dashboard. There was no MTTD trend, no risk burndown, no statement of residual risk against any appetite — because Northwind had never set a risk appetite, which was itself a Govern-layer gap (🔗 Chapter 27). The board had no way to judge whether risk was getting better or worse.
Failure 5 — There was no specific, decidable ask (the ask)
The closing slide read "Recommendation: increase security investment to address identified risks." That is not a motion a board can approve. How much? For what, exactly? Over what period? With what expected result? Faced with an un-decidable request, the board did the rational thing: it "took it under advisement," approved a modest across-the-board increase that funded the cheap, easy items, and deferred the expensive device-fleet program — the one that mattered most — pending "a more detailed proposal." The roadmap stalled at its most important step.
There is a cruel irony in how the deferral played out. Because Ravi had not separated the device-fleet program from the rest of his ask — it was buried in a general "increase investment" request — the board could not approve the part of his plan that mattered while questioning the parts that did not. A better-structured ask would have isolated the device-fleet program as its own decidable line item, so that even a cautious board could approve the critical piece while deferring genuinely optional work. Instead, by bundling everything into one vague recommendation, Ravi forced the board into an all-or- nothing posture — and a board faced with all-or-nothing and insufficient information will choose nothing every time, funding only the inoffensive minimum. The structure of the ask did not just fail to help; it actively channeled the board toward deferring the one thing Ravi most needed funded.
NORTHWIND — FIRST BOARD PRESENTATION (what the board took away)
===========================================================================
What Ravi presented What the board heard
--------------------------- --------------------------------------------
41 slides, ask on slide 38 "I don't know what decision I'm making"
activity list (status report) "a busy team" — but no risk to weigh
flawless program "what aren't they telling me?" (distrust)
operational metrics "is risk better or worse? unclear"
"increase investment" un-decidable -> defer the big item
---------------------------------------------------------------------------
RESULT: cheap items funded; the $3.2M device-fleet program DEFERRED.
===========================================================================
Figure CS2.1 — How a technically excellent program lost the room. Each failure maps to a §38.7 rubric dimension; the cumulative effect was deferral of the single most important initiative.
The Consequence
Eleven months later, ransomware entered Northwind through exactly the gap the deferred program would have closed: a compromised credential reached a flat clinical network segment where unpatched, unmonitored medical devices and imaging systems shared space with workstations. The attacker moved laterally with little resistance and encrypted systems across two hospitals. Because the device fleet had never been segmented or monitored (🔗 Chapters 6–7, 14, 33), there was no early detection and no containment boundary (🔗 Chapter 24). Patients were diverted; elective procedures were postponed; the recovery, helped by the IR plan and forensics readiness Ravi had built (🔗 Chapters 24–25), still took weeks.
Trace the incident against the deferred roadmap item and the correspondence is exact, control by control. Segmentation between the device fleet and the clinical workstations (Phase 1 of the deferred program) would have denied the lateral movement that let one compromised credential reach the imaging systems. Passive device monitoring (Phase 2) would have generated the early signal that something was traversing the fleet, turning a silent spread into a detected one (🔗 the passive-OT-monitoring approach of Chapter 33, which exists precisely because you cannot run an agent on a CT scanner). Neither existed, because neither had been funded, because the ask that would have funded them had been un-decidable. The controls Ravi had built mattered enormously to the recovery — the IR plan gave the response structure, the forensics readiness let the team scope what was hit — but recovery is the layer that runs after prevention and detection have failed. He had built the back half of the defense and been denied the front half, and ransomware, like every attacker, attacked the gap rather than the strength.
What makes this an autopsy rather than a tragedy is that the gap was known. This was not an unforeseen zero-day or a novel technique; it was the single risk Ravi had stood in front of the board and tried to fund. The post-incident review wrote it plainly: the organization had correctly identified its most serious exposure, had a sound and costed plan to close it, and did not close it — not because the plan was wrong but because the request was unintelligible to the people who controlled the money. In the cold accounting of the incident, the difference between Ravi's identified-but-unfunded risk and a risk no one ever found was zero. The patients diverted that week did not care that the security team had seen it coming.
📟 War Story: The painful detail — and the one Ravi could not stop thinking about — is that the board did not reject the device-fleet program. They deferred it, for the entirely reasonable reason that the request was un-decidable as presented. The risk that materialized was one the security team had identified, costed, and planned to fix. The failure was not in the engineering or even in the risk analysis. It was in the translation — the inability to turn a known, costed risk into a decision the board could own. A risk you identified and could not get funded is, in the cold accounting of an incident, indistinguishable from a risk you never found.
The Second Presentation — Learning the Skill
Ravi kept his job — the board valued that he had built real response capability and recovered the organization — and a year later he went back for the rebuilt device-fleet program, the post-incident remediation, and a UEBA investment. This time he had learned the chapter.
- He led with the ask. Slide 1: "We request $3.8M over eighteen months to segment and monitor the medical-device fleet, reducing our annualized ransomware-driven patient-safety risk from ~$9M to within a $1.5M appetite the board sets today." (He had, in the interim, run a risk-appetite exercise with the board — closing the Govern-layer gap.)
- He told the risk story in the board's units. Not "14,200 devices inventoried" but "an unsegmented device fleet is how ransomware shut down two of our hospitals last year; here is the annualized expected loss, in dollars and in diverted-patient days." He used the organization's own incident as the risk story — the most credible kind. The reframing of the device count was surgical: the same 14,200 that had once sounded like an accomplishment ("we inventoried everything") now appeared as "14,200 unpatchable, unmonitored devices sharing a network with clinical workstations — each one a way in, none of them watched." One number, two framings, opposite effects on the ask. He paired it with a labeled, defensible annualized-loss figure built the way Chapter 27 teaches: a ransomware-event likelihood drawn from healthcare-sector rates, multiplied by an impact that included both recovery cost and the clinical toll of diverted patients. The board, for the first time, had the device-fleet risk in a form they could weigh against $3.8M.
- He owned the gap. A full slide on what remained unaddressed even after this investment, and the residual risk that would remain — which, paradoxically, made the board trust the parts he said were handled.
- He showed board metrics. MTTD/MTTR trends, risk burndown since the incident, and residual-vs-appetite (🔗 Chapter 36) — not a single operational SOC metric in sight.
- He ended with a decidable motion. "Approve $3.8M for the device-fleet program in two phases, with Phase 2 contingent on Phase 1 segmentation milestones."
The board approved it in full, with one director — the security-experienced one — remarking that it was "the clearest security ask we've ever had." The program had not gotten dramatically better in the intervening year. Ravi had gotten better at the one skill no one had taught him: translating excellent security into a decision the board could own.
Compare the two decks side by side and the lesson is unmistakable. Nothing about Northwind's risk had changed in the intervening year except that one of the risks had stopped being hypothetical. Nothing about Ravi's engineering had changed except the addition of post-incident remediation. What changed was the translation layer — the thin, learnable, decisive skill of turning a known risk into a board decision.
NORTHWIND — FIRST DECK vs. SECOND DECK (same program, two translations)
===========================================================================
Dimension First (lost) Second (won)
---------------- ----------------------- ------------------------------
The ask slide 38, vague slide 1, specific motion
Risk framing activity list $ loss + diverted-patient days
The big risk "a planned initiative" "how ransomware shut us down"
Gaps hidden (looked flawless) owned (a full slide)
Metrics operational (alerts) board KRIs (MTTD/MTTR/burndown)
Appetite none set board-set $1.5M, residual within
Close "increase investment" decidable, phased, contingent
---------------------------------------------------------------------------
RESULT defer the $3.2M item full $3.8M approval
===========================================================================
Figure CS2.2 — The same program, two translations. Every row that changed is a §38.5 principle Ravi had learned. The engineering was never the variable; the translation was.
🔄 Check Your Understanding: Between Ravi's two presentations, which single change do you think moved the board most — leading with the ask, quantifying in patient-safety terms, owning the gap, or setting a risk appetite first? Defend your choice. (There is no single right answer; the discipline is arguing it from how a board actually decides.)
🚪 Threshold Concept: The skills of building a security program and defending it to a board are genuinely different, and the second is not optional. An organization is not protected by the security a CISO can build — it is protected by the security a CISO can get funded, staffed, and sustained. A brilliant program you cannot fund protects no one. This is the hardest lesson in the book for technical readers, and Northwind's two presentations are it in the starkest possible terms: the same program, the same risk, two translations, two outcomes — and, in between, real harm to real patients.
Discussion Questions
- Ravi's first program was, technically, better than the bank's in Case Study 1, yet it got far less funded. Does this mean technical quality does not matter? Reconcile "the translation is the job" with "you still have to build a real program."
- The board deferred (did not reject) the device-fleet program for a defensible reason: the ask was un-decidable. Where does responsibility lie — with a board that should have probed harder, or with a CISO who should have asked clearly? Argue it.
- Healthcare reframes "impact" from cardholder dollars to patient safety. How should that change the risk story and the business case relative to Meridian's? What is the healthcare equivalent of "the plane will land"?
- Northwind had never set a risk appetite — a Govern-layer gap (🔗 Chapter 27). How did that single missing artifact ripple through both the first presentation's failure and the second's success?
- Compare Ravi's second deck to Dana's deck in Case Study 1. What is structurally identical, and what is necessarily different because one is a bank and one is a hospital?
Your Turn
Take Ravi's failed first presentation and rewrite the first four slides to fix Failures 1–5: lead with a decidable ask, open the risk story in the board's units (invent a defensible ALE from a stated SLE and ARO for the device fleet), add a gap slide, and replace the operational metrics with three board KRIs. Then write the one-sentence version of the ask that Ravi should have opened with the first time — before the incident. Finally, in a short paragraph, identify the single change that would have done the most to change the first meeting's outcome, and defend your choice.
Key Takeaways
- Building and defending a program are different skills, and the second is not optional — an organization is protected only by the security a CISO can get funded, not the security they can build.
- The five failures are the negative space of §38.5: burying the ask, giving a status report instead of a risk story, presenting a flawless program, quantifying in operational units, and ending with an un-decidable request. Each maps directly to a rubric dimension.
- A deferred risk is, in an incident's accounting, indistinguishable from an undiscovered one. Ravi's team had identified, costed, and planned to fix the exact risk that materialized; the failure was in translation, not analysis.
- Owning the gap and quantifying in the board's units were the decisive changes between the losing and winning decks — the same lessons Dana applied in Case Study 1, learned here at real cost.
- A missing Govern-layer artifact (the risk appetite) rippled everywhere: without it, the first presentation had no way to say whether risk was acceptable; setting it was the foundation of the second presentation's success.
- The most credible risk story is your own incident — but the entire point of the chapter is to win the budget before you have one.