APRA CPS 234 backup requirements rarely show up as a checklist. Unlike the Essential Eight, the prudential standard never says "back up daily" or "retain for 30 days". What it says instead is that a regulated entity must maintain information security "commensurate with the size and extent of threats" to its information assets, in a way that lets the business keep operating. Backups fall inside that obligation whether or not the standard names them directly, and APRA's own guidance makes the connection explicit. It treats regular backups as one of the controls a security review checks, and a gap found there can become a reportable event under the standard, not just an internal action item.
This is a practical walk-through for banks, insurers, superannuation trustees and the other entities APRA regulates: what CPS 234's backup requirements actually ask of your recovery capability, how the newer CPS 230 raises the bar around business continuity, what changes when a third party holds the data, and the control set that tends to survive a review. Every clause reference below is drawn from APRA's published CPS 234 standard and its own "Security and adequacy of backups" guidance.
What CPS 234's backup requirements actually cover
CPS 234 has applied to APRA-regulated entities, including banks, insurers and superannuation trustees, since 1 July 2019. Its central obligation is that the entity maintains information security in a way that is commensurate with the size and extent of threats to its information assets, and that enables the entity's continued sound operation. Ultimate accountability for that sits with the Board, not IT, and the standard is explicit that information security roles and responsibilities need to be clearly defined rather than assumed.
APRA has been direct about where backups fit inside this. Its guidance on the security and adequacy of backups points straight at the Essential Eight, noting that the use of regular backups is one of the ACSC's eight mitigation strategies, and treats it as a baseline expectation for a mature information security programme. Crucially, APRA also states that if a review turns up gaps in backup security or adequacy that could materially affect an entity's risk profile or financial soundness, that finding is treated as a material information security control weakness. That brings a specific notification clock into play, covered below.
The standard doesn't hand you a fixed recovery point or recovery time objective, and that's deliberate. "Commensurate with the size and extent of threats" means your backup regime is judged against what you're protecting, not a number in a document. A core banking ledger and an archived marketing shared drive are not held to the same standard, and APRA doesn't pretend otherwise. What it does expect is that you've made the call deliberately, tested it, and can show your working when asked.
The two clocks: what happens when a gap surfaces
CPS 234 sets two separate notification obligations, and knowing which one a backup problem triggers matters.
Under paragraph 35, an entity must notify APRA as soon as possible, and no later than 72 hours, after becoming aware of an information security incident that materially affected, or had the potential to materially affect, financially or non-financially, the entity or its depositors, policyholders, beneficiaries or other customers. The 72-hour clock starts at awareness rather than once you've confirmed the damage, so a ransomware event that touches your backup environment starts that clock immediately, before anyone has finished assessing how bad it is.
Under paragraph 36, a different and slower clock applies to control weaknesses rather than live incidents. Notification is due no later than 10 business days after the entity becomes aware of a material information security control weakness it does not expect to remediate in a timely manner. This is the one backup testing programmes tend to trip. If a disaster recovery exercise reveals your restores don't actually work, or that a privileged account can quietly delete backups inside their retention period, and you can't fix it quickly, that discovery itself becomes notifiable. The practical lesson is that testing your backups isn't just good operational hygiene under CPS 234. An untested backup regime is precisely the kind of unknown that turns into a 10-business-day compliance problem the day someone finally checks it properly.
Where CPS 230 fits alongside it
CPS 230 Operational Risk Management commenced on 1 July 2025, with targeted amendments taking effect from 1 July 2026, and it changes the picture without replacing CPS 234. Where CPS 234 governs the security of information assets, CPS 230 requires entities to identify their critical operations, set tolerance levels for how long those operations can be disrupted, and demonstrate they can keep them running, or recover them, inside that tolerance.
Backups are the mechanism that makes a recovery time objective real rather than aspirational. A business continuity plan that assumes a core system comes back inside four hours is only as credible as the backup, replication and restore process sitting behind that promise. An APRA reviewer reading a continuity plan will ask how the recovery time was tested, and "we assume the backups are fine" is not an answer that holds up.
CPS 230 also tightens expectations around arrangements with service providers that support critical operations, including formal requirements around what those contracts must cover. Entities have until the earlier of 1 July 2026 or the next renewal date of an existing contract to bring those arrangements into line. For many regulated firms that means backup and DR vendor contracts are due for a compliance-focused review regardless of when the underlying technology last changed.
Third parties don't dilute the obligation
A point that catches teams out: CPS 234's obligations do not reduce simply because an information asset is managed by a third party. That includes cloud providers, managed service providers and offshore teams. If your backup data sits with an external provider, the regulated entity still owns the obligation to ensure that provider's security is commensurate with the standard, through contractual terms, capability assessment and ongoing monitoring rather than a one-off sign-off at onboarding.
In practice this is where data sovereignty considerations earn their place, even though CPS 234 doesn't spell out a residency rule in so many words. A backup copy held with an Australian-hosted provider is materially simpler to assess, monitor and produce evidence for than one governed by a foreign jurisdiction's access laws layered on top of your own contractual controls. It's a risk-reduction choice more than a strict legal requirement, but it's one a growing number of regulated entities are making deliberately rather than by default. Our data sovereignty work with partners usually starts with exactly this question: where does the data actually sit, and who can compel access to it?
What this doesn't mean
It's worth being clear about what CPS 234 is not. It's not a product you buy, and no vendor can hand you a certificate that says "compliant". It's also not a fixed technical spec: there's no clause mandating a specific backup frequency, retention period or storage medium. Entities sometimes over-correct by throwing budget at the newest platform while leaving the actual gap, whether that's an untested restore, a shared admin account or an unreviewed third-party contract, exactly where it was. APRA's reviews look for evidence of a considered, tested, governed process, not the most expensive tool in the market.
A practical control set
None of this requires exotic tooling, but it does require the right architecture underneath ordinary backup software. The pattern that tends to hold up under an APRA review looks like this.
- Backups matched to a stated criticality and recovery objective, not a blanket schedule. It's the same "commensurate" logic that runs through the whole standard.
- Immutable, tamper-resistant storage, so that a compromised privileged account, the exact scenario paragraph 35 exists for, can't also destroy the recovery path.
- Tested restores with evidence, on a documented cadence, because a green backup log is not what paragraph 36 is asking for. Keep the evidence pack: dates, systems restored, and who signed off.
- Clear, contractually enforced ownership when any part of the backup chain sits with a third party, per paragraph 16, reviewed alongside the CPS 230 service-provider deadline.
For the SaaS workloads regulated entities increasingly run on, including Microsoft 365 and Entra ID, Keepit is built around exactly this shape: an immutable store that sits outside the customer's own tenant, so no compromised admin account inside that tenant can reach it, with the option to keep the copy in an Australian data centre. It won't make an entity CPS 234 compliant on its own; nothing does. But it removes the architectural weak point regulators keep finding, and it gives an assessor a straightforward answer to "who can delete this, and from where".
How regulated firms buy through partners
Financial services buyers usually aren't shopping for a backup product in isolation. They're trying to close a specific finding from an internal audit or an APRA review, on a timeline, with evidence they can hand back. That's a conversation CRS partners have often, and it's usually faster with someone who has already mapped CPS 234 and CPS 230 controls to real infrastructure rather than starting from a blank page. If you're a partner working with a regulated client, or an enterprise team scoping this internally, get in touch and we'll help build the stack the review is actually looking for.