Overcoming Hurdles in CPS 234 Third-Party Audits for Australian Financial Firms
Alexander Sverdlov
Security Analyst

APRA's Prudential Standard CPS 234 has one clause that trips up almost every Australian bank, insurer, and superannuation fund I have worked with: the requirement to manage information security across the third parties that hold or process your data. You can lock down your own environment perfectly and still fail, because a payroll provider, a cloud host, or an outsourced help desk has weak controls you never verified. I am Alexander Sverdlov. I have run more than 200 security assessments across 14 countries since 2013, and third-party assurance is where I see APRA-regulated entities lose the most sleep and the most audit points.
This article walks through the five hurdles that actually derail CPS 234 third-party audits, and what a regulated entity should do about each one. No hype, no invented case studies. Just the practical mechanics of getting your vendor assurance program to a state where an APRA review or an internal audit will not embarrass you.
What CPS 234 Actually Requires From You Regarding Third Parties
CPS 234 makes the regulated entity accountable for information security even when an asset is managed by someone else. The standard does not let you outsource the responsibility along with the workload. In plain terms, you must:
- Identify and classify the information assets managed by third parties, including their criticality and sensitivity.
- Assess whether the information security controls of those third parties are appropriate to the sensitivity of the assets and the threats they face.
- Maintain controls, and testing of those controls, at a frequency that reflects the rate of change and the criticality of the asset.
- Notify APRA of material information security incidents within 72 hours, and of material control weaknesses within 10 business days, including those originating at a third party.
The phrase "information assets managed by related parties and third parties" is the heart of it. If a supplier can touch, store, or transmit your regulated data, it is inside your CPS 234 scope whether or not your contract says so. That single fact is what makes third-party audits difficult, because your visibility stops at your own perimeter while your accountability does not.
Hurdle 1: Limited Visibility Into Vendor Systems
You cannot assess a control you cannot see. Most third parties will not give a customer direct access to their production environment, and they are right not to. The problem is that many regulated entities treat that refusal as the end of the conversation and simply trust the vendor. APRA does not accept trust as a control.
The way through is layered assurance evidence rather than direct inspection:
- Independent audit reports. Request the vendor's SOC 2 Type II report, ISO 27001 certificate with the current Statement of Applicability, or equivalent. Read the scope carefully. A SOC 2 that covers a different product line than the one you use is worthless to you.
- Bridge letters. If the SOC 2 reporting period ended months ago, ask for a bridge letter covering the gap to today.
- Security questionnaires mapped to your controls. Do not send a generic 300-question spreadsheet. Send targeted questions tied to the specific data the vendor handles.
- Right-to-audit clauses. For your most critical suppliers, negotiate the contractual right to audit or to commission an independent assessment. You may never exercise it, but the right itself changes the vendor's behaviour.
Where a vendor is genuinely opaque and material to your operations, that opacity is itself a finding. Document it as a residual risk, escalate it to the accountable owner, and decide consciously whether to accept it. A documented, accepted risk survives an audit. An undocumented gap does not.
Hurdle 2: Inconsistent Control Standards Across Vendors
One supplier certifies to ISO 27001, another produces a SOC 2, a third runs on a cloud platform with its own shared-responsibility model, and a fourth has nothing but a marketing page claiming it is "bank grade." Comparing them apples to apples is the second major hurdle.
The fix is to stop assessing vendors against their own frameworks and start assessing them against yours. Build a single internal control baseline, mapped to CPS 234 and to a recognised catalogue such as ISO 27001 Annex A or the CIS Controls, and evaluate every third party against that same baseline regardless of which certification they hold. This is exactly the discipline an ISO 27001 readiness program instills, and it pays off directly in vendor management.
The table below shows how the same underlying control obligation surfaces differently depending on the evidence a vendor provides, and where the assessor has to do real work.
| Control area | What weak vendor assurance looks like | What defensible assurance looks like |
|---|---|---|
| Access management | Vendor says "we use MFA" with no scope | SOC 2 control tested, covers admin and customer-facing access |
| Data segregation | Shared tenancy assumed, never confirmed | Architecture documented, logical separation evidenced |
| Incident notification | No contractual notification timeline | Contract requires notice fast enough for your 72-hour APRA clock |
| Sub-processors | Fourth parties unknown | Sub-processor list maintained and flow-down obligations imposed |
Notice the incident notification row. If your vendor is contractually allowed to tell you about a breach five days after they discover it, you cannot meet APRA's 72-hour notification obligation no matter how good your own processes are. Notification timelines in vendor contracts are a control, and most third-party audits find them missing.
Hurdle 3: Documenting Vendor Assurance in an Audit-Ready Way
The single most common reason a well-run security program still struggles in an audit is documentation. The controls exist, the assessments happen, but the evidence lives in email threads and one analyst's memory. When APRA or internal audit asks "show me how you assured this supplier's controls in the last 12 months," you need a paper trail, not a recollection.
An audit-ready vendor file for each material third party should contain:
- The information assets the vendor handles and their classification.
- The most recent independent assurance evidence and its scope and validity dates.
- A risk assessment with a residual risk rating and a named accountable owner.
- The contractual security obligations, including notification timelines and right-to-audit.
- Any identified gaps, the remediation plan, and target dates.
- The date of the next scheduled reassessment, driven by the asset's criticality.
Keep it consistent across every vendor. Auditors reward consistency because it demonstrates a repeatable process rather than heroic one-off effort. A tidy, uniform vendor register is often worth more in an audit than a marginally stronger but undocumented control.
Hurdle 4: Sustaining Ongoing Monitoring
CPS 234 is not a point-in-time standard. Controls must be maintained, and their effectiveness tested, on a frequency that reflects how fast things change. A vendor that was secure at onboarding two years ago is an unknown quantity today. Continuous assurance is where most programs quietly decay, because the initial due diligence gets done and then nobody revisits it.
Practical monitoring for a regulated entity looks like this:
- Tiered reassessment cadence. Critical vendors annually at minimum, with material changes triggering an immediate review. Lower-tier vendors on a longer cycle.
- Certification expiry tracking. Diarise when each SOC 2 or ISO 27001 lapses so you are not caught relying on an expired report.
- Change triggers. A vendor acquisition, a new sub-processor, a data centre migration, or a public breach at the vendor should all force a fresh look outside the normal cycle.
- Independent validation of your critical path. Periodic penetration testing and vulnerability assessment of the integrations that connect you to key vendors, because the connection is often where the real exposure sits.
Monitoring does not have to be expensive, but it does have to be scheduled and owned. An unowned monitoring obligation is the same as no monitoring at all.
Hurdle 5: Staff Capability and Governance
CPS 234 explicitly requires that roles and responsibilities for information security are clearly defined, and that the board has ultimate responsibility. In practice, third-party audits fail when the people running vendor assessments do not understand what "good" looks like, or when there is no clear escalation path from a procurement officer who spots a red flag to the person who can accept or reject the risk.
Close this gap by defining who owns vendor risk, training procurement and security staff to read assurance reports critically rather than filing them, and giving the board or a risk committee genuine visibility of the material third-party risks the organisation is carrying. If you do not have a senior security leader to own this end to end, a virtual CISO or fintech virtual CISO can provide that accountable function without the cost of a full-time executive hire.
How Atlant Security Helps With CPS 234 Third-Party Assurance
My team runs CPS 234 readiness work as a structured, evidence-first engagement. We map your third parties to their information asset scope, build a single control baseline aligned to CPS 234, assess your material vendors against it, and hand you an audit-ready vendor register with the gaps, owners, and remediation plans already documented. Where you need ongoing coverage, we act as your outsourced security leadership. If you are preparing for an APRA review or an internal audit and your vendor assurance is thin, start with an IT security audit and talk to us through the contact page.
Frequently Asked Questions
Does CPS 234 make me responsible for my vendors' security failures?
You remain accountable for the information security of assets managed by third parties. You cannot transfer that accountability through outsourcing. You must be able to demonstrate that you assessed the vendor's controls and that they are appropriate for the sensitivity of the data involved.
What evidence does APRA expect for third-party controls?
APRA expects a systematic, documented assessment rather than blind reliance on a supplier's assurances. Independent reports such as SOC 2 Type II or ISO 27001 certification, mapped to your own control requirements and refreshed on a defined cadence, are the practical backbone of that evidence.
How fast must I notify APRA of a third-party incident?
Material information security incidents must be notified to APRA within 72 hours, and material information security control weaknesses within 10 business days. This applies to incidents that originate at a third party, which is why your vendor contracts must require notification quickly enough for you to meet that clock.
How often should I reassess a critical vendor?
At least annually for critical suppliers, and immediately when a material change occurs, such as a new sub-processor, an acquisition, an architecture change, or a public breach. The standard ties frequency to the criticality and rate of change of the asset, so tier your cadence accordingly.
We are a smaller entity with limited resources. Where do we start?
Start by identifying which third parties actually hold or process your most sensitive regulated data, and focus your assurance effort there first. A short, prioritised program on your top handful of critical vendors will move your audit position further than a shallow review of everyone. Outsourced security leadership can run this without a permanent hire.
Turn CPS 234 Assurance Into a Repeatable Process
Third-party audits under CPS 234 are difficult because your accountability extends past your own systems while your visibility does not. The organisations that pass cleanly are not the ones with the biggest tooling budgets. They are the ones that identify their in-scope vendors, assess them against a single consistent baseline, document the evidence, and monitor on a schedule that someone actually owns. Build that discipline once and every future audit becomes a review of an existing process rather than a scramble. If you want an experienced pair of hands to build it with you, get in touch.

Alexander Sverdlov
Founder of Atlant Security. Author of 2 information security books, cybersecurity speaker at the largest cybersecurity conferences in Asia and a United Nations conference panelist. Former Microsoft security consulting team member, external cybersecurity consultant at the Emirates Nuclear Energy Corporation.