Prudential Standard CPS 234 commenced on 1 July 2019, before generative AI tools were in everyday use. It still applies to them. The standard is principle-based, and every one of its core obligations (classification, third-party assessment, controls, incident detection and notification) has something to say about an AI assistant that staff use with customer data.
APRA has now said so explicitly. Its letter to industry on AI, published 30 April 2026, followed a targeted engagement with a group of large banks, insurers and superannuation trustees in late 2025. APRA found that governance, risk management, assurance and operational resilience practices are not keeping pace with AI adoption. It didn’t create a new standard. It set out what it expects under the existing ones.
What APRA’s AI letter says
A few observations from the letter are directly relevant to a CISO:
- Staff use of enterprise AI tools outside approved control frameworks is a concern, and in many cases preventative controls were lacking, with entities relying on policy direction or after-the-fact measures rather than enforceable technical restrictions.
- Identity and access management has not yet adjusted to non-human actors such as AI agents.
- Entities should keep an inventory of AI tooling and AI use cases, with clear ownership across the lifecycle.
- Supplier risk: map the full AI supply chain, including fourth parties such as the foundation model provider, and get contractual transparency, auditability and assurance over AI services. APRA observed heavy dependence on single providers and few tested exit or substitution strategies.
- Boards need enough AI literacy to challenge management, rather than relying on vendor presentations.
APRA also said it is finalising a forward plan for supervising AI risk. Expect AI to come up in prudential reviews.
Where CPS 234 bites
Paragraph references below are to CPS 234 as published.
Board responsibility (paragraph 13). The Board is ultimately responsible for the entity’s information security. An AI rollout is an information security decision as well as a productivity one, and the Board should be able to see how it was assessed.
Third-party capability (paragraphs 16 and 22). Where a third party manages your information assets, you must assess its information security capability and evaluate the design of the controls protecting your assets, commensurate with the consequences of an incident. An AI vendor that receives customer data in prompts is such a party. Footnotes to both paragraphs make clear they apply to all third parties managing your information assets, not only outsourcing arrangements.
Classification (paragraph 20). Information assets must be classified by criticality and sensitivity, including those managed by third parties. Decide which classes of information may go into which AI tools, and write it down.
Controls (paragraph 21). Controls must be commensurate with the threats, the sensitivity of the assets and the consequences of an incident. For AI, that typically means access control, data-loss controls on prompts and logging.
Detection and response (paragraphs 23 to 25). You need mechanisms to detect and respond to information security incidents in a timely manner. If a staff member pastes customer records into an unsanctioned tool, you can’t scope the incident without a record of what was sent.
Testing (paragraph 28). If you rely on the vendor’s own control testing, you must assess whether its nature and frequency is adequate.
Notification (paragraphs 35 and 36). APRA must be notified within 72 hours of becoming aware of a material information security incident, and within 10 business days of a material control weakness you can’t remediate in time. Whether an AI-related exposure is material is your assessment to make; an exposure of customer data through an AI tool may well be. Either way, accurate notification needs the audit trail.
Assessing an AI provider under CPS 234
CPS 234 doesn’t require data to stay in Australia, and it doesn’t name certifications. It does require you to understand the risk well enough to set controls commensurate with it. These are the questions that do the work:
| Area | Questions to ask |
|---|---|
| Location | Where does inference run? Where are prompts, outputs, files, logs and backups stored? Is that contractual? |
| Retention | Does the provider keep prompts or responses, including in abuse-monitoring or invocation logs? For how long, and why? |
| Training | Is any customer data used to train or improve models? Is that excluded in the contract? |
| Supply chain | Which sub-processors and model providers (fourth parties) touch content, and where are they? |
| Access | Can provider staff read your content? Under what approval, and is it logged and visible to you? |
| Audit | Are there prompt-level audit logs you can export to your SIEM? How long are they kept? |
| Assurance | Which independent reports exist (ISO 27001, SOC 2, IRAP), with what scope and date? |
| Incidents | What is the provider’s notification timeframe, and does it fit your 72-hour obligation? |
| Exit | Can you export your data and switch provider? Has that been tested? |
The last row comes straight from APRA’s letter, and it’s the one most assessments skip.
A remediation path
If AI tools are already in use without a CPS 234 assessment, the order of work is fairly clear.
- Inventory every AI tool in use, including ones staff adopted without approval. APRA expects this inventory anyway.
- For each tool, establish what information staff are actually putting in it. Ask them; you’ll learn more than from the policy.
- Assess the approved tools as third parties under paragraphs 16 and 22. Where a tool can’t meet your requirements on location, retention, training or logging, negotiate the terms or replace it.
- Put technical controls in place: classification in the tool, SSO and role-based access, and audit logs flowing into your SIEM with detection rules for high-risk events.
- Document the assessments and report the programme to the Board or Risk Committee, with the residual risks stated.
Where K9 fits
K9 AI is one option to test against that table. Its models run on Amazon Bedrock in Sydney with no cross-region routing, and conversations, files, audit logs and backups are stored in Sydney. Every prompt is logged with user, time, IP, model and classification, and events can be forwarded to a SIEM over syslog, OpenTelemetry or vendor HTTPS. We don’t claim CPS 234 compliance on your behalf. That assessment is yours, and a security pack and data processing agreement are available on request to support it.
Frequently asked questions
Has APRA issued a prudential standard specifically for AI?
No. APRA's 30 April 2026 letter to industry on AI sets out expectations and common weaknesses, but describes its framework as technology and vendor agnostic. It treats existing prudential standards as applying to AI; for security and supplier risk that mainly means CPS 234 and CPS 230.
Is an AI provider a third party under CPS 234?
If it manages your information assets, yes. Paragraphs 16 and 22 require you to assess that party's information security capability and evaluate the design of its controls, commensurate with the consequences of an incident.
Does CPS 234 require AI data to stay in Australia?
CPS 234 doesn't set a data location rule. Location is one input to the classification, control and third-party assessments it requires, and offshore processing can change the risk you're assessing.
Put this into practice with K9 AI.
Australian-hosted AI with redaction, classification and audit built in. Try it free for 14 days with no credit card, or talk to us about a pilot.