Case Study 1: Meridian's First Risk Assessment

"You can't protect what you don't know you have — and you can't prioritize what you haven't scored." — Dana Okafor, CISO, Meridian Regional Bank (constructed)

Executive Summary

Two weeks after the phishing near-miss, CISO Dana Okafor asked her team for something deceptively simple: a one-page picture of Meridian's most important assets, the risks to them, and a ranking of what to fix first. No new tools, no consultants — just the vocabulary and the risk-scoring method from this chapter, applied honestly to the bank's real environment. This case study follows junior analyst Theo Brandt and GRC analyst Elena Vasquez as they produce Meridian's first lightweight risk register. You will see the chapter's terms — asset, threat, vulnerability, exploit, risk, control, residual risk — stop being definitions and start being a working tool. The scenario and all figures are constructed for teaching (Tier 3).

Skills applied: asset identification; threat/vulnerability articulation; qualitative risk scoring (likelihood × impact); risk-based prioritization; distinguishing risk from raw vulnerability count; translating findings into a register a manager can act on.

Background

Meridian Regional Bank is mid-size and, like most such organizations, has more environment than security staff. Before the near-miss, "risk management" at Meridian meant an annual spreadsheet that nobody read between audits. Dana wants something different: a living register, started small, that the team can defend to the board and grow every quarter. She gives Theo and Elena two days and one rule: "Be honest about what we don't know. A register full of confident nonsense is worse than a short, true one."

Elena starts where every risk process must start — with assets, because a risk is always a risk to something. She and Theo walk the environment (and the org chart) and list what genuinely matters:

🔗 Connection: Notice that the CIA emphasis differs by asset. The core ledger lives or dies on integrity and availability — a silently altered balance or a frozen system is catastrophic — while customer PII is mostly a confidentiality problem. This is the §1.5 idea in action: you defend each asset along the dimension that actually matters for it, not generically.

The Analysis

Phase 1 — From assets to threats and vulnerabilities

For each top asset, Theo asks the two questions this chapter taught him: who or what could harm it (threat)? and what weakness could they use (vulnerability)? He resists the temptation to jump straight to "risks," because a risk is meaningless until you can name the threat and the weakness behind it. A sample of his working notes:

Asset: Online/mobile banking platform
  Threat:        credential-phishing crews; credential-stuffing botnets
  Vulnerability: no account-lockout on the portal; some staff still password-only
  Exploit path:  phish or stuff credentials -> log in -> move toward customer data

Asset: Active Directory / Entra ID
  Threat:        any attacker who gains a foothold (lateral movement)
  Vulnerability: over-privileged accounts; stale/orphaned accounts (e.g., contractors)
  Exploit path:  compromise one account -> escalate -> domain-wide access

Asset: Cardholder data environment (CDE)
  Threat:        organized fraud groups
  Vulnerability: flat segment shares space with general corporate network
  Exploit path:  general foothold -> reach CDE because segmentation is weak

⚠️ Common Pitfall: Theo's first draft listed "hackers" as the threat for every asset. Elena pushed back: "Hackers isn't a threat, it's a noun. Who, specifically, would want this asset, and what would they do?" Naming the threat actor and the exploit path concretely (Chapter 2 builds the taxonomy) turns a vague worry into something you can actually score and defend against.

Phase 2 — Scoring the risks

Now the pair applies $\text{Risk} = \text{Likelihood} \times \text{Impact}$ on a 1–5 scale, justifying each rating in a phrase so the score is auditable later. They deliberately keep the register short — five rows — because a true short list beats an impressive long one nobody trusts.

The arithmetic took ten minutes; the conversation took the rest of the day, and that is the point. To rate R1's likelihood a 4, the team had to admit that a fraction of staff were still password-only — uncomfortable, but true. To rate R4's impact a 5, they had to confront that nobody had ever actually restored the core database from backup. The score is a forcing function for honesty.

🛡️ Defender's Lens: Every one of these five risks is the seed of a later chapter's defenses. R1 → authentication (Chapter 16). R2 → identity governance and PAM (Chapters 18–19). R3 → network segmentation (Chapters 6–7). R4 → incident response and recovery (Chapter 24). R5 → wireless and segmentation (Chapters 8, 6). A first risk assessment is, in effect, the table of contents of your own security program.

Phase 3 — Prioritizing and proposing treatment

With scores in hand, prioritization is no longer a matter of who argues loudest. The three CRITICALs come first. For each, the team proposes a treatment and — crucially — names the residual risk that remains afterward, because a board will (rightly) ask "and then are we safe?" and the honest answer is always "safer, and here's what's left."

R1 (score 20): Treatment  -> enforce phishing-resistant MFA for all staff; add lockout.
               Residual   -> insider misuse; MFA fatigue on any non-FIDO factors. (-> Ch.16)
R2 (score 15): Treatment  -> access review; disable orphaned accounts; reduce admin rights.
               Residual   -> privilege creep returns without ongoing governance.    (-> Ch.18)
R3 (score 15): Treatment  -> segment the CDE; default-deny between zones.
               Residual   -> misconfiguration; east-west paths inside a zone.        (-> Ch.6,7)

Theo runs the five risks through the riskcalc.py tool he built in this chapter's checkpoint to double-check the bands and sort. The output matches the table — a small confirmation that the mental model and the code agree.

🔄 Check Your Understanding: R4 (untested backups) scored 10, lower than the three CRITICALs, so it is not in the first wave. Yet many seasoned responders would argue it should be fixed urgently anyway. What about the simple model might understate R4's true priority? (Hint: consider how a single backup failure interacts with every other risk during a ransomware incident, and how the chosen likelihood of 2 might be optimistic.)

Discussion Questions

1. Elena insisted on keeping the register to five rows. What are the advantages and risks of starting a risk register small rather than attempting to be comprehensive on day one?
2. R2 and R3 both scored 15 with identical likelihood and impact. If you could fund only one this quarter, what additional information would you gather to choose between them?
3. The team rated R1's impact a 5 partly because of regulatory consequences (GLBA, state breach laws), not just direct financial loss. Should regulatory and reputational harm count in "impact"? Argue both sides.
4. Where in this process did honesty matter more than technique? Identify two ratings that depended on the team admitting an uncomfortable truth.

Your Turn

Take the organization you chose in Exercise 16 (or invent a small business) and reproduce this process: list five to seven assets with their CIA emphasis, name a threat and vulnerability for each, then score and rank five risks with likelihood × impact, justifying every rating in a phrase. For your top three, propose a treatment and state the residual risk. Keep it to one page. If you cannot justify a rating in a phrase, that is a signal you need more information — note what you would go find out.

Key Takeaways

• A risk assessment starts with assets, because a risk is always a risk to something of value; an asset inventory is the foundation, not a formality.
• Naming the threat and vulnerability concretely — not "hackers" — is what makes a risk scoreable and defensible.
• Likelihood × impact scoring is fast, auditable, and forces honest conversations; the number's main value is the discussion required to defend it.
• The simple model has limits (R4): a low score can understate risks that interact with everything else, which is why later chapters add richer methods.
• Every risk implies a treatment and a residual risk; mature defenders always state what remains after a control, because "are we safe now?" deserves an honest answer.
• A first risk register doubles as the roadmap for the security program you build across this book.