90 Day APRA CPS 234 AI Playbook for Australian Compliance
Map APRA CPS 234 to AI systems in 90 days. Build AI inventory, cover vendor risk, run adversarial testing, and produce audit ready evidence.
APRA expects regulated entities to apply CPS 234 to artificial intelligence proportionately and without delay. The core obligation hasn’t changed: classify assets, test controls, notify material incidents within 72 hours. What’s changed is scope. Your immediate priorities are a working AI inventory, full supplier visibility, adversarial testing evidence, and named accountability ready for board and APRA scrutiny.
TL;DR:
- Entities must now maintain a comprehensive AI inventory, classify assets by use case and sensitivity, and document each AI system’s purpose and lifecycle.
- Most organizations rely on vendor models, so due diligence should extend to the entire supply chain, with clear audit rights, contingency plans, and contractual protections.
- AI-specific attack vectors like prompt injection and data leakage require continuous adversarial testing and ongoing monitoring of model behavior and drift indicators.
- Compliance depends on sovereign hosting within Australian jurisdiction, with native audit logs and real-time analytics to support incident response and continuous validation efforts.
- Boards and accountable persons need to regularly demonstrate AI risk oversight, maintain clear reporting processes, and ensure human-in-the-loop controls are auditable for high-risk decisions.
Table of Contents
- Mapping APRA CPS 234 AI obligations clause by clause
- Build and maintain an AI inventory and lifecycle register
- Managing supplier and concentration risk for AI vendors
- Security controls and adversarial testing your AI systems need
- Moving from point-in-time checks to continuous monitoring
- Incident response and APRA notification timeframes for AI
- What boards and FAR accountable persons must demonstrate
- Sovereign hosting and CPS 234 evidence for conversational AI
- Publisher perspective: a 90-day practical roadmap for compliance officers
- How Conversational AI supports your CPS 234 evidence trail
- Sources
Mapping APRA CPS 234 AI obligations clause by clause
CPS 234 wasn’t written with large language models in mind, but its structure translates cleanly once you stop treating AI as a special category and start treating it as another information asset. APRA’s letter from 30 April 2026 confirms this directly: existing prudential standards, CPS 234 among them, already apply to AI systems. There’s no separate “AI standard” coming. There’s an expectation you’ve been applying the current one properly all along.
Start with roles. CPS 234 places responsibility with the Board for oversight and with senior management for implementation, and under the Financial Accountability Regime, specific accountable persons must be named against specific obligations. For AI, this means someone signs off on model deployment, someone owns the vendor relationship, and someone is answerable when a chatbot leaks customer data. Vague collective ownership doesn’t survive a supervisory review.
Next, your information security capability needs to extend across the full AI lifecycle, not just the production environment. That covers model development, training data handling, deployment configuration, and decommissioning. A model that’s been retired still needs its access revoked and its data disposed of, according to policy.
Asset classification is where most entities stumble. CPS 234 requires assets classified by criticality and sensitivity, and an AI system answering general customer queries sits in a different tier to one making credit decisions or handling health information. Classify by use case, not by the fact that it’s “an AI system.”
Finally, testing obligations under CPS 234 demand evidence, not assurance from a vendor’s marketing deck. If you can’t produce a test report, the control doesn’t exist as far as a supervisor is concerned.
Build and maintain an AI inventory and lifecycle register
You cannot secure what you haven’t catalogued, and this is precisely where tripartite assessments keep finding gaps. Reviewers routinely uncover AI use-cases that never made it into the asset register at all, often because a business unit adopted a tool without looping in risk or IT.
A functional AI inventory needs to capture, at minimum:
- Purpose and business owner — what the system does and who is accountable for it
- Vendor and hosting arrangement — including whether data leaves Australia
- Data processed — categories, sensitivity, and whether personal or financial information is involved
- Decisions supported — advisory only, or does the output directly affect a customer outcome
- Model version and lifecycle status — in development, live, under review, or decommissioned
Once catalogued, run each entry against a CPS 230 materiality assessment. A model classified as material triggers the heavier obligations under both CPS 230 and CPS 234, including tighter change control and more frequent testing. One that isn’t material still needs monitoring, just at a proportionate intensity.
Governance around updates matters as much as the initial entry. Every model retrain, prompt change, or integration update should trigger a review of whether the classification still holds, and decommissioning needs its own sign-off step so a “shadow” version doesn’t keep running quietly in a forgotten sandbox.
Managing supplier and concentration risk for AI vendors
Most regulated entities don’t build their own models. They license them, and that shifts a large share of the risk profile onto a vendor relationship most compliance teams haven’t fully mapped. APRA’s supervisory review found heavy reliance on single AI providers with gaps in contingency planning, exactly the pattern that turns a vendor outage into a business continuity event.
Three things need to happen before you can call your supplier risk framework AI-ready:
- Extend due diligence to fourth parties. Your AI vendor likely relies on a cloud provider, a model developer, and possibly a data labelling contractor. Map that chain and understand where your customer data actually sits.
- Negotiate contractual audit rights. Material AI vendors need clauses covering the right to audit, sub-processor controls, and clear notice obligations if the vendor changes its architecture or hosting location.
- Document exit and contingency arrangements. If your primary AI vendor fails, is compromised, or changes terms unfavourably, you need a tested plan, not an assumption you’ll figure it out later.
Supervisors running a tripartite assessment will ask to see the register of material AI service providers, the contracts backing those audit rights, and evidence of a contingency test, not just a policy stating one exists.
Security controls and adversarial testing your AI systems need
The control families CPS 234 has always required, access control, encryption, logging, segregation of duties, apply to AI systems the same way they apply to any other information asset. What’s different is the attack surface. APRA’s letter flags AI-specific pathways including prompt injection, data leakage through insecure integrations, and agentic misuse as observed risks worth specific testing attention.
Your testing regime should cover:
- Prompt-injection and jailbreak attempts against customer-facing chatbots
- Chain-of-prompts attacks that try to manipulate agentic workflows into unintended actions
- Data exfiltration testing across every downstream integration the AI system touches
- Code-generation security review, where relevant, to catch vulnerabilities the model itself might introduce
- Access control and API security testing at each integration point, not just at the front door
Pro Tip: Adversarial testing works best as a continuous, scenario-driven program rather than an annual exercise. Cyber authorities recommend running chain-of-prompts and simulated agentic workflow attacks specifically because they exercise downstream integrations that a single-prompt test would miss entirely.
Cadence matters as much as coverage. A test run once at go-live tells you nothing about a model that’s been retrained twice since. Save every test artefact, script, result, and remediation ticket, because that’s the evidence trail a supervisor will ask for when material incidents get reviewed.
Moving from point-in-time checks to continuous monitoring
A one-off penetration test or a vendor’s compliance certificate used to be enough to tick the assurance box. It isn’t anymore. APRA has observed that assurance for AI is too often point-in-time when the systems themselves are adaptive, meaning the model’s behaviour can drift well past what was tested at launch.
Continuous monitoring for material AI systems should track a defined set of metrics: output accuracy against a baseline, drift indicators showing behaviour change over time, and flagged bias patterns in decision outputs. Set detection thresholds that trigger automatic escalation rather than relying on someone noticing an anomaly in a monthly report.
For assurance packs, keep validation reports, drift logs, and remediation tickets organised and dated, because a tripartite assessment will want to see the trend line, not just the current snapshot. Internal audit teams need enough technical grounding to interpret that telemetry, which for most entities means upskilling second-line and audit staff specifically on AI risk indicators rather than assuming general IT audit experience transfers cleanly. Reviewing how AI model management practices structure lifecycle oversight gives audit teams a useful reference point for what continuous validation should actually look like in practice.
Incident response and APRA notification timeframes for AI
CPS 234’s notification expectation doesn’t change for AI: a material incident needs to reach APRA within 72 hours of the entity becoming aware of it. What changes is how quickly an AI-related incident becomes clear. A model quietly leaking data through an insecure integration might run for weeks before anyone notices, which makes the “aware of it” clock start later than the actual breach.
Sequencing matters when multiple regimes apply. An AI-driven data breach may trigger APRA notification, mandatory ransomware reporting if extortion is involved, and Notifiable Data Breach obligations under the Privacy Act simultaneously. Map these obligations against each other in advance so your incident response team isn’t figuring out reporting order mid-crisis.
Every incident, material or not, needs a root-cause analysis and a tracked remediation plan. Supervisors reviewing your CPS 234 maturity will look for evidence that a control gap identified in one incident was actually closed, not just logged and forgotten.
What boards and FAR accountable persons must demonstrate
A board that can’t produce its AI inventory on request has already failed the first test. Boards need to demonstrate the inventory exists, that it’s linked to the entity’s risk appetite statement, and that reporting on AI risk happens at a set cadence, not on an ad hoc basis when something goes wrong.
Under the Financial Accountability Regime, each CPS 234 obligation area needs a named Accountable Person, and the tripartite assessment programme increasingly expects that person to produce defensible evidence on demand, not a verbal assurance that “the team’s on top of it.”
Practical board oversight should include:
- A standing AI risk item on the board risk committee agenda, not a once-a-year briefing
- KPIs covering inventory completeness, test coverage, and open remediation items by severity
- Escalation triggers defined in advance, so an incident doesn’t wait for the next scheduled meeting
- A briefing template accountable persons can update rather than rebuild each cycle
Human-in-the-loop controls for high-risk, customer-facing AI decisions deserve specific board attention too, with override triggers and decision thresholds documented so the human intervention itself is auditable.
Sovereign hosting and CPS 234 evidence for conversational AI
A meaningful share of the supplier and concentration risk covered above disappears the moment your AI systems run on infrastructure you can actually see and audit. An Australia-hosted private cloud platform keeps data within Australian jurisdiction by design, which sidesteps the offshore data transfer question that complicates so many CPS 234 asset assessments for cloud-based AI vendors.
Frameworks like ISO 27001 and ISO 42001 map closely to what APRA’s letter expects from governance and information security practice, giving compliance teams a recognised structure to point supervisors toward rather than building an evidence framework from scratch.
Three things matter most for CPS 234 alignment:
- Audit logging at every conversation touchpoint, supporting incident containment and root-cause work
- Real-time analytics that feed directly into continuous monitoring rather than periodic manual review
- Contextual memory architecture that preserves explainability for a decision an accountable person may need to defend
| CPS 234 requirement | How sovereign hosting supports it |
|---|---|
| Asset classification | Data residency reduces offshore transfer complexity |
| Control testing evidence | Native audit logs and telemetry generate artefacts automatically |
| Incident containment | Full visibility over infrastructure speeds root-cause analysis |
| Continuous monitoring | Real-time analytics support drift and anomaly detection |
Publisher perspective: a 90-day practical roadmap for compliance officers
Ninety days is enough time to move from exposed to defensible, provided you sequence the work correctly. Weeks one to three: triage your AI inventory against the CPS 230 materiality test and run targeted reviews of your top three vendor dependencies. Don’t try to audit everything at once, that’s how these programs stall.
Weeks four to eight: stand up continuous monitoring for anything classed material and schedule the first adversarial test round, prompt injection first, agentic workflow testing second. By week nine, name your FAR accountable persons against each CPS 234 obligation area, brief the board with the evidence you’ve assembled, and run a tabletop incident response exercise before you need the real one.
— Sowrabh
How Conversational AI supports your CPS 234 evidence trail
There are other paths to closing these gaps, offshore SaaS platforms with bolt-on compliance add-ons, or building custom monitoring in-house. Conversational AI takes a different route: it’s built as an Australia-hosted private cloud platform from the ground up, so data sovereignty isn’t a configuration option you have to remember to enable.
For compliance teams under pressure to produce evidence fast, that matters. The platform’s audit logging, real-time analytics, and ISO-aligned architecture generate the artefacts a tripartite assessment actually asks for, without your team building a telemetry pipeline from scratch. Implementation support is built into onboarding, so you’re not left interpreting a dashboard alone when a supervisor requests validation reports.
If your AI inventory review has flagged a customer-facing system that needs a defensible, sovereign home, get in touch through the Conversational AI platform to talk through what a compliant deployment looks like for your organisation.
Sources
Keep these on hand for internal reference and supervisory review:
- APRA calls for a step change in AI-related risk management and governance
- APRA’s call to action on AI governance :: Sparke Helmore
- Cyber
- CPS 234: Six common compliance gaps — CyberAssure
This article is general information, not a substitute for advice from a qualified financial advisor. Consult a qualified financial professional about your own circumstances before acting on anything here.
