Industry Insight
APRA-Aligned Engineering Partnership Guide
Third-Party Risk Documentation, CPS 230/234 Compliance Evidence, and Outcome-Based Engagement for ANZ Enterprise
Eastgate Software - German Engineering Standards. Enterprise-Grade Results.
APRA-Aligned Engineering Partnership Guide: Third-Party Risk Documentation, CPS 230/234 Compliance Evidence, and Outcome-Based Engagement for ANZ Enterprise
APRA CPS 230 and CPS 234 raise the compliance bar for every third-party technology supplier to Australian regulated entities. This guide covers the specific obligations, what documentation to request, how to assess engagement models against regulatory risk, and how Eastgate structures evidence for ANZ procurement review.
Introduction
What Does APRA CPS 230/234 Actually Require of Your Engineering Partners?
APRA's Prudential Standard CPS 230 (Operational Risk Management) and CPS 234 (Information Security) create direct obligations for regulated entities engaging third-party technology vendors - including offshore engineering partners. Many ANZ technology leaders underestimate the scope: APRA does not distinguish between onshore and offshore suppliers. If an engineering team is delivering production code or handling regulated data, they are in scope.
This guide covers what the standards require, what documentation your engineering partner must provide, how to assess different engagement models against regulatory risk, and the specific evidence Eastgate provides to ANZ procurement teams.
Part I
What Are the Six Core CPS 230 Obligations for Third-Party Engineering Engagements?
CPS 230 became effective 1 July 2025. It applies to all APRA-regulated entities - ADIs, general insurers, life companies, and RSE licensees. These six obligations directly govern how regulated entities must manage material third-party engineering vendors.
Operational Risk Framework
Regulated entities must manage third-party operational risks within their enterprise risk framework. Engineering vendors are explicitly in scope as material service providers.
Material Third-Party Identification
Entities must identify and assess each material service provider. A third-party engineering team delivering production code on regulated systems qualifies under most interpretations.
Due Diligence Before Engagement
CPS 230 requires documented due diligence prior to engaging a material third party - including assessment of security practices, business continuity, and concentration risk.
Ongoing Monitoring
Regulated entities must monitor material third parties continuously, not just at onboarding. Vendors must support this with periodic reporting and audit rights.
Business Continuity Planning
Third-party dependencies must be included in the entity's business continuity plan. Engineering partners must provide BCPs and demonstrate ability to continue delivery under disruption.
Contractual Protections
Contracts must include termination rights, audit rights, data ownership provisions, and incident notification requirements aligned with APRA's CPS 230 expectations.
Key implication: Under CPS 230, due diligence must occur before engagement - not during onboarding. Requesting compliance documentation after signing a contract puts your organisation in breach of the standard's sequencing requirement.
Part II
How Does CPS 234 Apply to Your Engineering Partner's Security Controls?
CPS 234 requires that the information security controls of material third parties match or exceed the regulated entity's own standards. Below are the five control areas and the evidence Eastgate provides for each.
| Control Area | CPS 234 Requirement | Eastgate Evidence |
|---|---|---|
| Governance | Information security roles and responsibilities must be clearly defined across the third-party relationship | ISO 27001 ISMS governance documentation, named Information Security Officer, documented RACI for all delivery streams |
| Information Asset Identification | All information assets handled by the third party must be classified and documented | Asset register, data classification policy, project-specific data handling addendum available on request |
| Implementation of Controls | Third-party information security controls must match or exceed the entity's own control standards | ISO 27001 scope covers all project delivery environments - certificate and Statement of Applicability available |
| Incident Management | Incident detection, response, and notification processes must be documented and tested | Incident response plan, documented notification SLAs (2-hour initial notification for P1), annual tabletop exercise records |
| Testing of Controls | Control effectiveness must be tested by appropriately skilled personnel at least annually | Annual penetration testing, ISO 27001 surveillance audit reports, vulnerability management scan logs |
Important: When verifying ISO 27001 certification, check the scope statement - not just the certificate. A certificate that covers only head office administration does not satisfy CPS 234 for an engineering delivery partner. Eastgate's certification scope explicitly covers all engineering delivery environments.
Part III
What Should ANZ Procurement Teams Request Before Engaging an Engineering Partner?
Use this checklist during vendor assessment. Items marked as required are the minimum threshold for material third-party designation under CPS 230/234.
Certifications
- ISO 27001 certificate - verify scope covers engineering delivery, not just head office
- ISO 9001 certificate - quality management system audit coverage
- SOC 2 Type II report or aligned assessment (if available)
- Confirm certificate expiry dates and surveillance audit status
APRA CPS 230 Documentation
- Third-party risk questionnaire completed and signed
- Business continuity plan - minimum 4-hour RTO for critical delivery functions
- Concentration risk assessment - confirm vendor does not create unacceptable single-point dependency
- Sub-contractor disclosure - confirm whether work is further sub-contracted and to whom
APRA CPS 234 Documentation
- Information security policy and ISMS scope statement
- Incident response plan with APRA-aligned notification timeframes
- Penetration testing reports from last 12 months
- Data sovereignty statement - where code, data, and communications are stored and processed
Contractual Requirements
- Audit rights clause - entity retains right to conduct on-site security audit with reasonable notice
- Data ownership - IP and data ownership explicitly documented in favor of the regulated entity
- Incident notification obligations - contractual obligation to notify within agreed timeframes
- Termination and transition assistance - vendor must support orderly transition on contract end
Operational Assessment
- Reference checks from current and former clients in regulated industries
- Key person risk assessment - identify delivery lead dependencies and succession
- Delivery track record - request case studies and client references from comparable engagements
- Timezone and communication overlap - verify practical collaboration hours for ANZ teams
Part IV
Which Engagement Model Best Manages APRA Regulatory Risk?
The structure of your engineering engagement directly affects the complexity of your CPS 230 compliance obligations. Three common models, assessed for APRA compatibility.
Fixed-Scope Delivery
Low operational riskDefined deliverables, fixed price, clear definition of done.
Best for: Modernization projects, integrations, well-scoped platform work
APRA notes
Cleanest model for APRA purposes - contract specifies outcomes, not resources. Easier to include in BCP as a bounded dependency.
Embedded Engineering Team
Moderate operational riskDedicated team integrated into your engineering organisation, milestone-based billing.
Best for: Ongoing platform development, regulated system maintenance, long-term capability build
APRA notes
Requires material third-party designation under CPS 230. Needs full compliance pack, quarterly reporting, and annual audit. Higher due diligence but delivers deeper capability.
Time & Materials
Highest operational riskOpen-ended resource provision billed by the hour.
Best for: Short-term surge capacity only
APRA notes
Most difficult to manage under CPS 230. Scope creep risk and budget uncertainty conflict with regulated entity risk management expectations. Use only for bounded, non-critical tasks.
Eastgate Methodology
How Does Eastgate's ACDC (Agent-Centric Development Cycle) Apply to APRA-Regulated Delivery?
ACDC (Agent-Centric Development Cycle) is Eastgate's internal AI-augmented engineering methodology. In the context of APRA-regulated delivery, it addresses a specific concern: AI-assisted development introduces new risk vectors - unreviewed code, undocumented changes, non-deterministic outputs - that conflict with the auditability requirements of CPS 230/234.
Spec-Driven Design
All requirements are encoded in a structured OpenSpec before code generation begins. Creates an auditable trail from requirement to implementation - directly satisfying CPS 230's change management expectations.
Test-Driven Design
Test cases are defined before AI generates code. Every output is validated against concrete, documented assertions. Provides the automated evidence trail that CPS 234 control testing requires.
Human-in-the-Loop
A senior engineer reviews and approves every AI-generated output before merge. No unreviewed code enters the delivery pipeline. Maintains human accountability that APRA's oversight requirements demand.
Regulatory implication: Our ACDC methodology produces a structured audit trail from requirement to deployed code - OpenSpec documents, test case records, review approvals, and deployment logs. This evidence package is available to ANZ regulated entities as part of our compliance documentation pack.
Frequently Asked Questions
Common Questions from ANZ Procurement and Risk Teams
What is the difference between CPS 230 and CPS 234 for third-party engineering vendors?
Does APRA CPS 230 apply to offshore engineering teams?
What evidence should an engineering partner provide to satisfy APRA due diligence?
How does Eastgate's ISO 27001 certification support APRA CPS 234 compliance?
What engagement model is most compatible with APRA CPS 230 requirements?
Download the APRA-Aligned Engineering Partnership Guide
Third-party risk documentation, CPS 230/234 compliance evidence, and outcome-based engagement structures for ANZ enterprise buyers.
About Eastgate Software
Eastgate Software is a strategic engineering partner headquartered in Hanoi, Vietnam, with offices in Aachen, Germany and Tokyo, Japan. With 200+ engineers, 93% team retention, and 12+ years of delivery excellence, we build mission-critical systems for clients including Siemens Mobility and Yunex Traffic.
Our ACDC (Agent-Centric Development Cycle) methodology combines German engineering discipline with Vietnamese engineering talent to deliver enterprise-grade results across Intelligent Transportation, FinTech, Retail, and Manufacturing.
Contact: [email protected] | (+84) 246.276.3566 | eastgate-software.com
Ready to Start Your APRA Compliance Review?
Request Eastgate's full APRA compliance documentation pack - ISO 27001 certificate, incident response plan, data sovereignty statement, and third-party risk questionnaire response.
Engineers
ACDC (Agent-Centric Development Cycle)
Retention
Partners, not vendors
Years
Enterprise delivery