Insights

APRA CPS 230 explained for ICT leaders: critical operations, tolerance levels and service providers

What APRA CPS 230 means for ICT leaders: critical operations, tolerance levels, continuity testing, material service providers and notification timeframes.

APRA's Prudential Standard CPS 230 Operational Risk Management sets how banks and other authorised deposit-taking institutions, general and life insurers, private health insurers and superannuation trustees manage operational risk, keep critical operations running through disruption, and manage the service providers they depend on. It took effect on 1 July 2025. APRA finalised targeted amendments in April 2026, which commenced on 1 July 2026, and the transition period for pre-existing service provider contracts has now ended. This guide explains what CPS 230 means for the people who run and buy technology, whether you work inside a regulated entity or supply one. It is general guidance, not legal advice, and obligations vary by entity type, so check the current standard on the APRA website and take advice on your own position.

What CPS 230 replaced and why ICT leaders should care

CPS 230 replaced the earlier outsourcing standards (the 231 series) and the business continuity standards (the 232 series) and brought operational risk, business continuity and service provider management into one cross-industry standard. For ICT leaders the practical shift is that technology resilience is no longer judged only by whether a system has a disaster recovery plan. It is judged by whether the business can continue to deliver its critical operations within agreed tolerance levels through a severe but plausible disruption, including the failure of a provider you rely on.

The board remains accountable for oversight of operational risk, and senior management is accountable for managing it. In practice, ICT leaders are the people who produce the dependency maps, the recovery designs, the test results and the provider evidence that the board needs to be able to say that.

Critical operations and tolerance levels

A critical operation is a process the entity performs that, if disrupted beyond tolerance, would have a material adverse impact on its customers or on its role in the financial system. The standard lists minimum examples by industry, such as payments and deposit-taking for an authorised deposit-taking institution, claims processing for an insurer, and member services and benefit payments for a superannuation trustee. The entity must also justify any exclusion.

For each critical operation the entity sets tolerance levels for three things:

  • The maximum period of disruption it would tolerate.
  • The maximum extent of data loss it would accept.
  • The minimum service levels it would maintain while running on alternative arrangements.

These map directly onto engineering measures. Maximum disruption sets the recovery time objective for every system and provider the operation depends on. Maximum data loss sets the recovery point objective and replication or backup frequency. Minimum service levels define what a degraded mode must still do, for example accept payments but defer statements. Tolerance levels belong to the operation, not to a server, so the work starts with business owners and a dependency map from the operation down to applications, infrastructure, people, data and providers.

Business continuity: a credible plan that is tested

The entity must maintain a credible business continuity plan (BCP) that covers its critical operations, sets out triggers for activation, the actions to recover, dependencies, and communications. The standard requires a systematic testing program covering all critical operations, with an annual business continuity exercise, using severe but plausible scenarios, and an annual review of the plan. Test results go to the board or its delegate with remediation actions tracked.

A plan that says “restore from backup” is not enough if no one has measured how long a restore takes. The strongest evidence is a recorded test that shows time to detect, time to decide, time to recover and data loss compared with tolerance. See our guide on operational resilience testing and incident runbooks.

Service provider management

The entity must maintain a comprehensive service provider management policy, a register of its material service providers, and manage the risks of using them. Material service providers are those on which the entity relies to undertake a critical operation, or that expose it to material operational risk. The standard sets out categories of provider that must be treated as material unless the entity can justify otherwise, which differ by industry, so read the list that applies to your entity type. Cloud and core technology providers are frequent examples.

Before entering into or materially changing a material arrangement, the entity must carry out due diligence and assess the financial and non-financial risks, including geographic and concentration risk. A formal, legally binding agreement must cover, at a minimum, the services and service levels, rights and responsibilities including ownership and control of data, audit access, liability and indemnity, support for the entity's own legal and compliance obligations, and notification when the provider relies on other material providers. The entity must also monitor performance, control effectiveness and compliance, and report to senior management.

APRA's April 2026 amendments introduced a limited exemption from some contractual requirements for material arrangements with certain categories of provider, such as government agencies, regulators, central banks, exchanges, clearing and settlement operators, payment systems and financial messaging infrastructure, where the terms are standardised or contract compliance is not practicable. The exemption does not remove the duty to manage the risk.

The notification obligations to plan for

TriggerTimeframe to notify APRA
Operational risk incident likely to have a material financial impact, or a material impact on the ability to maintain critical operationsAs soon as possible and not later than 72 hours after becoming aware
Disruption to a critical operation outside toleranceAs soon as possible and not later than 24 hours
Entering into or materially changing an agreement for a service relied on for a critical operationAs soon as possible and not more than 20 business days after
Offshoring arrangement with a material service providerBefore entering into, or on significant change to, the arrangement

The entity must also submit its register of material service providers to APRA annually. APRA publishes electronic forms for these notifications, and where an incident is notifiable under both CPS 230 and CPS 234, a single notification to APRA is sufficient, with the earliest applicable timeframe applying. Our incident notification reference architecture shows how to design for the clocks.

The contract deadline has passed

When APRA finalised the standard, requirements applied to existing service provider contracts from the earlier of the next renewal date or 1 July 2026. That date has now passed. Any material arrangement should now meet the contract requirements, either because it was renewed or because the transition ended. If you supply a regulated entity, expect questions about audit access, sub-contractor notification, exit support and data ownership in renewals and security reviews. Some requirements for smaller, non-significant financial institutions were also deferred until 1 July 2026, so they should now be fully in effect.

What ICT leaders should be able to show

  1. A list of critical operations with named owners and approved tolerance levels.
  2. A dependency map from each operation to systems, data, people and providers, including fourth parties.
  3. Recovery designs whose RTO and RPO are derived from tolerance, with recorded test evidence.
  4. A register of material service providers and the due diligence, contract position and exit plan for each.
  5. Monitoring that detects operations moving outside tolerance, and an incident process that can notify on time.
  6. Reporting to the board that includes test results, open actions and concentration risk.

How CPS 230 relates to other obligations

CPS 230 sits alongside CPS 234 Information Security, the Privacy Act, and for some entities the Security of Critical Infrastructure Act. They overlap in incidents, third parties and evidence. Our standards map sets out the relationships. CPS 230 is also not the only operational resilience regime worldwide, but this guide covers the Australian standard only.

How EITSAA helps

EITSAA is a technology consultancy. We are not an assessor, auditor or law firm, and we do not hold any certification against these standards. What we do is help you design and evidence the technical side: mapping critical operations to services, building recovery capability from tolerance levels, setting up evidence and monitoring, and preparing the technical material your risk and compliance teams need. See the reference architectures for CPS 230 operational resilience and material service provider exit strategy.

This article reflects the published standard as at October 2026. Confirm current requirements with APRA and your advisers before relying on them.

Talk to an Adelaide team

If you are an APRA-regulated entity, or you supply one, talk to us about a CPS 230 technology readiness review or call 0402 401 584. We can start with a short, fixed-price review of your critical operation dependencies and recovery evidence. You can also read about our DevOps and cloud and managed IT and cyber security services.

More insights

Let’s talk about your next project

Talk to an Adelaide-based team. We reply within one business day.