The BCP test results were filed six months ago. Everything passed - RTOs were met, the plan was documented and signed off. Then the real disruption happened, and the activation timeline ran three times longer than the documented recovery objective. The gap between passing a test and carrying real load is wider than the results page suggests.
Most business continuity plans share a design flaw: they were built to satisfy the review, not to carry the operational load. In Australia, CPS 230 and CPS 232 require carriers to maintain documented and tested BCPs for critical operations. In New Zealand, equivalent obligations exist under regulatory governance requirements for licensed insurers. Meeting the documentation standard is the starting point, not the end state. A plan that satisfies the review but fails the real event does not reduce operational risk. It obscures it, behind a filed test result and a signed-off document.
BCP failures in insurance operations tend to follow a recognisable pattern. A plan designed to pass a review and a plan designed to carry real load are built against different criteria. Most BCPs are built against the first set.
The first failure mode is activation procedure assumptions. Most procedures assume named individuals are available, systems are accessible, and the disruption is single-channel. Real events do not respect those assumptions. The procedure that works when everyone knows it is a test fails when the conditions are unplanned.
The second is optimistic RTO framing. Recovery time objectives are set based on best-case estimates during plan design. Test conditions typically reflect those estimates. Live events introduce variables - data integrity issues, system access delays, dependency failures - that the documented RTO did not account for.
The third is second sources that need ramp time. A BCP that names a second provider as the recovery resource fails if that provider needs weeks to reach operational capacity. At the point of activation, ramp time is not available.
The distinction between a test-validated plan and an event-validated plan is not semantic. It is the difference between a plan that holds under controlled conditions and one that holds when the conditions are real.
Every assumption in the activation procedure is a potential failure point. The plan that identifies and removes those assumptions before the event - that asks "what breaks if this assumption does not hold?" for every step - is the one that does not produce a 3x RTO overrun.
The frame shift is not complicated. Build against the worst-case scenario, not the test case. Document what happens when the first named resource is unavailable, when the primary system is inaccessible, when the disruption is not the single-channel event the procedure assumes. That is the plan that holds.
The review that distinguishes a resilient BCP from an audit-ready one follows a consistent sequence.
First: audit the activation procedure for assumptions. For each step, ask what it assumes about availability, access, and system state. Remove each assumption and test whether the step still works.
Second: stress-test the RTO. The documented recovery timeline should be tested without the first two or three named resources. The test should introduce at least one variable - a system access issue, a data integrity flag, a dependency that is not immediately available - that was not in the original test design.
Third: verify the second source at the point of activation. The question is not whether the second source is documented. It is whether they can carry full operational load on day one, without a training runway on the carrier's specific systems. A second source that needs onboarding time after activation is a commitment the BCP cannot keep at speed.
The plan that passes this review is the one worth filing.
ISSI operates as a warm second source on the platforms ANZ carriers already run. Because platform fluency on CyberLife, wmA, and Ingenium already exists, there is no ramp period before load can be carried. ISO 22301-class business continuity protocols and audit-passed credentials are the foundation a resilient BCP second-source arrangement requires. If BCP design or testing is active in your organisation, it is worth thirty minutes.
Sources: APRA Quarterly Life Insurance Performance Statistics (2025); APRA Quarterly Insurance Performance Statistics (September 2025)
