Skip to main content
Security Risk · Third-Party & Vendor Guide

Vendor
attack
surface —
the honest
guide.

Third-party breaches now account for 30% of all confirmed data breaches globally — a figure that doubled in a single year. The average Australian organisation manages 286 vendor relationships. For each direct vendor, there are nearly 14 times more fourth and fifth parties beyond them that most organisations cannot see.

Medibank. Latitude Financial. HWL Ebsworth. Every major Australian breach in recent years has a third-party thread. APRA's own tripartite findings show 60% of regulated entities are not meeting the standard they think they are. The vendor attack surface is not a theoretical concept — it is Australia's most active breach vector right now.

This guide covers how vendor attack surfaces work, the attack techniques in use today, what Australian regulations actually require, where TPRM programmes most commonly fail, and what good looks like. Written by practitioners who conduct these assessments.

01 — The scale of the problem

Third parties are now the primary attack vector.

The Verizon 2025 Data Breach Investigations Report — the most comprehensive breach dataset available, covering 22,052 incidents and 12,195 confirmed breaches across 139 countries — found that third parties were involved in 30% of all confirmed data breaches. That figure doubled in a single year, up from 15% in the 2024 report.

IBM's 2025 Cost of a Data Breach Report, published in July 2025, found supply chain compromise was the second most common attack vector and the second costliest at USD $4.91 million per breach. More importantly: supply chain breaches took an average of 267 days to detect and contain — 26 days longer than the overall average. Attackers are inside for nearly nine months before discovery.

SecurityScorecard reported that 35.5% of all data breaches in 2024 originated from third-party compromises, and that 98% of organisations have a relationship with a third party that has been breached. For practical purposes, every organisation has a third-party exposure problem. The question is whether they know where it sits and how material it is.

30%
Of all confirmed breaches involved a third party
Verizon DBIR 2025 — doubled year-over-year from 15%
$4.91M
Average cost of a supply chain breach
IBM Cost of a Data Breach 2025 — second costliest attack vector
267
Days to detect and contain a supply chain breach
IBM Cost of a Data Breach 2025 — 26 days longer than average
60%
APRA-regulated entities that had not assessed all IT service providers' security control testing
APRA tripartite assessment findings, July 2023

The vendor ecosystem problem compounds at scale. The average organisation now manages 286 third-party vendors, up from 237 in 2024. For each direct vendor, there are nearly 14 times more fourth and fifth parties operating further down the chain (Cyentia Institute). A tier-1 bank assessed by Risk Ledger identified, within 48 hours, 36 fourth-parties, 175 fifth-parties, 15 sixth-parties, and 27 seventh-parties connected to just 14 direct suppliers.

The compounding problem: Sonatype's 2024 State of the Software Supply Chain logged 512,847 malicious packages in open-source registries in a single year — a 156% year-over-year increase. Gartner predicts 45% of organisations worldwide will experience a software supply chain attack by 2026, a 3x increase from 2021.

02 — The vendor attack surface

What the vendor attack surface actually is.

The vendor attack surface is not a single risk — it is every pathway through which a third-party relationship can introduce security exposure. It expands every time you add an integration, grant access, or acquire a new vendor. Most organisations don't have a current and accurate map of it.

API
APIs & integration layers
Every API integration between your systems and a vendor's is a potential attack pathway. Shadow APIs — integrations that exist but aren't in any inventory — expand the surface without visibility. SaaS-to-SaaS OAuth token connections are increasingly targeted; Salesforce experienced two third-party breaches in a single year (2025) through integration layer exploitation.
CRED
Shared credentials & privileged access
Vendor technicians, MSPs, and contractors routinely hold privileged access — VPN, remote desktop, admin accounts, API keys. Compromised credentials bypass network defences entirely, making MFA enforcement on all vendor access a non-negotiable baseline. Valid credentials remain the most common initial access technique in the DBIR.
Australian example
Medibank (2022): A third-party IT contractor saved Medibank administrator-level credentials on a personal device. The device was infected with malware. Credentials were sold on the dark web. No MFA was required on Medibank's VPN. 9.7 million customers affected.
SW
Software & update supply chain
Attackers compromise software build systems, code repositories, or update mechanisms to distribute malicious code through legitimate, trusted channels — often with valid digital signatures. The attack is invisible to end organisations because it comes through vendor software they trust.
Canonical examples
SolarWinds (2020): SUNBURST backdoor inserted into legitimate, signed Orion updates — ~18,000 customers received compromised updates including US government agencies. XZ Utils (2024): 2.5-year social engineering campaign to insert backdoor into a foundational Linux library. Polyfill.io (2024): Domain acquired by malicious actor, altered script affected 385,000 websites.
MSP
Managed service providers
MSPs are a concentrated target because compromising one gives access to all their clients simultaneously. 73% of MSPs reported at least one security incident in the past year (ESET/WeLiveSecurity). APT10's Operation Cloud Hopper conducted a multi-year campaign specifically targeting MSPs to reach downstream enterprise clients.
Example
Kaseya VSA (2021): REvil exploited a zero-day in a platform used by MSPs — 60 MSPs compromised, propagating to 800–1,500 downstream businesses. Coop Sweden closed 800 stores. $70M universal decryptor demanded.
DATA
Data processing & storage arrangements
Data entrusted to vendors — for processing, storage, analytics, or archiving — creates exposure at every handoff. Under Privacy Act APP 11, the originating entity retains accountability regardless of where data sits. Under APP 8, acts of an overseas recipient are taken to have been done by the Australian entity.
Australian example
Latitude Financial (2023): Attacker stole employee credentials and used them to breach two of Latitude's third-party service providers holding customer data. Initially reported as 328,000 records — ultimately revealed as 14 million records including 7.9 million driver's licences.
CONC
Concentration & cascade risk
When multiple critical systems depend on the same vendor or cloud provider, a single compromise produces outsized impact. A single compromised host can reach a median of 85% of internal systems in the first hop and 100% in the second hop (Zero Networks). CDK Global's ransomware incident (2024) took down 15,000 automotive dealerships from a single vendor compromise.
03 — How attackers target the supply chain

The techniques in active use.

Island hopping

Island hopping is the most common supply chain attack pattern: compromise a smaller, less-defended organisation to reach a larger target. The smaller organisation provides a trusted bridge — network connectivity, a shared credential, a software component — that the attacker exploits to pivot. Carbon Black's 2019 Global Incident Response Threat Report found island hopping accounted for 41% of all cyberattacks studied.

The Target breach (2013) remains the canonical example: attackers phished Fazio Mechanical Services, an HVAC contractor, obtained credentials for Target's billing portal, pivoted to the point-of-sale network, and stole 40 million credit card numbers. Target's security team received alerts they did not act on. The contractor was the entry point; Target bore the consequences.

Credential harvesting through vendor portals

Vendors access client systems through portals, VPNs, remote desktop, and admin consoles. Attackers target the vendor — often less defended than the ultimate target — to obtain credentials that provide legitimate, trusted access. The Change Healthcare breach (2024) exposed data on approximately 190 million Americans because there was no MFA on a remote access portal used by a vendor. No exploited vulnerability. No malware at the entry point. Just valid stolen credentials and an absent second factor.

Trusted relationship exploitation

Reverse business email compromise (reverse BEC) involves attackers compromising a vendor's mail server and launching attacks from a trusted, authenticated domain. Because the email genuinely originates from the vendor's infrastructure, it passes SPF, DKIM, and DMARC checks — and clears email security tools that flag unknown senders. The recipient has no technical signal that anything is wrong.

The compounding effect of trust: Every vendor you grant access to implicitly inherits the trust level of your own internal systems — without necessarily meeting the same security standards. Your perimeter is only as strong as the weakest trusted third party with access to it.

04 — Australian breach case studies

What the third-party thread looks like in Australian breaches.

Three of Australia's most significant recent cyber incidents share a common factor: the initial compromise came through, or was significantly enabled by, a third-party relationship. The pattern is consistent — and consistently underexamined.

October 2022
Medibank Private — 9.7 million customers
A third-party IT contractor saved Medibank administrator credentials on a personal device. The device was infected with malware and the credentials were stolen and sold on dark web forums. No MFA was required on Medibank's VPN, giving attackers direct access. 9.7 million current and former customers were affected; 520 GB of data exfiltrated including sensitive medical claims data. APRA imposed an AUD $250 million additional capital requirement — the first time APRA applied capital charges specifically for a cyber incident. OAIC commenced civil penalty proceedings. At least three class actions filed. The initial access point was a third party. The accountability sits entirely with Medibank.
March 2023
Latitude Financial — 14 million records
The attacker stole employee credentials and used them to breach two of Latitude's third-party service providers holding customer data. Initially reported as approximately 328,000 records; ultimately revealed as 14 million — including 7.9 million driver's licences and 53,000 passport numbers. Cash profit was slashed by at least $128 million; pre-tax incident costs reached $76 million. OAIC and the New Zealand Privacy Commissioner launched a joint investigation. The third-party data processors held more data than Latitude's own systems disclosed — a common pattern where data minimisation and third-party data handling have not been reviewed.
April 2023
HWL Ebsworth — 65 government agencies affected
ALPHV/BlackCat ransomware exfiltrated approximately 3.5 terabytes (~2.5 million documents) from HWL Ebsworth, one of Australia's largest commercial law firms. Described as the "largest supply chain attack seen in Australia" — 65 government agencies had sensitive data exposed through their legal services provider, including Home Affairs, Defence, Foreign Affairs, the AFP, and the OAIC itself. All four major banks were also affected. The incident directly prompted the appointment of Australia's first National Cyber Security Coordinator. The law firm was the third party. Every client became a victim.

The OAIC's conclusion: The H1 2024 Notifiable Data Breaches Report stated directly: "The risk of outsourcing personal information handling to third parties continues to be a prevalent issue." In 2024, Australia recorded 1,113 data breaches — the highest annual total since the NDB scheme began in 2018, a 25% year-over-year increase.

05 — The Australian regulatory landscape

What the law actually requires.

Australian organisations face overlapping third-party security obligations across five regulatory instruments. Many organisations treat these as separate compliance programmes — but they share a common underlying requirement: you are accountable for what happens to your data and systems regardless of which vendor is holding or touching them.

APRA CPS 234
In force Jul 2019
Para 16 requires assessment of third-party information security capability commensurate with consequences. Para 20 requires classification of assets managed by third parties. Para 28 requires entities to assess whether third-party control testing is adequate — self-assessments alone don't satisfy this. Paras 32–34 require internal audit to cover third-party controls. 72-hour APRA notification for material incidents regardless of whether the incident originated at a third party. APRA's 2023 tripartite findings: 60% of entities had not assessed all IT service providers' control testing in the past 12 months.
APRA CPS 230
In force Jul 2025
Replaces CPS 231 (Outsourcing). Material service provider management policy required, covering fourth-party risks. Due diligence before entering arrangements. Formal agreements must include: audit access rights, data ownership, sub-contractor notification, liability for sub-contractor failures, termination provisions. Annual register of material service providers submitted to APRA. APRA on-site access rights to service providers. Transition for pre-existing contracts: earlier of next renewal or 1 July 2026. APRA consulting on targeted amendments for major cloud providers with non-negotiable terms.
SOCI Act
Critical Infrastructure
Covers 11 sectors and 22 asset classes. The Critical Infrastructure Risk Management Program (CIRMP) takes an all-hazards approach across four domains, one of which is explicitly supply chain hazards. Entities must identify major suppliers, identify supply chain hazards, and implement controls. Board-approved annual CIRMP report required. Penalties: 1,000 penalty units per day (~$275,000) for non-compliance. November 2024 amendments extend obligations to business-critical data held by third-party data service providers.
Privacy Act
APP 11 + APP 8
APP 11 requires "reasonable steps" to protect personal information from unauthorised access — including from third parties you share it with. APP 8 (cross-border disclosure): acts of an overseas recipient are taken to have been done by the Australian APP entity. Enforceable contractual arrangements with overseas recipients are mandatory. Under the NDB scheme, the entity that "holds" the data bears the notification obligation — not the third party that was breached. Privacy and Other Legislation Amendment Act 2024 (Royal Assent 29 Nov 2024) introduced statutory tort for serious privacy invasions and expanded enforcement powers.
Cyber Security Act 2024
Royal Assent Nov 2024
Australia's first standalone Cyber Security Act. Mandatory cyber security standards for smart devices affect supply chain (manufacturers responsible before supply into Australian market). Mandatory ransomware payment reporting to ASD — applies even if the incident originated at a third party and cascaded to you. Limited use obligation encourages information sharing during incidents. The Act represents a shift from voluntary to mandatory baseline expectations for the supply chain.

The common thread across all five instruments: accountability does not transfer when you outsource. The regulatory obligation, the notification duty, and the penalty exposure remain with the Australian organisation regardless of where in the supply chain the incident originated.

06 — Eight common TPRM failures

Where third-party risk programmes break down.

APRA's tripartite assessment findings, combined with Gartner, Ponemon/RiskRecon, and IBM research, consistently surface the same failure patterns. Most are not complex to fix — they require process discipline, not technology investment.

  • 1
    Over-reliance on questionnaires and self-assessments
    Only 4% of organisations have high confidence that their third-party questionnaires match reality (RiskRecon/Ponemon 2024). APRA found entities "relied heavily on control self-assessments... and had not taken any steps to independently verify that information security controls were effective." 26% of respondents still use spreadsheets to manage third-party risks. A questionnaire tells you what a vendor believes about their own security — or wants you to believe. It tells you almost nothing about actual control effectiveness.
  • 2
    Annual point-in-time assessment for dynamic risk
    With supply chain breaches taking 267 days to detect, annual assessments leave organisations blind for most of the year. Gartner reported third-party interruptions surged 45% year-over-year in 2024. Nearly 50% of companies do not even rank vendors by risk level. A vendor that was compliant in January can be compromised in February. Annual reviews create a false confidence interval between assessments.
  • 3
    No fourth-party (Nth-party) visibility
    For each direct vendor, there are nearly 14 times more fourth and fifth parties beyond them (Cyentia Institute). CPS 230 explicitly requires service provider management policies covering fourth-party risks. ISO 27001 A.5.21 requires agreements to mandate suppliers propagate security requirements to their sub-contractors. Most organisations have accurate maps of their Tier 1 vendors and no visibility at all beyond them — which is exactly where MOVEit, SolarWinds, and Kaseya entered.
  • 4
    Inadequate or generic contractual provisions
    Gartner 2024 identified "generic contracts with broad language that lacked specificity" as a primary failure mode. Commonly absent clauses: right-to-audit, specific incident response timeframes, data return or destruction at termination, encryption requirements, sub-processor notification, and patch management obligations. Without breach notification timelines contractually specified, the vendor controls timing while your regulatory clock runs. An NDA alone does not satisfy ISO 27001 A.5.20 — it addresses only confidentiality, not integrity or availability.
  • 5
    Poor offboarding and access revocation
    Over 30% of organisations take more than three days to revoke all system access after a contractor engagement ends — some never fully complete the process (SecurEnds). Enterprises average 275 SaaS applications, making comprehensive account management extremely difficult. Orphaned contractor accounts are a primary attacker target precisely because they are active, legitimate, and unwatched.
  • 6
    Shadow IT and unsanctioned vendor relationships
    65% of all SaaS applications are unsanctioned and in use without IT approval. Gartner projects this will reach 75% by 2027. Shadow vendors bypass the TPRM process entirely — they never receive a questionnaire, never sign a security addendum, and never enter the vendor register. Shadow AI is an emerging frontier: 55% of knowledge workers tried generative AI tools without approval in Q3 2023 (Gartner), creating new data exposure risks at scale with no controls in place.
  • 7
    Treating certifications as sufficient without scoping review
    SOC 2 and ISO 27001 certifications have specific, often limited scopes. A certificate confirms the audited scope was assessed at a point in time — it does not confirm all relevant controls were in scope, are currently effective, or cover the specific service you are using. 40% of the time, business sponsors move forward with vendors despite known cyber risks because of ineffective TPRM programmes (Gartner 2024). Certificate review without scope analysis is false assurance.
  • 8
    No coordinated incident response with vendors
    Only 34% of organisations have confidence a third party would notify them of a breach (Ponemon/RiskRecon). IBM 2025 found supply chain breaches cost ~40% more to remediate than internal breaches. Without contractual notification timelines, tabletop exercises that include vendor scenarios, and tested escalation paths, organisations discover third-party incidents through media reporting — after APRA's 72-hour clock has already started running without their knowledge.
07 — What good looks like

A working TPRM programme.

Vendor tiering by criticality and data sensitivity

The foundation of an effective programme is tiering — classifying vendors by the actual risk they represent, not treating all 286 of them the same. APRA CPS 234 Para 16 effectively mandates this by requiring assessment "commensurate with potential consequences." NIST CSF 2.0 GV.SC-04 explicitly requires knowing and prioritising suppliers by criticality.

Tier Profile Assessment frequency Monitoring Examples
Tier 1 — Critical Direct access to highly sensitive data or critical infrastructure Quarterly reassessment Continuous + real-time alerts Core IT infrastructure, cloud providers, identity management
Tier 2 — High Moderate data access or operational impact Semi-annual Continuous monitoring HR systems, ERP, key SaaS platforms
Tier 3 — Medium Limited data access, moderate business impact Annual Periodic monitoring Marketing tools, collaboration software
Tier 4 — Low No material access to sensitive data Annual or biennial Event-triggered only Office supplies, low-integration SaaS

Unknown access defaults to Tier 1. If you cannot accurately determine what access or data a vendor has, treat them as critical until you can. This conservative default prevents the common failure mode where an apparently low-risk vendor turns out to have access that was never formally scoped.

Contractual security requirements that actually protect you

The contract is your primary enforcement mechanism. Once an incident occurs, the contract determines whether you have notification rights, audit access, liability, and termination options — or nothing. Key clauses that must be present for Tier 1 and Tier 2 vendors:

  • Breach notification within 24–48 hours of discovery — with scope, affected data, affected count, and remediation steps. This is your only defence against APRA's 72-hour clock running without your knowledge.
  • Right-to-audit provisions — without this, you cannot independently verify any claim a vendor makes about their controls. Required under ISO 27001 A.5.20.
  • Sub-processor notification and approval — any change to the vendor's own supply chain that could affect your data requires your prior approval.
  • Data return and secure destruction at termination — specific timelines, specific standards, written confirmation required.
  • MFA and access control requirements — particularly for any access to your systems, networks, or data.
  • Cyber insurance minimum requirements — commensurate with the data or systems they can access.
  • Termination for material security failures — without this clause, you may be contractually bound to a vendor you can no longer trust.

Moving beyond questionnaires to continuous monitoring

Security rating services, threat intelligence feeds, and external attack surface management tools provide dynamic, evidence-based views of vendor posture that questionnaires cannot. 88% of organisations now leverage security ratings as part of assessments (Whistic 2025). Trigger-based reviews — activated by vendor breaches, M&A activity, certification lapses, or financial deterioration — ensure assessment frequency matches actual risk change, not a calendar.

Board reporting on third-party risk

ASD's Cyber Security Priorities for Boards 2025–26 includes specific supply chain questions boards should be asking. 77% of boards now discuss material and financial implications of cyber incidents, up 25 points since 2022 (NACD 2025). Key metrics boards should receive: percentage of Tier 1/Tier 2 vendors with completed current assessments; open remediation items and aging by vendor; third-party incident count and trend; and concentration risk — how many critical operations rely on the same vendor or cloud provider.

08 — ISO 27001:2022 supplier controls

What A.5.19 through A.5.23 require.

ISO 27001:2022 dedicates five controls specifically to supplier security — A.5.19 through A.5.23 — with A.5.21 and A.5.23 being new in the 2022 revision. These controls are the most detailed framework treatment of third-party risk in any mainstream security standard, and they directly overlap with what APRA, the Privacy Act, and SOCI require.

A.5.19
Information security in supplier relationships
Requires defined processes to manage information security risks across all supplier relationships — covering the full lifecycle from vetting and onboarding through active management to decommissioning. Recommends four-tier risk-based segmentation. The key insight in A.5.19 is "all supplier relationships" — not just major outsourcing arrangements, not just regulated providers. Every supplier with access to your information assets.
A.5.20
Addressing information security within supplier agreements
25 guidance points for contractual provisions. The standard is explicit: an NDA alone does not satisfy A.5.20 because it addresses only confidentiality, not integrity or availability. Required elements include right-to-audit, incident reporting timeframes, encryption standards, data return/destruction, backup and DR obligations, change management notification, personnel screening, and sub-contractor requirements.
CPS 234 alignment
A.5.20 contractual requirements directly support CPS 234 Para 21–22 (controls protecting third-party-managed assets) and Para 28 (assessing adequacy of third-party control testing). Organisations with ISO 27001 certification have a documented obligation to meet these contract requirements — which simultaneously satisfies significant CPS 234 third-party provisions.
A.5.21
Managing information security in ICT supply chain
New in ISO 27001:2022. Requires mapping Tier 1 and critical Tier 2 suppliers. Agreements must mandate suppliers propagate security requirements to their own sub-contractors. Requires software component transparency (SBOM alignment) and hardware authenticity validation. This control was added specifically in response to SolarWinds and similar software supply chain attacks — recognising that the risk does not stop at your direct supplier.
A.5.22
Monitoring, review and change management of supplier services
Requires regular monitoring, auditing, and KPI tracking of supplier service delivery — not just initial assessment and then silence. Manage changes to supplier services including policy changes and control changes. This is the control that annual-questionnaire-only programmes fail. Point-in-time assessment followed by 12 months of inattention does not satisfy A.5.22's monitoring and change management requirements.
A.5.23
Information security for use of cloud services
New in ISO 27001:2022. Cloud-specific policy, shared responsibility documentation, SOC 2 Type II or ISO 27001 certificate review with scoping analysis, exit strategy, and continuous monitoring of sub-processor and jurisdictional changes. The shared responsibility model must be documented — what the cloud provider covers versus what remains the customer's obligation. Many organisations assume cloud providers cover more than they do.
APRA context
APRA is currently consulting on targeted CPS 230 amendments for "non-traditional service providers" (NTSPs) — major cloud providers with standardised, non-negotiable contracts. Where negotiation of terms is not possible, organisations must document the risk, assess compensating controls, and obtain senior management or board approval. Consultation closed 30 January 2026; APRA expects to finalise before 1 July 2026.
09 — How we help

What a Lighthouse Assessment delivers for third-party risk.

Third-party security risk sits across multiple assessment domains — APRA CPS 234 Para 16/20/21/22/28/32–34, CPS 230 material service provider requirements, ISO 27001 A.5.19–23, Privacy Act APP 8 and 11, and SOCI CIRMP supply chain obligations. Most organisations discover gaps in these areas only when an APRA reviewer or auditor finds them.

The Cliffside Lighthouse Assessment maps your current vendor security programme against each of these requirements, gives you a calibrated view of where you stand relative to the standard you will be measured against, and tells you — honestly — what is material and what can wait.

  • Third-party asset inventory and tiering — APRA Para 16 and 20 alignment
  • Contractual gap analysis against ISO 27001 A.5.20 requirements — right-to-audit, notification timelines, sub-processor provisions
  • Assessment methodology review — are you relying on questionnaires alone, and is that consistent with Para 28 and APRA's current expectations?
  • CPS 230 readiness — material service provider register, due diligence processes, APRA access provisions
  • Incident notification protocol review — does your vendor breach notification process let APRA's 72-hour clock run without your knowledge?
  • Shadow IT and unsanctioned vendor identification — what's in use that isn't in your register?
  • Board reporting framework for third-party risk — does your board receive what APRA expects them to receive?
  • Transferable report — yours to present to internal audit, your board, or APRA

APRA's tripartite findings are unambiguous: entities consistently underestimate their third-party exposure and overestimate their programme's effectiveness. If your third-party risk programme was designed before CPS 230 came into force in July 2025, it was built against a framework that no longer exists.

Third-party security risk

Know what's
in your
vendor
blind spot.

The Cliffside Lighthouse Assessment gives you an independent, evidence-based view of your third-party security programme — calibrated against CPS 234, CPS 230, ISO 27001 A.5.19–23, and APRA's published tripartite findings. We map your actual vendor exposure, review your contractual provisions, assess your assessment methodology, and tell you honestly what the standard requires versus what you currently have.

What you get from the Lighthouse Assessment
  • Vendor inventory and tiering review — are your Tier 1 vendors identified and treated as such?
  • Contractual gap analysis against ISO 27001 A.5.20 — right-to-audit, notification timelines, sub-processor provisions
  • CPS 230 readiness assessment — material service provider register, due diligence, APRA access provisions
  • Assessment methodology review — are you satisfying Para 28 or relying on questionnaires?
  • 72-hour notification readiness — does your vendor protocol protect your APRA clock?
  • Transferable report — yours to share with internal audit, your board, or APRA