Case Study 2: The Acceptance That Went Wrong — Anatomy of a Risk Decision at a Regional Hospital

"We didn't ignore the risk. We accepted it. The problem was that 'we' was nobody, and 'accepted' was a hallway conversation." — post-incident review, Lakeshore Regional Health System (constructed)

Executive Summary

Risk acceptance is the most misunderstood of the four treatments — beginners think it is a failure, when it is often the correct call. This case study examines the opposite error: a risk acceptance that was analytically reasonable in the moment but governed so poorly that it produced a major incident, and shows exactly which disciplines of §27.4 and §27.5, had they been present, would have changed the outcome. The setting is deliberately different from Meridian: Lakeshore Regional Health System, a 400-bed not-for-profit hospital network in a different sector with different stakes — where the asset at risk is not customer funds but patient data and, indirectly, patient care, and the regulator is HIPAA rather than the OCC. The case is analytical: rather than building a program forward as the Meridian case did, we reconstruct a real-shaped failure backward, applying the chapter's framework to diagnose precisely how a defensible decision became negligence. The organization, personnel, timeline, and figures are constructed for teaching (Tier 3), informed by the general pattern of well-documented healthcare breaches; no real institution or incident is depicted.

Skills applied: distinguishing a defensible risk acceptance from a silent one; the four properties of legitimate acceptance (explicit, documented, owned, time-bounded); compensating controls; inherent vs. residual risk under acceptance; risk-register hygiene and the role of the review date; quantitative hindsight (what the ALE actually was vs. what was assumed); and the governance and ethical dimensions of under-treating a known risk.

Background

Lakeshore Regional Health System runs three hospitals and a dozen clinics. Like most healthcare providers, it carries enormous quantities of the most sensitive data there is — protected health information (PHI), governed by HIPAA — on a sprawling, hard-to-change technology estate where clinical systems cannot simply be rebooted or patched on a whim because patients depend on their availability. This is the defining tension of healthcare security, and it is different in kind from a bank's: at Meridian, availability matters for revenue and trust; at Lakeshore, an availability failure in the wrong system can delay care. That tension makes risk acceptance a constant, legitimate part of the job — you genuinely cannot treat every risk immediately without harming patients — which is exactly why the governance of acceptance matters so much more, and why getting it wrong is so dangerous.

The risk in question was mundane. Lakeshore ran an internet-facing patient-portal application on an older web framework that had reached end-of-life: the vendor no longer issued security patches. Migrating to the supported successor was a real project — it would touch integrations with the electronic health record, require testing against clinical workflows, and take an estimated nine months and a budget the IT department did not have in the current fiscal year. In the meantime, the portal kept working, patients kept using it, and the framework's end-of-life status was, to the handful of people who knew about it, a problem for "next year."

🔗 Connection: This is the same shape of decision Meridian's R7 faced (a risk that cannot be fully treated this cycle) and that the §27.4 war story described (an unsupported internet-facing system awaiting replacement). The difference is entirely in the governance. Meridian documented R7's partial treatment, named the COO as owner, and flagged it for a deep-dive. Lakeshore, as we will see, did none of that — and the chapter's whole argument is that this difference is the difference between a managed risk and a breach.

The Analysis

Phase 1 — Reconstructing the decision: what was actually decided, and by whom?

The post-incident review's first task was to find the decision. There had to be one — someone had chosen not to migrate the portal this year, which is a choice to accept the risk of running unsupported software for nine-plus months. The reviewers went looking for the record of that decision and found nothing. There was no risk-register entry for the end-of-life portal. There was no documented acceptance, no named owner, no review date, and no analysis of what the risk actually was. What there was, the reviewers reconstructed from interviews, amounted to a series of hallway conversations:

   THE "DECISION", AS RECONSTRUCTED (there was no written record)

   ~14 months   An engineer notes the framework will reach end-of-life "next year."
   before       Mentioned in a team standup. No ticket created.

   ~10 months   During budget planning, migration is "deferred to next fiscal year"
   before       for cost. Discussed verbally. Not logged as a risk acceptance.

   ~9 months    Framework reaches end-of-life. Vendor stops issuing patches.
   before       No one is assigned to track the gap. No compensating control added.

   ~3 months    A vulnerability scanner flags the end-of-life framework.
   before       The finding lands in a backlog of 900 others. Not triaged by risk.

   Day 0        A known vulnerability in the unsupported framework is exploited.
               Attacker reaches the portal, then the PHI behind it.

The reviewers' verdict on Phase 1 was precise and, for students of this chapter, instructive: the problem was not that Lakeshore accepted the risk. Accepting the risk of running the portal for a few more months, with eyes open and controls in place, might well have been the right call given the genuine cost and clinical-testing burden of migration. The problem was that the acceptance failed all four of the properties §27.4 requires. It was not explicit (no decision was ever stated as "we accept this risk"). It was not documented (no register entry existed). It was not owned (no one with authority was on the hook). And it was not time-bounded (no review date existed to force a re-examination before the window of exposure widened). It was, in the language of the chapter, a silent acceptance — and a silent acceptance is indistinguishable, after an incident, from never having noticed the risk at all.

⚠️ Common Pitfall: Confusing "we talked about it" with "we decided it." A risk discussed in a standup or a budget meeting but never written into the register, assigned to an owner, and given a review date is not a managed risk — it is a shared assumption that everyone believes someone else is handling. The reviewers found three separate people who each thought the portal migration was "being tracked" by one of the others. Documentation is not bureaucracy; it is the mechanism that converts a vague collective unease into a single accountable decision.

Phase 2 — What a defensible acceptance would have looked like

The most useful exercise the reviewers ran was counterfactual: hold the same business decision (defer migration nine months for cost and clinical-testing reasons) and ask what governance would have made it defensible. The chapter gives the answer directly — the four properties, plus compensating controls. The reviewers wrote out the register row that should have existed:

   THE RISK-REGISTER ROW THAT SHOULD HAVE EXISTED

   ID:            R-PORTAL-EOL
   Description:   Internet-facing patient portal runs an end-of-life web framework
                  no longer receiving security patches; a known/zero-day flaw could
                  be exploited to reach PHI.
   Asset:         Patient portal; PHI (HIPAA scope).
   Threat/vuln:   External attackers / unsupported, unpatchable framework.
   Inherent:      L4 x I5 = 20 (CRITICAL); illustrative ALE ~$1.2M (breach cost,
                  HIPAA penalties, notification, reputational/patient harm).
   Treatment:     ACCEPT for <=9 months (migration funded next FY) WITH compensating
                  controls: WAF in front of the portal; enhanced monitoring/alerting
                  on the portal; virtual patching of known framework CVEs; restricted
                  network path from portal to PHI.
   Residual:      With compensating controls: L2 x I5 = 10 (HIGH) -- reduced, not
                  eliminated. Explicitly accepted at the reduced level.
   Owner:         CIO (has budget authority and accountability).
   Status/due:    Accepted; migration due by [date]; compensating controls live by [date].
   Review date:   Monthly (high-exposure acceptance) -- AND immediately if a relevant
                  CVE is published for the framework.

Two elements of that row deserve emphasis because they are what separated a defensible bet from the actual disaster. First, compensating controls. Accepting a risk does not mean doing nothing; it means choosing not to eliminate the root cause this cycle — but you can and must reduce the residual in the interim. A web application firewall, virtual patching of the framework's known vulnerabilities, tightened monitoring on the portal, and a restricted network path from the portal to the PHI behind it would each have lowered the residual risk during the acceptance window. Lakeshore added none of them, so its residual risk during the nine months was the full inherent risk — it accepted a CRITICAL and left it CRITICAL. Second, the review date with an event trigger. A monthly review, plus an explicit trigger to re-examine the instant a relevant vulnerability was published, would have caught the scanner finding three months out and forced a decision while there was still time to act. The review date is the mechanism that makes risk management a loop; without it, an acceptance is a decision made once and then forgotten until an attacker reminds you.

🛡️ Defender's Lens: From the attacker's side, an end-of-life internet-facing application is a high-value, low-effort target — the vulnerability is permanent (no patch is coming), so an exploit, once public, works indefinitely. This is precisely why a documented acceptance of such a risk should carry an event trigger, not just a calendar review: the moment a CVE drops for an unsupported framework, the risk's likelihood jumps from "possible" to "near-certain," and the acceptance must be revisited that day. A monitoring rule that watches for new CVEs against your known end-of-life software is, in effect, the trip-wire on an accepted risk.

Phase 3 — The quantitative hindsight

The reviewers ran the quantitative analysis that should have informed the original decision, and the comparison is damning in the way only hindsight ALE can be. Suppose Lakeshore had estimated, at decision time, the breach event at SLE \$1,200,000 (incident response, HIPAA penalties, breach notification to affected patients, credit monitoring, legal, reputational harm and patient attrition) — a conservative figure for a healthcare PHI breach. At the inherent likelihood of an unsupported internet-facing portal being exploited within the nine-month window — call it an ARO of about 1.0 over the exposure period — the expected loss of the unmitigated acceptance was on the order of its full SLE.

Against that, the compensating controls were cheap. A WAF and enhanced monitoring for nine months might cost \$60,000–\$90,000 all-in. Even a crude analysis shows the asymmetry:

The point is not that the controls guaranteed prevention — no control does — but that spending roughly \$75,000 to reduce a ~\$1.2M expected exposure is the most obvious cost-benefit decision in this entire book, and the only reason Lakeshore did not make it was that no one ever ran the numbers, because the risk was never in the register to be analyzed. The silent acceptance did not just skip the governance; it skipped the analysis that would have made the cheap, sensible mitigation self-evident.

🔄 Check Your Understanding: The reviewers estimated the unmitigated acceptance's expected loss at roughly the full SLE over the window, yet the compensating controls cost only ~\$75,000. If the cost-benefit was this lopsided, why did a competent IT team not add the controls? (Hint: the failure was not analytical judgment but governance — the risk was never identified, registered, owned, or reviewed, so the analysis that would have made the \$75K obvious was never performed. The lesson: missing process defeats good people.)

Phase 4 — Diagnosis: which disciplines failed, mapped to the chapter

The reviewers closed by mapping the failure precisely onto the chapter's framework — a diagnosis every reader should be able to reproduce:

1. Identification failed (§27.2): the risk never made it into the register, despite three opportunities (the standup, the budget meeting, the scanner finding). The scanner finding in particular was buried in a 900-item backlog that was never triaged by risk — a direct violation of the Chapter 1 lesson that you prioritize by risk, not by vulnerability count.
2. Treatment was botched (§27.4): the option chosen (accept) may have been reasonable, but it was executed without any of the four required properties and without compensating controls, leaving residual risk at the full inherent level.
3. The register discipline was absent (§27.5): no row, no business owner, no review date — so no mechanism existed to revisit the decision or to hold anyone accountable for it.
4. Communication never happened (§27.6): because the risk was never registered or owned, it was never reported upward, so leadership never knowingly accepted it — meaning the board could not discharge its duty of care over a risk it did not know it was carrying.

The single-sentence verdict the reviewers wrote is the one to remember: "A risk that is accepted but not documented, owned, and revisited is not a managed risk — it is an unmanaged risk with a story attached after the fact."

⚖️ Authorization & Ethics: There is an ethical edge to this case that intensifies in healthcare. The data at risk was patients' most private information, and the people whose information was breached had no say in, and no knowledge of, the decision to run their portal on unsupported software. When an organization accepts a risk on behalf of people who cannot consent to it — patients, customers, the public — the duty to govern that acceptance carefully is not merely professional but fiduciary. A silent acceptance is, in that light, not just a governance lapse; it is a decision made about other people's safety without telling anyone who could have objected or who was accountable. State the acceptance, name the owner, add the controls, set the review — because someone who is not in the room is relying on you to.

Discussion Questions

1. The reviewers were emphatic that accepting the risk was not the error. Construct the strongest case that deferring the migration nine months was a reasonable business decision. What, specifically, would have had to be true for that acceptance to be defensible?
2. Compare Lakeshore's silent acceptance to Meridian's treatment of R7 (the core-vendor concentration risk) in Case Study 1. Both faced a risk they could not fully treat this cycle. List every governance difference and explain why each one mattered.
3. The chapter says compensating controls are part of a well-governed acceptance. For Lakeshore's portal, propose three compensating controls and explain how each lowers the residual (not inherent) risk during the acceptance window.
4. The scanner finding sat in a 900-item backlog and was never triaged by risk. Connect this to the Chapter 1 lesson about prioritizing by risk rather than vulnerability count. How should the finding have been surfaced, and to whom?
5. Healthcare's availability constraints make immediate treatment genuinely impossible for many risks, so acceptance is unavoidable. Does that make healthcare's governance of acceptance more important or less important than a bank's? Argue your position.

Your Turn

Find (or construct) a risk in an organization you know that is currently being accepted silently — a deferred upgrade, an unpatched legacy system, a known gap awaiting budget. Write the risk-register row that should exist for it, using Lakeshore's counterfactual row as a template: a concrete description, inherent rating (with a rough ALE), the acceptance decision with compensating controls, the reduced residual, a named business owner, and a review date with an event trigger. Then write the two-sentence upward communication that would put this accepted risk in front of the person accountable for it. If you discover you cannot name an owner, you have found exactly the gap this case study is about.

Key Takeaways

• Risk acceptance is legitimate and often correct — but only when it is explicit, documented, owned, and time-bounded. Fail any of the four and a reasonable bet becomes negligence.
• A silent acceptance (a hallway decision never written down) is, after an incident, indistinguishable from never having noticed the risk at all.
• Accepting a risk does not mean doing nothing: compensating controls (a WAF, monitoring, virtual patching, network restriction) reduce the residual risk during the acceptance window. Lakeshore accepted a CRITICAL and, with no controls, left it CRITICAL.
• The review date — with an event trigger — is what makes risk management a loop; without it, an acceptance is forgotten until an attacker reminds you. For end-of-life software, a new CVE is the trigger.
• The failure was governance, not judgment: missing identification, registration, ownership, and review defeated a competent team — the cheap, obvious mitigation was never made because the analysis was never performed.
• When an organization accepts risk on behalf of people who cannot consent (patients, customers), the duty to govern that acceptance is fiduciary, and communicating it upward so the board can ratify it is part of the institution's duty of care.