A short version. CPS 234 binds every information asset inside an APRA-regulated entity. AI systems are not exempt. The obligation is to maintain information-security capability commensurate with the criticality and sensitivity of the information handled — and to demonstrate it. This article maps the standard's obligations to the design choices an AI deployment must make: information-asset registration, control selection, testing, lines of defence, incident notification, and the evidence regime that supports an APRA review. It is not a substitute for advice; it is a working checklist for the conversation between the AI team, the second line, and the CISO.
CPS 234 Information Security has been in force for Australian APRA-regulated entities since 1 July 2019. It is the prudential standard the AI team interacts with most often, whether they know it or not. Anything that handles bank customer data, insurance claims data, superannuation member data, or the operational-risk data that supports board reporting falls under its perimeter. AI is not carved out.
For most banks and insurers, the question is not whether CPS 234 applies — it does — but how to apply it to a class of system the standard was not written with explicitly in mind. This article is a working checklist for the conversation between the AI team, the second line, and the CISO.
The Standard, in One Page
CPS 234 has nine substantive requirements, grouped here by the role each plays in an AI deployment.
Accountability
The board is ultimately accountable for the information-security capability of the entity. For AI systems, this is not a delegation question — the board's accountability extends to AI even when the AI program lives inside a technology, data, or analytics function. Board reporting must contemplate AI's effect on the information-security posture.
Information-security capability
The entity must maintain information-security capability commensurate with the size and extent of threats and enabling the continued sound operation of the entity. For AI specifically this means the capability stack includes AI-literate security expertise — either internal or via a credible provider — that can reason about model-specific threats (prompt injection, training-data leakage, model extraction, output-based exfiltration) alongside traditional information-security ones.
Policy framework
A policy framework must direct the implementation of information-security controls. The framework must cover the information assets managed by the entity and by related parties and third parties. AI systems hosted with external providers do not escape the framework; the obligation is to ensure the framework's reach extends to them, which in practice requires contractual rights, assurance evidence, or direct control.
Information-asset identification and classification
The entity must identify and classify its information assets by criticality and sensitivity. For AI deployments, the information-asset register must record:
- The model (including version) and its hosting location.
- The training and inference data flows, including sensitivity classification of inputs and outputs.
- The downstream systems consuming the AI's output.
- The criticality of the workflow the AI supports.
A frequent gap to look for: AI systems absent from the information-asset register because they were classified as "analytics" or "tooling" by an earlier process. Re-registration is straightforward; it is also the kind of gap an external assurance pass surfaces first.
Control implementation
Controls must be commensurate with the vulnerabilities and threats, the criticality and sensitivity of the information assets, the stage at which they are held in the information lifecycle, and the consequences of compromise. For AI:
- Access controls on training data, fine-tuning data, model weights, prompt configurations, and inference logs. Different roles need different access; least-privilege is the baseline.
- Encryption in transit and at rest for input data, output data, and stored model weights where sensitivity warrants.
- Tamper-evidence on inference logs, audit records, and human-approval records.
- Output controls that prevent the model from disclosing information it should not — both training-data leakage and confused-deputy disclosure of one tenant's data to another. Output integrity (the accuracy of the generated content itself) is a parallel control surface — covered in accuracy as an operating control.
- Change management that captures prompt revisions, model swaps, configuration changes, and supplier changes as auditable events.
- Supplier risk assessment for any external model provider, vector database, embedding service, or hosting platform involved in the inference path.
Control testing
Controls must be tested in a way that surfaces design effectiveness and operating effectiveness. This is where AI deployments most often fall short. The control exists, is documented, and looks reasonable — but it has never been exercised against a realistic adversary or workload, so the operating effectiveness is unproven. APRA-aligned testing for AI typically includes:
- Adversarial prompt testing (red-team prompts intended to bypass the output controls).
- Access-control testing (can an unauthorised role retrieve sensitive logs or model artifacts?).
- Audit-log integrity testing (does tampering remain detectable?).
- Sampled operating-effectiveness review (across a representative period, did the controls behave as designed?).
- Change-management testing (was the most recent model or prompt revision processed through the documented change path?).
Internal audit
The internal audit function must form a view on the information-security control environment. For AI, this means internal audit needs sufficient understanding to assess whether the controls selected and tested address the AI-specific risk surface — not just generic information-security risks applied to a system that happens to have AI in it.
Notification of material incidents
Material information-security incidents must be notified to APRA within 72 hours of the entity becoming aware. For AI deployments, the incident definitions that matter:
- Unauthorised disclosure of sensitive information by the AI to an unintended recipient.
- Compromise of training data, fine-tuning data, or model weights.
- Compromise of audit or approval records.
- A control failure that prevents the entity from demonstrating compliance.
The notification clock starts at awareness, not investigation completion. Practical implication: the AI team and the incident-response team need a shared definition of what an AI incident looks like before the first one happens.
Control deficiency notification
Material weaknesses must be reported to APRA with a remediation plan. For AI, this is where supplier dependencies most often surface — a discovered weakness in a third-party model provider's controls becomes the entity's deficiency to report, regardless of where the underlying gap sits.
How to Apply It: A 12-Step Implementation Checklist
The checklist below is the agenda for the first artefact (workflow + regulator-surface map) in an APRA-regulated AI engagement, the first step of the build sequence. It structures the conversation between the AI team, the second line, and the CISO. Each step has a specific output that becomes evidence later.
1. Register the AI system as an information asset
Add the system to the entity's information-asset register with the eight fields above. Get the registration signed by the asset owner and reviewed by the second line. Output: register entry with version.
2. Classify the information at every stage
For every data flow into and out of the AI, assign the sensitivity classification (typically: public / internal / confidential / restricted, or the entity's equivalent). Different sensitivities at different stages drive different controls. Output: data-flow diagram with classifications.
3. Choose the hosting posture deliberately
Three options:
- External API — minimum-control posture; requires extensive supplier assurance.
- Hosted on the entity's infrastructure — control parity with the entity's existing standards; lifts the AI to the same control bar as comparable systems.
- On-premise or on-territory dedicated inference — maximum control; suitable for the most sensitive workflows and for entities whose customers expect data not to leave Australian or specified jurisdictional boundaries. The jurisdictional-specificity dimension is covered in detail in Sovereign AI in Australia: Queensland Infrastructure as a Data-Residency Strategy.
The choice is not technical; it is a risk-and-assurance decision. Most APRA-regulated entities reach option 2 or 3 for any workflow handling regulated customer or risk data. Output: hosting decision with risk justification.
4. Build the access-control matrix
Who can read training data? Who can update prompts? Who can change the model? Who can read inference logs? Who can read approval records? Who can deploy a new version? Each row is a role; each column is an action; least-privilege is the default. Output: access-control matrix mapped to identity provider.
5. Design the audit and approval logging
The audit log records every inference, the approval log records every human-in-the-loop decision, and both are tamper-evident. The seven minimum fields are listed in our human-in-the-loop framework. Output: logging spec including retention period.
6. Specify output controls
What is the model allowed to disclose? What is it not? What evidence does the deployment produce that disclosure controls are working in operation, not just in design? For RAG systems, what prevents one tenant's documents from surfacing in another tenant's responses? Output: output-control spec with test plan.
7. Design the human-in-the-loop posture
For each output category, decide in-the-loop, on-the-loop, or out-of-the-loop. Place the reviewer at the lowest-reversibility transition. Document the gating rule. Output: loop-placement decision per output category.
8. Document change management
Prompt revisions, model swaps, configuration changes, and supplier changes are all auditable events. Define who approves what and how the change is captured in the log. Output: change-management procedure specific to the AI deployment.
9. Define the incident playbook
What constitutes an AI-specific incident? Who detects it? Who triages? Who notifies APRA within the 72-hour window? Run a tabletop with at least one AI-specific scenario before go-live. Output: incident playbook with named owners and a completed tabletop record.
10. Plan the control test schedule
Annual at minimum; more often for higher-criticality systems. Schedule adversarial testing, access-control testing, log-integrity testing, and operating-effectiveness sampling. The schedule is owned by the second line, not the AI team. Output: test schedule with owner and methodology.
11. Brief internal audit
Walk internal audit through the system at design, again at go-live, and on a recurring cadence. Internal audit needs enough understanding to form an independent view. Output: internal-audit briefing record.
12. Establish the board-reporting cadence
How does AI risk surface in the regular board pack? Material changes — new deployments, version upgrades, incidents, control deficiencies — flow up promptly. Output: board-reporting template extended to cover AI.
A 12-step checklist looks intimidating on the page. For a well-bounded AI workflow, the full pass is sized as a focused two- to three-week effort that pays dividends through the lifetime of the system. The work that takes longer is the work that should take longer: contractual clarity with third-party providers, the first round of operating-effectiveness testing, and the first internal-audit pass.
The Three Lines of Defence, Adapted for AI
CPS 234 is silent on the three-lines-of-defence model explicitly, but the standard's expectations only make sense when read against it. The adaptation for AI:
First line: the AI team and the business owner. Builds, runs, and operates the AI system. Owns the controls in design and in operation. Owns the incident detection at the system level.
Second line: risk and compliance. Sets the policy framework, assures the control design, reviews the control testing, monitors the control environment, and owns the relationship with APRA on material matters. For AI specifically, the second line needs sufficient AI literacy to challenge the first line meaningfully — generic information-security competence is not enough.
Third line: internal audit. Provides independent assurance to the board on the effectiveness of the control environment. For AI, internal audit benefits from the same literacy uplift as the second line, often achieved through a co-source arrangement.
A failure mode the standard's three-lines-of-defence reading guards against: a first line that is technically competent but operating without effective second-line challenge. The AI team is doing the right things; nobody at the second line knows enough to confirm it. The fix is a deliberate AI uplift for the second line — short, intensive, focused on the specific workflows in scope — not a generic AI training.
What APRA Asks For
APRA's asks in planned reviews and incident-triggered ones tend to follow a consistent pattern. The list below is what to have ready, not what to expect every time.
Information-asset register entry. With versioning showing the AI system was registered and updated as it evolved.
Risk assessment. The document that justifies the specific control selection. APRA reads this for evidence of thought, not for a particular outcome.
Access-control matrix. Current state, with a sample of access-review records demonstrating recurring review.
Audit log sample. A defined period, with the integrity-protection mechanism documented.
Change-management record. Specifically for the most recent model swap or prompt revision. APRA looks for whether the change was processed through the same change path as other changes of comparable risk.
Incident log. Including near-misses. The presence of near-misses is a positive signal — it indicates monitoring is working. Absence is a negative signal.
Control-test results. Both design and operating effectiveness, including any deficiencies and the remediation status.
Board paper. Demonstrating oversight, with AI risk explicitly addressed in the regular cadence.
Supplier-assurance evidence. For any third-party in the inference path, including model providers, hosting providers, and vector-store providers.
The pattern: APRA is looking for a system the entity demonstrably controls, with a credible programme around it. The pass criteria are not algorithmic — they are judgemental, and the judgement turns on whether the entity is genuinely in command of the AI's risk surface or merely complying on paper.
Why the Hosting Decision Matters Disproportionately
Of the 12 checklist steps, step 3 (hosting posture) drives more of the rest than any single other decision. Hosting on a major-cloud AI API has a different control profile than hosting on the entity's own infrastructure, which has a different profile again than on-premise or on-territory dedicated inference.
For an APRA-regulated entity, the practical considerations:
- Data residency. What contractual and operational assurance exists that the data does not leave Australian jurisdiction during inference?
- Supplier risk. What evidence exists of the provider's own information-security capability? What is the right to audit, the right to terminate, and the right to extract data on termination?
- Control parity. Do the controls available from the provider match the entity's standard for systems handling data of the same classification?
- Concentration risk. If the same provider supports multiple critical workflows, what is the impact of a provider-side incident?
- Sovereignty considerations. For workflows where the customer or regulator has explicit expectations about jurisdictional control, what is the chain of custody?
The hosting decision drives more downstream choices than any other single step in a CPS 234 implementation. For workflows touching regulated customer or risk data, on-territory dedicated inference is typically the path of least friction — not because it is fashionable, but because the assurance burden for the alternatives turns out to be heavier than expected once it is taken seriously.
RyderAI's default for APRA-regulated AI work is on-territory dedicated inference on Queensland infrastructure, with the audit-trail and control architecture designed to map to CPS 234 evidence from day one. The engagement runs under controls you can demonstrate, with a model you control end to end.
When CPS 234 Is Not the Right Frame
CPS 234 is the right frame for almost every AI workflow that handles regulated information inside an APRA entity. It is not the right frame for:
Pure internal R&D. A model fine-tuned on anonymised data for research purposes, where the output never re-enters production and no customer or risk data crosses the boundary, has a lighter control profile. CPS 234 still applies to the data lifecycle, but the operational-risk surface is different.
Vendor-side analytics. Models a regulated entity uses purely for procurement evaluation of third-party products — the AI is operating on synthetic or test data only. The boundary is at procurement, not at customer data.
Marketing personalisation on de-identified data. Where the data has been genuinely de-identified to the standard the OAIC accepts, and the AI never re-identifies, the privacy and CPS 234 exposure are reduced. The bar for de-identification is high and the assurance work is substantial; this is not a shortcut.
In each of these cases, lighter does not mean absent. The information-asset register entry still exists, the access controls still apply, and the incident pathway still operates. The control surface scales down with the risk; it does not disappear.
Pairing CPS 234 with the AU AI Ethics Framework
CPS 234 is mandatory and information-security focused. The AU AI Ethics Framework is voluntary and broader — covering fairness, transparency, contestability, accountability, and wellbeing in addition to the security and privacy concerns CPS 234 addresses directly.
For APRA-regulated AI deployments, the practical pattern is to design to CPS 234 as the binding control set and to layer the AI Ethics Framework's principles as a quality lens over the design. Where the two converge — accountability, transparency, contestability — the design serves both. Where the Framework reaches into territory CPS 234 does not (fairness across demographic groups, environmental considerations), the Framework's principles drive additional controls that complement, rather than substitute for, the standard's requirements.
Regulators across the Commonwealth and the states are increasingly using the Framework's language even when they cite different statutory authority. Designing to it now is the lowest-friction path to whatever AI-specific statute eventually arrives.
A Note on AI-Specific Risks the Standard Does Not Name
CPS 234 does not list AI-specific threats — but it does require controls commensurate with the threats the entity faces. The first-line AI team and the second line need a shared understanding of:
- Prompt injection — adversarial input that subverts the AI's intended behaviour. Output controls and input sanitisation matter; logging matters more because detection often happens in retrospect.
- Training-data leakage — the model emitting fragments of its training data verbatim. Bounded by careful training-data hygiene and by output-side controls.
- Confused-deputy disclosure — the AI revealing information from one tenant or context to another. Bounded by retrieval-side access controls and per-query authorisation.
- Model extraction — repeated queries used to reconstruct the model's behaviour. Bounded by rate limits, query-pattern detection, and access scoping.
- Indirect injection via retrieved content — a RAG pipeline pulling adversarial content from a trusted-looking source. Bounded by source-side controls and output reasoning.
- Supply-chain risks in model weights — backdoors or behavioural modifications introduced upstream. Bounded by sourcing only from credible providers and by behavioural monitoring in operation.
None of these are mentioned in CPS 234 by name. All of them are inside the standard's risk perimeter for any AI deployment, and a second line that cannot speak to them is not yet equipped for AI-specific assurance.
The Path Forward
If you are an APRA-regulated entity deploying AI into a workflow that touches regulated information, the path is the same regardless of the entity's size or the workflow's specifics. It starts with the 12-step checklist above and ends with a system you can demonstrate, defend, and evolve.
RyderAI's engagement model covers strategy, implementation, integration, and governance — all four, because for APRA-regulated AI deployments they are not separable. The strategic decisions about hosting and risk posture set the implementation choices; the integration choices set the audit-trail design; the governance work runs through everything.
CPS 234 evidence quality is downstream of the delivery model that produced it. The AI consulting partner decision framework covers the five evaluation axes — regulator fit, data posture, accountability transfer, exit clauses, and the operating posture the buyer keeps after the consultant leaves — that distinguish a delivery model capable of producing APRA-grade evidence from one that isn't.
If you want to walk a specific workflow through the checklist, talk to the team that builds it. The first conversation works through which of the 12 steps are in place at your entity, which need uplift, and where the assurance gap is most material to close first.
Footnotes
[1] APRA Prudential Standard CPS 234 Information Security, in force from 1 July 2019. The authoritative text is published by APRA. [primary-source]
[2] APRA Prudential Standard CPS 230 Operational Risk Management, in force 1 July 2025 for ADIs, insurers, and RSE licensees, with targeted amendments finalised 30 April 2026 and in force 1 July 2026 [primary-source]. Operates alongside CPS 234 for AI deployments touching critical business operations.
[3] APRA Prudential Practice Guide CPG 234 Information Security — non-binding guidance that informs reasonable expectations under CPS 234. Not a substitute for the standard.
[4] Office of the Australian Information Commissioner, Guide to the Australian Privacy Principles; OAIC publications on automated decision-making and Privacy Act review. [primary-source]
[5] Department of Industry, Science and Resources, Australia's AI Ethics Principles, the voluntary eight-principle baseline. [primary-source]
[6] APRA Reporting Standard ARS 110.0 series; entity-specific reporting expectations that may surface AI-system performance and incident data in the supervisory cycle.