Testing and Continually Improving Operational Resilience
What this domain tests
This domain tests how you design, run, and use testing to validate impact tolerances and drive remediation. It is about evidence and learning, not test counts.
Core rules
- Test against each IBS and its tolerance, using severe but plausible scenarios that exercise people, process, technology, data, facilities, and third parties.
- Use a mix: tabletop exercises for decision-making, simulation for dependencies, recovery and restoration tests for technology, penetration and red-team tests for cyber, and live or component testing where safe.
- Define success criteria before the test: time to breach tolerance, decision latency, data integrity, communication effectiveness, and whether workarounds work.
- Include the business, technology, risk, communications, legal, and third-party representatives. Observe rather than facilitate for the business owner.
- After the test, record issues, assign owners and dates, track remediation, report to the board, and retest the weakened area.
Worked example
A tabletop for a major outage reveals that the incident team can restore systems in three hours but cannot contact 40% of customers within the four-hour tolerance because the call-centre list is outdated. The test passes the technical criterion but fails the customer outcome. The remediation is a verified contact strategy, not a new server.
Traps
- Testing for completion rather than validating tolerance.
- No success criteria, so every test “passes”.
- Using only mild scenarios that do not challenge the tolerance.
- Testing systems while ignoring people, suppliers, and communications.
- Closing issues without evidence or retesting.
- Reporting test volume instead of breach risk and remediation progress.