Voice AI for Australian Enterprises: APRA CPS 234 and IRAP Compliance

TL;DR

Australian banks, insurers, and superannuation entities must assess voice AI within their APRA CPS 234 information-security obligations and, where relevant, the current CPS 230 operational-risk standard. Government buyers may require assessment against the Information Security Manual (ISM) by an assessor in the Infosec Registered Assessors Program (IRAP). These are different obligations and evidence paths; a vendor cannot inherit or advertise a universal APRA or IRAP certification for every deployment.

For Australian buyers, the practical challenge is mapping real call data and service dependencies to the rules that apply to their entity. Hosting location, provider access, recordings, model processing, breach notification, continuity, and government classification can each change the required controls.

This article explains CPS 234 and IRAP in plain language, the evidence to request from a voice AI vendor, how Docker-based on-premise deployment changes the control boundary, and which obligations remain with the buyer. For a wider rollout view, see the Trillet Enterprise Voice AI Orchestration Guide.

For managed voice AI with Australian data-location or government assessment requirements, contact the Trillet Enterprise team to scope the architecture and evidence.

What is APRA CPS 234 and Why Does It Matter for Voice AI?

APRA CPS 234 requires regulated entities to maintain information security capabilities commensurate with their information assets and threat environment.

In plain language, CPS 234 is a rule from the Australian Prudential Regulation Authority (APRA), the body that supervises banks, insurers, and pension funds. It says regulated organizations must protect the data they hold to a standard that matches how sensitive and valuable that data is, and that the board, not just the IT team, is accountable for getting it right. The full text is published by APRA in the CPS 234 Information Security prudential standard, and the Australian Government's security control catalogue, the Information Security Manual (ISM), is maintained by the Australian Signals Directorate (ASD).

Prudential Standard CPS 234, effective since July 2019, applies to APRA-regulated entities including banks, insurers, and superannuation funds. Buyers should consult the current APRA text for their entity and arrangement. The core obligations include:

  • Clearly define information security roles and responsibilities
  • Maintain information security capability to manage vulnerabilities
  • Implement controls to protect information assets
  • Detect and respond to security incidents
  • Test control effectiveness through audits

For voice AI specifically, CPS 234 creates obligations around:

  1. Third-party risk management: Assess vendor access to information assets and, under CPS 230, determine materiality for the specific arrangement
  2. Data classification: Call recordings and transcripts containing customer PII require protection controls
  3. Incident notification: The APRA-regulated entity must notify APRA as soon as possible and no later than 72 hours after becoming aware of an incident that materially affected, or had the potential to materially affect, the entity or customers
  4. Board accountability: Directors bear responsibility for information security governance

The practical impact: an APRA-regulated institution must assess how the proposed voice AI service and vendor controls support its own CPS 234 obligations, then retain evidence for that decision.

What is IRAP and Which Organizations Need It?

IRAP is the Infosec Registered Assessors Program, under which endorsed assessors evaluate systems against relevant Australian Government Information Security Manual (ISM) controls.

An IRAP assessment gives a buyer findings about a defined system, boundary, controls, and date. The Australian Signals Directorate says assessors do not certify, accredit, endorse, or register systems, and the assessment does not itself establish compliance or an authority to operate (ASD IRAP guidance). The buyer must review the report and decide whether the proposed service meets its requirements.

The need for an IRAP assessment depends on the procuring agency, system boundary, information classification, and procurement terms. State, territory, critical-infrastructure, and healthcare buyers may have different assessment frameworks; none should be treated as automatically requiring IRAP.

Organizations that may request a scoped IRAP assessment, depending on their procurement and information classification, include:

  • Federal government departments and agencies
  • State and territory government bodies
  • Defense contractors and suppliers
  • Critical infrastructure operators
  • Healthcare organizations handling My Health Record data
  • Organizations bidding on government contracts

IRAP assessments evaluate voice AI platforms across domains including:

DomainVoice AI Relevance
Personnel securityWho has access to call data and systems?
Physical securityWhere are servers located?
Communications securityHow are voice streams encrypted?
ICT securityHow are systems hardened and patched?
Access controlWho can access recordings and transcripts?
Media handlingHow is call data stored and disposed?

Public vendor documentation may not disclose a private assessment or its scope. Ask shortlisted vendors for the exact evidence your procurement requires; SOC 2 and ISO 27001 can help with diligence but do not replace a required ISM or IRAP review.

What Gaps Should Australian Buyers Test in Voice AI Platforms?

Common risks are unclear processing locations, overseas support access, incomplete subprocessor maps, weak incident-reporting terms, and a lack of evidence for the proposed system boundary. These are due-diligence questions, not conclusions about every vendor.

When you examine the major voice AI platforms, a pattern emerges:

Retell AI: Request the current regional processing, BAA, subprocessor, and security-evidence terms for the exact product and plan.

Vapi: Map its component and provider choices, data regions, support access, and contractual controls for the intended workflow.

Synthflow: Verify current assurance reports, regional data paths, and any assessment material directly with the vendor.

For Australian enterprises, these gaps create real problems:

  1. Unapproved data flows: Recordings, transcripts, prompts, backups, or remote access may cross a boundary the buyer has contractually set.
  2. Evidence gaps: Auditors and procurement teams may lack current scope, controls, findings, or remediation evidence.
  3. Contract gaps: Notification, subcontractor, audit, exit, and continuity duties may be missing.
  4. Governance gaps: The regulated entity may be unable to show how it assessed and approved the arrangement.

The technical architecture matters too. Cloud-only platforms cannot satisfy organizations requiring air-gapped or on-premise deployments for sensitive workloads.

How Trillet Addresses Australian Enterprise Compliance

Trillet Enterprise can deploy its voice AI application layer via Docker in an approved on-premise architecture. The complete data boundary depends on telephony, speech, model, logging, support, backup, and integration choices documented for the engagement.

Trillet's enterprise offering addresses Australian compliance requirements through:

Configurable Data Residency

Australian enterprises can scope regional residency, including Australian processing where available for the selected architecture and providers. APAC is broader than Australia, so the Order Form and data-flow map must name the precise location and data categories. CPS 234 itself is not a blanket Australian-hosting mandate.

On-Premise Deployment via Docker

For organizations requiring a customer-controlled application boundary, Trillet can deploy the voice application layer on-premise using Docker containers where included in the agreement. The complete dependency chain still determines whether the broader system meets an infrastructure-control requirement. This architecture can enable:

  • An air-gapped design only if every required telephony, model, speech, support, and update dependency can operate inside the approved boundary
  • Integration with existing security monitoring and SIEM tools
  • Customer-controlled logging for the components in scope
  • Reduced third-party exposure where the whole call path is designed for it

For technical considerations, see on-premise voice AI deployment via Docker. The related on-premise voice AI guide corrects a previously unsupported claim that 62% of enterprises deploy voice AI locally; its cited broader AI study instead measures a preference for hybrid AI.

PII and PHI Handling Controls

Where included in the applicable Enterprise agreement, Trillet can provide options to:

  • Opt out of data storage entirely (ephemeral processing only)
  • Enable automatic PII/PHI redaction in transcripts
  • Configure custom data retention policies
  • Implement role-based access controls aligned with CPS 234 requirements

Compliance Certifications

Trillet's public assurance and available contract options include:

  • SOC 2 Type II and ISO 27001 certifications, with report scope to be reviewed
  • A BAA available for eligible Agency or Enterprise PHI workflows after the standard process and applicable Order Form
  • Engagement-specific evidence and controls to support an APRA-regulated customer's CPS 234 assessment
  • An IRAP assessment only where commissioned and scoped for a particular government system; no general IRAP certification is claimed

Fully Managed Service Model

Trillet can reduce the need for a dedicated internal voice AI engineering team. The customer still provides source-system owners, governance, access, policies, testing, and approvals. The managed scope can include:

  • Solution architecture and implementation planning
  • Integration with legacy CRM and telephony systems
  • 24/7 onshore (Australian) proactive monitoring
  • A financially backed 99.99% uptime SLA where approved in the signed Enterprise agreement

How to Evaluate Voice AI Vendors for APRA CPS 234 Compliance

APRA-regulated entities should assess voice AI vendors against specific criteria before procurement.

When evaluating voice AI platforms for APRA compliance, request documentation on:

1. Material Service Provider Classification

Material-service-provider classification is assessed by the APRA-regulated entity under CPS 230, not automatically assigned to every voice AI vendor under CPS 234. Verify the vendor can provide:

  • Completed APRA third-party questionnaires
  • Evidence of information security governance
  • Incident notification procedures
  • Audit rights and access

2. Data Residency Controls

Confirm whether the signed arrangement can commit to:

  • Defined Australian processing or storage for the required data categories
  • Documented exceptions, subprocessors, support access, and transfer mechanisms
  • Documented data flow architecture
  • Contractual data sovereignty commitments

3. Security Control Framework

Assess alignment with CPS 234 requirements:

RequirementVerification Questions
Information security capabilityWhat certifications does the vendor hold?
Vulnerability managementHow frequently are systems patched?
Incident responseWhat is the notification timeline for breaches?
Access controlsHow is access to call data restricted?
EncryptionWhat encryption standards protect data at rest and in transit?

4. Audit Support

Verify the vendor can support:

  • External auditor access for CPS 234 assessments
  • Penetration testing and security audit reports
  • Evidence of control ownership and remediation
  • Current assurance reports for their actual scope and period

How to Evaluate Voice AI Vendors for IRAP Assessment

Government agencies should verify voice AI platforms meet ISM control requirements before procurement.

For a procurement that requires IRAP, assess the proposed system against the relevant ISM controls and the agency's chosen information classification:

Assessment Classification

The procuring agency determines the information classification and selects assessment scope. Categories that may be relevant include:

  • OFFICIAL
  • OFFICIAL: Sensitive
  • PROTECTED

Do not infer a classification from a generic call type. The agency determines classification and assessment scope based on the information and connected systems.

Key ISM Controls for Voice AI

Control AreaISM RequirementVendor Verification
PersonnelApply the personnel-security controls selected for the systemWho has access, from where, and what screening or clearance is required?
CommunicationsApply the relevant ISM communications and cryptography controlsWhich protocols protect signaling, media, administration, and integrations?
CryptographyUse algorithms, key management, and configurations approved for the systemHow are recordings, transcripts, logs, and backups protected?
NetworkApply the segmentation, administration, monitoring, and boundary controls in scopeHow is the voice AI environment separated and monitored?
GatewayApply the gateway controls required by the architecture and assessment scopeWhich traffic is allowed, inspected, logged, and blocked?

Documentation Requirements

Request from vendors:

  • System Security Plan (SSP) aligned with ISM
  • Security Assessment Report if previously assessed
  • Statement of Applicability for ISM controls
  • Relevant penetration-test results and remediation evidence

Ask Trillet which penetration-test reports, security audit documentation, and assessment evidence apply to the proposed environment. Availability and scope should be confirmed in the Enterprise agreement.

Implementation Timeline for APRA and IRAP-Compliant Voice AI

Implementation timing depends on architecture, procurement, assessment, integration, and agency approvals. The following eight-week sequence is an illustrative planning model, not a committed schedule.

An Australian regulated project may use these workstreams:

Weeks 1-2: Discovery and Architecture

  • Map existing telephony and CRM infrastructure
  • Document compliance requirements and constraints
  • Design deployment architecture (cloud, hybrid, or on-premise)
  • Identify integration points with legacy systems

Weeks 3-4: Configuration and Integration

  • Deploy voice AI infrastructure per architecture design
  • Configure data residency and retention policies
  • Integrate with existing CRM and telephony systems
  • Implement access controls and audit logging

Weeks 5-6: Testing and Validation

  • Conduct security testing against CPS 234 or ISM controls
  • Validate data flows and residency compliance
  • Test failover and disaster recovery procedures
  • User acceptance testing with operational staff

Weeks 7-8: Documentation and Go-Live

  • Complete compliance documentation for auditors
  • Finalize runbooks and operational procedures
  • Transition to managed service operations
  • Conduct post-implementation review

Do not treat this sequence as a baseline commitment. Extensive legacy integration, assessment scope, evidence gaps, procurement, and agency approvals can change both the order and duration of the work.

Frequently Asked Questions

Can voice AI comply with both APRA CPS 234 and HIPAA simultaneously?

Potentially. An entity with both APRA and HIPAA obligations must map each regime to its specific workflow, execute a BAA before PHI processing where required, and document vendor and customer responsibilities. Trillet's certifications and available controls are evidence for that assessment, not an automatic determination of either regime's compliance.

Does on-premise deployment eliminate all compliance concerns?

On-premise Docker deployment can give the customer more control over the agreed application and storage boundary. It does not automatically localize carriers, model calls, remote support, backups, or connected systems, and it does not remove access, security, or incident obligations. The complete path still needs testing and documentation.

How do I get started with APRA CPS 234 compliant voice AI?

Start by documenting the entity's CPS 234 duties, any CPS 230 materiality decision, information classification, call data flows, and chosen residency limits. Contact Trillet Enterprise for a scoped architecture and evidence review.

How does Trillet handle APRA's 72-hour incident notification requirement?

Trillet provides 24/7 Australian monitoring for the managed Enterprise service. The APRA-regulated entity must notify APRA as soon as possible and no later than 72 hours after becoming aware of an incident that materially affected, or had the potential to materially affect, the entity or customers. Vendor detection, escalation, evidence, and notification timeframes should be set in the contract and tested with the customer's incident team; Trillet monitoring does not transfer the regulatory duty.

What happens if compliance requirements change?

APRA standards and the ISM can change. Assign a contract owner to review updates, reassess the architecture, and agree any control changes, testing, costs, and deadlines with Trillet. Ongoing legal monitoring and implementation duties depend on the signed scope.

Conclusion

Australian buyers need evidence that the proposed voice AI system fits their information-security, continuity, data-flow, and procurement requirements. CPS 234, CPS 230, ISM, and IRAP have distinct roles, and no public absence of a competitor badge proves that a vendor cannot meet a private procurement requirement.

Trillet Enterprise can scope Docker-based on-premise deployment, Australian or broader APAC residency, managed implementation, and security evidence for a regulated engagement. The buyer and Trillet must document the actual boundary, controls, responsibilities, and assessment scope. For vendor due diligence, see the enterprise voice AI security audit preparation guide and the Trillet Enterprise Voice AI Orchestration Guide.

For Australian enterprises evaluating voice AI, contact Trillet Enterprise to discuss your specific compliance requirements and implementation timeline.

Updated for September 2026: corrected CPS 234/CPS 230, IRAP, residency, on-premise, incident, BAA, assurance, SLA, and implementation claims while preserving Australian enterprise procurement intent.

Related Resources