Industry Insight

Choosing an Engineering Partner for APRA-Regulated Delivery

How to assess third-party risk, review CPS 230 and CPS 234 evidence, and select the right engagement model

Eastgate Software Engineering

April 2026

Eastgate Software - German Engineering Standards. Enterprise-Grade Results.

Industry Insight

Choosing an Engineering Partner for APRA-Regulated Delivery

How to assess third-party risk, review CPS 230 and CPS 234 evidence, and select the right engagement model

APRA stands for the Australian Prudential Regulation Authority. It requires regulated organizations to manage risks from their service providers. The organization itself remains responsible, even when a partner delivers part of a key service.

This guide explains how CPS 230 and CPS 234 affect the review of technology partners. It shows which records to request, what questions to ask, and how to choose a delivery model that fits the risk.

Eastgate Software Engineering April 2026
Choosing an Engineering Partner for APRA-Regulated Delivery white paper cover

How Do APRA CPS 230 and CPS 234 Affect Engineering Partnerships?

APRA's CPS 230 (Operational Risk Management) and CPS 234 (Information Security) place the main duties on the regulated organization. They do not place the same duties on every engineering partner. They also cover information assets managed by outside parties.

First, each regulated organization must determine whether the engineering partner qualifies as a material service provider. It must then review the risks. The location of the team does not change this duty. However, a partner is not covered simply because it writes live code or handles data. The answer depends on the service, the assets involved, the impact if it fails, and the contract.

6 Areas of CPS 230 to Review Before Engaging an Engineering Partner

CPS 230 took effect on 1 July 2025. It requires APRA-regulated organizations to manage day-to-day risk and keep critical services running during a disruption. They must also oversee service providers that are classed as material.

However, you must assess whether the partner supports a critical operation or could create a serious operational risk. If it does, review the following six areas before signing and throughout the work.

1

Manage Operational Risk

The client must include risks from the service in its framework. The review should cover all the risks and focus on risks that could disrupt critical operations.

2

Determine Whether the Partner Is Material

First, assess whether the partner supports a critical operation. Writing production code alone does not decide this. Instead, consider the service, its dependencies, and the impact if it fails.

3

Check the Partner Before Signing

Before signing a material arrangement, check whether the partner can provide the service safely and reliably. Review its controls, resources, plans, use of subcontractors, and location or concentration risks.

4

Monitor the Service Over Time

Once work begins, the client must keep checking the service and its risks. Therefore, the contract should allow for regular reports, control reviews, performance checks, issue escalation, and audits.

5

Plan for Disruption

Continuity plans must account for dependence on the engineering partner. Both sides should agree on recovery steps, test plans, communication, and exit options before a disruption occurs.

6

Put Key Protections in the Contract

A material arrangement requires a formal written agreement. It should define the service, each party's duties, service levels, data ownership, audit access, subcontracting, continuity, disputes, and termination.

Complete due diligence before the client signs the contract or the service starts. However, the work does not stop there. The client must keep tracking performance, risk, and resilience throughout the partnership.

5 Areas of CPS 234 to Review With an Engineering Partner

CPS 234 requires an APRA-regulated organization to protect its information assets, including those managed by an engineering partner. Therefore, the organization must assess whether the partner's security capability and controls are suitable for the risks involved based on these 5 main areas:

Control Area What the Client Must Review Our Own Evidence
Governance Both sides should define who makes security decisions, manages access, responds to incidents, and reports control gaps. ISO 27001 governance records, a named security lead, and a responsibility matrix for each delivery stream.
Information Asset Identification The client must identify the information assets managed by the partner. It should then classify them by their importance and sensitivity. Asset register, data classification policy, and a project-specific data handling plan.
Risk-Based Security Controls Security controls should reflect the threats, weaknesses, and importance of each asset. As a result, higher-risk assets may need stronger controls. The ISO 27001 certificate and scope, evidence of access control, encryption, logging, and vulnerability management.
Incident Management Both sides should agree on how incidents will be detected and reported. In addition, the contract should give the client enough time to meet its own duties. An incident response plan, escalation routes, key contacts, test records, and a contractual two-hour initial alert target.
Control Testing Controls should be tested through a planned programme. However, the timing and depth of each test should reflect the level of risk, system changes, and importance of the assets. Penetration-test reports, vulnerability-scan records, ISO 27001 surveillance results, and records of corrective actions.

Important: When verifying ISO 27001 certification, check the scope statement. 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.

What Should ANZ Procurement Teams Request Before Engaging an Engineering Partner?

Once the organization has reviewed CPS 230 and CPS 234, procurement can turn those requirements into a practical checklist. Some items below support APRA requirements for material arrangements. Others provide added assurance during procurement.

0 of 32

Items completed

Work through each category and tick items as you complete them. Your progress saves in this browser.

Nothing left to do here. Turn off "Hide completed items" to review the items.

Nothing left to do here. Turn off "Hide completed items" to review the items.

Nothing left to do here. Turn off "Hide completed items" to review the items.

Nothing left to do here. Turn off "Hide completed items" to review the items.

Nothing left to do here. Turn off "Hide completed items" to review the items.

Which Engagement Model Best Manages APRA Regulatory Risk?

After completing the procurement checks, the organization must choose a suitable engagement model. However, no model is automatically low risk or APRA compliant. Each model creates different oversight needs.

Fixed-Scope Delivery

Low operational risk
How it works:
The contract defines the deliverables, price, timeline, acceptance criteria, and process for approving changes.
Best for:
Modernization projects, integrations, well-scoped platform work.
Risk level:
Easy to manage.

Friendly reminder: Clear deliverables and acceptance criteria can make performance easier to monitor. In addition, a defined endpoint can support transition planning. However, the arrangement is still material if it supports a critical operation. The organization must assess the service itself rather than relying on the contract type.

Embedded Engineering Team

Moderate operational risk
How it works:
A dedicated team works closely with the organization's internal teams, systems, and delivery processes.
Best for:
Ongoing product development, long-term modernization, and capability building.
Risk level:
Requires closer oversight.

Friendly reminder: An embedded team can have broad system access and hold important technical knowledge. As a result, the organization should assess access controls, key-person risk, continuity, knowledge transfer, and exit planning. However, an embedded team is not automatically a material service provider. Materiality depends on the role and risks of the arrangement.

Time-and-Materials Delivery

Highest operational risk
How it works:
The organization pays for the time and resources used while priorities and scope can change during delivery.
Best for:
Discovery work, evolving requirements, urgent fixes, and short-term specialist support.
Risk level:
Requires strong commercial and delivery controls.

Friendly reminder: Flexible scope can create uncertainty around cost, priorities, and completion. Therefore, the organization should use spending limits, approval controls, a managed backlog, clear security duties, and regular performance reviews.

How Does Eastgate's ACDC Support APRA-Regulated Delivery?

Whichever engagement model you choose, your organization needs a clear record of each software change. This record should explain why the change was made. It should also show how the change reached production.

ACDC stands for Agent-Centric Development Cycle. It is our internal method for managing AI-assisted delivery. AI tools may help teams work faster. However, their involvement can make decisions harder to trace. ACDC addresses this issue by giving every change a documented path.

Spec-Driven Design

Before development begins, we record each requirement in a structured OpenSpec document. We also define the relevant security limits and acceptance criteria. The specification then becomes the reference throughout delivery.

Test-Driven Design

We write tests before producing AI-assisted code. These tests define how the software should behave. We then check each output before the work progresses. The resulting records show how we verified the change.

Human Review and Approval

One of our qualified engineers reviews each AI-assisted change before it is merged or released. Higher-risk changes receive a deeper review. The review record shows who checked the work and approved the final decision.

ACDC gives you a traceable path from the original requirement to the final release. We can provide the records created along that path as assurance evidence.

Common Questions from ANZ Procurement and Risk Teams

What is the difference between CPS 230 and CPS 234 for third-party engineering vendors? +

CPS 230 (Operational Risk Management) focuses on the business continuity and operational risk obligations when relying on a material third-party service provider. It requires due diligence before engagement, ongoing monitoring, and contractual protections. CPS 234 (Information Security) focuses specifically on information security controls, requiring that your engineering partner's controls match the risk to your information assets. In practice, CPS 230 governs the relationship structure and governance, while CPS 234 governs the security of what the partner builds and handles.

Does APRA CPS 230 apply to offshore engineering teams? +

APRA's CPS 230 applies to material service providers regardless of geography. An offshore engineering team that supports a critical operation, or could create a serious operational risk, is in scope. The regulated entity remains fully accountable for the risk: delegating the work does not delegate the obligation. The same due diligence, contract protections, and ongoing monitoring requirements apply to a Vietnam-based engineering partner as to a Sydney-based one.

What evidence should an engineering partner provide to satisfy APRA due diligence? +

At minimum: an ISO 27001 certificate (verify the scope), an incident response plan with notification targets, a business continuity plan, a data handling and sovereignty statement, and a completed third-party risk questionnaire. For material arrangements, you should also request penetration testing reports, a SOC 2 or equivalent controls assessment, and documented subcontractor disclosure. The checklist in this paper covers every category.

How does Eastgate's ISO 27001 certification support APRA CPS 234 compliance? +

Our ISO 27001 certification covers the full engineering delivery environment, not just head office administration. The scope includes our Hanoi delivery hub, all project delivery systems, and the development, build, and deployment toolchain. This directly supports the CPS 234 requirement that a partner's controls suit the risks to the regulated entity's information assets. We provide the certificate, the Statement of Applicability, and the most recent surveillance audit report to qualifying ANZ clients.

What engagement model is most compatible with APRA CPS 230 requirements? +

No model is automatically APRA compliant. Fixed-scope, outcome-based delivery is usually the easiest to oversee: it creates a bounded dependency with defined deliverables, which is simpler to include in your continuity plan and to assess for concentration risk. Embedded teams deliver deeper capability for ongoing platform work but need closer oversight of access, key-person risk, and exit planning. Time-and-materials work needs strong commercial and delivery controls, so keep it to bounded, well-governed tasks.

Read the Full White Paper

Detailed framework, implementation methodology, and actionable insights - available instantly with your business email.

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

Let's Work Together

Tell us what you're building. Our engineers will respond within 1 business day with a concrete next step - no sales script, no obligation.