APRA's CPS 230 Operational Risk Management took effect on 1 July 2025. A lot of teams filed it under "risk and compliance, not my problem" — which is a mistake, because three parts of it land directly on whoever runs your AWS environment.
CPS 230 isn't a security standard. It's about operational resilience: that critical operations keep running, that you understand your service-provider dependencies, and that you can withstand a severe-but-plausible disruption. But "your AWS environment" is now squarely inside that scope.
Practitioner guidance, not legal or audit advice. Confirm against the current CPS 230 standard for your entity.
What actually changed
CPS 230 consolidated the old business-continuity (CPS 232) and outsourcing standards into one operational-resilience framework. Three obligations have direct AWS consequences.
1. AWS is now a "material service provider"
CPS 230 requires a register of material service providers and active management of those arrangements. For most regulated entities, AWS is the most material provider you have. That means:
- A documented understanding of which AWS services underpin which critical operations.
- Tolerances for how long a critical operation can be disrupted — and evidence your AWS architecture meets them (multi-AZ, multi-region, tested failover).
- AWS's own controls don't discharge your obligation. Under the shared-responsibility model, resilience in the cloud is yours.
2. Critical operations must be mapped to AWS architecture
You have to identify critical operations and the resources behind them. On AWS that's a real exercise: tag and inventory what supports each critical operation (Resource Groups, Config inventory), then show the architecture meets your disruption tolerance. A critical payments flow sitting in a single AZ is now a documented finding, not just bad practice.
3. It leans on CPS 234 for the security half
CPS 230 explicitly points to CPS 234 for information security — and notes that an incident already reported under CPS 234 doesn't need separate CPS 230 notification. The two standards are now a pair. If your CPS 234 controls on AWS are solid, you've done a chunk of CPS 230's security expectations already.
The AWS resilience checklist CPS 230 implies
| Obligation | What it means on AWS | Evidence |
|---|---|---|
| Critical-operation continuity | Multi-AZ by default; multi-region for the critical few | Architecture diagrams + failover test results |
| Disruption tolerances | Documented RTO/RPO per critical operation | Backup/DR runbooks; db-instance-backup-enabled |
| Service-provider management | AWS dependencies mapped and monitored | Service register; Health Dashboard alerting |
| Scenario testing | Annual test against severe-but-plausible scenarios | Game-day results, DR test reports |
What to do now
If you're already past your CPS 234 work, CPS 230 is less of a new build and more of a documentation and testing exercise: map critical operations to AWS resources, write down your tolerances, and actually test failover. The teams that struggle are the ones who have resilient architecture but can't evidence it — same failure mode as CPS 234.
A readiness assessment covers both: where your AWS estate stands against CPS 234's controls and CPS 230's resilience expectations, with the evidence pack to match. Or start with the free CPS 234 → AWS Controls cheatsheet.