{"id":210,"date":"2026-06-18T21:46:25","date_gmt":"2026-06-18T17:46:25","guid":{"rendered":"https:\/\/blog.neomeric.com\/?p=210"},"modified":"2026-07-11T23:56:39","modified_gmt":"2026-07-11T19:56:39","slug":"ai-vendor-risk-management-apra-cps-230","status":"publish","type":"post","link":"https:\/\/neomeric.com\/blog\/ai-vendor-risk-management-apra-cps-230\/","title":{"rendered":"AI Vendor Risk Management Under APRA CPS 230"},"content":{"rendered":"\n

AI vendor risk management under APRA CPS 230 means treating every third party that builds, hosts, or runs an AI system on your behalf as part of your own operational risk surface \u2014 and proving you can control it. APRA’s Prudential Standard CPS 230 (Operational Risk Management)<\/a>, in force since 1 July 2025, requires banks, insurers, and superannuation trustees to identify their material service providers, assess the risks those providers introduce, and maintain the ability to keep critical operations running if a provider fails. When that provider is an AI vendor, the standard’s expectations apply in full. On 1 July 2026, the standard’s transitional arrangements for pre-existing service-provider contracts ended — every material arrangement, however old the contract, is now in full scope. This guide sets out what that means in practice, the supplier-risk traps specific to AI, and the practical checklist Australian regulated entities and their material service providers need to work through now — especially where the deadline arrived before the work was finished.<\/p>\n\n\n\n

The urgency is real. APRA’s 30 April 2026 letter to industry on AI<\/a> singled out artificial intelligence as an area where boards must understand third-party and supplier concentration risk before relying on AI in critical operations. With the transitional grace period now closed (it ended on 1 July 2026), an unfinished supplier register or unmapped AI dependency is no longer a project milestone \u2014 it is a live compliance exposure. Too many organisations still run AI governance that is active on paper but inactive in practice, which is exactly the gap CPS 230 is designed to close.<\/p>\n\n\n

Recent change to be across:<\/strong> on 30 April 2026 APRA finalised targeted amendments to CPS 230<\/a> that commenced 1 July 2026, creating limited exemptions from specific contractual requirements for material arrangements with certain non-traditional service providers such as central banks, payment schemes and clearing facilities. The exemptions are narrow — they do not soften anything for commercial AI vendors, whose arrangements remain squarely in scope.<\/p>\n\n\n\n

What is AI vendor risk management under APRA CPS 230?<\/h2>\n\n\n\n

AI vendor risk management under CPS 230 is the discipline of identifying, assessing, monitoring, and controlling the operational risk that AI service providers introduce to your critical operations. CPS 230 replaces the older CPS 231 (Outsourcing) and CPS 232 (Business Continuity) with a single, broader operational-risk standard that took effect on 1 July 2025 (with transitional arrangements for pre-existing arrangements ending 1 July 2026). Crucially, its scope is not limited to formal “outsourcing”: it covers any material service provider<\/em> whose disruption could affect a critical operation, which sweeps in AI platforms, model providers, data-labelling vendors, and the cloud regions they run on.<\/p>\n\n\n\n

The shift matters because AI procurement rarely looks like traditional outsourcing. A risk team might never sign a master services agreement with the foundation-model provider sitting three layers down the stack, yet that provider can still take down a critical operation. APRA’s view is unambiguous: accountability cannot be outsourced. Even where a provider is exempt from formal registration, the board remains responsible for the operational resilience of the service. McKinsey’s latest State of AI<\/a> survey found 88% of organisations now use AI in at least one function, but only a minority can point to measurable bottom-line returns \u2014 with fragmented data and weak knowledge governance among the recurring culprits, the same weaknesses that turn a vendor outage into a business-continuity event.<\/p>\n\n\n\n

Which AI vendors count as “material service providers”?<\/h2>\n\n\n\n

A material service provider is any party whose failure or disruption could have a significant impact on an APRA-regulated entity’s business operations or its ability to manage risk. For AI, this typically captures four layers: the application vendor you contract with directly; the foundation-model or inference provider behind it; the cloud platform and region hosting the workload; and any data, retrieval, or labelling service that feeds the model. Each layer is a potential single point of failure.<\/p>\n\n\n\n

Most entities materially underestimate this map. The Office of the Australian Information Commissioner recorded a record 1,205 notifiable data breaches in 2025<\/a>, a meaningful share involving third-party providers \u2014 proof that supplier risk is where exposure concentrates. To classify your AI vendors, work backwards from your critical operations: list the operations that must keep running to meet customer or regulatory obligations, then trace every AI dependency that supports them. Any vendor whose outage would breach a tolerance is material, regardless of contract size. This is the same dependency-mapping discipline we describe in our guide to building an AI governance framework for Australia in 2026<\/a>.<\/p>\n\n\n\n

Hear it before you buy it<\/h4>

Maeve is our AI voice teammate \u2014 she answers every call, books jobs and speaks from your business’s own knowledge. Live in 60 minutes, hosted in Australia, from $79\/mo.<\/p>Meet the AI teammates<\/a><\/div>\n

What does CPS 230 actually require for AI suppliers from 1 July 2026?<\/h2>\n\n\n\n

Under CPS 230 \u2014 with no transitional carve-outs remaining for pre-existing contracts after 1 July 2026 \u2014 regulated entities must maintain a register of material service providers, conduct due diligence before engagement and on an ongoing basis, set and monitor service-level and risk tolerances, and hold tested plans to respond to provider failure. Applied to AI, that translates into five concrete obligations.<\/p>\n\n\n\n