APRA CPS 230 and CPS 234 compliance: where the evidence requirements break automated security pipelines
Geert WarmenbolApril 29, 2026
Key takeaways
CPS 230 and CPS 234 have different notification triggers: CPS 234 clause 42 requires notification when an information security incident has a 'material' impact on information assets; CPS 230 paragraph 74 triggers when an event has materially impacted the ability to manage operational risk. A single incident can trigger both, requiring coordinated notification processes most organizations have not built.
CPS 234 clause 28 requires penetration testing by a qualified independent party — but the standard does not define 'qualified,' and APRA has indicated in practice that in-house security teams conducting tests against their own infrastructure do not satisfy the independence requirement regardless of their technical capability.
The CPS 234 third-party access requirements under clauses 33-36 extend to terminated vendors: access must be revoked and evidence of revocation must be maintained. Vulnox assessments of Australian financial services environments consistently find active VPN credentials and API keys belonging to vendors whose contracts ended 6 to 18 months prior.
Automated vulnerability management pipelines satisfy CPS 234 clause 27 scanning requirements but routinely fail clause 29 evidence requirements: APRA expects evidence that vulnerabilities were assessed for operational risk impact, not just detected and patched. Those are different outputs requiring different pipeline stages.
CPS 230 requires scenario testing of critical operations under plausible stress conditions (paragraph 58). The specific failure in assessed environments is scenarios that test technical recovery without testing the decision-making chain — who declares an incident, who communicates to APRA, and within what timeframe. Technical resilience passes; governance resilience fails.
TL;DR
The CPS 230 and CPS 234 compliance problem for Australian financial services is not that the standards are contradictory — they are not. The problem is that building evidence pipelines satisfying both simultaneously is harder than it looks, because the evidence each standard requires is different in format, timing, and organizational scope. Most compliance programs produce evidence for each standard separately, which works for audits and breaks during actual regulatory inquiries.
Where the overlap breaks in practice
A regional ADI had built what looked like a functional integrated compliance program. Vulnerability scans ran weekly, results fed into a risk register, the risk register was reviewed quarterly by the board risk committee. CPS 234 clause 27 satisfied. CPS 230 board oversight of operational risk documented.
APRA requested evidence following an information security incident that had caused a four-hour outage to a payment processing service. They wanted the incident timeline in machine-readable format, the vulnerability assessment that should have identified the exploited component, evidence that the board had been notified within the required timeframe, and documentation showing the third-party service provider involved had been assessed for information security capability under CPS 234 clause 34 prior to engagement.
The vulnerability scan that should have identified the component had run. The finding was in the risk register. It had been rated medium severity and scheduled for remediation in the next quarter. The rating methodology was internal — it assessed likelihood and technical impact. It had not assessed operational risk impact, which CPS 230 requires. APRA's question was not 'did you know about this vulnerability?' It was 'did you assess its operational risk implications and act accordingly?' The pipeline produced the wrong evidence for the question being asked.
The gap was not in the controls. The vulnerability management pipeline was functioning. The gap was that the pipeline was built to satisfy CPS 234 clause 27 scanning requirements and was not designed to produce the operational risk assessment evidence CPS 230 paragraph 55 requires. Two standards, one pipeline that satisfied one of them.
Why the evidence requirements diverge where they matter most
CPS 234 is primarily an information security standard. Its evidence requirements are technical: what was scanned, what was found, what was patched, who has access to what, when was access reviewed. The outputs of a well-configured security operations pipeline — scan results, patch records, access review logs, penetration test reports — map reasonably well to CPS 234 evidence requirements.
CPS 230 is an operational risk standard. Its evidence requirements are operational: what could disrupt critical business functions, how would the disruption be managed, who makes decisions during disruption, how quickly can normal operations be restored. The outputs of the same security operations pipeline do not map to these requirements because the pipeline is designed to detect and remediate technical findings, not to assess their operational risk implications.
The intersection of the two standards is where the evidence gap is widest. When an information security event causes operational disruption — which is the scenario both standards are most concerned with — the organization needs to produce evidence that satisfies both evidence frameworks simultaneously: technical evidence of what happened (CPS 234) and operational evidence of how risk was managed and communicated (CPS 230). Most compliance programs have each type of evidence in separate systems with separate owners and no automated process connecting them.
The notification trigger difference compounds this. CPS 234 clause 42 requires notification to APRA of material information security incidents. CPS 230 paragraph 74 requires notification when an operational risk event has materially impacted the ability to manage operational risk. A ransomware attack that encrypts the trading system triggers both. The CPS 234 notification goes to APRA's prudential supervision team; the CPS 230 notification goes to the same team but under a different reporting obligation with different content requirements. Organizations that have not mapped the dual trigger explicitly discover during the incident that they have two notification obligations with potentially different timelines and different content, both running simultaneously.
Example
In Vulnox assessments of Australian financial services environments, the most consistent gap in CPS 234 clause 34 compliance is third-party information security capability assessment: the standard requires assessing whether service providers have adequate information security controls before granting access. Assessment records exist for initial vendor onboarding. They do not exist for access scope changes after onboarding, and they do not exist for the access that remains after contracts terminate. Active credentials belonging to terminated vendors — VPN access, API keys, database connection strings — appear in a consistent fraction of assessed environments, credentials that were never revoked because offboarding processes did not route through the same system that tracked the CPS 234 assessment.
The CPS 234 clause 34 assessment requirement creates a specific pipeline problem: the assessment must be documented at the time of access grant, which means the pipeline needs to gate access provisioning on completion of the assessment. Most identity and access management pipelines do not include a compliance gate. Access is provisioned when the business request is approved; the CPS 234 assessment may happen separately and may not be linked to the access record in any way that satisfies APRA's evidence standard during an inquiry.
What assessment data shows about CPS 230 and CPS 234 implementation
Assessment base: Findings from Vulnox assessments of Australian financial services organizations subject to APRA prudential standards.
Vulnerability severity ratings that satisfy CPS 234 but fail CPS 230 evidence requirements
Vulnerability management pipelines in assessed Australian financial services environments rate findings using CVSS scores or internal risk matrices calibrated against technical impact and likelihood of exploitation. CPS 230 requires that operational risk be assessed — which means a medium-CVSS vulnerability in a component that processes payment transactions has a higher operational risk rating than a high-CVSS vulnerability in an internal tool with no customer-facing function. The distinction matters because CPS 230 paragraph 55 requires operational risk events to be managed based on their operational impact. A vulnerability management pipeline that does not produce an operational risk impact assessment alongside the technical severity rating produces evidence for CPS 234 and not for CPS 230.
The client assumption is that a functioning vulnerability management program satisfies both standards. It satisfies the scanning and remediation tracking requirements of CPS 234. It does not satisfy the operational risk assessment requirements of CPS 230 unless it is specifically extended to include an operational impact assessment stage. Adding that stage to an existing pipeline is a configuration and process change, not a new system — but it requires understanding what evidence CPS 230 expects, which is different from what CPS 234 expects.
Active third-party access credentials for terminated vendor relationships
CPS 234 clauses 33-36 require that third-party access be managed, assessed, and revoked when no longer required. In assessed environments, active credentials belonging to vendors whose contracts ended 6 to 18 months prior were present in every environment where a detailed third-party access audit was conducted. The mechanism is consistent: vendor access is provisioned through an identity management system, vendor contracts are managed through a procurement system, and the two systems are not connected by any automated offboarding trigger. Access persists until someone manually identifies that it should be revoked.
The compliance documentation typically shows a vendor access review process and periodic access certification. The access certification reviews access that the identity management system knows about, against a current vendor list from procurement. Vendors removed from the procurement system before the last access certification cycle have access that no longer appears in either system in a way that would trigger review. The access exists. The review process cannot see it.
Business continuity scenario tests that test recovery but not governance
CPS 230 paragraph 58 requires scenario testing of critical operations. In assessed environments, scenario tests demonstrate that systems can be recovered within defined RTO objectives. They do not test the governance chain: who declares an operational risk event, who authorizes escalation to APRA notification, who communicates with regulators and within what timeframe, and who has delegated authority when primary personnel are unavailable. APRA's focus in CPS 230 inquiries is frequently on whether governance worked during the event, not only whether systems recovered.
Technical resilience and governance resilience are different. A scenario test that passes because systems recovered within RTO may fail against APRA's actual inquiry questions if the test did not include a simulated notification process, a documented decision log, and evidence that escalation thresholds were correctly applied. The test produces evidence that systems recovered. APRA may want evidence that the operational risk governance framework functioned.
The compliance efficiency that creates the audit gap
Common belief
Building a unified compliance program that satisfies both CPS 230 and CPS 234 with shared controls, shared evidence, and shared reporting reduces compliance overhead and produces better outcomes than maintaining separate programs for each standard.
What we found
A superannuation fund had a mature, unified CPS 230/234 compliance program with a single vendor risk framework, single incident response plan, and consolidated board reporting. During a CPS 234 independent security assessment, the assessor requested clause 34 evidence for the fund's core administration system provider. The unified vendor assessment record showed a security rating and a questionnaire response. It did not contain evidence that information security capability had been specifically assessed against CPS 234 requirements. The unified assessment had been designed against the organization's internal vendor risk framework, which predated CPS 234 and had not been updated when the standard came into effect.
The unified program argument is correct about overhead reduction and incorrect about evidence completeness. The problem is which controls get unified. Organizations building integrated CPS 230/234 programs typically unify the controls that overlap cleanly — incident response plans, board reporting, vendor risk management frameworks — and produce single outputs that they reference for both standards. This works for documentation review.
It breaks for the controls where the standards overlap in topic but diverge in evidence requirement. Third-party risk management is the clearest example: CPS 234 clauses 33-36 require evidence of information security capability assessment for third parties with access to information assets. CPS 230 paragraph 66 requires evidence of due diligence on service providers that support critical operations. These can be unified into one vendor assessment process — but the output of that process needs to contain two different types of evidence. A unified vendor assessment that produces a security questionnaire response satisfies neither standard's full evidence requirement. The standards describe the same activity but want different evidence of it.
The counterintuitive outcome: organizations with unified compliance programs sometimes have worse evidence quality for individual standard requirements than organizations running separate programs, because the unification optimized for process efficiency rather than evidence completeness.
Where automated pipelines produce the wrong evidence
Patch records that satisfy CPS 234 and miss CPS 230
CPS 234 clause 27 requires timely remediation of vulnerabilities. Automated patch management pipelines produce records of what was patched and when, which satisfies the CPS 234 remediation evidence requirement. CPS 230 paragraph 55 requires that operational risk events be identified, assessed, and managed. A vulnerability that was detected, rated, and scheduled for patching is an operational risk event if it affects a critical operation. The patch record shows it was remediated. It does not show that the period between detection and remediation was assessed for operational risk, that compensating controls were applied during that period, or that the risk acceptance decision was documented. APRA inquiries following exploited vulnerabilities focus on that period.
The CPS 234 independent assessment and in-house security teams
CPS 234 clause 28 requires that the board ensure information security capability is assessed by a qualified independent party at least every three years and following significant change. In practice, APRA expects this to mean external to the organization — not a different team within the same organization. Organizations that have conducted internal red team exercises or internal security reviews and documented them as satisfying the clause 28 independent assessment requirement have discovered during APRA inquiries that the independence interpretation is stricter than the text alone implies. The qualified independent party needs to be independent of the APRA-regulated entity.
Dual notification obligations running simultaneously
CPS 234 clause 42 and CPS 230 paragraph 74 can both trigger from the same incident. The notification processes are typically owned by different teams — information security for CPS 234, operational risk for CPS 230 — with different escalation paths and different content requirements. Incidents that trigger both obligations simultaneously require coordination between those teams that most incident response plans do not explicitly address. The practical failure is two separate notification processes running in parallel during an incident, with no one responsible for ensuring consistency between them or managing the timeline of both.
Where APRA compliance exposure is accumulating
Within 18 months, APRA will issue enforcement action or formal guidance specifically addressing the evidence standard for CPS 234 clause 34 third-party information security capability assessment, following a pattern of findings in supervised entity examinations showing that vendor security questionnaire responses are being accepted as clause 34 evidence when they do not constitute capability assessment.
The third-party access chain is the most consistently cited finding in APRA's own supervisory publications. The pattern of organizations treating vendor questionnaire responses as CPS 234 capability assessments is well-documented in assessment data and has been referenced in APRA's broader commentary on third-party risk. Regulatory guidance tends to follow a pattern: persistent supervisory finding, formal letter to industry, updated guidance or enforcement action. The persistent finding is established. The next step in that pattern is due.
Confidence: mediumIf APRA does not issue specific guidance on clause 34 evidence standards by end of 2026, the prediction is early rather than wrong — the supervisory finding pattern remains.AI-assisted compliance tooling adopted by Australian financial services organizations will create a new category of CPS 230 operational risk exposure within 24 months, as AI-generated risk assessments produce outputs that satisfy documentation requirements without reflecting genuine operational risk analysis, and regulators begin distinguishing between documented assessment and demonstrated assessment capability.
AI compliance tools generate risk register entries, assessment summaries, and board reports at scale. The outputs satisfy documentation format requirements. They do not demonstrate that the organization has the analytical capability to assess operational risk without the AI tool. CPS 230 is a principles-based standard that requires genuine operational risk management capability, not just documentation. APRA has historically examined whether governance processes reflect genuine capability — the three lines of defense question is frequently about whether each line can actually do the risk work, not just produce the artifacts. AI-generated documentation creates the right artifacts without demonstrating the underlying capability, which is what APRA is looking for.
Confidence: mediumIf APRA provides formal guidance explicitly accepting AI-assisted risk assessment outputs as satisfying CPS 230 capability requirements, the prediction does not hold.
The integration problem is an architecture problem
The standard advice for CPS 230 and CPS 234 compliance is to build a unified framework that maps controls to both standards and avoids duplication. That advice is correct at the governance layer. It is incomplete at the evidence layer, and the evidence layer is where regulatory inquiries happen.
The specific problem is that most compliance programs are designed to produce documentation that describes controls, not pipelines that produce evidence of controls operating. The distinction matters because APRA regulators examining a program post-incident are not asking what the organization's controls are — they are asking what those controls produced during the specific period under examination. That requires that the controls themselves generate auditable output, linked to specific regulatory obligations, with timestamps, with decision logs, and with escalation records.
Building that kind of evidence pipeline is harder than building a control framework, and it requires making decisions that a documentation-first compliance approach defers: which system is the authoritative record for each type of evidence? How does a vulnerability finding in the security scanner get linked to an operational risk record in the risk register? How does a vendor access provisioning event create a CPS 234 clause 34 assessment record? These are integration architecture questions, not compliance questions. Organizations that treat them as compliance questions build documentation. Organizations that treat them as architecture questions build evidence.
Counterargument
The counterargument is that building evidence pipelines to the level of specificity described is only feasible for larger institutions with dedicated engineering resources for compliance infrastructure. Smaller ADIs and superannuation funds cannot build custom integrations between every system in their technology stack. This is a real constraint. The response is that the integration does not need to be automated to satisfy regulatory requirements — it needs to be reliable and auditable. A manual process that consistently links vulnerability findings to operational risk assessments and documents that linkage is better evidence than an automated pipeline that produces scan results and patch records in separate systems with no documented connection between them.
One concrete action this week
Pull the last 90 days of vulnerability findings from your security tooling and the last 90 days of entries in your operational risk register. For each critical or high severity vulnerability finding, check whether there is a corresponding operational risk record that documents the assessment of operational impact during the remediation window. If the vulnerability finding and the operational risk record are not linked — if the security team and the risk team are working from separate systems with no documented connection between them — that gap is your most immediate CPS 230 and CPS 234 evidence problem, and it is one APRA will ask about directly if an exploited vulnerability triggers a regulatory inquiry.
Further Reading
Gap Analysis
framework gap analysisDigital Footprint
digital footprint analysisAPAC cybersecurity and privacy compliance frameworks: the complete guide
APRA CPS 230 and CPS 234 compliance gaps and where evidence requirements break automated pipelinesNational Vulnerability Database Home
National Vulnerability DatabaseThird-Party Risk Management
third-party risk managementNIST Cybersecurity Framework 2.0
NIST Cybersecurity Framework
Frequently Asked Questions
What is the difference between CPS 230 and CPS 234 notification triggers?
CPS 234 clause 42 requires notifying APRA when an information security incident has a material impact on information assets or the ability to manage information security. CPS 230 paragraph 74 requires notification when an operational risk event has materially impacted the ability to manage operational risk. A single incident — ransomware that encrypts a trading system, for example — can trigger both obligations simultaneously. Each notification has different content requirements and is assessed against different materiality thresholds. Organizations that have not explicitly mapped the dual-trigger scenario typically discover during an incident that they have two separate notification processes with potentially different timelines running in parallel with no coordination mechanism.
Does CPS 234 clause 28 allow in-house security teams to conduct the required independent assessment?
No. APRA's practical interpretation of the clause 28 independent party requirement is that the assessor must be external to the APRA-regulated entity. An internal red team or a different security team within the same organization does not satisfy the independence requirement regardless of technical capability. Organizations that have documented internal assessments as satisfying clause 28 have found during APRA inquiries that this is not accepted. The qualified independent party needs to be outside the organization, and APRA has indicated that the assessment should be specifically framed against CPS 234 requirements, not just general security best practice.
What evidence does APRA actually request during CPS 230 operational risk inquiries?
APRA requests operational evidence, not just technical evidence. For incidents involving information security, this means: incident timeline in machine-readable format showing intrusion time, lateral movements, and affected systems; evidence that the operational risk implications of the incident were assessed (not just the technical impact); documentation of who made escalation decisions and when; records showing the notification process was triggered correctly and within required timeframes; and evidence that the board was informed with appropriate specificity. A vulnerability scan report and a patch record satisfy CPS 234 technical evidence requirements but do not answer the CPS 230 question of how operational risk was governed during the incident period.
How should CPS 234 clause 34 third-party assessments be documented?
Clause 34 requires assessing whether service providers have information security capabilities adequate for the access and data they handle. APRA expects this to be documented as a specific capability assessment against CPS 234 requirements, not a general vendor security questionnaire or a vendor's SOC 2 report. The assessment must exist before access is granted, must cover the scope of access being provided, and must be updated when access scope changes. Evidence must be retained and linkable to the specific access provisioning event. Vendor questionnaire responses and third-party security ratings are supporting evidence, not substitutes for the assessment itself.
Why do vulnerability management pipelines fail CPS 230 evidence requirements?
Standard vulnerability management pipelines produce technical findings — CVSS scores, affected components, remediation records. CPS 230 requires operational risk assessment: the likelihood and impact of the vulnerability disrupting critical business operations, compensating controls applied during the remediation window, and the risk acceptance decision if remediation was deferred. A high-CVSS vulnerability in a non-critical internal tool may have low operational risk. A medium-CVSS vulnerability in the payment processing system has high operational risk. The technical severity rating does not capture this distinction. Pipelines built to satisfy CPS 234 scanning requirements produce the wrong evidence for CPS 230 operational risk assessment unless specifically extended to include an operational impact assessment stage.
Is a SOC 2 report sufficient for CPS 234 third-party assessment requirements?
No. A SOC 2 report describes the service organization's internal control environment at a point in time against the Trust Services Criteria. CPS 234 clause 34 requires assessing whether the third party has information security capabilities adequate for the specific access and data involved in your relationship with them. The SOC 2 scope may not cover the specific controls relevant to that access, the report is point-in-time, and it does not document your organization's assessment of adequacy against CPS 234 requirements. A SOC 2 report is relevant supporting evidence for a clause 34 assessment. It is not the assessment itself.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.