Case Study 1: Meridian's Enterprise Risk Assessment

"The examiner didn't want my control list. She wanted my judgment — written down, owned, and dated." — Dana Okafor, CISO, Meridian Regional Bank (constructed)

Executive Summary

The OCC examiner's request was specific and uncomfortable: not the list of controls Meridian had built over the past year, but the risk assessment behind them — the reasoning that decided which risks to treat, which to accept, and why the bank could defend each choice. Meridian had a maturing security program and a one-page risk register seeded back in Chapter 1, but it did not yet have an enterprise risk assessment: a structured, quantified, treated, and owned picture of the bank's most significant risks, produced by a repeatable process rather than by whoever worried loudest. This case study follows GRC analyst Elena Vasquez, CISO Dana Okafor, junior analyst Theo Brandt, and security engineer Sam Whitfield as they run Meridian's first full enterprise risk assessment end-to-end — framing the context, identifying and analyzing risks both qualitatively and quantitatively, deciding treatments, and producing the register and risk-appetite statement that become the spine of the program. The scenario, figures, and personnel are constructed for teaching (Tier 3); the method is exactly what a regulated institution actually does.

Skills applied: establishing risk context and criteria; risk identification across multiple lenses; qualitative scoring (likelihood × impact) and the risk matrix; quantitative analysis (SLE, ARO, ALE) and cost-benefit of safeguards; risk-treatment selection (mitigate/transfer/avoid/accept); inherent vs. residual risk; risk-register construction with business ownership; drafting a risk-appetite statement; and packaging the result for an examiner and a board.

Background

Meridian Regional Bank — roughly 1,800 employees, 120 branches, 2.5 million customers, a hybrid on-prem/AWS environment, and a compliance surface that includes the GLBA Safeguards Rule, PCI-DSS, SOX, and FFIEC examination guidance — had spent a year maturing after a phishing near-miss. The team had network segmentation, a SIEM, phishing-resistant MFA rolling out, an incident-response plan. What it lacked was the connective tissue: a single, current, defensible answer to "what are our worst risks, what are we doing about each, who owns them, and what have we knowingly chosen to live with?"

Dana framed the assignment to Elena with a deadline (three weeks before the next exam cycle) and a governing principle inherited from the Chapter 1 assessment: be honest about uncertainty; a register of confident nonsense is worse than a short, true one. Elena's plan followed the five-step process from this chapter — frame, identify, analyze, treat, monitor/communicate — and deliberately built on the Chapter 1 seed (R1–R5) rather than starting over, because a risk-management program that throws away its history forgets its own decisions.

🔗 Connection: The Chapter 1 risk register was a seed — five risks, scored qualitatively, to prove the method. This case study is the enterprise assessment: the same five risks carried forward and deepened, plus new ones, now with quantitative ALEs on the largest, formal treatment decisions, business owners, and an appetite statement to measure them against. A first assessment proves you can score; an enterprise assessment proves you can govern.

The Assessment

Phase 1 — Frame the context and criteria

Before identifying a single risk, Elena established the context — the step beginners skip and examiners notice. She wrote down four things:

1. Scope. The assessment covers Meridian's information assets and the business processes that depend on them — the core-banking platform, online/mobile banking, the cardholder data environment (CDE), identity infrastructure, and the data they hold. Physical and purely operational risks (interest-rate risk, credit risk) are out of scope; this is an information-security risk assessment that feeds the bank's broader enterprise-risk process.
2. Business objectives at stake. Protecting customer funds and data, maintaining the availability of customer-facing services, and meeting regulatory obligations (GLBA, PCI-DSS) — the things a bank exists to do.
3. Risk criteria — the scoring scales. Elena defined the 1–5 likelihood and impact scales precisely, so that "High" meant the same thing to every analyst. Impact 5 ("Severe") was defined as ">\$1M loss, a reportable breach of customer data, or a material regulatory finding"; impact 1 ("Minor") as "<\$10K, no customer or regulatory effect." Likelihood 5 ("Almost certain") meant "expected multiple times per year"; likelihood 1 ("Rare") meant "expected less than once per decade." Defining the scales is what keeps qualitative scoring from being arbitrary.
4. Risk appetite (draft). Elena pulled the board's risk-tolerance language from the governance work of Chapter 26 and drafted a first appetite statement to measure residual risks against — very low appetite for customer-data and compliance risk, low for availability, moderate for internal tooling. This draft would be refined in Phase 4 and ratified by the board.

⚠️ Common Pitfall: Skipping the criteria. A team that scores risks without first defining what each number means produces a register that cannot be compared across analysts or defended to an examiner — one person's "Impact 4" is another's "Impact 2." Elena spent the first half-day writing the scales, and it paid for itself every time two analysts disagreed and resolved it by pointing at the definition rather than arguing about feelings.

Phase 2 — Identify the risks (multiple lenses)

Elena ran three identification lenses over the environment and reconciled them, rather than relying on a single brainstorm:

• Asset-driven (from the Chapter 1 asset inventory): for each crown-jewel asset — core database, customer PII, banking platform, CDE, identity — name the threat and vulnerability. This recovered and refined R1–R5.
• Control-driven (gap analysis against the NIST CSF and CIS Controls): for each expected control, ask where its absence creates risk. This surfaced new risks the asset lens missed — notably an untested vendor-dependency risk (the core-banking platform is operated by a third party) and a cloud misconfiguration risk in the growing AWS footprint.
• Event-driven (incidents, audit findings, threat intel): the phishing near-miss, a prior audit note about stale accounts, and threat intelligence on DDoS extortion campaigns against regional banks. This surfaced the DDoS availability risk that becomes the quantitative worked example.

Theo's job, as in Chapter 1, was to keep every risk concrete. Elena enforced the rule relentlessly: "'Hackers' is a noun, not a risk. Name the threat, the weakness, the asset, and the harm." The reconciled identification produced a register of about a dozen risks; this case study follows the most significant.

   MERIDIAN ENTERPRISE RISK — IDENTIFICATION (excerpt of working notes)

   R1  Credential attack on customer accounts
       Threat: phishing/credential-stuffing crews
       Vuln:   some staff/customer accounts not on phishing-resistant MFA; no lockout
       Asset:  online-banking platform, customer PII   →  harm: account takeover, breach

   R2  Lateral movement via privileged accounts
       Threat: any attacker who gains an initial foothold
       Vuln:   orphaned + over-privileged accounts (stale contractors, standing admin)
       Asset:  Active Directory / Entra ID             →  harm: domain-wide compromise

   R3  Foothold reaches the cardholder data environment
       Threat: organized fraud groups
       Vuln:   weak segmentation between corporate net and CDE
       Asset:  CDE (PCI scope)                          →  harm: card-data theft, fines

   R6  DDoS takes online banking offline   (NEW — event-driven)
       Threat: extortion-driven DDoS crews
       Vuln:   limited volumetric-attack absorption at the edge
       Asset:  online-banking availability              →  harm: outage, revenue, trust

   R7  Core-platform vendor failure/breach (NEW — control-driven, gap analysis)
       Threat: compromise or outage at the third-party core provider
       Vuln:   concentration on a single vendor; limited visibility into their controls
       Asset:  core-banking processing                  →  harm: outage, data exposure

Phase 3 — Analyze: qualitative first, quantitative where it matters

Elena scored every identified risk qualitatively on the defined 1–5 scales, because qualitative analysis is fast and right for the bulk of the register. She plotted them on the 5×5 matrix (Figure 27.2 in the chapter) so the team — and later the board — could see the landscape at a glance.

Then — and only then — Elena applied quantitative analysis to the handful of risks where a dollar figure would change a decision or win a budget. Quantifying all twelve risks would have been false precision and a waste of effort; quantifying the top few was exactly the cost-benefit lever the team needed for the budget cycle. She worked R6 (DDoS) and R1 (credential attack) in dollars.

R6 — DDoS availability risk (the worked quantitative example). Using the method from §27.3, the team estimated the online-banking platform's value at roughly \$2,000,000 per day of availability (fees, service costs, attrition). A serious DDoS event, at current defenses, knocks it offline about half a day (EF 0.5), and the team estimated about two such events per year (ARO 2.0):

$$SLE = \$2{,}000{,}000 \times 0.5 = \$1{,}000{,}000 \qquad ALE_{\text{before}} = \$1{,}000{,}000 \times 2.0 = \$2{,}000{,}000\text{/yr}$$

Sam priced a managed DDoS-mitigation/CDN service: it would cut serious events to about one every two years (ARO 0.5) and shrink each outage to a tenth of a day (EF 0.1, so SLE \$200,000), at an annualized cost of \$250,000 (ACS):

$$ALE_{\text{after}} = \$200{,}000 \times 0.5 = \$100{,}000\text{/yr} \qquad \text{Net value} = \$2{,}000{,}000 - \$100{,}000 - \$250{,}000 = +\$1{,}650{,}000\text{/yr}$$

R1 — credential-attack risk. The team estimated a successful customer-account-takeover-at-scale event at SLE \$900,000 (fraud, remediation, notification, attrition) with current ARO 2.0 (given some accounts still lacked phishing-resistant MFA), for $ALE = \$1{,}800{,}000$/yr. Completing the MFA rollout and adding lockout was estimated to cut ARO to roughly 0.2, dropping ALE to about \$180,000/yr — a ~90% reduction for a control already largely budgeted.

🛡️ Defender's Lens: Notice the discipline of which risks got quantified. Elena did not run ALE on R5 (guest WiFi) — a qualitative HIGH was enough to schedule the fix, and a dollar figure would have been spurious. She quantified R6 and R1 precisely because each carried a six-or-seven-figure control decision that a board would want justified in money. Quantitative analysis is a scalpel for big decisions, not a blanket you throw over the whole register. Matching the method to the decision is itself a senior skill.

Phase 4 — Treat: choose, and name the residual

For each significant risk the team made an explicit treatment decision among the four options, recording the inherent rating, the treatment, and the residual rating — because an examiner wants to know not just where you ended up but how far you moved and what you knowingly left.

   R1 (inherent CRITICAL/20; ALE $1.8M)
     Treatment -> MITIGATE: complete phishing-resistant MFA for all accounts; add lockout.
     Residual  -> MEDIUM (L1 x I5 = 5); ALE ~$180K. Within appetite. Accept residual, review Q.
     Owner     -> Head of Digital Banking.

   R2 (inherent CRITICAL/15)
     Treatment -> MITIGATE: access reviews; disable orphaned accounts; cut standing admin (Ch.18-19).
     Residual  -> MEDIUM (L1 x I5 = 5). Accept residual *only while* quarterly reviews run.
     Owner     -> Head of IT Infrastructure.

   R3 (inherent CRITICAL/15)
     Treatment -> MITIGATE: segment the CDE; default-deny between zones (Ch.6-7).
     Residual  -> MEDIUM (L1 x I5 = 5). Accept residual; re-test segmentation annually (PCI).
     Owner     -> Head of IT Infrastructure / PCI lead.

   R6 (inherent CRITICAL/16; ALE $2.0M)
     Treatment -> MITIGATE: managed DDoS/CDN service (net value +$1.65M/yr).
                  + TRANSFER the catastrophic tail via cyber-insurance.
     Residual  -> ALE ~$100K/yr, within the "<= $150K/yr" availability tolerance. Accept.
     Owner     -> Head of Digital Banking + CIO.

   R7 (inherent HIGH/10)
     Treatment -> MITIGATE (vendor security requirements, monitoring) + TRANSFER (contractual
                  liability/indemnity) — full treatment deferred to the TPRM work of Ch.29.
     Residual  -> HIGH, partially treated; concentration risk acknowledged.
     Owner     -> COO (owns the vendor relationship). Flagged for Ch.29 deep-dive.

   R4 (inherent HIGH/10)
     Treatment -> MITIGATE: implement and *test* backup/restore for the core DB (Ch.24).
     Residual  -> MEDIUM. Accept after first successful restore test.
     Owner     -> Head of IT Infrastructure.

The team's treatment of R6 illustrates composition: mitigate the bulk with the DDoS service, transfer the catastrophic tail with insurance, and accept the small residual that remains — three of the four options applied to one risk, exactly as §27.4 describes. R7 illustrates honesty about partial treatment: the vendor concentration risk could not be fully resolved in this cycle, so the team documented it as partially treated, named the COO as owner, and flagged it for the third-party risk work of Chapter 29 rather than pretending it was closed.

🔄 Check Your Understanding: R7 (core-vendor failure) was scored inherent likelihood 2 — "rare" — yet several team members were uneasy accepting even its partial treatment. What about the simple model might understate R7's true priority? (Hint: consider concentration — the entire bank runs on this one vendor — and how a single vendor failure interacts with every other risk, much as untested backups did in Chapter 1. A low likelihood times a severe impact can still hide a tail risk the bank cannot survive.)

Phase 5 — Register, appetite, and the examiner

Elena assembled the decisions into the enterprise risk register — the living artifact with every field from §27.5: ID, concrete description, asset, threat/vulnerability, inherent rating (qual + ALE where computed), treatment, residual rating, business owner, status/due date, and review date. Crucially, every risk owner was a business leader (Head of Digital Banking, Head of IT Infrastructure, COO), with security as advisor and scorekeeper — converting each technical finding into an organizational decision someone with budget actually owned.

She finalized the risk-appetite statement (the chapter's Figure 27.4): very low appetite for customer-data and regulatory risk with hard tolerance lines, low appetite for availability risk ("residual outage ALE ≤ \$150K/yr"), moderate for internal tooling and innovation. The statement let the team show that each accepted residual sat within a pre-stated boundary — R1's and R6's residuals were below their category tolerances, so accepting them was governance, not guesswork.

When the examiner returned, Dana did not hand her a binder of controls. She walked her through the register and the appetite statement: here are our top enterprise risks in priority order, here is each one's inherent and residual level, here is the treatment and the named business owner, here are the risks we have consciously accepted and the tolerance lines that make those acceptances defensible, and here is the quarterly review cadence that keeps the picture current. The examiner's note afterward was the highest praise the function gets: "Risk decisions are documented, owned, and revisited."

📟 War Story: A constructed but representative contrast. A peer institution, examined the same cycle, presented a thick control catalog and a heat map — but no owners on the risks, no documented acceptances, and no review dates. The examiner's finding was blunt: the bank could show what it had built but not why, could not name who owned its largest residual risks, and had no evidence it ever revisited an accepted risk. The controls were arguably better than Meridian's in places. The governance was not, and in a regulated institution the governance is what gets graded. The lesson the peer's CISO took away: a control with no documented risk decision behind it is, to an examiner, a control that might vanish in the next reorg with no one the wiser.

Discussion Questions

1. Elena defined the 1–5 likelihood and impact scales precisely before scoring anything. What concrete problems does this prevent, and what would have gone wrong if the team had scored first and defined later?
2. The team quantified only R6 and R1, leaving the rest qualitative. Defend that choice. When is it a mistake to not compute an ALE, and when is computing one a waste (or worse, false precision)?
3. R6's treatment combined mitigation, transfer, and acceptance for a single risk. Walk through why each of the three was appropriate for a different part of that risk, and what would be lost by using only one.
4. Every risk owner in the final register is a business leader, not a member of the security team. Why does the chapter insist on this, and what goes wrong when the "owner" field reads "Security" for every row?
5. The examiner praised that risk decisions were "documented, owned, and revisited" — not that risk was low. What does that tell you about what a regulator actually evaluates, and how it differs from a purely technical view of security?

Your Turn

Run an enterprise risk assessment for an organization you know (or the fintech startup from Exercise 20). Follow the five phases: (1) write a short context — scope, objectives, and defined 1–5 scales; (2) identify 6–8 concrete risks using at least two lenses (asset- and event-driven, say); (3) score all qualitatively and put a dollar ALE on your single largest; (4) choose a treatment for each, recording inherent and residual ratings and a business owner; (5) assemble a register and a one-paragraph risk-appetite statement, then write the three-sentence summary you would give an examiner or board. Keep it to two pages. Where you cannot name a business owner or justify a rating, mark it — that gap is itself a finding.

Key Takeaways

• An enterprise risk assessment runs the full five-step process — frame, identify, analyze, treat, monitor/communicate — and produces a living register plus an appetite statement, not a one-time spreadsheet.
• Defining the scoring scales first is what makes qualitative analysis defensible across analysts and to an examiner; skipping it produces incomparable, indefensible scores.
• Identify with multiple lenses (asset-, control-, and event-driven) and reconcile — each lens has blind spots the others cover.
• Qualitative for the bulk, quantitative for the big decisions: compute ALE only where a dollar figure changes a decision or wins a budget; quantifying everything is false precision.
• Treatments compose: Meridian mitigated, transferred, and accepted parts of the same DDoS risk; every decision recorded inherent → residual and a business owner.
• Business ownership and review dates are what turn a register from security's private worry list into the organization's auditable risk ledger.
• A regulator grades governance — documented, owned, revisited decisions — at least as much as the controls themselves; reasoning that lives only in the CISO's head does not exist.