salam@localhost · ~/salamkhan.au
mel aest
← back to blog
2026-05-28

I asked the wrong question about supply chain under SOCI.

I thought supply chain meant our IT vendors. The usual suspects, Snowflake, Okta, AWS, the SaaS list. WRONG. It's anyone whose failure could break the asset. Same hospital, much wider attack surface. Here's how I found out.

A couple of weeks ago I wrote I asked the wrong question about the SOCI Act. The short version was that the Security of Critical Infrastructure Act 2018 doesn't put a company in a sector. It puts each asset a company operates in a sector. A hospital with a sizeable data centre sits in health care AND data storage or processing at the same time, two CIRMP obligations under section 30AC of the Act, both carried by the Group CISO.

I've moved on to the next layer of the same Act.

Every Responsible Entity has to address four hazard categories under their Critical Infrastructure Risk Management Program (CIRMP). Cyber, personnel, physical, and supply chain. They're listed plainly in the Security of Critical Infrastructure (Critical infrastructure risk management program) Rules 2023 (LIN 23/006 if you want the proper instrument name), under section 30AH of the Act.

This post is about supply chain.

I thought supply chain meant our IT vendors. The usual suspects. Snowflake, Okta, AWS, the SaaS list. Or the consulting companies, the Big 4 and that lot. WRONG :).

The hospital, again

I fed my AI engine the same hospital from last time and asked it to map the supply chain hazard. I was expecting the IT vendor list back. It did not give me that.

It came back with the catering contractor. The pathology service. The medical device firmware vendor. The generator service company. The cleaners with after-hours badge access. AND the IT vendors. Same hospital. Much wider attack surface.

Wow.

Supply chain in CIRMP isn't your vendor spreadsheet

Supply chain under CIRMP isn't the cyber or IT procurement list. It's anyone whose failure could break the availability or integrity of the critical asset. The cleaner with badge access == Okta. The generator service == AWS. The catering contractor that handles meals for 800 inpatients matters as much as any of them.

If they break, your critical asset breaks. That's the test.

Supply chain scoping under SOCI. The question I asked first, show me the vendor list, returns the IT procurement list of Snowflake, Okta, AWS and the Big 4. The question that matters, who would break us if they broke, returns the actual hazard: catering, pathology, medical device firmware, the generator service, cleaners with badge access, and the IT vendors. The test is whether the asset would break if that party broke.

So I changed the question I'd been asking the engine. I'd been asking "show me the vendor list" and, helpfully, the engine came back with the vendor list. Now I ask "who has access to the asset, who provides essential goods or services, and who would break us if they broke?" Different question, completely different answer.

Other asset classes follow the same pattern

I ran the same prompt against a few other asset classes the Security of Critical Infrastructure (Definitions) Rules 2021 covers.

A critical data storage or processing asset: the obvious cloud and IT vendors, plus the silicon supply chain (chips, replacement drives), HVAC service, power and generator vendors, the cleaners with physical access, and the security firm.

A critical electricity asset: the control system vendor, the SCADA software vendor, the parts manufacturer, the transformer service company, and the tree-pruning contractor. Vegetation contact really is a live availability risk here.

A critical higher education asset with a research data store: the cloud SaaS, plus the university's own facilities, the research-data vendor handling sensitive datasets, and the cleaners with overnight access to the data hall.

Same pattern every time. Supply chain under CIRMP is anyone whose failure could break the asset.

What this means for AESCSF v2

Once the supply chain list is actually right, the next question is how you assess what you've got. Most CIRMP-regulated entities in Australia evidence this with the Australian Energy Sector Cyber Security Framework (AESCSF v2, released 10 October 2023 by AEMO) or an ISO 27001 equivalent. v2 expanded the supply chain practices specifically because of how often it gets under-scoped.

I'll write about AESCSF v2 properly next time. For now, just know: the framework assumes you've drawn the right boundary first. If you scoped supply chain as your IT vendor list, the assessment underneath that boundary will be neat, clean, and incomplete.

How I worked it out

I worked this out the same way I worked out the scoping question last time. I tried to code the supply chain mapping logic into a small rule engine, mostly to test whether I'd actually understood what supply chain meant or just thought I had.

The engine, helpfully, would not let me get away with the cyber person's instinct of treating supply chain as the SaaS list. It kept pushing the harder question. Who, on this site, on this asset's day, has the access or the dependency that could bring it down?

This is part of what I'm building toward at cirmpai.au. Early days, learner-builder project, not a launched product. The point of it is to keep me honest about exactly this kind of scoping mistake.

. . .

Have you done this?

Every layer of CIRMP I touch, I find I'd been asking the wrong question :).

If you've done supply chain scoping under CIRMP, either inside a Responsible Entity or advising one, what was the thing that surprised you most? I'd love to compare notes. Thanks.

tags
#SOCI#CIRMP#Critical Infrastructure#Cybersecurity#GRC
I asked the wrong question about supply chain under SOCI.