APRA CPS 230 Compliance: Managing Third-Party Tech Risk for Australian Financial Entities

A fintech CTO showed us a vendor register with 43 names, renewal dates, and risk ratings. It looked complete until we asked one question: which repository, deployment credential, recovery procedure, and named engineer would keep the payments operation running if the primary delivery team disappeared tomorrow?

The register could not answer. The business had performed vendor management as procurement administration. CPS 230 requires something harder: evidence that material service-provider arrangements are governed in relation to critical operations, impact tolerances, continuity, incident response, and operational risk.

That distinction matters for fintech software development, banking platforms, insurers, superannuation providers, and any Australian financial entity whose customer outcomes depend on software maintained by another organisation. CPS 230 has been in force since 1 July 2025. APRA’s transition treatment for existing material service-provider arrangements brought the compliance deadline to the earlier of 1 July 2026 or the next renewal, according to the CPS 230 implementation material summarised by BA-Copilot. The practical deadline is not a document date. It is the point at which your board, risk team, or APRA supervisor can ask for proof and your engineering organisation can produce it.

This guide takes one position: treat third-party technology risk as a delivery and resilience problem owned by the entity, not as a contract file owned by procurement. The regulated entity remains accountable. A technology partner can supply continuity, specialist capability, and evidence, but it cannot outsource the accountability attached to the code and service.

What CPS 230 changes for material service providers

CPS 230 changes the question from “do we have a contract with this vendor?” to “can we maintain a critical operation when this provider fails, is compromised, or becomes unavailable?” A material service provider is one whose service supports a critical operation or exposes the entity to material operational risk; the level of oversight must reflect that dependency, not the supplier’s label or contract value.

The approach fails when an entity classifies providers individually but never maps them to an end-to-end operation. A low-risk ticketing tool may sit beside a high-risk deployment provider, while a small engineering pod may have privileged access to the code and infrastructure that execute customer payments. The supplier’s size does not determine the risk. The operational dependency does.

APRA’s CPS 230 framework expects regulated entities to identify critical operations, set tolerance for disruption, manage material service-provider risk, and maintain continuity through severe disruption. The standard replaced several older arrangements, including CPS/SPS 232 business continuity management and CPS/SPS/HPS 231 outsourcing, as described by KPMG. APRA’s final targeted amendments to CPG 230 commenced on 1 July 2026 and provide further clarity on operational resilience, service-provider risk management, and ongoing compliance.

For a financial entity, the accountable chain looks like this:

• The board and senior management set risk appetite and oversee resilience.
• The entity identifies critical operations and the maximum disruption it can absorb.
• Technology and operations teams map the people, systems, data, facilities, and providers supporting those operations.
• Procurement and legal teams put enforceable controls around material arrangements.
• Engineering produces evidence that access, change, deployment, monitoring, backup, recovery, and exit mechanisms work.
• The service provider performs its agreed responsibilities, but does not become the holder of the entity’s prudential accountability.

That last point is where many APRA CPS 230 vendor management programmes go wrong. A clause saying “the vendor will maintain security” is not evidence of a working control. A service-level target is not a tested recovery capability. A vendor questionnaire is not a dependency map.

For Australian entities with Singapore or Hong Kong delivery teams, the operating model must also fit local control expectations. Singapore financial institutions commonly reason from MAS Technology Risk Management expectations around technology risk governance, access control, change management, resilience, and incident response. The frameworks are not interchangeable, but the engineering evidence overlaps: named ownership, controlled access, traceable changes, tested recovery, and a credible response path.

Our position is deliberately narrow: classify the arrangement by the operation it supports, not by whether the provider calls itself a consultancy, software vendor, contractor, or dedicated team. If the provider can change production code, operate infrastructure, handle sensitive data, or block recovery, it belongs in the same operational-risk conversation as the platform it supports.

Mapping your engineering vendor against the standard

The symptom of weak third-party risk management in Australia is not an empty vendor register. It is a register that cannot be reconciled with the production system. In one inherited environment, the risk team listed a “software development supplier,” while engineering knew the same supplier also held repository administration, cloud deployment, test-data access, and the only practical knowledge of a legacy settlement service.

That mismatch creates a false sense of control. The vendor has been named, but the dependency has not been understood. When an incident occurs, people discover that the service description in the contract does not match the service actually delivered.

Build the map from the critical operation outward. Start with the customer or market outcome: accepting a payment, processing a claim, administering a superannuation transaction, settling a trade, or keeping a multi-site operational platform available. Trace every application, interface, database, identity provider, cloud account, deployment path, data store, support queue, and human capability required to keep that operation within tolerance.

For each engineering provider, record at least:

• Which critical operation the provider supports.
• What service the provider actually performs, including work omitted from the statement of work.
• Which systems, environments, data sets, secrets, repositories, and production controls it can access.
• Which individuals hold privileged knowledge or permissions.
• What would stop if the provider were unavailable for one hour, one day, or the entity’s defined tolerance.
• Which internal owner can make decisions during an incident.
• What evidence demonstrates continuity, recovery, and controlled change.
• How the entity would replace the provider without losing code, operational knowledge, or access to its own systems.

Do not confuse this with renting headcount. Staff augmentation, body shopping, and per-hour developers supply people under a client-managed delivery model. The client owns prioritisation, architecture, QA coordination, DevOps, continuity, and the outcome. A delivery-owning pod is different: a technical lead, engineers, QA, and DevOps capability operate against a defined roadmap and control boundary, with the work, evidence, and handover obligations made visible to the client.

Neither model removes CPS 230 accountability. The difference is where operational work is owned day to day. With rented headcount, the entity must usually assemble the control system around individuals. With a properly governed dedicated pod, the provider can own agreed delivery controls while the entity retains oversight, approval rights, risk decisions, and accountability for the critical operation.

OmniStack’s model is built around engineers on our payroll and on the client roadmap. That continuity can help when an internal engineering capacity gap has left the entity dependent on a few overloaded employees, but it only belongs in a CPS 230 operating model if access, change, incident, recovery, and exit responsibilities are explicit.

Related:data backup, recovery, and resilience capabilities, useful when the vendor map exposes untested recovery dependencies.

Map dependencies from the critical operation outward

1. Start with the operation — Identify the customer or market outcome to preserve.
2. Trace operational dependencies — Map applications, infrastructure, data, deployment paths, and human capabilities.
3. Record provider responsibilities — Capture actual services, privileged access, and named individuals.
4. Assess provider unavailability — Record what stops within the entity’s defined tolerance.
5. Identify ownership and evidence — Name incident decision-makers; document continuity, recovery, change, and replacement evidence.

Contract clauses: resilience, exit plans, incident reporting

The root cause of most weak vendor arrangements is a contract that describes activity but does not define resilience. “Provide software development services” says what the supplier does commercially. It does not say how the entity will preserve a critical operation when the supplier suffers an outage, loses key personnel, experiences a cyber incident, or exits the market.

The contract should connect each clause to an operational owner and a piece of evidence. If the supplier must support recovery testing, identify who schedules the test, who supplies the runbook, who approves the result, and where the artefacts are stored. If the provider must report incidents, define the information needed to assess customer impact, affected systems, data exposure, containment, and recovery.

Exit planning deserves special attention in legacy modernisation and fintech software development. A provider can be contractually replaceable while being operationally irreplaceable because the deployment pipeline is undocumented, the domain model exists only in engineers’ memory, or the cloud account is controlled through a vendor-owned identity. Exit is not a termination letter. It is a tested capability to continue the critical operation with another team or internal staff.

We write exit obligations into the delivery rhythm rather than leaving them for renewal. Each material release should improve the entity’s documentation, automated tests, infrastructure definition, access records, and runbooks. A provider that becomes more indispensable with every sprint is increasing third-party risk, even if its service levels look excellent.

For teams operating across Australia and Singapore, contract language should also identify jurisdiction, data location, subcontractors, cross-border access, and regulatory cooperation. A Singapore-based engineer may be perfectly capable of maintaining an Australian platform, but the entity must know what access exists, how it is logged, and how the arrangement fits its own risk appetite and regulatory obligations.

Use the same discipline for AI-enabled development and quality assurance. If an AI tool can read source code, generate changes, inspect production-like data, or influence release decisions, it belongs in the dependency and access map. The label “AI tool” does not reduce the control requirement.

Exit readiness: Exit is tested continuity, not a termination letter.

• Connect every clause to an operational owner and evidence.
• Maintain documentation, automated tests, infrastructure definitions, access records, and runbooks.
• Test continued operation with another team or internal staff.

exit rights versus exit capability

• continuity without enforceable obligations — Contractual transition assistance remains undefined
• tested exit capability — Exit obligations support continuity with another team
• unresolved exit risk — Neither exit obligations nor continuity are established
• contractually replaceable only — The entity cannot operate the code without the supplier

Exit requires both enforceable obligations and tested continuity.

Evidence pack: access logs, change management, tested recovery

Verdict: an evidence pack is credible only when it proves that the control operated on the system supporting the critical operation. Policies and supplier attestations establish intent; access logs, approved changes, recovery results, and incident records show execution.

We build the pack around the questions an accountable executive or supervisor will ask. Who could access production during the period? What changed? Who approved it? What happened when the change failed? Which backup was restored? How long did recovery take? Which dependency was unavailable? Did the result remain inside the impact tolerance?

Access evidence

Export named-user access for source repositories, cloud consoles, CI/CD systems, databases, secrets stores, monitoring, ticketing, and production support tools. Retain approval records, role changes, privileged access reviews, and leaver removal. Shared accounts are a control failure because they prevent reliable attribution. A provider’s internal access policy does not substitute for the entity’s ability to see and challenge access to its environment.

Change evidence

For every material release, connect the requirement or incident to the pull request, review, test result, deployment record, approval, and rollback path. Emergency changes need their own trail, including why normal control was bypassed and when retrospective review occurred. A screenshot of a ticket is weak evidence if it cannot be tied to the deployed artefact and environment.

Recovery evidence

Recovery testing must exercise the dependencies that matter. Restoring a database snapshot while the identity provider, deployment pipeline, encryption key, or external payment interface remains unavailable does not demonstrate end-to-end continuity. Record the scenario, assumptions, participants, start and end times, data loss, defects, decisions, and remediation owner.

For operational resilience fintech programmes, the pack should be readable by both engineering and risk. A board-level summary can state the operation, tolerance, scenario, result, and unresolved exposure. The engineering annex should contain the logs, runbooks, architecture, test output, and remediation tickets. One document cannot serve both audiences well without a traceable evidence chain.

• Critical-operation map linked to material providers and internal owners.
• Current architecture and dependency diagrams, including human dependencies.
• Access review results and privileged activity logs.
• Change records, deployment history, test evidence, and rollback outcomes.
• Incident notifications, timelines, root-cause analysis, and corrective actions.
• Backup inventory, restore results, recovery tests, and unresolved gaps.
• Subcontractor register and cross-border access assessment.
• Exit plan, portability checks, documentation inventory, and transition test results.

Our dedicated engineering model can support this evidence chain when the pod has a named technical lead, QA ownership, DevOps responsibility, and a client-side accountable owner. It cannot fix an entity that has no decision rights, no production visibility, or no willingness to test failure. The pod supplies delivery continuity; the regulated entity supplies governance and risk decisions.

Teams that need a broader operating model can review dedicated engineering team capability aligned to a client roadmap, but the relevant test is not team size. The test is whether the arrangement leaves the entity with stronger control and better evidence than it had before.

Evidence over attestations: Prove controls operated on systems supporting the critical operation.

• Show who accessed production and who approved changes.
• Connect deployed changes to tests, approvals, and rollback paths.
• Demonstrate tested recovery against the operation’s impact tolerance.

How a dedicated pod is audited differently from a freelance bench

The comparison is not “employees versus contractors.” It is “a delivery system with accountable continuity versus a collection of individuals whose control boundaries the client must assemble.” A dedicated pod is easier to audit when it has stable membership, named technical ownership, integrated QA and DevOps, client-owned systems, and a documented responsibility matrix. A freelance bench can still be governed, but it usually requires more internal coordination and stronger individual-level controls.

There is also a real APAC hiring trade-off. For a Singapore-based senior engineer, the fully loaded in-house comparison includes base salary, 17 percent CPF, roughly 20 percent recruiting fee, and a three-month ramp before the first shipped increment. The relevant alternative is not a cheaper body. It is a delivery-owning pod that carries technical leadership, QA, and DevOps continuity against an agreed roadmap. The numbers below are deliberately expressed as components because the brief does not provide a salary figure or a pod fee.

We would hire in house when the capability is strategically permanent, the entity can recruit and retain the required leadership, and internal management can absorb the full control burden. In-house is the right choice when the organisation needs enduring domain ownership inside its own operating model rather than an external delivery unit.

We would not call a rotating freelance bench a resilience strategy. Rotation increases the chance that access reviews, undocumented decisions, and recovery knowledge drift apart. A pod is not automatically resilient either. Audit it against the same hard questions:

• Does the same team remain on the account, or does the provider rotate people when the roadmap becomes difficult?
• Can the entity retrieve code, infrastructure definitions, test suites, runbooks, and access records without negotiation?
• Does QA have authority to block an unsafe release?
• Can DevOps demonstrate recovery rather than merely describe it?
• Is there a client-side owner who can accept risk, approve changes, and direct incident response?
• Can the team continue operating if one technical lead is unavailable?

For leaders closing an engineering capacity gap, the decision should be made against the critical operation rather than the vacancy. If the entity needs one person to own a narrow internal capability, hire in house. If it needs a stable unit to modernise a legacy platform, maintain product delivery, strengthen QA, and build recovery evidence while the internal team stays focused on operations, a dedicated pod is the more coherent control boundary.

Use software development and modernisation capabilities as a starting point for defining that boundary, not as a substitute for the entity’s CPS 230 assessment. If the immediate gap is test evidence rather than feature capacity, AI-driven quality assurance and testing services may be relevant, but any AI-assisted workflow still needs access, review, data, and change controls.

The next decision is specific: take one critical operation, name every material technology provider supporting it, and ask for the evidence pack before signing or renewing the arrangement. If the provider cannot show who owns the code, who can change production, how recovery was tested, and how the entity would exit, the issue is not a missing form. It is an unresolved operational-resilience risk.

FAQ

Does CPS 230 make a technology vendor responsible for an APRA-regulated entity’s compliance?

No. The regulated entity remains accountable for operational risk management, critical operations, impact tolerances, continuity, and material service-provider oversight. A technology vendor can have contractual responsibilities and provide evidence, but it does not inherit the entity’s prudential accountability.

What makes an engineering provider material under CPS 230?

An engineering provider is material when its services support a critical operation or expose the entity to material operational risk. Privileged access to production, code, infrastructure, sensitive data, deployment systems, or recovery capability can make a provider material even when the supplier is small or the contract value is modest.

What evidence should a fintech collect from a material technology provider?

Collect evidence tied to the actual operation: access reviews and logs, change and deployment records, testing results, incident records, backup and restore tests, recovery exercises, dependency maps, subcontractor information, and exit documentation. Attestations are useful context but do not replace evidence that controls operated in the entity’s environment.

Can a dedicated engineering pod satisfy CPS 230 requirements?

A dedicated pod can support compliance by providing continuity, named technical ownership, integrated QA and DevOps, delivery records, and recovery evidence. It cannot satisfy the entity’s obligations by itself. The entity must define the critical operation, set tolerances, retain oversight, approve risk decisions, control its systems, and test the arrangement.

When should an Australian financial entity hire in house instead?

Hire in house when the capability is strategically permanent, the organisation can recruit and retain the required leadership, and internal management can carry the full delivery and control burden. A dedicated pod is more suitable when the immediate problem is a cross-functional capacity gap, legacy modernisation workload, or need for stable delivery continuity rather than one permanent internal role.