Most organisations now depend on cloud platforms, SaaS applications and, increasingly, AI model providers for services that matter. For APRA-regulated entities CPS 230 turns that dependence into a formal obligation: know who your material service providers are, do proper due diligence before relying on them, hold the right contract terms, monitor them, and be able to exit. The same discipline benefits any organisation whose operations depend on a few suppliers. This guide covers due diligence, contract points, concentration risk and exit planning for cloud, SaaS and AI vendors. It is general guidance, not legal advice.
Start with a register that reflects reality
CPS 230 requires a register of material service providers, and the entity must submit it to APRA annually in the format APRA specifies. A useful internal register goes further and covers every provider that supports a critical operation. For each provider record the service, the critical operations supported, the owner, contract dates and notice periods, data held and its classification, locations of storage and support, the provider's own key sub-contractors, service levels, the latest assurance evidence, and the exit plan status. Keep it in a system that can be queried, so concentration is visible, such as three critical operations on one cloud region or two SaaS products relying on the same fourth party.
Due diligence before you rely on a provider
CPS 230 expects appropriate due diligence before entering into or modifying a material arrangement, including an assessment of the provider's ability to deliver on an ongoing basis and of the financial and non-financial risks, including geographic and concentration risk. A practical checklist:
- Financial strength and viability. Ownership, funding, customer concentration and what happens in a sale or insolvency.
- Security. Independent assurance such as ISO/IEC 27001 or SOC 2, penetration testing, vulnerability handling, incident history and notification commitments.
- Resilience. Architecture, recovery objectives, test evidence, regional design and dependence on other providers.
- Data. Location, residency options, encryption and key control, segregation, retention, deletion and return.
- Legal and compliance. Privacy, jurisdiction of support staff, subpoena or government access terms and sub-contractor controls.
- Operational fit. Support model, change management, release cadence and deprecation policy.
- Exit. Data export formats, transition assistance, notice periods and any escrow or step-in options.
Due diligence is proportionate. A provider of a trivial tool does not need the same scrutiny as one that holds customer data for a critical operation. Tier your providers and apply the effort accordingly.
AI providers need extra questions
When the provider is a large language model or other AI service, add these questions: Where are prompts, outputs and logs processed and stored, and can you restrict them to Australian regions? Are your inputs used to train models, and can that be switched off in writing? How are model versions changed or retired, and how much notice do you get? What happens to your service if the model is withdrawn, rate-limited or repriced? Is there an alternative model that can be swapped in behind your own interface? Which sub-processors host the model? Our guide to responsible AI adoption and the LLM gateway architecture go deeper on controls and portability.
Contract terms that matter
For all material arrangements, CPS 230 expects a formal, legally binding agreement that, at a minimum, specifies the services and service levels, sets out the rights, responsibilities and expectations of each party including ownership of assets, ownership and control of data, dispute resolution, audit access, liability and indemnity, supports the entity's legal and compliance obligations, requires the provider to notify the entity of other material service providers it relies on, and places liability for failures with the provider as appropriate. Large vendors often offer standard terms. Where the terms cannot be changed, document which requirements are met through the vendor's documentation or addenda, which are not met, the compensating controls, and the decision to accept the residual risk. Get your lawyers to review, because this guide is not contract advice.
Concentration and substitutability
Look at concentration on four axes: provider, region, technology stack and fourth party. Then ask how substitutable each is. Some services can be replaced with moderate effort, such as object storage. Others, such as a core banking platform or a specialised clinical system, may take years. Be honest in the plan about substitutability and match controls to it: a tested second region, regular data export in open formats, source or configuration escrow, and extra monitoring where substitution is slow.
Exit planning that works
An exit plan is a tested capability. It should answer:
- Triggers. What events start an exit or a substitution: insolvency, breach, sustained service failure, sanctions, price changes, regulator direction or loss of key sub-contractor.
- Scenarios. Orderly exit at end of contract, stressed exit with short notice, and sudden provider failure.
- Data. How the data is exported, in what format, how often, how it is verified and where it lands.
- Service. What replaces the service: another provider, in-house build, or manual fallback, and the minimum service level in the meantime.
- People and knowledge. Who runs the exit, what documentation exists and what skills the new path needs.
- Timeline and cost. Realistic duration and cost compared with tolerance, with gaps escalated.
- Rehearsal. A scheduled test for critical providers: export, restore into a clean environment and prove the operation runs.
See the exit strategy reference architecture, which shows a portability layer, scheduled exports, a second provider path and escrow.
Monitoring through the life of the arrangement
Review performance against service levels, control effectiveness and contract compliance at a frequency that matches criticality. Track provider incidents, acquisitions, outages, security reports and regulatory actions. Report to senior management, and update the register and exit plan when anything material changes. Remember that a material change to an arrangement for a critical operation may itself trigger a notification to APRA within 20 business days.
What small suppliers can learn from this
If you are the provider, expect to be asked for much of this. A clear security and resilience pack, current assurance evidence, a sub-contractor list, a data export and exit description and a standard incident notification commitment make you easier to buy from. See our guide for suppliers on CPS 234 and third-party security.
This article reflects general practice and the published standard as at October 2026. Take advice before acting on it.
Talk to an Adelaide team
If you need a provider register, an exit design or a rehearsed switch plan for a key cloud, SaaS or AI service, talk to us about a provider dependency review or call 0402 401 584. See our DevOps and cloud engineering and AI consulting services.