The Patch That Costs More Than the Breach
Northbridge Health Administrators processes 3,400 claims a day on a claims engine running Windows Server 2012 R2. The vendor has declared end of support and will not issue fixes; migration is quoted at $1.9M over 18 months. Scanning found an unauthenticated remote code execution flaw (CVSS 9.8) in a service that must stay reachable from the provider portal. Your analyst estimates a successful exploit occurs 0.3 times per year with a $4.2M loss per event. A compensating stack - tight segmentation, a reverse proxy with virtual patching, EDR, and 24/7 monitoring - costs $380K per year and is judged to cut likelihood by about 70% without changing impact. You control $500K of discretionary spend this year. The board's appetite statement says the company will not tolerate "foreseeable catastrophic loss." The state regulator requires "reasonable" safeguards.
1. What treatment do you recommend for the next 12 months, and how do you justify it both numerically and against the board's appetite statement?
Read the worked answer
Run the numbers before arguing.
- Current ALE = 0.3 × $4.2M = $1.26M/yr.
- Post-control likelihood = 0.3 × 0.3 = 0.09/yr, so residual ALE = 0.09 × $4.2M = $378K/yr.
- Control cost = $380K/yr.
The naive rule ("ALE exceeds control cost, therefore buy") is the trap here: the control is essentially break-even in expected value and does not touch impact at all. Justifying the spend purely on ALE reduction is weak and a CFO will find it.
The real justification is the tail plus the standard of care:
- A single event is $4.2M - that is the loss the appetite statement is actually about, not the annual average. The control buys detection and containment time, which converts many attack paths from "silent RCE" to "blocked or caught," and reduces the probability of the catastrophic case specifically.
- The regulator asks for reasonable, and "we knew about a 9.8 and ran an EOL platform with nothing in front of it" is not defensible. The compensating stack also produces evidence you currently lack.
- The stack is fundable in 90 days; migration is not. Sequencing matters more than the math.
Recommendation: fund the compensating stack immediately, fund migration as a board-visible program with a named owner and a sunset date, and treat the residual as something that must be transferred (confirm the cyber policy sublimit and whether EOL platforms are excluded - many are) as well as accepted. Do not present the stack as remediation; it is a bridge with an expiry.
2. Who must formally accept the residual risk, and what must the acceptance record contain?
Read the worked answer
Not you. The acceptance authority must sit at the level that owns the loss, and this residual exceeds both the stated appetite and your delegated authority - that means the CEO or the board risk committee, minuted, with the CISO as recommender, not acceptor.
The record needs more than a signature:
- Scenario and assumptions - including the 0.3/yr frequency and $4.2M figure, and that the control reduces likelihood only.
- Quantified residual (~$378K/yr expected, $4.2M single event).
- Expiry date - e.g., 12 months, tied to migration milestones, not open-ended.
- Reopening triggers - vendor confirms no fix, any exploitation attempt, audit finding, change in insurance coverage, migration slip.
- Evidence the compensation is real - proxy rule set tested against the CVE, segmentation verified, monitoring alert tested.
- Insurance position - sublimits and exclusions stated explicitly, because "transfer" is not transfer if the policy excludes unsupported software.
- Named decision owner and date.
The failure mode to avoid is a perpetual acceptance that quietly renews itself. An acceptance that never expires is a decision nobody is making.
3. Six months in, the vendor confirms there will never be a patch. What changes about your recommendation and the acceptance?
Read the worked answer
The narrative collapses. Up to now the story was "compensating controls pending remediation" - that framing is what made the residual defensible to the board and to a regulator. With no fix ever, the residual is permanent, and the only remaining treatments are avoid (decommission or re-architect the function), change the architecture so the vulnerable service is no longer the control point, or replace the platform.
What changes concretely:
- The existing acceptance is void on its own terms - it was conditioned on a remediation path. Do not silently renew it; take a new decision to the board with the permanent-residual numbers.
- Re-test the compensating controls against known exploit variants and get independent validation; the credibility of the whole position rests on them actually working.
- Accelerate or re-scope migration. If $1.9M/18 months is unaffordable, ask whether a partial re-architecture (rebuild only the internet-facing service, leave the back end) closes the exposure faster and cheaper.
- Revisit contractual and regulatory notification obligations - some provider and payer agreements require disclosure of unsupported components.
- Answer the hard question explicitly: if migration cannot complete, is continuing to operate the service defensible? Documented, board-level, with the business consequence of shutting it down on the table. That is a business decision your evidence should inform, not one you should make alone.