APRA CPS 234: What It Means for Your Cloud Provider

If you're APRA-regulated — a bank, credit union, insurer, superannuation fund, or registered financial intermediary — and you use cloud storage for sensitive data, CPS 234 is the prudential standard you need to understand. It's not optional, it's not aspirational, and APRA's enforcement posture has visibly hardened since 2023. The cost of getting it wrong is regulatory action and (for the executives accountable) personal consequences under the BEAR/FAR regime.

What CPS 234 requires

CPS 234 has been in force since July 2019, and was updated in the 2024-25 prudential reform cycle. It requires regulated entities to:

• Clearly define information security roles and responsibilities at the Board, executive, and operational levels.
• Maintain an information security capability commensurate with the vulnerabilities and threats faced and the criticality of the information assets.
• Implement controls to protect information assets, and test those controls regularly through systematic testing programs.
• Have documented incident management and breach response procedures, including escalation to the Board.
• Notify APRA of material information security incidents within 72 hours of awareness.
• Provide an annual attestation by the Board that CPS 234 has been complied with.

The 2024 amendments tightened the third-party oversight language and added explicit expectations around cyber-resilience testing — most regulated entities now run quarterly tabletop exercises and annual penetration tests as a baseline.

The third-party problem (Section 15)

Section 15 of CPS 234 is the one that catches firms out repeatedly. It says that when information assets are managed by a "related party or third party" — which includes every cloud provider you use — you remain responsible for ensuring their controls are adequate. You can outsource the management; you cannot outsource the accountability.

In practice, this means:

• You can't accept a SOC 2 Type II report at onboarding and forget about it. The assurance has to be ongoing, refreshed at least annually, and supplemented by your own testing where you can.
• If the cloud provider has an incident, you have your own 72-hour clock to APRA — independent of the provider's customer notification timeline.
• You need contractual rights that let you actually exercise oversight: audit rights, right to require specific controls, right to terminate quickly if a control test fails.
• Sub-contracting by the cloud provider (fourth-party risk) is now explicitly in scope. If your provider uses an offshore data-processing partner, you need to know.

What this means for cloud provider selection

When evaluating a cloud provider for APRA-regulated workloads, the practical checklist looks like this:

• Contractual rights. Can you audit them on reasonable notice? Can you require specific controls in writing? Can you terminate on breach without penalty?
• Regular assurance. SOC 2 Type II annually. ISO 27001 certification. ASD-IRAP assessment if you're handling classified or government-related data.
• Incident notification SLA. The provider must notify you of security incidents within a timeframe that lets you meet APRA's 72-hour requirement. Anything more than 24 hours in the contract is functionally too slow.
• Data residency. Australian residency is strongly preferred. It simplifies Privacy Act compliance, eliminates APP 8 cross-border disclosure layering, and aligns with APRA's stated expectations.
• Exit plan. Documented exit-and-portability plan. If you need to leave, can you get your data back in a usable, complete format within the contractually-agreed period?
• Fourth-party visibility. Who do they use as sub-processors? Are those parties contractually bound to equivalent standards?
• Cyber-incident response participation. Will they cooperate with your incident response? Provide forensic logs? Participate in tabletop exercises?

The documentation expectation

APRA expects you to document all of this. Your third-party risk management framework should include explicit reference to each cloud provider, the controls they provide, the residual risks you're accepting, and the Board's approval of those risks. If APRA comes asking — and on supervisory visits they do — you need to produce this file in days, not weeks.

The Board-level attestation under CPS 234 is more than a formality. Directors and senior executives are personally exposed under the FAR (Financial Accountability Regime) for information security failings that should have been caught by an adequate framework. The attestation is your evidence that the framework actually exists and is being used.

Common mistakes

• Accumulating cloud providers without documenting each. Every new SaaS that handles regulated data is another third-party risk that needs assessment, monitoring, and inclusion in the annual attestation. Most regulated entities have 50+ undocumented providers in the shadow.
• Treating SOC 2 as set-and-forget. A report from 18 months ago doesn't satisfy ongoing assurance. Some controls degrade.
• Skipping the exit plan. When the relationship ends, you need your data back in a form you can use. Many providers make this surprisingly hard.
• Ignoring fourth parties. Your provider's provider is now in scope under the 2024 amendments. If you don't know who they are, your framework is incomplete.
• Not testing the 72-hour incident notification. Tabletop the scenario annually. Find out where your assumptions break before APRA finds out.
• Cross-border data flow without explicit risk acceptance. If your provider stores or replicates data offshore, the Board needs to have accepted that risk in writing.

How Sydney-resident infrastructure simplifies the picture

A material part of the CPS 234 burden — for SMB regulated entities especially — is the cross-border data flow analysis. If your data is stored or processed offshore, you compound the assessment with APP 8 Privacy Act obligations, you take on fourth-party risk for any offshore sub-processor, and you increase the complexity of your incident-response coordination.

Using Australian-resident infrastructure collapses several of these compounding obligations into one analysis. ShareAndGo stores all content in Sydney (GCP australia-southeast1), with no US/EU edge caching of regulated content. For an APRA-regulated entity using ShareAndGo for sensitive document sharing, the third-party assessment is materially simpler than for an equivalent US-based provider.

Practical advice for mid-sized APRA entities

For most mid-sized APRA-regulated entities (say, $1-50B in assets), the practical operating model is:

• Pick a small number of cloud providers — five or six, not fifty. Each one is a thing you have to assess and defend.
• Get comprehensive documentation from each. Standardise on SOC 2 Type II + ISO 27001 as minimum.
• Build a standard template for your third-party risk assessment, refreshed annually.
• Run quarterly tabletop exercises. Document the lessons learned. APRA reads these on supervisory visits.
• Maintain a current incident response runbook. Test it.
• Make the Board CPS 234 attestation a real annual review, not a sign-off.

How ShareAndGo fits

For APRA-regulated entities sharing sensitive documents externally — auditor engagement, regulatory disclosure, prudential review correspondence — ShareAndGo provides Australian-resident, audit-traceable, NDA-gateable document sharing that aligns with CPS 234's third-party expectations. Our companion piece on ASIC obligations covers the corporate side; /industries/legal documents the workflow for prudentially-regulated counterparty arrangements.

This is general information about CPS 234. For specific compliance guidance speak to your risk or compliance function, or refer directly to APRA's published guidance at apra.gov.au.