# CPS 234 AI vendor due diligence checklist - TheAICommand artefact Name: CPS 234 AI vendor due diligence checklist Date: 2026-08-15 Source: https://theaicommand.com/library/artefacts/what-to-ask-an-ai-vendor-under-cps-234 Article: https://theaicommand.com/grc/cps-234-third-party-ai-vendor-due-diligence Licence: Free to use and adapt internally. Attribution appreciated. No warranty. Educational purposes only. Disclaimer: General information and education only. Not legal, compliance, financial, or professional advice. --- ### Section 1: the eight areas **1. Information asset identification and classification.** Document every information asset category the relationship will expose: prompts, fine-tuning data, embeddings, inference logs, configuration. For each, record the originating data source, the sensitivity classification under your information classification scheme, and the regulatory regimes that apply. Deliverable: an information asset inventory specific to the vendor relationship. Any change to what data flows to the vendor requires a review against this inventory. **2. Vendor architecture and chain mapping.** Identify the foundation model provider, the inference infrastructure provider, the data residency for each component, and any sub-processors. CPS 234 paragraph 16 requires the entity to assess the information security capability of a related party or third party that manages its information assets, commensurate with the potential consequences of an incident affecting those assets. You need to know what the chain looks like before you can make that assessment. Deliverable: an architecture diagram and chain map held by the entity, independently of the vendor's marketing material. **3. Control commitments.** Identify the controls the vendor commits to operate and the evidence available for them. CPS 234 paragraph 22 requires the entity to evaluate the design of a third party's information security controls that protect the entity's information assets. Where control evidence is thin in AI-specific areas (training data isolation, inference log access controls, model update governance), record a documented compensating control or an accepted residual risk. **4. Data handling commitments.** Answer these in writing before vendor selection. The vendor's standard terms often do not address them clearly. - Will prompts be used for model training? If yes, are there opt-outs and how are they evidenced? - How long are prompts and inference data retained? - Who at the vendor, or its sub-processors, can access prompts and inference data? - Are prompts and inference data ever co-mingled with other customers' data, including for service-improvement purposes? **5. Update and change management.** AI vendors update their underlying models, so the behaviour of the service may change without a new contract being signed. CPS 234 paragraph 27 requires testing at a nature and frequency commensurate with, among other factors, the materiality and frequency of change to information assets. Document the vendor's change management approach for model updates: notice given, testing you can perform, ability to roll back to a previous model version, and any substitute behaviour during a model deprecation. **6. Incident notification and response.** CPS 234 paragraph 35 requires notification to APRA no later than 72 hours after becoming aware of a material information security incident, and paragraph 36 requires notification no later than 10 business days after becoming aware of a material information security control weakness. Document the vendor's incident notification commitments, including coverage of AI-specific incident categories. The standard approach, where the vendor notifies the entity within a set number of hours, may not be sufficient where the incident category is novel. **7. Testing and assurance.** CPS 234 paragraph 27 requires control testing through a systematic testing program, and paragraph 28 extends this to third parties: where you rely on a third party's control testing, you must assess whether its nature and frequency is commensurate with the factors in paragraphs 27(a) to 27(e). Cover both standard control testing (penetration testing, configuration review) and AI-specific testing (prompt injection, data leakage, output quality drift). **8. Exit planning.** Document the exit pathway: what happens to fine-tuned models, embeddings and historical inference data when the relationship ends, data deletion commitments, attestation processes, and any residual information assets that will continue to exist post-exit. Record any irreducible information leakage paths. ### Section 2: three AI-specific failure modes Standard information security questionnaires do not cover these, because the underlying technology was not in scope when they were designed. - **Prompt injection.** A malicious or careless input causes the tool to behave in unintended ways, potentially exposing data or executing actions outside the design intent. Evaluate the vendor's input filtering, output review, and system prompt protection. - **Data leakage between customers.** In multi-tenant inference infrastructure, mistakes in tenant isolation can expose one customer's data to another. Examine the tenant isolation architecture explicitly, including cache and embedding-store isolation. - **Training data contamination.** Where the vendor uses customer data for any training purpose, even with consent, the data becomes part of the model's behaviour and may surface in responses to other customers. The commitments and operational controls should be specific and verifiable. ### Section 3: what to never do - Accept a vendor's standard SaaS contract for an AI deployment that touches customer data without the AI-specific addendum. - Rely solely on the vendor's logs for the audit trail you will need under APRA notification. - Treat AI vendor due diligence as a separate discipline from existing CPS 234 work. It is an extension, not a parallel. - Allow the vendor's inference infrastructure to host customer data without a documented residency and access posture. ### Section 4: governance checklist - Every material AI vendor relationship has all eight framework areas documented - An AI-specific addendum to the third-party security questionnaire is in use - Architecture and chain map exists for every material AI vendor, held by the entity and not the vendor - Testing cadence matches change cadence, and the rationale is documented - Incident notification commitments explicitly cover AI-specific failure modes - Exit planning addresses fine-tuned models, embeddings, and irreducible information assets - AI vendor concentration risk is reviewed at Board or Risk Committee level on an annual cycle