Standards such as CPS 230 and CPS 234 do not reward plans. They reward evidence that plans work. This guide explains how to design an operational resilience testing program and incident runbooks that stand up to a regulator, an auditor, or a real bad day. It covers scenario selection, test types, what to record, runbook structure, and how to line up notification clocks. It is general guidance, not legal advice.
What the standards expect
CPS 230 requires a credible business continuity plan for critical operations, and a systematic testing program that covers all critical operations and includes an annual business continuity exercise using severe but plausible scenarios. The plan must be reviewed at least annually, test results reported to the board or its delegate, and findings remediated. CPS 234 requires an information security incident response plan, tested at least annually, and testing of control effectiveness. Operators of critical infrastructure assets have separate duties under the SOCI Act. In each case the expectation is practised, recorded capability.
Choose scenarios that matter
Start from the critical operations and ask what would take them beyond tolerance. Good scenarios are severe but plausible, specific and linked to your dependency map:
- Loss of a cloud availability zone, then loss of a cloud region.
- Failure or compromise of the primary identity provider.
- Ransomware that encrypts production and replicated data.
- A material service provider outage, or its insolvency.
- A bad release or configuration change in the critical path.
- Loss of a key site, network or telecommunications provider.
- Loss of key staff, or an incident that happens out of hours.
- A data breach involving personal information, including at a supplier.
A layered test program
| Test type | What it proves | Frequency |
|---|---|---|
| Backup restore test | Data can be recovered within tolerance and is usable | Per critical system, at least quarterly, and after major change |
| Fault injection or game day | Architecture handles zone, dependency and deployment failures | Quarterly for critical operations |
| Failover exercise | Regional or site failover works to the runbook and time target | At least annually |
| Tabletop exercise | Decision making, escalation and communication | Quarterly, with executives at least annually |
| Provider exit or switch rehearsal | You can move or recover without a failed provider | For critical providers, on a rolling schedule |
| Annual business continuity exercise | The whole operation, including people and third parties, stays within tolerance | Annual |
Run tests first in a safe environment, then in production with stop conditions and rollback. Tools such as AWS Fault Injection Service and Azure Chaos Studio help control the blast radius. Our guide to cloud architecture and testing explains the engineering side.
What to record every time
- The scenario, scope, date, participants and observers.
- Time of fault, time detected, time decided, time recovered, and data loss, each compared with tolerance.
- What worked, what failed, what was slow and what was unclear.
- Actions with owners, due dates and priority, and the retest date.
- Sign-off by the accountable executive, and a summary to the board or its delegate.
Store the record in a place where it cannot be quietly edited, and link it to the critical operation in the register. The evidence automation architecture shows how to keep it.
What a good runbook looks like
A runbook is for the tired person at 3am. It is short, specific and tested.
- Purpose and trigger. What situation this covers and how you know you are in it.
- Roles. Incident lead, technical lead, communications lead, scribe and deputies, with phone contacts that do not depend on the system that failed.
- Decision points. For example, who can declare a regional failover, and what the criteria are.
- Steps. Numbered, with expected outputs and timing, commands or links, and a rollback.
- Dependencies. Access needed, keys, break-glass accounts, third-party contacts and contract references.
- Communications. Internal updates, customer messages, regulator notifications and media, with templates.
- Verification. How to confirm the operation is back within tolerance, and who signs off.
- After the event. Evidence capture, review within a set time and follow-up actions.
Keep copies where you can reach them when the main environment is down, such as an offline pack and a second system. Keep them in version control and review after every test and incident.
Incident reporting runbook: line up the clocks
Several notification regimes can apply to the same event, with different triggers and units. Build a single incident record that starts a clock for each applicable obligation, shows the earliest deadline, and generates the notification content. Examples are summarised below.
| Obligation | Trigger | Time limit |
|---|---|---|
| CPS 230 operational risk incident | Likely material financial impact or material impact on critical operations | 72 hours from awareness |
| CPS 230 tolerance breach | Disruption to a critical operation outside tolerance | 24 hours |
| CPS 234 information security incident | Material effect or potential material effect, or notified to other regulators | 72 hours from awareness |
| CPS 234 control weakness | Material weakness not expected to be fixed in a timely way | 10 business days |
| SOCI critical cyber incident | Significant impact on availability of a critical infrastructure asset | 12 hours, with written record within 84 hours of an oral report |
| SOCI other cyber incident | Relevant impact on integrity, reliability or confidentiality | 72 hours, with written record within 48 hours of an oral report |
| Ransomware payment report | Payment made, or made on your behalf, by an in-scope entity | 72 hours |
| Notifiable data breach | Eligible data breach likely to cause serious harm | Assess within 30 days. Notify as soon as practicable once confirmed |
APRA has said a single notification is enough where an incident is notifiable under both CPS 230 and CPS 234, with the earliest timeframe applying. Regulators change forms and thresholds, so keep the table in your runbook under version control and review it at least annually with your lawyers. The reference architecture for incident notification shows one way to automate this.
Do not forget your suppliers
Include service providers in exercises where you can, and make sure contracts oblige them to notify you quickly, with enough detail for your own clocks. Test the contact path. Many exercises fail at the first step because no one can find the provider's out-of-hours number. See our guide to provider due diligence and exit planning.
Common weaknesses
- Tests that only prove the happy path.
- Findings logged but never closed.
- Runbooks that assume the primary tools and identity provider are up.
- Exercises limited to technology staff, with no executives, communications or legal.
- No record of how long each step took.
This article reflects common practice and published requirements as at October 2026. Confirm current obligations with your regulator and advisers.
Talk to an Adelaide team
If you want a test program, runbooks and an incident workflow that you can evidence, talk to us about a resilience and incident readiness review or call 0402 401 584. We can facilitate technical exercises and build the tooling. See our managed IT and cyber security and DevOps and cloud services.