Third-party cyber risk: governing the suppliers you cannot control

The risk you accepted without assessing it

Every organisation we assess has a supplier list far longer than its risk register. Payroll, CRM, managed IT, a marketing platform with a copy of the customer database, a niche analytics tool a business unit bought on a card, and now a dozen AI services processing whatever staff paste into them.

Each of those relationships transferred data, access or dependency outside the boundary you control, and in most cases the security assessment happened once, at procurement, if it happened at all. The uncomfortable framing for a board is simple: your risk appetite has been set by other companies' security teams.

Tier by consequence, not by spend

The most common failure in vendor risk management is treating the process as uniform. Two hundred suppliers each receive the same 180-question spreadsheet, nobody has time to read the answers, and the one supplier that actually matters gets the same attention as the office coffee subscription.

Tier instead on consequence. Tier one: suppliers who hold or process personal, health, payment or client-confidential data, or who have privileged access to your environment, or whose outage stops revenue within 24 hours. Tier two: material but recoverable — data is limited, access is scoped, an outage is survivable for a week. Tier three: everything else.

In a typical mid-sized Australian organisation tier one is between five and fifteen suppliers. That is a list a leadership team can actually govern, and it is the list that belongs in front of the board.

Ask questions that produce evidence

A self-attested questionnaire tells you what a supplier believes about itself. For tier one that is not enough. Ask for artefacts: a current ISO/IEC 27001 certificate with the scope statement (the scope is where the surprises live), a SOC 2 Type II report, recent penetration test summaries, and the sub-processor list.

Then ask the questions that actually predict incidents. Who at your organisation can access our data, and how is that access approved and reviewed? Is our data encrypted at rest with keys you control? Where is it hosted, and does it leave Australia? What is your notification commitment to us after you detect an incident, in hours? When did you last restore this service from backup as a test, not a plan?

For AI suppliers, add three more: is our data used to train or improve your models, is it retained beyond the session, and can you tell us which sub-models and hosting regions are involved? Answers that arrive as marketing language rather than a straight yes or no are themselves a finding.

Clauses that hold when it goes wrong

Assurance work is wasted if the contract does not carry it. For tier one suppliers the clauses worth fighting for are a defined incident notification window — 24 or 48 hours from detection, not from confirmation — a right to audit or to receive the audit reports of others, sub-processor change notification with a right to object, data location and return-or-destruction obligations on exit, and security requirements referenced as a schedule rather than a vague "industry standard" phrase.

Two clauses are consistently missing and consistently painful. The first is an exit and transition clause with a defined data export format and a support period — without it, your ability to leave a failing supplier is theoretical. The second is a cooperation clause requiring the supplier to support your regulatory notification obligations, which under the Notifiable Data Breaches scheme remain yours regardless of whose systems failed.

Concentration and fourth parties

Boards are usually briefed on individual suppliers and almost never on concentration. If your CRM, your finance platform, your identity provider and your managed service partner all sit in one cloud region, that is a single correlated failure dressed up as four separate relationships.

Fourth-party exposure follows the same pattern. Your supplier's critical dependency is your dependency, and it is invisible unless you ask for the sub-processor list and read it. The 2023–2025 pattern of Australian incidents is instructive: the initial compromise frequently occurred at a downstream provider that the affected organisation could not have named before the event.

The practical control is not to eliminate concentration — that is rarely economic — but to know where it exists, state it explicitly in the risk register, and rehearse the failure. Ask what happens to your operations if this one provider is unavailable for 72 hours, and write down the answer.

Monitoring between reviews

An annual review of a supplier that changed its architecture in March is a document, not a control. Between formal reviews the signals worth watching are cheap: breach disclosures and regulatory findings, changes to the sub-processor list, certificate expiry dates, material changes to terms of service, and — the one most often missed — whether the integration's access scope has quietly expanded.

Access review is the highest-yield of these. Supplier accounts, API keys and service principals accumulate permissions and outlive the projects that created them. A quarterly review of external identities and their entitlements finds more real exposure than another round of questionnaires.

Where the Australian obligations bite

Under the Privacy Act, disclosing personal information to a supplier does not disclose the obligation. If a provider you engaged suffers an eligible data breach involving your customers' information, the OAIC's expectations on reasonable steps and the notification duty land on you.

For critical infrastructure entities the SOCI Act adds explicit supply chain hazard obligations within the risk management programme — supplier dependency is a named hazard vector, not an implied one. APRA-regulated entities carry CPS 234 information security obligations for information assets managed by third parties, and CPS 230 sharpens this further around material service providers and their own dependencies.

The ACSC's cyber supply chain risk management guidance is the most usable free reference for organisations outside those regimes, and it aligns closely with the ISO/IEC 27001 supplier relationship controls most certified organisations already hold.

What to report to the board

Five numbers, reported quarterly, cover it. How many tier one suppliers exist and how many have current assurance evidence. How many hold personal or regulated data offshore. How many contracts carry an incident notification clause under 72 hours. Where the concentration sits, named. And how many supplier-originated incidents or near misses occurred this quarter.

Avoid the vanity metric of questionnaires issued. A board learns nothing from "we sent 140 assessments". It learns a great deal from "three of our eleven tier one suppliers cannot commit to a notification window, and one of them holds our client contract archive".

A 30-day start

Week one — build the real list. Pull it from accounts payable and the identity provider rather than from memory; both will surface suppliers the IT function has never heard of. Tier it by consequence.

Week two — assess tier one only. Request evidence, not attestations, and record the gaps as risks with owners rather than as an unfinished spreadsheet.

Week three — review the contracts behind tier one. Identify which lack notification, audit, sub-processor and exit clauses, and queue those for the next renewal or a variation now if the exposure warrants it.

Week four — close the access gap and report. Review external accounts and API access, revoke what is stale, and put the five board metrics in front of the executive with a named owner for the register.

None of this requires a platform purchase. Vendor risk tooling helps at scale, but the organisations that get burned are rarely the ones without a tool — they are the ones who never decided which suppliers actually mattered.