Forty Tier 1 Labels and Twenty-Five Recovery Slots
Meridian Health Administrators runs 220 applications. A fresh BIA, built from 14 business-unit workshops, labels 42 applications as Tier 1 with an RTO of four hours or less. The current DR contract guarantees only 25 recovery instances and an eight-hour site activation. Dependency mapping shows the claims adjudication system, which supports a payer API with a four-hour availability SLA, depends on an identity service with a 24-hour RTO, a mainframe batch cycle with a 12-hour RTO, and storage replication that has never been timed. The CIO proposes buying 20 more recovery instances for $1.8 million a year. The CFO authorizes $400,000 and asks for a defensible way to close the gap. A state regulator requires claims to be processed within 15 days, and the largest payer can assess $60,000 per hour after a four-hour outage. The board wants one number for cyber resilience risk.
1. Reconcile the BIA with the DR contract capacity. What method do you use, and what interim decisions should be made with the $400,000?
Read the worked answer
Start by treating the BIA labels as claims to be tested, not facts. Build a recovery dependency graph for each of the 42 Tier 1 applications: include identity, directory, DNS, batch, storage, network, and data flows. Then compute the transitive closure, which is the set of services that must recover for a business function to work. A common result is that 42 business labels map to fewer recovery instances because shared services are counted once, but the four-hour claims RTO may still be impossible while identity is at 24 hours and batch is at 12 hours.
Classify into time bands rather than a single tier: 0 to 4 hours for the payer-facing API and the minimum claims workflow, 4 to 24 hours for internal adjudication, and 24 to 72 hours for reporting and support. Compare the minimum recovery set to the 25 contracted instances. If the set fits, the gap is dependency timing, not capacity. If it does not, negotiate on-demand activation rather than buying 20 permanent instances.
Spend the $400,000 on the binding constraints, not evenly. Likely candidates are pre-provisioned identity in the DR environment, more frequent or parallel batch, timed storage replication, and a pre-agreed manual claims workaround with the payer. Fund only changes that move a business service inside its tolerance. Record residual risk, the owner who accepts it, and the trigger for buying more capacity. Do not present the 42 labels or the 25 slots as the answer; present the validated recovery set and the services that still miss tolerance.
2. The payer's four-hour API SLA conflicts with the dependency RTOs. Evaluate the options and recommend a decision rule.
Read the worked answer
The options are technically different and should not be priced as one DR purchase. First, make the API active-active in a second region or availability zone with independent identity and data paths; this targets the contractual exposure but is expensive and adds data consistency risk. Second, use queue-and-forward with a degraded read-only portal and manual claim status updates; this can meet the business need at lower cost if the payer accepts it. Third, renegotiate the SLA or its penalty cap, recognizing that a contract change does not restore service. Fourth, add recovery instances, which does not fix the identity and batch dependencies.
Use a decision rule based on expected loss and evidence. Estimate the annual probability of a four-hour-plus outage from historical events and test results, multiply by the $60,000-per-hour penalty and relationship damage, and compare with the lifecycle cost of each option. If the targeted active-active design costs less than the expected penalty plus revenue risk, fund it. If not, negotiate a defined degraded mode with the payer and document the accepted risk at executive level.
Do not rely on the 99.9 percent style availability number as proof. Require a tested failover of the API and its identity dependency, measure actual recovery time, and include the payer's technical contact in the exercise. The decision rule should be: meet the obligation through architecture or an agreed workaround when the cost is below expected loss; otherwise renegotiate and record residual risk.
3. What should the board see as the resilience metric, and what would you refuse to present?
Read the worked answer
Give the board a small set of decision-grade measures: the number of critical business services that can meet their impact tolerance with current, tested capability; the number that cannot; the top three gaps with cost and owner; and the trend over the last four quarters. Add one service-level example, such as claims API recovery time versus the four-hour obligation, so the board can see what the number means. Show the cost curve for closing gaps so the board can choose a risk appetite rather than approve a single project.
Refuse to present a single composite cyber resilience score. It hides which service fails and encourages false precision. Also refuse to present unvalidated RTOs from the BIA as capability, or a DR contract instance count as recovery capability. State the evidence: last test date, actual recovery time, data loss observed, and exceptions. If the board insists on one number, give a count of services meeting tolerance with evidence and label it clearly, not a weighted index.