90 Day APRA CPS 234 Compliance for Australian Chatbots
A 90 day APRA CPS 234 playbook for Australian chatbots that maps APRA's 2026 AI guidance to vendor checks, testing and incident response.
Yes, CPS 234 governs chatbots and conversational AI whenever they handle or connect to APRA-regulated information. Start by classifying the chatbot as an information asset, identifying any material service providers behind it, and confirming baseline controls are in place. From there, begin systematic testing and prepare your APRA notification process, informed by APRA’s 2026 letter on AI and the practical advantage of Australia-hosted data sovereignty.
TL;DR:
- Chatbots connected to APRA-regulated data must undergo comprehensive asset classification, vulnerability testing, and secure vendor due diligence under CPS 234 and CPS 230 standards.
- Vendors hosting critical systems require legally binding agreements focused on data residency, audit rights, offshore transfer restrictions, and exit strategies to minimize jurisdictional risks.
- Lifecycle controls demand ongoing monitoring, regular testing of models after updates, and secure decommissioning of models, logs, and training data to ensure audit readiness.
- Incident response plans should include log preservation, escalation to the board, and prompt reporting to APRA within 72 hours of suspicion or discovery of material security incidents.
- A 90-day compliance framework involves asset inventory, contract upgrades, testing, and thorough documentation, all stored in a centralized governance folder for audit purposes.
Table of Contents
- How CPS 234 maps to chatbot components and data flows
- Key CPS 234 requirements applied to conversational AI
- Material service providers and CPS 230 implications for chatbot vendors
- Lifecycle controls for chatbot deployments
- Incident response, escalation and APRA notification for chatbot-related incidents
- A 90-day compliance playbook for chatbots
- Why sovereign hosting and lifecycle evidence matter
- How Conversational AI supports CPS 234 compliance for chatbots
- FAQ
- Sources
How CPS 234 maps to chatbot components and data flows
Before you can protect a chatbot, you need to know what it actually touches. CPS 234 treats information assets broadly, and that definition extends well past the chatbot’s chat window into everything feeding it and everything it feeds.
Start with an honest inventory. Most compliance teams underestimate how many moving parts a conversational AI system has, and each one carries its own risk profile:
- The underlying model or models, including any fine-tuned versions
- Training and fine-tuning datasets, particularly any containing customer or member data
- Prompt stores, conversation transcripts and query logs
- Telemetry and usage analytics
- Integrations with CRM, payment systems or core banking platforms
Classify each of these by criticality and sensitivity, the same way you would a core banking system. A chatbot with read or write access to a payments ledger carries the criticality of that ledger, not the criticality of a simple FAQ bot. Threats are also distinct: prompt injection, data leakage through model outputs, model tampering, and unauthorised access to logs or training data all sit outside traditional perimeter security thinking, and your asset register should name them explicitly.
Key CPS 234 requirements applied to conversational AI
CPS 234 isn’t a chatbot-specific standard, but its obligations translate cleanly once you know where to look. CPS 234 requires an information security capability commensurate with the threats an entity faces, and AI systems have measurably expanded that threat surface.
Four things need to happen in sequence:
- Assign accountability. The Board and senior management need documented oversight of chatbot risk, not a verbal assurance from IT that “it’s covered.”
- Build proportionate capability. Security resourcing should scale with how much the chatbot touches, not with how novel the technology feels.
- Design a testing programme. Scope should cover model-level integrity, prompt-injection resilience and regression testing after every update, following the secure AI development guidelines from the Australian Cyber Security Centre.
- Escalate deficiencies through internal audit. Any gap found in testing needs a clear path to senior management and the Board, with a remediation timeline attached.
Pro Tip: Treat every model update as a change event requiring its own regression test, not a minor patch you can wave through.
Internal audit should review AI-specific controls on the same cycle as other critical systems, not as an annual afterthought bolted onto the broader IT audit.
Material service providers and CPS 230 implications for chatbot vendors
Most chatbot platforms run on a vendor’s infrastructure, and that changes your obligations the moment the vendor processes APRA-regulated data or supports a critical business function. CPS 230 sets the bar: material service providers require due diligence, a formal legally binding agreement, ongoing service-level monitoring and a documented exit plan.
Work through these checks before you sign anything:
- Confirm whether the vendor’s access makes it “material” under your own risk framework, based on data sensitivity or operational criticality
- Insist on contractual clauses covering data residency, audit rights and incident notification timeframes
- Map fourth-party exposure, including where any subcontracted hosting or model training occurs
- Build in substitution and exit rights so you’re never locked into a vendor that can’t meet your obligations
Offshore hosting and opaque supply chains are where this usually breaks down. A vendor’s third-party dependencies can introduce jurisdictional exposure your own contract never anticipated, which is why preventing unauthorised offshore transfers deserves its own line item in vendor due diligence.
Lifecycle controls for chatbot deployments
CPS 234 compliance isn’t a one-off certification. It’s a lifecycle discipline that starts before procurement and continues after a chatbot is retired.
- Procurement. Request an AIBOM or SBOM, vendor security attestations and evidence of prior testing before signing.
- Change and release management. Model updates need the same rigour as code releases, adapted for a system that behaves probabilistically rather than deterministically.
- Continuous monitoring. Watch for model drift, degraded explainability and anomalous outputs, not just uptime and latency.
- Decommissioning. Archive or securely dispose of retired models, logs and training data according to your retention policy, not by simply switching off the service.
Pro Tip: Build decommissioning into the original contract, including who owns the training data and logs once the relationship ends.
This is where secure-by-design practices pay off. A platform designed with lifecycle controls from day one gives you far more to show an auditor than a bot that was simply switched on and left running.
Incident response, escalation and APRA notification for chatbot-related incidents
A chatbot incident doesn’t always look like a conventional breach. It might be a prompt injection that exposes customer data, a logging failure that loses forensic evidence, or a model update that silently starts leaking sensitive fields into its responses. Detection needs to account for all three.
- Preserve query logs, model version history and API traces the moment an anomaly is flagged
- Escalate to the Board per your existing incident playbook, adapted to name AI-specific triggers
- Coordinate with the OAIC and notify affected customers where privacy is affected
- Document the root cause before remediation closes, not after
CPS 234 sets firm deadlines: material information security incidents must be reported to APRA promptly, within a short timeframe, and material control weaknesses that can’t be fixed quickly within a timely notification period. Those clocks start the moment you reasonably suspect an incident, not when you’ve confirmed it.
A 90-day compliance playbook for chatbots
You don’t need a year-long programme to get a chatbot into a defensible compliance position. Thirty, sixty and ninety-day milestones give you a structure that’s realistic and auditable.
First 30 days:
- Complete an asset inventory covering every chatbot component and data flow
- Classify each asset by criticality and sensitivity
- Register any material service providers in your governance system
- Confirm baseline logging is capturing conversation and system-level events
Next 30 days:
- Uplift vendor contracts with the clauses CPS 230 expects
- Implement baseline controls: access management, encryption and retention policies
- Begin your testing programme, including an initial round of model-level checks
Final 30 days:
- Run red-team or penetration testing against the chatbot and its integrations
- Compile internal audit evidence into your governance pack
- Report findings to the Board with a formal remediation schedule attached
Pro Tip: Keep every artefact from this 90-day run (logs, test results, vendor attestations) in one governance folder. It’s the first thing an APRA reviewer will ask for.
Conversational AI’s own 90-day APRA CPS 234 AI playbook walks through this same structure with practical templates for compliance teams working through it for the first time.
Why sovereign hosting and lifecycle evidence matter
The gap I see most often isn’t a lack of policy, it’s a lack of evidence. Entities write good governance documents and then can’t produce the logs, version history or vendor attestations an auditor actually asks for. Sovereign hosting and disciplined lifecycle records solve that problem directly, and they matter most in banking, insurance and healthcare, where the cost of a gap is highest.
— Sowrabh
How Conversational AI supports CPS 234 compliance for chatbots
The platform is hosted entirely within Australia on private cloud infrastructure, which removes the offshore jurisdictional questions that complicate vendor due diligence under CPS 230. That matters because every control described above is easier to evidence when your data never leaves the country.
The platform is built around the controls compliance teams actually need to produce for APRA:
- Full conversation and system-level logging with real-time analytics
- CRM integration that keeps customer data flows inside a single, auditable system
- Model versioning and rollback for defensible change management
- Documented playbooks mapped directly to CPS 234 obligations
These capabilities are most relevant for entities running conversational AI in banking and finance, where regulatory exposure is highest and audit evidence needs to be ready on demand. For compliance teams wanting a structured starting point, Conversational AI’s 90-day APRA CPS 234 AI playbook sets out the same milestones covered above with practical artefacts you can adapt directly into your own governance pack. Entities evaluating hosting options for stricter data residency can also look at on-premises deployment as an alternative to shared cloud infrastructure.
FAQ
Does CPS 234 apply to all chatbots or only customer-facing ones?
CPS 234 applies to any chatbot handling or connected to APRA-regulated information, regardless of whether it’s customer-facing or used internally. The deciding factor is what data or systems the chatbot can access, not where it sits in the organisation.
What are the requirements for APRA CPS 234?
CPS 234 requires APRA-regulated entities to maintain an information security capability proportionate to the threats they face, including defined Board and management accountability, systematic testing, and incident notification within set timeframes. Entities must notify APRA of material incidents within 72 hours and material control weaknesses within 10 business days.
What does APRA CPS stand for?
APRA CPS stands for Australian Prudential Regulation Authority Cross-industry Prudential Standard. CPS 234 is the specific standard covering information security obligations for regulated entities.
What are the new cybersecurity laws in Australia for AI systems?
There’s no standalone AI cybersecurity law yet. Instead, APRA’s 2026 letter to industry clarifies that AI systems are managed under existing prudential frameworks like CPS 234 and CPS 230, with entities expected to register material service providers for existing AI arrangements by 1 July 2026.
How does CPS 230 affect chatbot vendor contracts?
CPS 230 requires formal, legally binding agreements with material service providers, including due diligence, ongoing monitoring and documented exit rights. Any chatbot vendor processing regulated data or supporting a critical function needs to meet these contractual minimums.
Sources
Keep these documents on hand in your governance pack. They’re the primary references APRA reviewers will expect you to cite, and the companion guidance that helps translate the standards into day-to-day practice.
