Back to Blog
Insights11 min read

How to Audit CPS 234 Compliance in Australia

A

Alexander Sverdlov

Security Analyst

7/20/2026
How to Audit CPS 234 Compliance in Australia

Most CPS 234 assessments I am asked to run start the same way: the compliance team has a binder of policies, the board has signed an attestation, and everyone assumes the controls actually work. Then we test them and find that privileged accounts have no MFA, the "annual" control testing was a vendor questionnaire nobody reviewed, and the last time anyone rehearsed the APRA notification process was never. Auditing CPS 234 is not a paperwork exercise. It is the difference between an attestation you can defend and one that falls apart the moment APRA or an actual attacker applies pressure.

I am Alexander Sverdlov, founder of Atlant Security. I have run more than 200 security assessments across 14 countries since 2013, including for regulated financial entities, and this guide is the audit approach I actually use for APRA's Prudential Standard CPS 234. It is written for the CISO, head of risk, or CTO who has to sign something and needs it to be true.

What CPS 234 Actually Requires You to Prove

CPS 234 has applied to all APRA-regulated entities since 1 July 2019: authorised deposit-taking institutions, general and life insurers, private health insurers, and superannuation (RSE) licensees. It is short, principles-based, and unforgiving because it does not tell you which controls to buy. It tells you what outcomes you must be able to demonstrate. An audit of CPS 234 is really an audit of whether you can evidence each of these obligations:

  • Roles and responsibilities. The board is ultimately accountable for information security. Roles for the board, senior management, governing bodies, and individuals are clearly defined.

  • Information security capability. Capability is commensurate with the size and extent of threats, and is maintained across the entity and its third parties.

  • Policy framework. A documented information security policy framework commensurate with exposures and vulnerabilities.

  • Asset identification and classification. Information assets, including those managed by third parties, are identified and classified by criticality and sensitivity.

  • Controls implementation. Controls are implemented commensurate with the criticality and sensitivity of the assets they protect.

  • Incident management. Mechanisms exist to detect and respond to incidents in a timely manner, with response plans that are maintained and tested.

  • Testing control effectiveness. A systematic testing program evaluates control effectiveness, with results escalated to the board and senior management.

  • Internal audit. Internal audit reviews the design and operating effectiveness of information security controls, including those of third parties.

  • APRA notification. Notify APRA within 72 hours of a material information security incident, and within 10 business days of identifying a material control weakness you cannot remediate in a timely manner.

A useful companion is APRA's Prudential Practice Guide CPG 234, which sets out expectations in more detail. Read the standard and the guide together before you audit against them. And be precise about consequences: APRA is a prudential regulator, not a fining authority in the consumer sense. The real exposure is enforceable undertakings, additional capital requirements, licence conditions, intensified supervision, and the reputational and commercial damage that follows a public failure. That is worse than a line-item fine, and it is the reason boards care.

Step 1: Scope Against a Complete, Current Asset Register

You cannot audit controls over assets you have not listed. The first thing I ask for is the information asset register, and it is almost always incomplete. Shadow SaaS, a decommissioned database that still holds production data, a fintech integration nobody documented, a third-party administrator processing member data offshore - these are the assets that make attestations false.

Reconcile the register against reality:

  • Cross-check the register against cloud billing, SSO application logs, DNS records, and the CMDB. Anything that appears in one source but not the register is a finding.

  • Confirm each asset has an owner, a criticality rating, and a sensitivity classification that a human actually applied, not a default value.

  • Trace where regulated data flows to third parties and fourth parties. CPS 234 explicitly extends to assets managed by related parties and service providers.

If the register is stale, stop and fix it before assessing anything else. Every downstream conclusion depends on it.

Step 2: Test Governance, Not Just Read It

Governance findings are where audits look weakest to APRA because they are easy to fake with a template and hard to fake under questioning. Read the policy framework, then interview the people named in it.

  • Ask a board or committee member to describe, in their own words, the entity's material information security risks and what they receive to oversee them. If the board only sees a green dashboard, oversight is nominal.

  • Confirm roles are defined and staffed. A named security function on an org chart with one overloaded person is a capability gap under CPS 234, not a control.

  • Check that the policy framework is version-controlled, reviewed on a defined cycle, and mapped to the assets and threats it claims to address.

When governance is genuinely weak, the fix is usually structural: a clearer reporting line, a real security capability, and board reporting that includes control test results rather than only project status. A virtual CISO engagement is a legitimate way for smaller entities to close a governance and capability gap without pretending a part-time hire covers it.

Step 3: Validate Controls By Attacking Them

This is where most self-assessments break. A control that exists in a policy is not the same as a control that works in production. When I validate CPS 234 controls, I test the operating effectiveness, not the documented design.

  • Identity and access. Enumerate every privileged and remote-access path and confirm MFA is enforced, not just enabled. Phishing-resistant factors for administrators. Verify joiner-mover-leaver processes by sampling recent terminations and checking whether access was actually revoked.

  • Vulnerability and patch management. Do not accept a scan summary. Pull the raw data, check coverage against the asset register, and confirm that high-severity findings are remediated within the SLA the policy claims.

  • Segmentation and exposure. Validate that internet-facing surface matches the register and that critical systems are segmented from the general corporate network.

  • Logging and detection. Confirm that the systems classified as critical are actually feeding the SIEM and that someone would see an alert, out of hours, if they fired.

A structured IT security audit combined with hands-on penetration testing is the honest way to evidence the "systematic testing" obligation, because it produces results an internal author cannot quietly soften. A vulnerability assessment handles breadth; penetration testing proves whether the controls that matter would stop a capable attacker.

Step 4: Rehearse Incident Response and the APRA Clock

The 72-hour material-incident notification and the 10-business-day control-weakness notification are the obligations most entities have never practised. A tabletop exercise tells you the truth fast.

  • Run a realistic scenario, for example ransomware on a critical system or a third-party administrator breach, and time how long it takes the group to decide the incident is material.

  • Confirm who is authorised to notify APRA, whether they know the reporting channel, and whether legal, communications, and the board are looped in on the same timeline.

  • Check that response plans are current, name real people, and account for the third parties who hold your data.

"Materiality was unclear so nobody started the clock" is the failure mode I see most. Fix it by pre-defining materiality thresholds and giving a named person the authority to trigger the process.

Step 5: Make Internal Audit Independent and Real

CPS 234 explicitly requires internal audit to review the design and operating effectiveness of information security controls, including those maintained by third parties. Two questions decide whether this holds up:

  • Independence. The people testing the controls cannot be the people who built or operate them. If your security team audits itself, APRA will discount the result, and rightly so.

  • Competence. Reviewing information security controls needs genuine security skill. A generalist auditor ticking a checklist will miss the findings that matter. Co-sourcing to a specialist is expected practice and is explicitly contemplated by CPG 234.

CPS 234 Audit Readiness at a Glance

CPS 234 obligation

What weak looks like

What defensible looks like

Roles and responsibilities

Board sees only a green dashboard

Board receives control test results and material risk reporting

Asset identification

Register out of date, shadow IT uncounted

Register reconciled to cloud, SSO, and CMDB with owners and classification

Controls implementation

MFA "enabled" but not enforced on admin paths

MFA enforced and tested on every privileged and remote path

Testing effectiveness

Annual vendor questionnaire filed unread

Independent testing and pen testing with tracked remediation

Incident management

Notification process never rehearsed

Tabletop-tested plan with pre-defined materiality and named owners

Internal audit

Security team reviews its own controls

Independent, security-competent review including third parties

The Mistakes That Sink Real Audits

  • Auditing the design, not the operation. A policy that says MFA is required proves nothing. Test the running configuration.

  • Ignoring third and fourth parties. CPS 234 follows your data wherever it goes. An offshore administrator or a critical SaaS vendor is in scope even if you would rather it were not.

  • Confusing an attestation with assurance. Signing the annual attestation without independent testing behind it is the single most common weakness I find.

  • Treating CPS 234 in isolation. CPS 230 (operational risk management, effective 1 July 2025) raises the bar on third-party and operational resilience. Align your CPS 234 work with it rather than auditing the same vendors twice.

If you want the standards and controls side by side, our comparison of CPS 234 versus NIST 800-53 is a useful companion, and CPS 234 best practices goes deeper on the day-to-day program.

Frequently Asked Questions

How often should we audit CPS 234 compliance?

Internal audit should review information security controls on a risk-based cycle, with critical controls covered at least annually. Control effectiveness testing under the systematic testing program runs more frequently, and you re-test whenever a material change to systems, threats, or third parties occurs.

Does CPS 234 require an external auditor?

The standard requires internal audit to review controls, and it must be independent and competent. It does not mandate an external firm, but APRA may request an independent review, and many entities co-source specialist security assessors precisely because their internal audit function lacks deep security expertise.

What counts as a material information security incident for the 72-hour rule?

One that has materially affected, or could materially affect, the entity, its depositors, policyholders, or members, or that has been notified to another regulator. Because the judgement call is where entities lose time, pre-define materiality thresholds and give a named person authority to start the clock.

Are our cloud providers and outsourced administrators in scope?

Yes. CPS 234 applies to information assets managed by related parties and third parties. You are responsible for assessing and evidencing the controls protecting your regulated data wherever it is processed or stored, including offshore.

Can a smaller entity meet the capability requirement without a full security team?

Capability must be commensurate with your size and threat exposure, not identical to a major bank's. Smaller RSE licensees and insurers commonly meet the bar through a combination of a fractional security leader and specialist assessment partners. A fintech-focused virtual CISO or part-time CISO is a recognised way to do this.

Get Your CPS 234 Attestation to Something You Can Defend

A CPS 234 audit is worth doing only if it tells you the truth. If your last review was a questionnaire and you would rather find the gaps before APRA or an attacker does, we run independent, evidence-based CPS 234 assessments that test controls in production and give the board something real to sign. Talk to Atlant Security about an assessment scoped to your entity.

Alexander Sverdlov

Alexander Sverdlov

Founder of Atlant Security. Author of 2 information security books, cybersecurity speaker at the largest cybersecurity conferences in Asia and a United Nations conference panelist. Former Microsoft security consulting team member, external cybersecurity consultant at the Emirates Nuclear Energy Corporation.