APRA CPS 230 Operational Risk and AI Vendors

Table of Contents

1. What APRA CPS 230 Actually Means for AI Vendors
2. The Material Service Provider Test
3. Operational Risk Controls and Evidence
4. Third-Party Risk Management Framework
5. Business Continuity and Resilience Requirements
6. Building Your Compliance Evidence Base
7. Audit Preparation and Documentation
8. Common Pitfalls and How to Avoid Them
9. Practical Implementation: PADISO’s Approach
10. Next Steps and Governance

---

What APRA CPS 230 Actually Means for AI Vendors

APRA CPS 230 is not theoretical. It is a live operational risk management standard that affects every Australian Authorised Deposit-taking Institution (ADI), insurer, and superannuation fund that relies on external service providers—including AI vendors, cloud platforms, and automation tools.

The standard sits at APRA CPS 230 Operational Risk Management and mandates that regulated entities maintain oversight of third-party risks that could materially impair their ability to operate. If your AI platform, automation tool, or data service is classified as a “material service provider” under CPS 230, you are now in scope of that regulated entity’s compliance obligations.

What does this mean in practice? A major Australian bank using your AI agent for customer service, a fund manager using your workflow automation for trade settlement, or an insurer using your claims processing system—they all need to demonstrate to APRA that they have:

• Documented oversight of your operational resilience
• Contractual obligations that bind you to continuity and security standards
• Audit rights to verify your controls
• Exit or contingency plans if you fail
• Regular testing of recovery procedures

For AI vendors, this translates into real commercial pressure. Your customers cannot renew or expand their use of your platform without evidence that you meet CPS 230 requirements. Your contract terms, security posture, and operational governance are now part of their compliance file.

The shift from “nice to have” to “non-negotiable” happened in 2023–2024. We have seen AI vendors lose six-figure annual contracts because they could not produce audit evidence of uptime commitments, disaster recovery plans, or security controls. Conversely, vendors who invested in compliance infrastructure have won new deals and expanded existing ones.

APRA’s perspective is clear: Navigating Operational Risks: CPS 230’s Influence on AI and Cybersecurity Strategies shows that operational risk now includes vendor risk, AI risk, and resilience risk in equal measure. Your AI vendor is no longer a software purchase—it is a material operational dependency.

---

The Material Service Provider Test

Not every vendor is a “material service provider” under CPS 230. The distinction matters because it determines the depth of controls, documentation, and audit obligations required.

APRA defines materiality by asking: If this service provider failed, could the regulated entity no longer meet its prudential obligations or regulatory requirements?

For AI vendors, materiality typically turns on:

Criticality to Core Operations

If your AI system directly supports revenue-generating or risk-critical functions—claims processing, trading systems, customer onboarding, credit decisioning—you are almost certainly material. A bank cannot process mortgage applications without its decisioning engine. An insurer cannot settle claims without its automation platform. These are material.

Conversely, an AI tool used for internal reporting or non-critical analytics may not be material, even if it saves time. The test is whether the regulated entity could continue to meet its obligations if the tool went down.

Volume and Concentration

If 30% or more of a transaction type flows through your system, APRA treats you as material. If a single customer concentration exceeds a threshold (often 5–10% of their revenue or critical operations), materiality is triggered. We have seen AI vendors become material overnight when a customer integrated them into their core settlement process.

Data Sensitivity

If you hold, process, or have access to customer personal information, credit data, or transaction records, you are material. Voice AI and APRA CPS 230: Operational Resilience Requirements makes this explicit: voice AI systems that record customer interactions are material because they hold sensitive data.

Regulatory or Legal Obligations

If a regulated entity cannot meet its ASIC, AUSTRAC, or APRA reporting obligations without your service, you are material. A platform that feeds data into regulatory reporting is material by definition.

How to Know If You Are Material

Ask your largest customers directly. Bring this question into your customer success and sales conversations:

• “Have your compliance or risk teams classified us as a material service provider under CPS 230?”
• “Are we listed in your third-party risk register?”
• “Has your internal audit team requested a SOC 2 report or security questionnaire?”

If the answer to any of these is yes, you are material. Plan accordingly.

The practical implication: material AI vendors need operational risk controls that are documented, tested, and auditable. Non-material vendors can often get away with lighter-touch documentation. But the line is blurry, and it shifts as customers scale their use of your platform.

---

Operational Risk Controls and Evidence

Once you are classified as material, APRA expects your regulated customers to have evidence that you operate robust controls across five domains:

1. Information Security and Confidentiality

This is the baseline. You must have:

• Access controls (role-based, multi-factor authentication, least privilege)
• Data encryption (in transit and at rest)
• Segregation of customer data (no cross-contamination)
• Audit logging (who accessed what, when, and why)
• Vulnerability management (regular scanning, patching cycles, penetration testing)

The evidence is typically a SOC 2 Type II report or ISO 27001 certification. PADISO’s Security Audit service helps vendors achieve SOC 2 and ISO 27001 audit-readiness via Vanta, which generates the evidence artefacts that regulated customers require.

For AI vendors specifically, information security must extend to:

• Model and training data protection (who can access training datasets, how are they stored)
• API key and credential management (rotation, revocation, no hardcoding)
• Third-party dependencies (if your AI uses external APIs or cloud services, those are in scope too)

2. Availability and Business Continuity

Your customers need contractual and operational evidence that you will be available when they need you. This includes:

• Uptime commitments (SLA, typically 99.5% or higher for material services)
• Redundancy and failover (geographic distribution, automatic recovery)
• Disaster recovery plan (documented, tested, with recovery time objectives—RTO—and recovery point objectives—RPO)
• Backup and restoration procedures (tested regularly, not just documented)
• Incident response playbook (how you handle outages, who communicates, timelines)

The evidence is your disaster recovery test results, your SLA reports, your incident logs. Customers will ask to see these. Some will require annual DR testing with their own teams.

3. Operational Resilience and Stress Testing

APRA now requires regulated entities to test their ability to survive severe operational shocks. If you are material, your customers will ask you to participate in stress tests or scenario exercises:

• “What if your primary data centre fails?”
• “What if you lose 50% of your staff?”
• “What if your cloud provider has a regional outage?”
• “What if a key supplier (e.g., your AI model provider) becomes unavailable?”

Your answers must be grounded in documented procedures and past test results. Vague reassurance is not acceptable. Regulated customers need evidence that you have thought through these scenarios and have plans in place.

4. Audit and Transparency Rights

Material service providers must grant regulated customers (and their auditors) the right to:

• Audit your controls (on-site or remote)
• Review your security documentation (policies, procedures, test results)
• Verify your compliance with contractual obligations
• Access your incident logs and performance data

This is contractual, not optional. Your terms of service must explicitly permit customer audits. Many AI vendors balk at this, citing competitive sensitivity. But if you want to be a material service provider, audit rights are non-negotiable.

5. Incident Reporting and Escalation

When something goes wrong—a security breach, an outage, data loss—you must notify your customers quickly and provide transparent information. APRA expects:

• Incident notification within 24 hours (or sooner for critical incidents)
• Root cause analysis (why did it happen)
• Remediation plan (how will you prevent it happening again)
• Impact assessment (which customers were affected, what data was involved)

This is where many AI vendors stumble. They either hide incidents or provide vague, delayed communication. Regulated customers need timely, detailed information so they can assess whether they need to notify their own regulators or customers.

---

Third-Party Risk Management Framework

If you are a material AI vendor, your regulated customers will apply a third-party risk management framework to you. This is a structured process that typically includes:

Due Diligence and Onboarding

Before signing a contract, regulated entities conduct due diligence on vendors. This includes:

• Financial stability checks (can you survive a downturn)
• Ownership and control verification (who owns the company, is there a conflict of interest)
• Security and compliance questionnaires (detailed, often 50+ questions)
• Reference checks (calling other customers to ask about your reliability)
• Regulatory status checks (are you licensed, do you have any regulatory findings)

The questionnaire is the key artefact. CPS 230 Implementation: Your Roadmap to Compliance outlines typical vendor risk assessment categories. Expect to answer questions on:

• Data residency and sovereignty
• Subcontracting and outsourcing (who are your vendors)
• Regulatory compliance (SOC 2, ISO 27001, etc.)
• Disaster recovery and business continuity
• Cybersecurity maturity
• Incident history

Ongoing Monitoring

Once you are live, regulated customers monitor you continuously:

• Performance metrics (uptime, latency, error rates)
• Compliance attestations (annual SOC 2 reports, security certifications)
• Regulatory filings (ASIC, APRA, AUSTRAC announcements about you)
• News and reputation monitoring (are you in the news for the wrong reasons)
• Regular check-ins (quarterly or annual calls with your leadership)

Periodic Reassessment

Every 2–3 years, regulated customers re-assess their material vendors. This is your chance to demonstrate improvements:

• New security certifications
• Enhanced disaster recovery capabilities
• Geographic expansion (new data centres)
• Expanded audit rights
• Improved SLAs

Vendors who invest in these upgrades typically see contract renewals and expansions. Those who stand still lose customers.

---

Business Continuity and Resilience Requirements

APRA’s CPS 230 standard is increasingly focused on operational resilience—the ability to absorb shocks and continue serving customers. For AI vendors, this translates into concrete requirements:

Documented Business Continuity Plan

You must have a written plan that covers:

• Critical functions (which services must be restored first)
• Recovery time objectives (RTO—how quickly must you restore each function)
• Recovery point objectives (RPO—how much data loss is acceptable)
• Roles and responsibilities (who does what when things fail)
• Communication protocols (how you notify customers, regulators, staff)
• Escalation procedures (who makes decisions, what are the authorities)

The plan must be version-controlled, regularly reviewed, and tested. Regulated customers will ask to see it. Many will require you to update it annually.

Geographic and Infrastructure Redundancy

If you operate from a single data centre, you are vulnerable. Regulated customers expect:

• Multi-region deployment (at least two geographically separate locations)
• Automatic failover (no manual intervention required)
• Data replication (real-time or near-real-time)
• Independent infrastructure (not just multiple servers in the same facility)

For Australian regulated entities, data residency is critical. CPS 230: Your roadmap to compliance emphasises that data must remain in Australia unless the customer explicitly permits otherwise. If you are a cloud-based AI vendor, ensure your infrastructure is Australian-hosted or has explicit customer consent.

Disaster Recovery Testing

Documentation is not enough. You must test your disaster recovery plan regularly:

• Annual full DR test (simulate a complete failure and recover)
• Quarterly partial tests (test specific components or scenarios)
• Tabletop exercises (walk through scenarios with your team)
• Customer participation (invite key customers to observe or participate)

Regulated customers will ask for test results. Some will require you to test with them present. If you cannot produce evidence of regular, successful DR testing, you are not material-vendor ready.

Vendor Concentration and Dependency

If your AI platform depends on a single cloud provider, a single model provider, or a single third-party service, that is a concentration risk. Regulated customers will ask:

• “What happens if your cloud provider has a regional outage?”
• “What happens if your AI model provider (e.g., OpenAI, Anthropic) goes down or changes their terms?”
• “What happens if your payment processor fails?”

You need documented contingency plans. For critical dependencies, consider:

• Multi-cloud architecture (AWS and Azure, or AWS and GCP)
• Model diversification (if you use third-party LLMs, have fallback options)
• Service provider alternatives (if you depend on a payment processor, have a backup)

---

Building Your Compliance Evidence Base

Compliance is not a state; it is a collection of evidence. Regulated customers assess you by examining documentation, test results, certifications, and audit reports. Here is how to build a robust evidence base:

Security Certifications

SOC 2 Type II is the minimum expectation. This is a third-party audit of your security controls, conducted over at least 6 months. It covers:

• Access controls (who can access your systems)
• Change management (how you deploy code safely)
• Encryption (data in transit and at rest)
• Incident response (how you handle breaches)
• Logical and physical security

SOC 2 costs AU$20–50K and takes 6–9 months to obtain. But it is the language that regulated customers speak. Without it, you will lose deals.

ISO 27001 is a more comprehensive information security standard. It covers all aspects of information security management, including:

• Information security policies
• Asset management
• Access control
• Cryptography
• Physical and environmental security
• Operations security
• Communications security
• System acquisition, development and maintenance
• Supplier relationships
• Information security incident management
• Business continuity management

ISO 27001 is more rigorous than SOC 2 and is increasingly required for material vendors. It costs AU$30–80K and takes 6–12 months.

PADISO’s Security Audit service helps vendors achieve SOC 2 and ISO 27001 audit-readiness via Vanta in weeks, not months. Vanta is a compliance automation platform that generates evidence artefacts (policy templates, control assessments, audit logs) that feed directly into your SOC 2 and ISO 27001 audits.

Disaster Recovery Test Reports

Document every DR test:

• Date and time
• Scenario tested (e.g., “primary data centre failure”)
• Team involved
• Steps taken to recover
• Time to recovery (RTO)
• Data loss (RPO)
• Issues encountered
• Lessons learned
• Actions to prevent recurrence

Keep these reports for at least 3 years. Regulated customers will ask to see them. If you have 3 years of successful DR tests, you are credible.

SLA and Performance Reports

Track and publish your uptime:

• Monthly uptime percentage
• Incidents and their duration
• Root causes
• Remediation actions
• Performance trends

If you commit to 99.5% uptime, you need evidence that you are meeting it. Automated monitoring tools (e.g., Datadog, New Relic) can generate these reports.

Incident Logs and Post-Mortems

When incidents occur, document them thoroughly:

• Incident description
• Detection time
• Impact (which customers, how many transactions)
• Root cause
• Resolution steps
• Time to resolution
• Preventive actions
• Post-incident review

Regulated customers will ask for incident logs. If you have a pattern of incidents, that is a red flag. If you have few incidents and thorough post-mortems, that is credible.

Audit and Attestation Letters

If external auditors have assessed your controls, keep their reports:

• SOC 2 audit reports
• ISO 27001 certification
• Penetration test reports
• Compliance assessment letters
• Customer audit results

These are gold. They provide independent verification of your controls.

---

Audit Preparation and Documentation

Regulated customers (and their auditors) will audit you. Prepare for this:

Internal Audit Readiness

Before a customer audit, conduct your own internal audit:

• Review all policies and procedures
• Verify that controls are operating as documented
• Test access logs, encryption, backups
• Review incident logs and post-mortems
• Check that staff are trained on security policies
• Verify that contracts include required audit rights

An internal audit will reveal gaps before a customer sees them. Fix gaps before customer audits.

Documentation and Artefacts

Prepare a compliance folder that includes:

• Security policy
• Access control procedures
• Change management procedures
• Incident response plan
• Business continuity plan
• Disaster recovery plan
• Data protection and privacy policy
• Vendor management policy
• Risk assessment and treatment plan
• SOC 2 or ISO 27001 reports
• Disaster recovery test results
• Incident logs (last 3 years)
• SLA and performance reports
• Audit logs (sample, last 90 days)
• Staff training records
• Contracts (redacted, showing audit rights and SLA commitments)

Organise this logically. Auditors will ask for specific documents. If you can produce them quickly, you save time and build confidence.

Audit Logistics

When a customer schedules an audit:

• Assign a point person (usually your security or compliance lead)
• Prepare a meeting room with internet access
• Arrange for relevant staff to be available (engineering, operations, security)
• Provide access to systems for auditors to review logs
• Be transparent and honest about gaps or issues
• Follow up promptly with any information requested

Auditors are not trying to trick you. They want to understand your controls and verify that you are managing risk responsibly. Cooperation and transparency go a long way.

---

Common Pitfalls and How to Avoid Them

We have seen AI vendors make the same mistakes repeatedly. Here are the most common and how to avoid them:

Pitfall 1: Treating Compliance as a Checkbox

The mistake: Getting a SOC 2 report and thinking you are done.

The reality: Compliance is ongoing. SOC 2 is a snapshot in time. Regulated customers expect continuous improvement and evidence of active management.

How to avoid it: Establish a compliance program with clear ownership, regular reviews, and continuous improvement. Assign someone (or a team) to own compliance. Review your policies and procedures annually. Track and remediate findings from audits. Communicate improvements to customers.

Pitfall 2: Overpromising on Uptime

The mistake: Committing to 99.99% uptime without the infrastructure to support it.

The reality: If you miss your SLA, you damage trust and trigger customer escalations. Regulated customers are especially sensitive to uptime failures.

How to avoid it: Be realistic about your uptime. If you can reliably deliver 99.5%, commit to 99.5%. Build redundancy and monitoring to support your commitment. Track uptime meticulously. If you miss SLA, investigate root cause and communicate transparently.

Pitfall 3: Weak Vendor Management

The mistake: Using third-party services (cloud, AI models, payment processors) without assessing their risk.

The reality: If your vendors fail, your customers’ regulators will ask why you did not have oversight. You inherit your vendors’ risks.

How to avoid it: Apply the same rigor to your vendors that your customers apply to you. Assess their security, resilience, and compliance. Require SLAs and audit rights. Monitor them continuously. Have contingency plans if they fail.

Pitfall 4: Poor Incident Communication

The mistake: Hiding incidents or providing vague, delayed updates.

The reality: Regulated customers need timely, accurate information to assess impact and decide whether to escalate to their regulators. Lack of transparency erodes trust.

How to avoid it: Establish an incident response process that includes rapid notification to customers. Provide updates every 2–4 hours during an incident. Be specific about what failed, who is affected, and when you expect resolution. Publish a post-mortem within 5 business days. Learn from incidents and prevent recurrence.

Pitfall 5: Inadequate Disaster Recovery Testing

The mistake: Having a DR plan that has never been tested.

The reality: An untested plan is fiction. When a real disaster strikes, your team will not know what to do.

How to avoid it: Test your DR plan at least annually. Involve your team. Document the results. If the test reveals gaps, fix them. Repeat the test to verify the fix. Keep records of all tests.

Pitfall 6: Ignoring Regulatory Changes

The mistake: Thinking CPS 230 is stable and will not change.

The reality: APRA is actively updating its standards. New prudential standards are released regularly. Regulated customers are adopting new requirements.

How to avoid it: Subscribe to APRA updates. Read regulatory announcements. Engage with your customers’ compliance teams. Attend industry forums. Anticipate changes and plan ahead.

---

Practical Implementation: PADISO’s Approach

At PADISO, we partner with AI vendors to build compliance into their operations from day one. Here is our practical approach:

Phase 1: Compliance Assessment (2 weeks)

We conduct a AI Quickstart Audit to understand your current state:

• Which customers are regulated and material
• What compliance obligations they have imposed
• What evidence you currently have
• What gaps exist
• What is your priority roadmap

This is a fixed-scope, fixed-fee engagement. We tell you where you actually are, what to ship first, what to retire, and what 90 days could unlock.

Phase 2: Compliance Roadmap (4 weeks)

Based on the assessment, we build a prioritised roadmap:

• Immediate (0–8 weeks): Quick wins that close critical gaps (e.g., audit logging, access controls)
• Medium-term (2–3 months): Foundational work (e.g., SOC 2 preparation, DR testing)
• Long-term (3–6 months): Strategic improvements (e.g., ISO 27001, multi-region deployment)

We focus on outcomes, not activities. The roadmap is grounded in your customers’ actual requirements, not generic compliance checklists.

Phase 3: Evidence Building (8–16 weeks)

We help you build the evidence artefacts that regulated customers require:

• Security policies and procedures (written, reviewed, communicated)
• Access control implementation (role-based, multi-factor, audit logging)
• Encryption and data protection (in transit, at rest, in backups)
• Disaster recovery plan and testing (documented, tested, improved)
• Incident response process (rapid notification, root cause analysis, remediation)
• SOC 2 or ISO 27001 preparation (via Vanta, generating evidence)

We work with your engineering and operations teams to embed compliance into your workflows. Compliance is not a separate function; it is how you operate.

Phase 4: Customer Readiness (ongoing)

Once you have evidence, we help you communicate it to customers:

• Compliance communications (“Here is our SOC 2 report, here is our DR test results”)
• Audit support (preparing for customer audits, responding to questions)
• Contract negotiation (ensuring your terms include required audit rights and SLA commitments)
• Continuous improvement (monitoring, testing, and improving controls)

For AI-specific vendors, we also advise on:

• Model governance (how you manage third-party AI models, how you test for bias and drift)
• Data protection (how you handle customer data in training and inference)
• Transparency and explainability (how you explain model decisions to customers)

Our AI Advisory Services extend to compliance and operational risk. We help vendors understand how their AI systems fit into regulated customers’ risk frameworks.

---

Next Steps and Governance

If you are an AI vendor serving Australian regulated entities, here is how to move forward:

Immediate Actions (This Week)

1. Identify your regulated customers. Which of your customers are ADIs, insurers, or superannuation funds? Which are material to those customers?

2. Ask your customers directly. Are you classified as a material service provider? What compliance obligations have they imposed on you?

3. Review your contracts. Do they include audit rights? SLA commitments? Incident notification obligations? If not, you need to update them.

4. Assess your current state. Do you have SOC 2 or ISO 27001? Have you tested your disaster recovery plan? Do you have incident logs and post-mortems?

Short-Term Actions (Next 4 Weeks)

1. Engage a compliance partner. If you do not have internal compliance expertise, bring in external support. PADISO’s Security Audit service can help you achieve SOC 2 and ISO 27001 audit-readiness via Vanta.

2. Prioritise your roadmap. Based on customer requirements, what is your priority? Often it is SOC 2, then DR testing, then incident response.

3. Assign ownership. Who in your organisation owns compliance? If it is no one, that is a problem. Assign a person or team.

4. Communicate with customers. Let them know you are taking compliance seriously. Share your roadmap. Ask for their input on priorities.

Medium-Term Actions (Next 3 Months)

1. Build evidence artefacts. Implement the controls and generate the documentation that regulated customers require.

2. Test your systems. Run a disaster recovery test. Review your incident response process. Verify that your access controls are working.

3. Pursue certifications. If you do not have SOC 2, start the process. If you have SOC 2, consider ISO 27001.

4. Prepare for audits. Organize your compliance folder. Brief your team on audit expectations. Run an internal audit.

Governance and Ongoing Management

Compliance is not a project; it is how you operate. Establish governance:

• Compliance committee (quarterly reviews of policies, risks, and improvements)
• Risk register (identify and track operational risks)
• Control testing schedule (monthly or quarterly testing of key controls)
• Incident management process (rapid detection, notification, investigation)
• Customer communication cadence (annual or semi-annual updates on compliance status)

For vendors serving regulated customers, compliance is competitive advantage. Customers will choose vendors with strong compliance evidence. Vendors who invest in compliance win deals and expand relationships.

APRA’s CPS 230 Implementation: Your Roadmap to Compliance emphasises that compliance is not just about passing audits; it is about managing operational risk responsibly. Vendors who take this seriously build trust, reduce customer churn, and create sustainable competitive advantage.

Specific Resources for AI Vendors

If your platform involves AI models, voice, or data processing, pay special attention to:

• Data residency and sovereignty. How to achieve APRA CPS 230 compliance with Gatekeeper highlights vendor governance and procurement. Ensure your AI infrastructure is Australian-hosted or has explicit customer consent.

• Model governance. If you use third-party LLMs (OpenAI, Anthropic, etc.), document your vendor management. Have contingency plans if model providers change their terms or become unavailable.

• Transparency and explainability. Regulated customers increasingly require explainable AI. If your model makes decisions (e.g., credit decisioning, claims triage), be prepared to explain how it works.

• Bias and fairness testing. Regulated customers care about AI bias. Document your testing and mitigation strategies.

For financial services vendors specifically, AI for Financial Services Sydney | PADISO provides AI strategy and delivery aligned with APRA CPS 234, ASIC RG 271, and AUSTRAC requirements. For insurance vendors, AI for Insurance Sydney | PADISO covers claims automation, conduct risk monitoring, and underwriting AI aligned with APRA and Life Insurance Framework requirements.

---

Conclusion

APRA CPS 230 has fundamentally changed the relationship between AI vendors and regulated customers. Compliance is no longer optional; it is a commercial requirement.

Vendors who invest in operational risk controls, build robust evidence bases, and communicate transparently with customers will thrive. Those who treat compliance as a checkbox will lose deals and face customer churn.

The good news: compliance is achievable. You do not need to be perfect. You need to be credible, transparent, and continuously improving.

Start today. Identify your regulated customers. Understand their requirements. Build your roadmap. Execute. Measure. Improve.

If you need support, PADISO’s CTO Advisory and AI services can help you navigate compliance, build operational resilience, and scale your platform sustainably. We have worked with dozens of vendors serving regulated customers. We know what works.

Book a 30-minute call to discuss your compliance roadmap. We will tell you where you are, what to prioritise, and what 90 days could unlock.