Third-party risk management sits at an uncomfortable intersection: it's everyone's problem, but rarely anyone's priority. Australian IT teams spend significant energy hardening their own environments while vendors, contractors, and SaaS integrations quietly accumulate access that nobody audits properly. The result is a well-defended perimeter around a network that dozens of external parties can reach anyway.
The supply chain cyber attacks hitting Australian businesses over recent years have made the cost of this blind spot concrete. When a trusted vendor's credentials, update mechanism, or API connection becomes the attack vector, your own patch cadence and firewall rules don't matter much. The breach arrives through the front door.
Why third-party inventories are usually wrong
The first mistake is believing the vendor list is complete. Most organisations maintain a formal register that captures major suppliers. It misses the integrations that developers added via OAuth tokens, the monitoring agents a managed service provider installed eighteen months ago, and the four SaaS tools the marketing team provisioned without raising a ticket. Each of these has some level of access to production systems or sensitive data.
A realistic inventory exercise requires pulling OAuth grants from identity providers, reviewing outbound firewall logs for recurring external destinations, and auditing cloud IAM role assumptions. That's a different exercise from reviewing a spreadsheet of contracts. In most Australian organisations, the gap between the formal register and the real attack surface is wider than the security team expects.
The fix isn't a one-off audit. It's a continuous discovery process tied to identity governance, so that new access grants trigger a review workflow rather than accumulating unnoticed for quarters.
Questionnaire-based assessments and why they fail
Vendor security questionnaires are the dominant third-party risk tool in Australian organisations. They're also, in isolation, close to useless. A vendor that completes a 150-question self-assessment has demonstrated the ability to fill in a form. It hasn't demonstrated that its systems are actually secure.
The problem is structural. Questionnaires are point-in-time, self-reported, and answered by the vendor's sales or legal team rather than the engineers who built the system. A vendor can truthfully answer "yes" to a question about multi-factor authentication while having MFA enforced on only one of its three administrative portals. That's not deception; it's the natural ambiguity of self-assessment at scale.
Better approaches layer evidence on top of the questionnaire. Asking for SOC 2 Type II reports rather than Type I is a start: Type II covers a testing period, not just a design assertion. External attack surface scans, penetration test summaries, and independent security ratings services (companies like SecurityScorecard and BitSight provide these) add signal that the vendor can't manipulate by choosing how to phrase an answer.
For high-criticality vendors with access to regulated data, on-site assessments or technical walkthroughs remain the standard. Most Australian organisations reserve that depth for two or three tier-one suppliers. The rest get tiered based on data access and connectivity, with lighter but still evidence-backed assessments for lower-risk relationships.
Contractual protections that look strong but aren't
Australian IT procurement teams have gotten better at including security clauses in vendor contracts. The clauses often look substantial. They require the vendor to maintain appropriate security controls, notify the customer of breaches within a specified period, and permit audits. In practice, several of these provisions fail quietly.
Breach notification clauses are the clearest example. A contract might require notification within 72 hours of a vendor discovering a breach. That sounds aligned with Australia's Notifiable Data Breaches obligations. But "discovering" is doing a lot of work in that sentence. A vendor that spends three weeks investigating before formally declaring a confirmed breach has technically complied while leaving your organisation exposed throughout.
Audit rights clauses are rarely exercised. The customer has the right to audit but almost never does, partly because of cost, partly because vendors make it procedurally difficult, and partly because the internal team doesn't have a trigger to initiate one. A right that isn't used doesn't reduce risk.
The more meaningful contractual lever is the right to terminate for security-related cause without penalty, combined with data return and deletion obligations that are specific rather than aspirational. "The vendor will return all customer data in a reasonable format within a reasonable timeframe" is not enforceable. "The vendor will provide a complete export in CSV or JSON format within 14 days of termination and certify deletion within 30 days" is.
The offboarding gap
Third-party risk management focuses heavily on onboarding assessment and almost not at all on offboarding. When a vendor relationship ends, the access rarely does. API keys issued to a former integration partner remain valid. Service accounts created for a managed service provider's tooling stay active in Active Directory. S3 bucket policies that granted a contractor read access don't get cleaned up because nobody remembers they exist.
This is partly a tooling problem and partly a process one. On the tooling side, centralising third-party access through a privileged access management platform makes revocation deterministic: ending the relationship revokes the access in one place rather than requiring a manual hunt across systems. On the process side, vendor offboarding needs the same formal checklist as employee offboarding. The case for privileged access management in Australian IT is particularly strong in vendor contexts precisely because external parties often get broader access than individual employees and receive far less scrutiny when they leave.
Dormant third-party credentials are attractive targets. Attackers who gain access to a former vendor's systems can use still-valid API keys to reach your environment directly, with no need to phish your staff or exploit a vulnerability in your own infrastructure.
How to tier your vendor portfolio
Not every vendor warrants the same level of scrutiny, and trying to apply deep assessments uniformly is what causes programmes to collapse under their own weight. A practical tiering model uses two axes: the sensitivity of data the vendor can access, and the connectivity the vendor has to production systems.
Tier one covers vendors with both high-sensitivity data access and production connectivity. Think: your managed detection and response provider, your payroll platform, your cloud infrastructure partner. These receive full assessments, annual reviews, and contractual audit rights that are actually exercised.
Tier two covers vendors with one of those two characteristics but not both. A SaaS HR platform holds sensitive data but has no direct production connectivity. A network monitoring tool has production connectivity but touches only metadata. These receive questionnaire plus evidence-based assessments, with reviews triggered by material changes rather than on a fixed calendar.
Tier three covers low-sensitivity, low-connectivity relationships. These get a lightweight baseline check at onboarding and monitoring via external ratings services. The key discipline is re-tiering vendors when the relationship scope expands. A tier-three vendor that gets granted access to customer PII through a new integration should move to tier two before that access goes live, not after.
Making the programme stick
Third-party risk programmes fail when they're treated as a security team responsibility rather than a shared accountability between security, procurement, legal, and business owners. The vendor relationship owner, not the CISO, is best placed to know when a vendor's scope is expanding, when a key contact has left, or when the vendor is being acquired. Those events should trigger a risk review, and only the relationship owner will notice them in time.
Embedding third-party risk checkpoints into procurement workflows is more effective than running a separate programme in parallel. When the purchase order system prompts for a security tier classification before a contract can be executed, the assessment becomes a natural part of the process rather than a security team audit that happens after the relationship is already in production.
Australian organisations subject to the Notifiable Data Breaches scheme have a regulatory incentive to close these gaps: a vendor breach that exposes personal information triggers your own notification obligations, regardless of where the fault sits. The Privacy Act reform programme moving through Parliament in 2026 is likely to tighten those accountability provisions further, extending to the organisations that hold the customer relationship, not just the party that suffered the breach.
The organisations with the most mature programmes treat third-party risk as an ongoing discipline rather than a project. The inventory is live. Tiers update when relationships change. Offboarding is automated. That's not a long way from where most Australian teams sit today, but the gap only closes if someone owns the programme explicitly rather than distributing the work until it disappears.