Single Flood-Zone Data Centre and a 99.9% Promise
You are CISO of a 3,000-employee logistics company operating from a single primary data centre built in 2011, on a site the insurer now classifies as a 1-in-100-year flood zone. The DR contract is a warm site 400km away advertising an 8-hour RTO for tier-1 systems; it has been tested twice, both times as a tabletop, and the last full technical failover was four years ago, before two major WMS upgrades. The BIA is three years old. Last month's phishing simulation produced a 31% click rate, a 9% report rate, and 58% completion of mandatory awareness training. Helpdesk records show 40% of reported suspicious emails are reported to a colleague before IT. A customer-facing track-and-trace portal launches in five months and will be contractually required to be available 99.9% with service credits. The insurer has hinted at a premium increase, and your largest customer has sent a security questionnaire asking for BCP test evidence.
1. Design the continuity validation programme for the next 12 months. What do you test, how, and what evidence do you produce?
Read the worked answer
Start with the BIA, not the test. RTO and RPO are business decisions; a three-year-old BIA means the tiers are stale and any test validates the wrong things.
Programme:
- Months 1-2: refresh the BIA for tier-1 services - track-and-trace, WMS, order intake, finance. Document dependencies (identity, DNS, network, third parties) and agree RTO/RPO with each service owner in writing.
- Month 3: executive tabletop - decision-making, escalation, communications, manual workarounds. Output is a deviation log, not a pass.
- Months 4 and 9: two full technical failovers of tier-1 to the warm site, followed by business validation rather than 'systems came up'. Measure actual RTO/RPO against agreed targets and record every deviation with an owner and a date.
- Quarterly: backup restore tests on a rotating sample, plus a call-tree and communications test.
- Month 11: repeat tabletop incorporating lessons; report to the board.
Evidence the insurer and customer will accept: dated test plan, participant list, timestamps of failover and recovery, measured versus target RTO/RPO, the deviation log, and corrective actions with completion dates. A dashboard screenshot is not evidence.
Surface early: a warm site claiming 8-hour RTO is incompatible with 99.9% availability on the new portal - roughly 43 minutes of permitted downtime per month. That is an architecture and contract problem, not a testing problem, and it needs a decision before launch, not after the first outage.
2. Redesign the awareness programme. What changes, what do you measure, and how do you avoid a click-rate-only scorecard?
Read the worked answer
Diagnosis first: 31% click, 9% report, and 40% of reports going to a colleague before IT says the problem is friction and culture, not knowledge. People who suspect something are not routing it to the people who can act.
Changes:
- One-click reporting in the mail client with automatic acknowledgement and visible follow-up ('we acted on your report'). Close the loop publicly with anonymised examples.
- Reward reporting, never punish clicking. Simulation clicks feed coaching, not discipline. Punitive programmes destroy the report rate, which is the metric that actually reduces attacker dwell time.
- Role-based content - finance and procurement get payment-diversion and invoice fraud; helpdesk gets vishing and MFA-reset social engineering; engineering gets credential handling. Generic annual modules are compliance theatre.
- Short, frequent, varied simulations, including voice and SMS, not just email.
- Process controls alongside training - callback verification for payments, phishing-resistant MFA, a documented authority matrix. Awareness without a backing control is a hope.
Metrics: report rate and median time-to-report as primary; repeat-click rate; ratio of real reported phish to simulations; helpdesk ticket quality; one behavioural measure from real telemetry, such as payment-diversion attempts stopped by callback verification. Click rate appears once as context and never as the headline.
Board reporting: a two-line trend - reporting up, time-to-report down - plus one sentence on what changed in the process as a result. That is a defensible scorecard.
3. The insurer and your largest customer want BCP evidence. How do you handle the gap between what you can prove today and what they ask for?
Read the worked answer
Principle: describe the gap, do not decorate it. A questionnaire answered optimistically is a misrepresentation risk, and the first incident will test it publicly.
Approach:
- Answer factually with dates. Where there is no evidence - for example no full failover since the WMS upgrades - say so, and state the test date now booked.
- Provide a maturity statement rather than pass/fail: what is designed, what is operating, what is untested. Insurers and enterprise customers accept 'untested, scheduled, owner named' far better than an unsupported 'yes'.
- Offer evidence that exists today: BIA scope, tabletop outputs, restore test records, the insurer's own findings and your remediation plan against them.
- If the customer demands third-party assurance, commission an ISO 22301 assessment or a focused readiness review, and give a realistic timeline rather than a promise.
Use the pressure commercially: the questionnaire and the premium signal are the cheapest business case I will get for funding the failover programme and resolving the single-site flood exposure. Bring the customer letter and the insurer's hint to the risk committee alongside the remediation cost, and ask for a decision between accepting the concentration risk, investing in resilience, or relocating the primary site.
And fix the contract: a 99.9% commitment on the new portal needs an architecture that can meet it. Renegotiating service credits before launch is far cheaper than explaining an outage afterwards - and cheaper than discovering the DR claim was never true.