The pattern of the past eighteen months in Australian and global cyber has been consistent enough to be uncomfortable. The largest-impact incidents — the ones that interrupted operations, generated regulator interest, and forced extraordinary board meetings — were not, in most cases, breaches of the affected organisation's own perimeter.
They were breaches of a vendor.
A managed file transfer tool used by hundreds of organisations. An identity provider that fronts SaaS for thousands. A SaaS analytics platform with thousands of corporate tenants. A cloud SDK shipped inside other vendors' products. A logistics platform sitting in the middle of supply chains that boards had never thought of as digitally connected. In each case, the affected organisations' own controls were fine. Their suppliers' controls were not. The consequence landed on them anyway.
For Australian boards heading into FY27 budget conversations and CIRMP attestations, this raises a question that vendor questionnaires were not built to answer:
How much of our cyber risk lives outside our perimeter — and what is it worth in dollars?
Cyber risk quantification, as the industry has practiced it for the last decade, runs on telemetry. Vulnerability scanners, attack-surface monitors, EDR agents, network sensors, configuration management databases. The platform reads the inputs, runs the model, produces a number.
That works fine for systems you own and operate. It does not work for the systems that matter most in 2026.
| Asset class | Why your tools can't reach it | Where it shows up |
|---|---|---|
| OT and SCADA | Active scanning causes disruption; safety-critical | Energy, water, ports, manufacturing |
| Air-gapped networks | No path for agents or scanners | Defence, intelligence, critical infrastructure |
| Legacy and end-of-life systems | Cannot run modern agents; unsupported OS | Healthcare, government, utilities |
| Embedded and IoT devices | Resource-constrained; no agent support | Hospitals, smart infrastructure |
| Third-party vendor systems | No administrative access to scan or instrument | Every organisation, in every sector |
Third-party systems sit in the same category as OT and air-gapped networks for one structural reason: you do not have permission to instrument them. You can ask the vendor for a SOC 2 report. You can require ISO 27001. You can run a SIG questionnaire and a CAIQ. None of that produces the kind of telemetry your CRQ tooling expects. It produces attestations.
The paradox repeats itself: the systems that are most likely to cause your next material incident are precisely the systems your existing risk-quantification toolchain cannot see.
The dominant tool in third-party risk management today is still the questionnaire. Increasingly, automated TPRM platforms can send and score questionnaires at scale. These are useful. They are not, however, financial arguments.
Three things questionnaires cannot do:
"47 high-risk, 312 medium-risk vendors" tells the board nothing about the size of the loss those vendors expose the organisation to.
Two vendors might fail the same control question. One stores nothing material. The other holds the credentials for your billing system.
Three vendors on the same cloud, the same IdP, or the same upstream library aren't three risks. They're one risk with three names.
The Australian Signals Directorate's 2024–25 Annual Cyber Threat Report puts average business cybercrime cost up 50% year-on-year and large-enterprise cost up 219%. A non-trivial share of those incidents had a third-party trigger. The CISO who walks into a board meeting with a questionnaire scorecard is being asked a financial question and answering it in compliance language. That gap is the one regulators, insurers, and audit committees are increasingly unwilling to bridge for the organisation.
"How many high-risk vendors do we have?" is a control question. "How much of our annual loss expectancy lives in our supplier base?" is a board question. They have different answers.
The FAIR framework — Factor Analysis of Information Risk — gives a defensible structure for quantifying any cyber risk, third-party included. The shape of a real third-party risk number is not exotic. It is just rarely assembled.
A defensible third-party Annual Loss Expectancy (ALE) needs five ingredients:
Not a list of vendors by spend. A list of vendors by the business processes they enable. Your billing platform vendor is not in the "finance software" category — they are in the "revenue collection" process. If they go down for 72 hours, what is the cost to the organisation? If they breach, what regulated data is exposed? Process mapping is where the dollar figures start.
For each vendor, enumerate the loss-event types that vendor can cause:
A vendor can contribute to several. A SaaS HR platform breach is a confidentiality event and a regulatory event under the Privacy Act. A cloud provider outage is an availability event with downstream revenue and SLA consequences.
How often does a vendor of this type, in this sector, suffer the loss event? Industry breach data, the vendor's own incident history, threat intelligence on their sector, and structured expert estimates from your security team all feed this. The key is that the input is a range, not a single number — and that the range is recorded so the assumption can be challenged later.
The Australian-context costs are now well documented. Notification costs under the Privacy Act. Regulator engagement under SOCI, APRA CPS 234, or sector-specific obligations. Downtime cost per hour for revenue-critical processes. Contract penalties. Recovery and forensics. Independent investigation. These are the inputs that turn an event probability into a dollar figure.
This is the step that most TPRM programmes skip — and it is the one that most distorts the answer.
If you simulate your vendor portfolio assuming each vendor's risk is independent, you will get a loss curve that looks reasonably tidy. A central estimate. A modest tail. A 99th percentile that feels manageable.
That curve is wrong. And it is wrong in the direction that matters: it under-states the worst-case loss.
The implication for the board number is not subtle. When you correctly account for shared exposure across your vendor portfolio, the upper tail of the loss distribution gets fatter — sometimes substantially. The central estimate may move only modestly. The 95th and 99th percentile losses, the ones the board actually needs to budget against, can move by an order of magnitude.
This is what good third-party risk quantification is doing under the hood: not just adding up vendor-by-vendor risks, but modelling the moments when several of them go bad together. The board doesn't need to know the maths. They do need the answer.
| What you ask | Old answer | Quantified answer |
|---|---|---|
| How many high-risk vendors do we have? | "47" | (Still useful as a control metric, not a financial one) |
| What's the worst-case third-party loss? | "Hard to say — depends on the vendor" | "The 99th percentile is $X million, dominated by these four shared-exposure scenarios" |
| If we cut our SaaS portfolio by 20%, what changes? | "Smaller attack surface" | "Expected loss drops $Y; the tail tightens by $Z, mostly from removing concentration in [shared dependency]" |
| Should we pay more for vendor due diligence? | "Probably" | "$N of due-diligence spend reduces expected loss by $M and the 95th percentile by $P" |
The right-hand column is the one capital-allocators recognise. It is also the one regulators are starting to look for in CIRMP and CPS 234 attestations.
A board-ready third-party cyber risk programme — one that produces a defensible dollar number and survives a regulator, an insurer, or an auditor pushing on the assumptions — has six properties. Most TPRM programmes today have one or two.
You can tell which business processes break, and by how much, when each vendor fails.
A small vendor sitting in a critical path can carry more risk than a strategic vendor in a non-critical one. Tier accordingly.
Not single numbers. Ranges with explicit assumptions, so they can be challenged and updated.
Structured expert elicitation — your own security and procurement team, calibrated against historical data — fills the gaps automated tools cannot.
A loss curve, not a list. The upper tail visible to the board, not hidden by an independence assumption that does not hold in real attack patterns.
Vendor risk changes faster than annual cycles. Threat intel, vendor M&A, new dependencies, and incident data should re-enter the model continuously.
None of these are exotic. None require an internal data science team. They do, however, require thinking about third-party risk as a portfolio of dollar exposures rather than a list of attested controls.
Third-party systems are the largest class of unscannable assets in most Australian organisations. They sit alongside OT, legacy, and air-gapped systems as infrastructure that determines material loss exposure but cannot be reached by the standard CRQ toolchain. That is not a TPRM failure. It is a structural feature of how modern enterprises are built. Boards, regulators, and insurers have, in different ways, all noticed.
What is changing in 2026 is the patience for the gap. SOCI enforcement is live. APRA expectations are sharpening. The ASIC and OAIC posture on third-party disclosures is firmer. Cyber insurance underwriters are increasingly asking for quantified evidence of third-party exposure, not attestation that vendors were assessed. The boards that walk into FY27 with a portfolio ALE — including the fatter tail that comes from shared vendor exposure — will defend their decisions more cleanly than those that walk in with a heatmap and a vendor list.
CRQ does not replace TPRM. The questionnaire programme still matters; the control assessments still matter. What CRQ does is translate the output of that programme into the unit the board, the CFO, the regulator, and the insurer all use to reason about everything else: dollars.
It also forces the conversation about concentration risk that most TPRM programmes have been ducking. When the loss curve gets honest about shared weather, the answer to "should we consolidate vendors?" stops being a procurement preference and becomes a quantified trade-off. That is the conversation FY27 budgets will be settled in.
CyQuantiFi quantifies risk on the assets your scanners can't touch — including your third parties.