Look at the cause-of-incident analysis from any major data breach over the past 18 months and you’ll see a familiar pattern. Initial access through a third-party. Movement through trust relationships that were too generous and too persistent. Detection delayed because the compromise didn’t look like a normal threat from the inside. Recovery delayed because the contractual and operational relationship with the third party hadn’t been designed for incident response.

This pattern is not new. Third-party risk management (TPRM) programmes have existed at most organisations for over a decade. They’ve grown more elaborate, more documented, more compliance-driven. The incidents have not slowed in proportion to the investment in the programmes. Something is structurally not working, and it’s worth describing what.

What TPRM programmes actually look like in practice

A typical TPRM programme at a medium-to-large Australian organisation will include the following components.

A vendor inventory — who you do business with, what services they provide, what data they touch. The inventory is usually less complete than the people running it believe, and the gap is in the long tail of small vendors with niche access.

A risk classification — vendors get scored or banded based on the sensitivity of their access and the size of the engagement. This drives the depth of due diligence and the frequency of review.

A questionnaire process — vendors fill in security questionnaires before engagement and on an annual or periodic basis. These are usually variants of the SIG, CAIQ, or industry-specific frameworks like APRA CPS 234 expectations.

Contractual provisions — security obligations, breach notification timelines, audit rights, data handling requirements. The contract is the formal allocation of obligations.

Ongoing monitoring — for some vendors, an attempt at external risk monitoring through services that score the vendor’s external attack surface, dark web exposure, and similar signals.

This framework, executed well, sounds reasonable. So why is it failing?

The structural problems

A few patterns explain a lot of the failure mode.

The questionnaire is a self-attestation problem. Vendors fill in questionnaires that ask whether they have controls in place. The questionnaire process has no useful mechanism to verify the answers. A vendor that has answered “yes” to “do you have logging of administrative actions on systems holding customer data” is making an assertion. Whether the logging is comprehensive, whether anyone reviews it, whether the retention is long enough to support incident investigation — none of this is captured in the questionnaire and most acquirer programmes don’t follow up on it.

The annual review cadence doesn’t match the threat dynamics. A vendor that’s secure in March can be compromised in August. The TPRM programme that re-reviews them next March is unlikely to detect the issue. Continuous monitoring exists but is uneven in quality and often surfaces signals that the acquirer’s team isn’t resourced to action.

The contract isn’t a control. Contractual obligations are reactive. They define what happens after a breach. They don’t prevent the breach. The legal teams that wrote the original contracts often haven’t been on top of the operational maturity of the cybersecurity provisions, and the vendors signing them often haven’t either. When something happens, the contract becomes the framework for argument, not a useful operational guide for incident response.

The “trusted third party” problem. Once a vendor has been onboarded, the access they have to your systems and data tends to be more permissive than security best practice would suggest. VPN connections that persist, service accounts with broad privileges, integration credentials that haven’t been rotated since the original deployment. The vendor is “trusted” in a way that exceeds the actual security posture and the actual risk profile.

Vendor concentration. A surprising number of Australian organisations are exposed to the same handful of critical vendors. A compromise of any of these has systemic effects that the individual TPRM programmes don’t see because each one looks at the vendor in isolation. This is the kind of concentration risk that the APRA CPS 230 framework was partly designed to surface, and it’s only just starting to be operationalised seriously.

Where the recent incidents have actually originated

Looking at the high-profile Australian incidents over the past two years, the most common third-party initial access vectors have been:

IT services and managed service providers. When the MSP is compromised, every customer’s environment is exposed. The MSP’s privileged access into customer environments is often more extensive than the customer realises.

Software supply chain. Compromised updates, malicious dependencies, or weaknesses in widely-deployed business applications. Defending against this is fundamentally a posture and detection problem, not a TPRM problem.

Specialist data processors. Companies that handle customer data for specific functions (marketing analytics, payment processing, identity verification) and have less mature security than their customers.

Help desk and front-of-house outsource. Where social engineering of help desks has been used to subvert authentication and credential reset processes. This has been a particularly damaging vector and one that traditional TPRM programmes don’t really look at.

The Office of the Australian Information Commissioner publishes notifiable data breach reports that show the pattern over time. Worth reading.

What programmes that work actually do differently

The smaller number of organisations whose TPRM programmes have actually reduced incident frequency share some characteristics.

Verification rather than attestation for material vendors. For vendors in the higher-risk tiers, the programme demands evidence rather than answers. SOC 2 reports with the management response read carefully, penetration test summaries, incident response runbooks, observed access reviews. Effort goes into verifying that the controls described actually exist.

Right-sizing access. Vendor access is scoped tightly to the minimum required, time-bounded where possible, and reviewed actively. Privileged access management for third parties is at least as important as for internal staff and usually more so.

Tabletop exercises that include third-party scenarios. Working through what happens when a key vendor is compromised, including the communications, the legal interactions, the technical containment, and the customer-facing communications. Most programmes don’t do this.

Practical preparation for the breach you can’t prevent. Detection engineering tuned for the kinds of activity that follow third-party compromise. Logging and visibility into how third-party accounts and integrations are actually being used. Identity hygiene that limits the blast radius when a compromise occurs.

The ACSC’s guidance on third-party risk management is a useful baseline and several APRA-regulated entities have publicly shared their CPS 230 implementations.

The honest position

Third-party risk management as practiced in most Australian organisations is closer to a documentation exercise than a meaningful risk-reduction programme. The investment is real and the people working in the function are mostly competent, but the structural design of the programmes — questionnaire-driven, annual-cycle, contract-anchored — doesn’t fit the threat dynamics.

The organisations that have shifted toward verification, monitoring, tight access scoping, and realistic incident preparation are getting better outcomes. They’re also doing measurably more work for measurably the same headcount, which is a hard sell internally when nothing visible has happened. The argument has to be made on what would have happened, which is always the argument security teams have the hardest time winning.

The third-party problem is not going to be solved by another framework. It’s going to be solved by more organisations choosing to do the unglamorous, expensive, ongoing work of verifying what their vendors actually do, scoping access tightly, monitoring continuously, and preparing for the failures that will happen anyway. None of that is a product purchase. All of it is a programme commitment. The ones that make it will be measurably safer than the ones that don’t.