APRA CPS 234 Compliance: What Australian Financial Entities Must Do, and How to Evidence It

APRA's own tripartite audit of over 300 regulated entities found that the majority had significant compliance gaps, and the number one problem was not that organisations hadn't tried to comply, it was that they couldn't demonstrate they had. This guide explains what CPS 234 actually requires, where most organisations fall short, and how continuous external risk monitoring closes the gap between what your policy documents say and what an APRA auditor can verify.

What Is APRA CPS 234 and Who Must Comply?

Prudential Standard CPS 234 (Information Security) is a mandatory standard issued by the Australian Prudential Regulation Authority (APRA). It came into force on 1 July 2019 and requires all APRA-regulated entities to maintain an information security capability that is commensurate with the size and nature of threats to their information assets. The goal is not compliance on paper. It is demonstrable, operational resilience.

CPS 234 applies to every legal entity regulated by APRA:

• Banking: Authorised deposit-taking institutions (ADIs), including banks, credit unions, building societies, and neobanks
• Insurance: General insurers, life insurance companies, reinsurance companies, and friendly societies
• Superannuation: Registrable superannuation entity (RSE) licensees and trustees
• Health insurance: Private health insurers regulated under the Private Health Insurance (Prudential Supervision) Act 2015
• Third-party providers: Any ICT service provider that manages information assets on behalf of an APRA-regulated entity, including cloud providers, managed service providers, and technology vendors

The third-party chain extends to your suppliers. If you are an ICT provider to an APRA-regulated entity, CPS 234 obligations flow down to you contractually. Your regulated clients are required to assess your information security capability and monitor it on an ongoing basis. Demonstrating your security posture to them is increasingly a commercial requirement, not just a regulatory one.

600+ APRA-regulated entities subject to CPS 234

300+ Banks, insurers & super funds assessed in APRA's tripartite audit

70% Entities that self-reported compliance gaps in early assessments

$250M Capital adequacy increase imposed on Medibank post-breach

The 7 Core Requirements: Plain-Language Breakdown

CPS 234 is structured around seven distinct requirement categories. Understanding what each one demands operationally, not just in regulatory language, is the foundation of any compliance programme.

Requirement 1: Board Accountability & Defined Roles (Para 13-16)

The Board is ultimately responsible for information security. Roles and responsibilities must be clearly defined across Board, senior management, governing bodies, and all individuals involved in information security decisions. This is not delegable to IT. It is a governance obligation.

Monitoring relevance: Monthly board-ready reports provide the documented evidence of active security oversight that boards need to demonstrate accountability.

Requirement 2: Maintaining Adequate Security Capability (Para 17-19)

Entities must maintain an information security capability commensurate with the size and extent of threats, and actively update it as threats evolve. Capability must cover people, processes, and technology, and must be proportional to risk profile.

Monitoring relevance: Vulnerability Insights and Threat Intelligence provide the continuous threat-awareness that "capability commensurate with threats" requires.

Requirement 3: Information Asset Identification & Classification (Para 20-23)

All information assets must be identified and classified by criticality and sensitivity. Controls must be applied based on classification. Assets managed by third parties must be included, not just internally managed systems.

Monitoring relevance: External attack surface scanning discovers assets (including forgotten subdomains and cloud resources) that may not appear in internal asset registers.

Requirement 4: Information Security Controls Implementation (Para 24-31)

Controls must protect information assets commensurate with their criticality. Controls must account for existing and emerging threats, the lifecycle of assets, and the consequences of a breach. Controls in third-party environments must be assessed and verified.

Monitoring relevance: Ongoing vulnerability scanning verifies whether controls are working, not just whether they are documented.

Requirement 5: Systematic Testing & Assurance (Para 32-36)

Controls must be tested regularly through a systematic programme that considers: rate of change in threats, criticality of assets, consequences of breach, and risks from environments where policies cannot be enforced. Testing must occur at least annually and after significant changes.

Monitoring relevance: Continuous external scanning provides documented ongoing testing between formal assessment cycles, directly addressing the "systematic programme" requirement.

Requirement 6: Detection, Response & 72-Hour Notification (Para 37-40)

Entities must have mechanisms to detect and respond to information security incidents in a timely manner. Material incidents must be reported to APRA within 72 hours. Material control weaknesses must be notified within 10 business days. Incident response plans must be tested annually.

Monitoring relevance: Real-time alerting on new vulnerabilities and dark web exposure compresses the detection window, giving you more time to remediate before the 72-hour clock starts.

Requirement 7: Internal Audit of Information Security Controls (Para 41-45)

Information security must be included in internal audit activities. Audits must cover the design and operating effectiveness of controls, including those maintained by third parties. Where internal audit lacks necessary skills, supplementary expertise must be used.

Monitoring relevance: Monthly reports provide independent external evidence that auditors can reference, supplementing internal audit where security skills are limited.

The 6 Gaps APRA Found in Its Own Industry Audit

Between 2021 and 2023, APRA conducted an independent tripartite cyber assessment across more than 300 APRA-regulated entities, the largest study of its kind in Australian history. Each entity was required to appoint an independent auditor to assess their CPS 234 compliance. The results were sobering.

APRA identified six common control gaps that appeared consistently across the industry. Understanding where the industry failed is the most efficient way to prioritise your own compliance programme.

Gap 1: Incomplete Information Asset Identification & Classification

Entities couldn't demonstrate a complete, current inventory of information assets, particularly those managed by third parties or hosted in cloud environments.

How monitoring addresses this: External attack surface discovery maps all internet-facing assets, including those not tracked in internal registers.

Gap 2: Limited Third-Party Information Security Assessment

Most entities had done some initial vendor assessment but couldn't demonstrate ongoing, continuous monitoring of third-party security posture, which is what CPS 234 requires.

How monitoring addresses this: Vendor Insights module monitors critical supplier security posture continuously, not just at onboarding.

Gap 3: Inadequate Control Testing Programs

Testing was either too infrequent, too narrow in scope, or lacked clear success criteria. Many entities relied on annual penetration tests as their sole testing evidence.

How monitoring addresses this: Continuous external scanning provides documented testing activity between formal assessment cycles, broadening the evidence base.

Gap 4: Incident Response Plans Not Tested

Plans existed on paper but were not tested annually as required. Organisations couldn't demonstrate that plans were fit for purpose or that relevant staff knew their roles.

How monitoring addresses this: Real-time alerting creates regular practice opportunities for response workflows, and the alert history provides evidence of detection capability.

Gap 5: Limited Internal Audit of Security Controls

Internal audit teams often lacked the cybersecurity expertise to assess information security controls effectively, particularly for third-party and cloud environments.

How monitoring addresses this: Monthly external reports provide independent, technical evidence that internal audit teams can incorporate as supplementary assurance.

Gap 6: Inconsistent Incident & Weakness Reporting to APRA

Entities were not consistently reporting material incidents and control weaknesses to APRA within required timeframes, often due to unclear criteria or slow detection.

How monitoring addresses this: Continuous monitoring accelerates detection, giving more time for assessment and notification before regulatory deadlines.

Enforcement is real. APRA's response to the Medibank data breach was to impose a $250 million increase in capital adequacy requirements, maintained until completion of a remediation programme. This is not a fine; it is a standing capital cost. For smaller entities, the equivalent proportional impact would be significant. APRA has also made clear that non-compliance can trigger increased supervisory oversight, formal enforcement action, and public disclosure of breaches.

What "Continuous Monitoring" Actually Means Under CPS 234

The phrase "continuous monitoring" appears throughout CPS 234's accompanying guidance (CPG 234) and in APRA's public commentary on the tripartite assessment findings. But regulators rarely define exactly what "continuous" means in practice, and that ambiguity is where many entities fall short.

APRA's CPG 234 makes the expectation reasonably clear: entities should have mechanisms that provide timely detection of information security threats and vulnerabilities, not detection after the fact, not annual detection, but detection at a rate commensurate with the rate at which the threat landscape changes.

In operational terms, this translates to three distinct monitoring layers:

1. External Attack Surface Monitoring

Your internet-facing infrastructure is the first thing an attacker sees, and it changes constantly. New subdomains are spun up, SSL certificates expire, software versions are updated (or not updated), cloud instances are misconfigured, and open ports appear without IT's knowledge. Continuous external monitoring means knowing what your attack surface looks like right now, not what it looked like at your last penetration test six months ago.

The average organisation has 30% more internet-facing assets than its IT team knows about. Under CPS 234, those unknown assets are still your liability, and APRA auditors look for asset inventories that are complete, not optimistic.

2. Credential and Data Exposure Monitoring

Compromised employee credentials are among the most common entry points for cyberattacks on financial institutions. When credentials from your organisation appear in dark web breach databases, stealer logs, or credential marketplaces, you have a limited window to force password resets before those credentials are used. CPS 234's requirement to detect and respond "in a timely manner" is directly implicated, because the average window between a credential being stolen and being used in an attack is measured in hours to days, not weeks.

3. Third-Party Security Monitoring

CPS 234 requires continuous monitoring of third-party security capability, not just initial assessment. This means tracking whether your critical ICT providers' security posture changes over time: whether new vulnerabilities appear in their internet-facing systems, whether their SSL configurations degrade, whether their staff credentials appear in breach data. A vendor that was secure at onboarding may not remain secure, and your regulatory obligation does not end at onboarding.

Why Point-in-Time Assessment Is Not Enough

CPS 234 Third-Party Risk: Your Vendor Oversight Obligations

Third-party risk management is the area where APRA's tripartite audit found the most widespread gaps, and the one where regulatory expectations are most frequently misunderstood. The common misconception is that conducting a vendor assessment at onboarding satisfies CPS 234. It does not.

CPS 234 paragraphs 24-31 make clear that information security controls must be applied and assessed for all information assets, including those managed by third parties. And CPG 234 explicitly states that APRA's expectation is that regulated entities take reasonable steps to satisfy themselves that third parties maintain sufficient information security on an ongoing basis.

What This Means in Practice

Your CPS 234 third-party risk obligations cover the full lifecycle of every vendor relationship with access to your information assets:

• Before onboarding: Security capability assessment proportional to the criticality of the vendor's access
• During the relationship: Ongoing monitoring of the vendor's security posture, not just trust that nothing has changed since onboarding
• At contract review: Evidence that the vendor's CPS 234-aligned controls remain effective
• At offboarding: Confirmation that access has been appropriately revoked and data returned or destroyed

APRA's key concern: the fourth-party problem. CPS 234's accompanying guidance notes that many third parties rely on their own sub-contractors. APRA expects regulated entities to take reasonable steps to satisfy themselves that this sub-contracting chain does not introduce unacceptable risk. Vendor monitoring that surfaces changes in a supplier's security posture, including their own third-party dependencies, directly addresses this expectation.

The 72-Hour Incident Notification Requirement, and How Monitoring Helps You Meet It

CPS 234 imposes two distinct notification timelines that are easy to misremember and easy to breach if your detection capability is slow:

T+0: Incident Occurs: Attack, breach, or control failure happens

72 hours: APRA Notified: Material incidents must be reported within 72 hours of becoming aware

10 business days: Control Weakness: Material control weaknesses that cannot be promptly remediated must be notified within 10 business days

Promptly: Ongoing Updates: Updates on material incidents must continue until resolved

The critical phrase in the 72-hour rule is "within 72 hours of becoming aware." This means your notification obligation starts not when the incident occurred, but when you detected it. If your detection capability is slow (if you discover a breach days or weeks after it happened) the 72-hour clock was already running before you knew about it.

This is not a hypothetical problem. The Medibank breach, which triggered APRA's $250 million capital adequacy action, involved an attacker who had been present in Medibank's environment for an extended period before detection. The delay in detection compressed the time available for assessment, notification, and response.

Continuous monitoring, specifically real-time alerting on credential exposure, new vulnerabilities, and anomalous external-facing changes, is the most effective way to compress the gap between when an incident begins and when you become aware of it. That compression directly protects your ability to meet the 72-hour notification obligation.

How CyberInsights Addresses CPS 234 Requirements Module by Module

CyberInsights is not a GRC platform and it does not replace your information security policy framework, incident response plan, or internal audit function. What it does is provide the continuous external monitoring layer that CPS 234 requires you to have, and that most APRA-regulated entities were found to be missing in the tripartite audit.

Vulnerability Insights

CPS 234 paragraphs addressed: Para 17 (Security capability), Para 24 (Controls), Para 32 (Control testing), Para 37 (Incident detection)

Continuous external scanning of all internet-facing assets. Identifies unpatched CVEs, misconfigured services, expired SSL certificates, and open ports, updated daily so new vulnerabilities are caught as soon as they are disclosed. Provides the documented testing evidence that "systematic testing programme" requires between formal penetration test cycles.

Data Exposure

CPS 234 paragraphs addressed: Para 17 (Security capability), Para 37 (Incident detection), Para 41 (Internal audit support)

Dark web monitoring across breach databases, stealer logs, and credential marketplaces. Surfaces compromised employee and privileged-account credentials before they are used in an attack. Compresses the detection window for credential-based incidents, directly supporting the 72-hour notification requirement. Provides an independent evidence stream for internal audit review.

Vendor Insights

CPS 234 paragraphs addressed: Para 24 (Third-party controls), Para 32 (Third-party testing), Para 20 (Asset classification)

Continuous external security monitoring of critical ICT third-party providers. Tracks changes in their vulnerability profile, SSL configuration, and data exposure. Directly addresses Gap 2 from APRA's tripartite audit, the most widespread failing. Provides the ongoing third-party assurance that CPG 234 explicitly requires, not just onboarding-point assessment.

Brand & Typosquat

CPS 234 paragraphs addressed: Para 17 (Security capability), Para 37 (Incident detection)

Monitors for typosquat domains, phishing infrastructure targeting your organisation, and brand impersonation. Financial sector entities are among the highest-value targets for phishing campaigns. Early detection of impersonation infrastructure allows proactive takedown before customers or staff are compromised.

Threat Intelligence

CPS 234 paragraphs addressed: Para 17 (Security capability), Para 32 (Threat-aware testing), Para 41 (Board reporting)

Sector-relevant threat actor activity, CVE prioritisation based on active exploitation, and early warning of campaigns targeting Australian financial institutions. CPS 234 requires security capability to be "commensurate with threats." This means knowing which threats are active, not just which vulnerabilities exist. Provides the threat context for board-level risk reporting.

The Compliance Evidence Trail APRA Auditors Actually Look For

This is the section that most compliance guides skip, and the reason so many APRA-regulated entities fail their tripartite assessments despite having genuinely invested in security. The gap is not always between what you do and what CPS 234 requires. Sometimes the gap is between what you do and what you can prove you do.

APRA does not take organisations at their word. The tripartite assessment framework is specifically designed to test whether documented policies are matched by operational reality. Independent auditors look for contemporaneous, timestamped evidence that monitoring is happening, not assertions that it happens.

What Auditors Look For

The critical insight here is that a monthly external risk report is not just a security tool. It is a compliance document. It is timestamped evidence, produced by an independent external platform, that monitoring is active, findings are being identified, and your security posture is being tracked over time. That is exactly the kind of evidence that satisfies the "continuous monitoring" requirement in a way that a policy document never can.

The trend data matters as much as the findings. APRA auditors do not just look at what your current security posture is. They look at whether it is improving. A series of monthly reports showing a reduction in Critical findings, a decrease in exposed credentials, and an expanding vendor monitoring programme tells a compliance story that a single point-in-time assessment cannot. It demonstrates not just that you are compliant today, but that you have a functioning, improving security programme.

Your CPS 234 Compliance Checklist: 22 Actionable Items

Use this checklist to audit your current posture against CPS 234's core requirements. Each item maps to the relevant paragraphs of the standard and indicates whether it requires a policy activity, a technical capability, or documented evidence.

Governance & Board Accountability (Para 13-16)

• [ ] Board-approved information security policy in place, with documented board-level accountability (not delegated entirely to IT or management) [Para 13]
• [ ] Information security roles and responsibilities clearly defined across Board, senior management, governing bodies, and all relevant individuals [Para 14]
• [ ] Regular board-level security reporting in place demonstrating active oversight, not just annual update presentations [Para 13]

Information Security Capability (Para 17-19)

• [ ] Security capability documented and proportional to current threat landscape, not based on threats as they were when the programme was designed [Para 17]
• [ ] Continuous external monitoring programme in place covering vulnerability scanning, credential monitoring, and threat intelligence [Para 17]
• [ ] Security capability review process defined, with evidence of capability being updated as threats evolve [Para 19]

Information Asset Identification & Classification (Para 20-23)

• [ ] Complete, current inventory of all information assets, including those managed by third parties and hosted in cloud environments [Para 20]
• [ ] All information assets classified by criticality and sensitivity, with controls applied according to classification [Para 21]
• [ ] External attack surface discovery conducted to identify internet-facing assets not captured in internal asset registers [Para 20]

Information Security Controls (Para 24-31)

• [ ] Information security controls implemented and commensurate with the criticality and sensitivity of each information asset class [Para 24]
• [ ] Controls applied to third-party managed information assets, with documented evidence of assessment, not just contractual provisions [Para 27]
• [ ] Vulnerability management process in place with defined SLAs for Critical, High, and Medium findings [Para 24]

Control Testing & Assurance (Para 32-36)

• [ ] Systematic testing programme defined with documented scope, frequency (at minimum annual), and clear success criteria [Para 32]
• [ ] Continuous external scanning in place to provide documented testing activity between formal assessment cycles [Para 32]
• [ ] Testing results reported to board or senior management, including any control deficiencies that cannot be remediated promptly [Para 36]
• [ ] Third-party control testing included in scope, not just internal systems [Para 33]

Incident Management & APRA Notification (Para 37-40)

• [ ] Incident detection mechanisms in place, including external monitoring for credential exposure and vulnerability changes [Para 37]
• [ ] Incident response plan documented, tested annually, and fit-for-purpose, with named roles and escalation paths [Para 38]
• [ ] APRA notification process defined: 72-hour timeline for material incidents, 10 business days for material control weaknesses [Para 39]
• [ ] Criteria for "material incident" and "material control weakness" documented and reviewed by legal/compliance [Para 39]

Internal Audit (Para 41-45)

• [ ] Information security included in internal audit scope, covering design and operating effectiveness of controls [Para 41]
• [ ] Third-party controls included in internal audit scope, with external evidence (e.g. vendor monitoring reports) incorporated where internal audit lacks technical skills [Para 42]

The Bottom Line: Policy Isn't Proof

APRA's tripartite audit delivered a clear message to the Australian financial sector: the bar for CPS 234 compliance is not a documented policy and good intentions. It is demonstrable, operational, continuous security capability, with the evidence to prove it.

The six gaps APRA identified across 300+ entities all share a common thread: they are gaps between what organisations said they did and what an independent auditor could verify they actually did. Asset inventories that were incomplete. Vendor monitoring that stopped at onboarding. Testing programmes that were annual at best. Incident detection that was reactive rather than proactive.

Continuous external monitoring, covering your own attack surface, your credential exposure, your vendors, and the threat landscape, directly addresses all six gaps. Not by replacing your security programme, but by producing the ongoing, timestamped, independent evidence that turns a policy document into a demonstrable compliance reality.

For APRA auditors, the question is not "do you have a monitoring policy?" It is "show me the last 12 months of monitoring outputs." Monthly external risk reports are the answer to that question.

Frequently Asked Questions

What does CPS 234 require for external monitoring?

CPS 234 requires APRA-regulated entities to maintain an information security capability commensurate with the size and extent of threats to their information assets. In practice, this means continuous monitoring of your external attack surface, credential exposure across dark web sources, and the security posture of third-party providers, with documented evidence that this monitoring is active and producing actionable outputs.

How often must CPS 234 compliance be evidenced?

CPS 234 does not specify a single reporting frequency, but APRA's accompanying guidance (CPG 234) and tripartite audit findings make clear that annual or quarterly evidence is insufficient. Entities must demonstrate ongoing, continuous monitoring activity with timestamped outputs. Monthly external risk reports are the most practical way to satisfy this expectation and provide auditors with the evidence trail they look for.

What is the relationship between CPS 234 and CTEM?

Continuous Threat Exposure Management (CTEM) is a framework that operationalises many of the outcomes CPS 234 requires, including continuous asset discovery, credential monitoring, vendor risk tracking, and documented evidence of security posture over time. Adopting a CTEM approach directly addresses the six control gaps APRA identified in its tripartite audit of over 300 regulated entities.

Does CPS 234 require dark web monitoring?

CPS 234 requires entities to detect and respond to information security incidents in a timely manner, and compromised credentials are among the most common initial access vectors for attacks on financial institutions. While the standard does not name dark web monitoring explicitly, monitoring breach databases and stealer log repositories is the only practical way to detect credential exposure before those credentials are used in an attack.