CPS 234 Compliance Checklist for AI Tools in Financial Services

CPS 234 Was Not Written for AI, But It Applies to Every AI Tool You Use

APRA Prudential Standard CPS 234 (Information Security) came into force on 1 July 2019. Paragraph numbers below are from the July 2019 standard. It was designed to ensure APRA-regulated entities maintain information security commensurate with the size and extent of threats to their information assets.

CPS 234 does not mention artificial intelligence. It does not need to. The standard applies to information assets, and every piece of data processed by an AI tool is an information asset. When a fund manager pastes a DDQ into ChatGPT, when an insurer feeds claims documents into a cloud AI service, or when a super fund uses a generative AI tool to draft member communications, CPS 234 applies.

With CPS 230 (Operational Risk Management) in force since 1 July 2025, and pre-existing service provider contracts brought under it at renewal or by 1 July 2026, the obligations around AI tool adoption are tightening. Firms that adopted AI tools informally (staff using ChatGPT on personal accounts, teams experimenting with cloud AI services) now face a compliance gap that APRA expects to be closed.

This checklist covers what Australian financial services firms must verify before any AI tool touches client data.

The Checklist

1. Information Asset Classification

CPS 234 requirement: An APRA-regulated entity must classify its information assets, including those managed by related parties and third parties, by criticality and sensitivity (CPS 234, paragraph 20).

What this means for AI tools:

Every category of data that flows into or out of an AI tool must be classified:

• Client personal information (names, addresses, TFNs, beneficial ownership details), highest sensitivity
• Financial data (portfolio positions, performance figures, fee structures, investment strategies), commercially sensitive
• Compliance documents (DDQ responses, regulatory filings, audit artifacts), regulatory sensitivity
• Internal operational data (meeting minutes, policy documents, procedures), moderate sensitivity

Checklist items:

• All data categories processed by the AI tool are documented and classified
• Classification aligns with your existing information security policy
• The AI tool's data handling matches the classification level: highly sensitive data requires stronger controls
• Data classification is reviewed when the AI tool's scope expands (e.g., adding new document types or data sources)

Common failure: Firms classify their CRM and administration data but forget to classify AI inputs and outputs as separate information assets. If a staff member pastes client data into an AI tool, that interaction is an information asset, even if the AI tool is not formally part of your technology stack.

2. Third-Party Risk Assessment

CPS 234 requirement: Where information assets are managed by a related party or third party, the entity must assess the information security capability of that party commensurate with the potential consequences of an information security incident (CPS 234, paragraph 16). It must also evaluate the design of that party's controls (paragraph 22), and where it relies on the party's control testing, assess whether that testing is adequate (paragraph 28).

What this means for AI tools:

Any AI service that processes your data externally is a third party under CPS 234. This includes:

• Cloud AI APIs (OpenAI, Google Gemini, Anthropic API, Microsoft Copilot)
• SaaS platforms with embedded AI (document processing tools, CRM add-ons with AI features)
• Consulting firms using AI on your data (see the Deloitte incident where undisclosed AI use in a government report resulted in fabricated references and a contract refund)

Checklist items:

• Every AI tool that processes your data is identified and documented as a third-party provider
• Due diligence has been conducted on each provider's information security posture
• The provider's data processing locations are documented, including whether a local residency option exists for your plan
• The provider's data retention and deletion policies are documented and acceptable
• The provider's model training practices are understood: do the terms for your plan allow it to train on your inputs?
• The provider's sub-processors are identified and assessed
• Contractual arrangements address information security requirements, incident notification, and audit rights
• The assessment is reviewed at least annually, or when the provider's terms change

Common failure: Staff adopt AI tools without IT or compliance involvement. A portfolio analyst uses ChatGPT to draft DDQ responses. A compliance officer uses an AI summarisation tool on regulatory documents. These are third-party data processing relationships under CPS 234, even if no formal procurement occurred.

The on-premise alternative: Running the AI inside your own infrastructure (your Azure tenancy, your AWS account, your data centre) narrows this category rather than removing it. Your data stays under your controls and your logs, so fewer parties hold it. But the vendor that supplies and maintains the software is still a third party under paragraphs 16, 22 and 28, and so is any external AI model the system sends data to. The assessment gets smaller and easier to evidence. It does not disappear.

3. Access Controls

CPS 234 requirement: An APRA-regulated entity must have information security controls that protect its information assets, commensurate with their criticality and sensitivity and the threats to them (CPS 234, paragraph 21). Access control is one of the most basic of those controls.

What this means for AI tools:

• Who can use the AI tool?
• What data can each user access through the AI tool?
• Are access permissions aligned with your existing role-based access controls?

Checklist items:

• AI tool access is managed through your existing identity and access management (IAM) framework
• Role-based access controls determine what data each user can process through the AI tool
• Access is provisioned and de-provisioned through the same processes as other information systems
• Privileged access to the AI tool's configuration and training data is restricted and logged
• Multi-factor authentication is enforced for AI tool access
• Access reviews include the AI tool in their scope

Common failure: Cloud AI tools operate outside your IAM framework. When a staff member accesses ChatGPT with a personal account, your access controls do not apply. You cannot restrict what data they input, you cannot audit their usage, and you cannot revoke access through your standard processes.

4. Logging and Audit Trails

CPS 234 requirement: An APRA-regulated entity must have robust mechanisms in place to detect and respond to information security incidents in a timely manner (CPS 234, paragraph 23), and maintain, review and test plans to respond to them (paragraphs 24 to 26). Detection depends on logging.

What this means for AI tools:

Every interaction with an AI tool that processes client data must be logged within your controlled environment:

• What data was input to the AI
• What output the AI generated
• Who initiated the interaction
• When the interaction occurred
• What actions were taken on the AI's output (approved, rejected, modified)

Checklist items:

• All AI tool interactions involving client data are logged
• Logs are stored within your controlled infrastructure (not solely in the AI provider's environment)
• Logs include sufficient detail for incident investigation and regulatory reporting
• Log retention periods meet APRA's expectations and your internal policies
• Logs are included in your security monitoring and alerting framework
• AI-generated outputs are version-controlled with approval workflows

Common failure: Cloud AI tools maintain their own logs, but you may not have access to them, or they may be purged according to the provider's retention schedule, not yours. If APRA asks for an audit trail of how a specific document was generated, you need that trail within your systems.

5. Incident Response

CPS 234 requirement: An APRA-regulated entity must notify APRA as soon as possible, and no later than 72 hours after becoming aware, of a material information security incident (CPS 234, paragraph 35). A material control weakness it cannot remediate in time must be notified within 10 business days (paragraph 36).

What this means for AI tools:

If a cloud AI provider experiences a data breach that affects your data, you must:

1. Detect that the incident has occurred (which requires the provider to notify you)
2. Assess the impact on your information assets
3. Notify APRA within 72 hours if it is material
4. Review whether the provider's controls and response change your assessment of it

Checklist items:

• Your incident response plan includes scenarios involving AI tool security incidents
• Contractual arrangements with AI providers include timely incident notification obligations
• You have a process to assess the impact of a provider-side incident on your information assets
• APRA notification procedures are documented and tested for AI-related incidents
• Incident response exercises include AI tool scenarios

Common failure: A provider's standard terms may not commit it to tell you about an incident quickly enough for you to meet APRA's 72-hour clock. Check the notification clause in each contract before relying on it.

6. Information Security Capability

CPS 234 requirement: An APRA-regulated entity must maintain an information security capability commensurate with the size and extent of threats to its information assets (CPS 234, paragraph 15), and clearly define information security roles and responsibilities (paragraph 14).

What this means for AI tools:

• Does your team have the expertise to assess AI-specific security risks?
• Are AI tools included in your vulnerability assessments and penetration testing?
• Is there clear ownership of AI tool security within your organisation?

Checklist items:

• AI tools are included in your information security risk assessment
• Roles and responsibilities for AI tool security are clearly defined (who owns the risk?)
• Your security team has the capability to assess AI-specific threats (prompt injection, data extraction, model manipulation)
• AI tools are included in your vulnerability management and testing programs
• Board or senior management reporting includes AI tool risk assessment

Common failure: AI security is treated as a technology risk rather than an information security risk. CPS 234 does not distinguish between the two: if an AI tool processes information assets, it falls within the standard's scope, and your information security capability must extend to cover it.

7. Testing

CPS 234 requirement: An APRA-regulated entity must test the effectiveness of its information security controls through a systematic testing program (CPS 234, paragraph 27). Testing must be conducted by appropriately skilled and functionally independent specialists (paragraph 30).

What this means for AI tools:

• Are AI tools included in your security testing program?
• Has the AI tool been tested for information security risks specific to AI (data leakage through prompts, output manipulation, unauthorised access to training data)?

Checklist items:

• AI tools are included in your systematic security testing program
• Testing covers AI-specific risks: data leakage, prompt injection, output accuracy, access control bypass
• Testing is conducted by specialists with AI security expertise
• Testing frequency is commensurate with the sensitivity of data processed by the AI tool
• Testing results are reported to senior management and remediation is tracked
• Testing includes scenarios where the AI tool is unavailable (business continuity)

CPS 230: The Third-Party Deadline

CPS 230 (Operational Risk Management) introduces additional requirements for managing material service provider relationships. Since 1 July 2025, APRA-regulated entities must:

• Identify and manage material service providers (which may include AI providers if the AI tool supports a critical operation; core technology services are treated as material unless the entity can justify otherwise)
• Maintain business continuity plans that address service provider disruptions
• Ensure service provider arrangements do not compromise the entity's ability to meet prudential obligations

For firms that have adopted cloud AI tools for document generation, compliance reporting, or client communications, CPS 230 requires a formal assessment of whether that AI provider is a material service provider, and if so, whether the arrangement meets APRA's expectations.

The Practical Path Forward

There are two approaches to CPS 234 compliance for AI tools:

Approach 1: Comply with third-party requirements. Conduct full CPS 234 due diligence on every cloud AI provider. Negotiate contractual terms covering data handling, incident notification, audit rights, and sub-processor management. Implement logging and monitoring of external AI interactions. Maintain ongoing assessment as provider terms change. This is achievable but creates significant ongoing compliance overhead.

Approach 2: Narrow the third-party risk. Deploy AI inside your own infrastructure. The system runs on your compute, processes data within your environment, and operates under your existing information security controls. Your access controls, logging, incident response and testing frameworks extend to cover it. The software vendor, and any external AI model the system calls, remain third parties to assess under paragraphs 16, 22 and 28, but there are fewer of them and the evidence sits in your systems.

For many APRA-regulated entities, Approach 2 is operationally simpler. Most of the conversation becomes "how do we secure this system in our environment", which your information security team already does, with a narrower third-party assessment beside it.

BackPro AI can be deployed On-prem into your own cloud subscription on Azure, AWS or Google Cloud, which is Approach 2, or hosted by us in Australia. It collects evidence against CPS 234 and CPS 230 and maps your controls to the standards' requirements. Collecting evidence for a standard is not certification, and BackPro holds neither SOC 2 nor ISO 27001.

Book a walkthrough to see how BackPro is deployed and what it records for CPS 234.

Related reading: Why Australian Fund Managers Can't Use ChatGPT for Client Documents | Why On-Premise AI Is Non-Negotiable for Australian Financial Services | APRA Compliance Automation for Super Funds