$600,000 and a Tabletop That Found the Wrong Things
Meridian Mutual is a 1,200-person insurer. Six weeks ago a tabletop simulated ransomware on the claims-processing application. Findings: backups are domain-joined and reachable with the same credentials administrators use daily; the last successful restore test was 14 months ago; the IR plan was written in 2019 and never exercised; there is no retainer with a forensic firm; three analysts cover 24x7 with no formal on-call rotation or escalation contacts; EDR covers 70% of endpoints but no servers. The board has approved $600,000 for IR capability next year. Proposal A spends $450,000 on EDR expansion plus a SIEM upgrade. Proposal B spends $250,000 on isolated immutable backups, $150,000 on a forensic retainer, $100,000 on training and on-call staffing, and $100,000 on closing part of the server EDR gap.
1. Choose between the proposals and justify the choice as a risk argument, including what you would change about the option you pick.
Read the worked answer
Take B, with modifications - and be explicit that this is a judgement about which failure mode dominates.
What the exercise actually found. The findings cluster around recovery and decision-making, not around visibility. Domain-joined backups reachable with daily-use admin credentials are the single highest-likelihood catastrophic finding in the list: one domain administrator compromise converts your recovery capability into another victim, and no amount of EDR prevents that. A 14-month-old restore test means the restore capability is unproven, which is the same as absent for planning purposes. A five-year-old untested plan and a 24x7 rotation with no escalation path mean the first two hours of a real event will be improvised.
Why A loses on sequencing. Proposal A consumes 75% of the budget on tools whose value depends on analysts who currently have no rotation, and a SIEM upgrade with no defined log-source or retention requirement is a purchase in search of a problem. Visibility is genuinely inadequate on servers - that is what the $100,000 carve-out in B addresses - but it is the second-order gap.
Modifications to B:
- Write the backup design requirement as restore-time objective plus isolation, not "immutable storage". Immutability is a property; the test is whether a domain admin can delete the copy.
- Contract the retainer with a defined call-out time and a named engagement lead, and run one paid activation exercise - otherwise you have bought a phone number.
- Split the $100,000 training line: tabletop facilitation and on-call process first, generic awareness second.
- Put the SIEM upgrade into next year's ask with a written requirement derived from the new IR plan's decision windows.
State the accepted residual risk in writing - server visibility remains partial for twelve months - with the executive who owns it named.
2. What would you measure over the next twelve months to show the investment produced capability rather than activity?
Read the worked answer
Measure capability, and design each metric so it cannot be improved by paperwork.
- Median time to restore the claims application from backup in a test, against a target (e.g. under eight hours). This is the only backup metric that matters. "Percentage of backups completed successfully" measures the backup job, not recovery, and is routinely gamed by a job that writes corrupt data quickly.
- Percentage of tier-1 systems with a successful restore test in the last 90 days, reported as a count of systems, not jobs.
- Elapsed time from scenario start to first containment action in each exercise, tracked over successive exercises - the trend, not the absolute number.
- Percentage of critical servers with EDR, plus whether the alerts actually reach a triage queue with an owner.
- On-call health: page-to-acknowledgement time in unannounced tests, and the number of escalations that reached the right person on the first attempt.
- Closure rate of tabletop actions, with age of open items - this catches the common failure where findings are recorded and never funded.
Guard against gaming. The moment a metric becomes a target, analysts optimise the metric. Pair each number with a qualitative check: sample two restores a year and watch them, rather than trusting the dashboard.
Report the leading indicators, not just outcomes. "Zero incidents" is not evidence of capability; it is absence of data.
3. The board asks why you are not simply buying the EDR expansion, which is easy to explain. How do you frame the answer and sequence the spend?
Read the worked answer
Frame it in the language of loss, not controls. Boards fund reduced uncertainty, not product categories. Present three scenarios - ransomware on claims processing, theft of a policyholder database, and a supplier breach - and for each show the current expected downtime, the regulatory exposure (notification cost per record, supervisory scrutiny), and which line item moves it.
The honest answer to "why not EDR": EDR is a detection control and it is worth buying, but in the ransomware scenario the binding constraint is whether you can restore the business and whether you can investigate defensibly. Those are the constraints the tabletop exposed. Buying detection first optimises the stage of the incident you are best equipped to handle.
Sequencing, with dependencies made explicit:
- Q1: backup isolation and the first restore test - everything else assumes recoverability; the retainer contract, because procurement takes eight to twelve weeks.
- Q1–Q2: on-call rotation, escalation contacts, incident commander training, and a re-run of the same tabletop as a before/after measurement.
- Q2–Q4: server EDR in risk order, starting with domain controllers and the claims platform.
- Year 2: SIEM upgrade, now justified by named log sources and retention requirements derived from the plan.
Offer the board a choice, not a lecture: "We can fund A instead, but then the board is accepting that a domain compromise likely destroys recovery capability." Record whichever they choose, and by whom.