AI data centre security: five layers, four boundaries and who is accountable

What changed in August, and what was already there?

The SOCI regime has covered data storage or processing since 2021. What changed on 26 August 2026 is a second, separate regime aimed at energy, water and land use, not security.

It would be easy to read the recent political attention as the moment Australia worked out that data centres matter. That is not what happened, and the distinction matters for anyone establishing what their operator is already obliged to do.

Government had line of sight on this sector early. The data storage or processing sector was brought into the Security of Critical Infrastructure Act 2018 (Cth) by the 2021 amendments, one of eleven sectors in the expanded framework. The risk management program obligation followed in 2022, and the CIRMP Rules commenced on 17 February 2023 with a grace period that closed that August. The cyber framework obligation inside those rules took effect a year later. A critical data storage or processing asset has therefore carried a board-approved, annually reported risk management program for three years.

What changed on 26 August 2026 is the focus, not the fact of regulation. National Cabinet affirmed the Commonwealth's plan to legislate mandatory standards for large data centres, backing the framework the Prime Minister announced on 15 July 2026 and building on the Expectations of data centres and AI infrastructure developers released in March 2026. First ministers agreed that large data centres bring material energy, water and land-use impacts that need to be managed. Coordination sits with the new Office of AI in the Department of the Prime Minister and Cabinet, and legislation is targeted for early 2027. The first regime is about security. The second is about sustainability, community and environment.

The reason the focus moved is visible in the capital. Amazon announced A$20 billion for Australian data centre infrastructure across 2025 to 2029, on top of roughly A$9 billion invested between 2012 and 2023. Microsoft followed in April 2026 with A$25 billion by the end of 2029, which it says will expand its Australian cloud footprint by more than 140 per cent. The Australian Bureau of Statistics reported a seventh consecutive quarter of growth in data centre building construction for the March quarter 2026. AEMO's 2026 Electricity Statement of Opportunities forecasts data centre consumption in the National Electricity Market rising from about 5 TWh in 2025-26 to around 34 TWh by 2035-36, from roughly 3 per cent of grid demand to about 13 per cent.

Key takeaway: The sector is regulated on security grounds, about to be regulated again on environmental grounds, and growing faster than either regime was designed for. Neither tells you what risk you are carrying underneath your own AI workload.

What are the five layers, and why do the boundaries matter more than the layers?

An AI capability depends on five layers: physical, operational technology, infrastructure, data fabric and AI fabric. Serious incidents happen at the four boundaries between them, where each side assumes the other holds the risk.

Most security programmes have a mature position on the top two layers and almost nothing on the bottom two. The layers are worth naming precisely.

Physical. The building. Power delivery and redundancy, cooling plant, physical access control, the construction and commissioning programme, and the hardware that arrives through it. This layer fails in ways that do not resemble a cyber incident and that no amount of application security will address.

Operational technology. The systems that run the building: building management and its control protocols, power and uninterruptible supply monitoring, cooling controls, fire detection and suppression, and the data centre infrastructure management platform that ties them together. This is a control system estate, and it behaves like one.

Infrastructure. Compute, storage, network, virtualisation, container orchestration and the identity services that govern them. This is the layer most security programmes were built around, and where most existing controls already sit.

Data fabric. The data platform the organisation manages itself, typically on a third party's infrastructure: ingestion, storage, transformation, governance, lineage and the serving layer. The foundations belong to somebody else. The platform, its configuration, its access model and its governance belong to the customer.

AI fabric. Models, inference endpoints, retrieval and vector stores, agent orchestration and tool calls. The newest layer, the one attracting the most security attention, and the one that depends entirely on the four beneath it.

The layers are the easy part. A boundary is only real if something enforces it, and in practice the enforcement is frequently assumed rather than verified. Each of the four boundaries has a characteristic way of failing.

Physical to operational technology. The commissioning handover, where a building assembled by multiple vendors becomes an operating environment with an accountable owner. Credentials, network configuration and vendor access created during construction cross this boundary and frequently outlive it.

Operational technology to infrastructure. The network separation question, and the boundary that produces the incidents people remember. A building management system that shares a broadcast domain with anything an ordinary user can reach has collapsed a boundary that both sides assume is intact.

Infrastructure to data fabric. The identity and configuration boundary. The customer manages a platform they did not build on foundations they cannot inspect, and the division of responsibility for the platform's security is set by configuration rather than by architecture.

Data fabric to AI fabric. The reach question: what the model can retrieve, what an agent is permitted to call, and whether the serving layer enforces the same classification and permission model the data layer holds. A model with broader reach than the person querying it has dissolved this boundary entirely.

The argument in one line: Almost everything serious happens where two layers meet, and boundaries are where accountability is weakest, because each side reasonably assumes the other holds it.

Who is interested in this infrastructure?

State actors are already inside Australian critical infrastructure and mapping it for later. The facility layer has been reached directly at least once, and baseboard management controllers are the most reachable privileged control point.

The picture is more specific than the general anxiety around AI suggests, and it separates into three parts, evidenced to very different standards.

State actors are already inside Australian critical infrastructure, and are preparing for sabotage. This is not inference. In his Annual Threat Assessment of 24 June 2026, the Director-General of Security stated that ASIO had discovered nation state hackers in the network of an Australian critical infrastructure provider, and assessed that they were preparing for sabotage. They were not planting anything destructive. They were mapping the network and maintaining access so they could cripple it at a time of their choosing. He described the scale of the activity, led by one nation state in particular, as difficult to overstate. ASIO has established dedicated teams for cyber sabotage.

The supply chain is named explicitly as a route in. ASD's Annual Cyber Threat Report 2023-24 states that networks connected to critical infrastructure, directly or through their supply chains, may be targeted to pre-position capabilities for later effects on services, or used to reach a higher-value target. The 2024-25 report records critical infrastructure at 13 per cent of all incidents, and reports that ASD's ACSC notified entities of potentially malicious activity more than 1,700 times, an increase of 83 per cent on the prior year. A facility captured as a critical data storage or processing asset sits inside that picture, and so does every vendor with a maintenance contract on its plant.

The facility layer has been reached directly, at least once, at scale. In 2021 attackers obtained credentials for the customer support portals of two of Asia's largest colocation operators, GDS Holdings and ST Telemedia Global Data Centres. Roughly two thousand customers were affected, among them some of the largest enterprises in the world. The credentials remained live for more than a year, were auctioned for around 175,000 US dollars, and were later dumped publicly. Attackers logged into at least five customer accounts.

Two details matter for anyone running a workload in someone else's building. The attackers also took credentials for more than thirty thousand surveillance cameras, most protected by passwords such as 'admin'. And having reached the support portal, they went looking for remote hands services, specifically iDRAC, OpenBMC and FreeIPMI. That is movement from an operator's business system toward the management controllers of tenant servers.

The reporting is Resecurity's, published by Bloomberg, and it is a private attribution rather than a government one. Both operators disputed the impact, stating there was no data loss and no compromise of their customer service portals. The dispute is worth recording. So is the fact that the attackers' next move was toward the baseboard management controller.

On AI assets specifically, the evidence runs elsewhere. In September 2026 the NSA, CISA and the FBI issued a joint advisory on China-based AI companies running industrial-scale distillation campaigns against United States frontier models. Google's threat intelligence group reported in the same month that adversaries are targeting proprietary models and source code, exfiltrating API credentials, and co-opting victim cloud environments to run unauthorised AI workloads. Open source supply chain compromises against package registries have run at scale since March 2026, reaching government, military, healthcare and media organisations rather than only AI laboratories.

Those paths are APIs, credentials and software supply chains. Model weight theft is the scenario most often raised, and as of December 2025 the International AI Safety Report recorded no confirmed, publicly documented instance of it. Saying so is not a comfort. It is the reason the rest of this section can be trusted.

Where that leaves the facility. There is at least one privileged control point in the estate that is demonstrably reachable. Baseboard management controllers sit beneath the operating system, stay powered when the host is off, and hold near-total control of the hardware. Research published in mid-2026 found more than twenty-four thousand internet-exposed BMCs disclosing authentication hashes before login, through a vulnerability first documented in 2013. A separate authentication bypass in a widely deployed BMC firmware stack was added to the United States Known Exploited Vulnerabilities catalogue in June 2025. A major server vendor confirmed in June 2026 that its factory-default BMC password format can be recovered in practical time where the management interface is internet-facing.

The honest shape: State actors are in Australian critical infrastructure and are mapping it for later. Supply chains and connected systems are the named route. A colocation operator's support platform has already been used to reach toward tenant hardware management. And the control point at the bottom of your stack is one of the most privileged and least examined in the estate.

What goes wrong at each layer?

Each layer fails in a characteristic way. Physical fails on availability and access, operational technology on unauthenticated protocols, infrastructure at its lower boundary, data fabric by assumption, and AI fabric through excess reach.

With the adversary established, the failures themselves are more ordinary than the threat picture suggests. Only two of the five layers are usually covered by an existing programme.

Physical. The failure modes are availability and access rather than confidentiality, and high-density AI compute has made both sharper. Racks running AI training and inference draw power densities that older halls were never designed to carry, and liquid cooling introduces a plant dependency with a much shorter tolerance for failure than air cooling. A cooling event in a high-density hall is not a degradation, it is a shutdown. On the access side, the construction and commissioning programme is the period of greatest exposure: the site is populated by contractors from multiple vendors, the access control system is often not yet in its final state, and the security programme that will eventually govern the facility does not exist yet.

Operational technology. This is where I find the most consistent gap. Building management and power systems frequently run protocols with no authentication in their base form, monitored by platforms using community-string authentication that has been deprecated for years, and patched to a cadence set by the vendor's maintenance window rather than by a vulnerability management standard. What makes it serious is that the same systems increasingly have a management interface reachable from somewhere an attacker can get to, because remote monitoring was a commercial requirement and the segmentation that was supposed to contain it exists on the architecture diagram and not in the switch configuration.

Infrastructure. The failure here is rarely an absence of controls, because this is the layer everyone has invested in. It is the boundary with the layer below. A facility run as an IT estate has strong core networking, mature identity and real monitoring across everything the team recognises as a system, and treats the plant as somebody else's equipment. A facility run as an OT estate has immaculate power and cooling engineering and treats the network as plumbing rather than as an attack surface. Both leave the same seam open. What I find on the ground is consistent: segmentation on the diagram but not in the configuration, a patching regime that is behind on whichever subsystems were never assigned to a team, and accounts shared across contractors, created at commissioning, and never reviewed since.

Data fabric. The platform is managed by the customer and secured by assumption. The organisation holds responsibility for the access model, the classification, the lineage and the serving layer, while relying on foundations it cannot inspect and a provider whose own assurance stops at the platform boundary. It goes wrong at the seams: service principals with standing access created for a pipeline that was decommissioned, workspace-level permissions that do not reflect the sensitivity of what landed in them, and governance metadata that describes the intended state rather than the actual one.

AI fabric. The failure is reach. A model or an agent is given access sufficient to be useful, and the scope of that access is set once, at build time, against an estate that then changes. The result is a component that can retrieve more than the person querying it is entitled to see, with an audit trail that records the service identity rather than the human behind it. This layer also inherits everything beneath it. An agent is only as trustworthy as the data fabric it reads from, which is only as available as the plant three layers down.

Two observations cut across all five layers. Identity is the only control that spans the whole stack, and it is administered separately at every layer. Facility access, control system accounts, platform identity, data platform service principals and agent credentials are typically held by five different teams on five different lifecycles. Nobody holds the complete picture of who and what can reach a given asset.

What finally makes anyone address the lower layers is almost never the regulator and almost never an incident. It is a customer asking a question the operator cannot answer. Someone senior enough asks whether the building management system shares a network with anything touching their environment, or who holds the administrative accounts on the access control platform, and the answer does not exist in a form anyone can produce. That question does more than an audit finding, because it arrives through the commercial relationship rather than the compliance one.

What does a defensible facility architecture look like?

Six design positions, each aimed at a boundary rather than a layer: separate the facility plane, broker vendor access, isolate management controllers, give every workload an identity, centralise telemetry and treat hardware as supply chain.

None of these positions is novel. They are rarely applied below the infrastructure layer, and a customer asking about them will learn a great deal from the quality of the answer. First, the shape. The diagram below is the standard wiring of a colocation facility. The useful part is that only two things legitimately cross between the operator and the tenant, and both are on the left.

There is a standard for this, and it is not the one most operators cite. IEC 62443 is the control system counterpart to ISO 27001. Its central idea is to group assets with shared security requirements into zones, and treat every path between zones as a conduit that is documented, owned and enforced. It assigns obligations by role, so the operator is the asset owner and the building management contractor a maintenance service provider with its own part of the standard. Almost nobody in this sector references it, which is worth knowing when you ask what framework governs the facility plane.

1. Separate the facility plane from anything a tenant touches, and verify it in the configuration. Building management, power and cooling controls, the DCIM platform and the physical access system belong on their own segment with no path to the enterprise network and no path to a tenant environment. The test is whether someone has read the switch and firewall configuration recently enough to say so. This is the boundary with the worst record in the whole stack.

2. Broker vendor remote access rather than granting it. The usual answer is a standing account with remote access enabled by default. The better pattern is access that is requested, scoped to one system, time-limited, recorded, and revoked automatically. This is a solved problem in privileged access management, and it is rarely applied to the plant.

3. Treat the management controller as a tier zero asset. The baseboard management controller has more authority over a server than any administrator account. It belongs on an isolated management network, never facing the internet, with default credentials rotated at commissioning, firmware patched on a defined cadence, and its own monitoring. NIST published a high-performance computing security overlay in May 2026 that tailors sixty controls from SP 800-53 to environments supporting AI workloads, a reasonable reference point for anyone who needs an external standard to argue from.

4. Give every workload its own identity, including the non-human ones. Models, agents, pipelines and their supporting services should each hold a distinct identity with a named owner, short-lived credentials, and authorisation expressed as policy rather than as a position on the network. Shared service accounts are the most common single finding in this space, and they defeat every downstream control that depends on knowing who did something.

5. Land facility telemetry in the same place as everything else. Building management and DCIM events should reach the same platform as infrastructure and application logs, with detections written against facility events rather than only login events. A cooling anomaly and an authentication anomaly should be visible to the same team at the same time, because in a high-density environment the first can be a consequence of the second.

6. Treat the hardware and its firmware as part of the supply chain. Know what is in the estate, know what firmware it is running, verify integrity rather than assuming it, and be able to say what state the hardware was in before a workload ran. The same applies to the software supply chain feeding the AI fabric, where compromised packages and poisoned model artefacts have been a documented pattern through 2026.

One caution. Every one of these has an operability cost, and the facility has availability obligations that predate the security programme. A segmentation design that prevents a vendor responding to a cooling fault at two in the morning will be reversed, quietly, within a quarter. The work is to hold the boundary and keep the plant operable, which is why the answer is brokered access rather than no access.

Case study one: the boundary that existed only on the diagram. Illustrative composite, drawn from patterns common across engagements rather than a single organisation. A tenant taking space in a new facility asked, before go-live, what the building management system could reach. The answer took three weeks to assemble. The BMS shared a flat network with corporate wireless, the badge readers, and a management host with a path into the environment that would later hold AI training workloads. Nobody had intended this. The building had been assembled by several vendors across a construction programme, each commissioning their own subsystem onto whatever network was available, and the segmentation design had been drawn before any of them arrived.

The documented parallels are not hard to find. The 2013 Target breach began with credentials belonging to a refrigeration and HVAC subcontractor whose remote access was not segmented from the payment environment. In September 2023 one of the world's largest building automation vendors was hit by ransomware involving unauthorised access and data exfiltration across part of its internal IT infrastructure. Its own filing put the impact for the following quarter at approximately twenty-seven million US dollars, primarily response and remediation expenses, net of insurance recoveries. The attackers claimed a far larger data theft, and the company stated it found no evidence of impact to its digital products and services. A compromised building automation vendor has a reach that extends to every building it services. The lesson is about timing rather than technology. Before power-on, a segmentation correction is a configuration change. After go-live it is a change request with customer impact, an outage window and a commercial negotiation attached to it.

Case study two: the registry nobody owned. Illustrative composite. An enterprise AI platform had grown organically. Three teams pushed model artefacts to a shared registry. No team owned the access policy, and no individual held the keys, because every team did. The remediation required no new tooling: distinct workload identities, signed artefacts, one accountable owner, and the removal of seven shared service accounts.

The public record has caught up with this one. A critical unauthenticated server-side request forgery flaw in the MLflow tracking server, disclosed in 2026 with a CVSS score of 9.3, arises because the default configuration exposes the model registry webhooks API without authentication, and it has been exploited to steal cloud credentials. Model repositories have been a documented malware distribution channel since at least 2024, and a July 2026 incident at a major model hosting platform involved a malicious dataset achieving code execution on a worker and escalating to harvest cloud and cluster credentials. The lesson is that shared identity is no identity. Most of what goes wrong in an AI platform in the next two years will trace back to weak workload identity rather than to an attack on a model.

Key takeaway: None of these positions is exotic, and an operator who has done the work can describe them in a sentence. The question is what obliges them to, and what a customer is entitled to see.

What does Australian obligation attach to?

Data storage or processing is a SOCI sector, but capture turns on whose data a facility holds. The four hazard categories map onto the lower layers, and the 2026 prescriptive uplift went to nine other sectors.

There is a useful vocabulary sitting in Australian law already, and most organisations do not know it is there. What is worth borrowing is the structure of the security regime rather than its obligations.

Where an asset is a critical data storage or processing asset under section 12F of the Security of Critical Infrastructure Act 2018 (Cth), meaning it is operated by a commercial provider and used wholly or primarily to handle business critical data for a government body or for the responsible entity of another critical infrastructure asset, the responsible entity carries the Part 2A obligation to adopt, maintain and comply with a critical infrastructure risk management program, and to report on it annually. Separately, since 20 December 2024, section 9(7) has deemed data storage systems holding business critical data to form part of the critical infrastructure asset itself where the responsible entity owns or operates the system and its compromise could affect the asset. Whether a given facility is captured turns on whose data it holds and for whom, not on its size.

The CIRMP Rules require a responsible entity to identify and manage material risks across four hazard categories: cyber and information security, personnel, supply chain, and physical and natural hazards. They map onto the lower layers of this stack better than most security taxonomies do, and they are the language the operator's own board-approved program is already written in. Asking an operator about the four hazard categories is asking about a document they are legally required to hold.

The recent uplift went elsewhere. The Security of Critical Infrastructure Legislation Amendment (Enhanced Critical Infrastructure Risk Management Program) Rules 2026 were registered on 9 June 2026 and commenced the following day, moving nine asset classes from principles-based obligations to prescriptive ones, on a staged timetable. Those classes are electricity, energy market operators, gas, liquid fuel, water, broadcasting, domain name systems, freight infrastructure and freight services. Data storage or processing is not among them.

The uplift adds two hazard vectors to the original four, credential compromise and lateral movement, along with two further material risks covering national security impairment and foreign ownership, control or influence. It also adds four prescriptive controls: phishing-resistant multi-factor authentication with central logging, network segregation sufficient for critical systems to run independently for at least three months, supply chain mapping including major suppliers, and background-checked or security-cleared critical workers reviewed at least every five years. All-hazard and foreign influence requirements apply from around December 2026, patching and legacy technology from mid-2027, and the remaining measures from mid-2028. Network segregation and supply chain mapping are precisely the measures that address a facility plane sharing a network with a tenant environment, and a contracted service crossing a boundary nobody drew. The regulator has written the control. It has gone to nine sectors, and data centres are not among them.

A route many operators relied on has narrowed. A responsible entity holding a strategic-level certificate under the Commonwealth Hosting Certification Framework is exempt from the CIRMP obligation. From 3 November 2025, the Department paused HCF certification registration for prospective providers and for certified providers seeking supplementary assessment, pending reform of the framework. Providers already certified are not affected. The exemption still operates for those who hold it, and the path to obtaining it is closed for now.

Tranche 2 may move some of this. The consultation on streamlining and modernising the regime proposes reforms to the asset framework, including the data storage or processing class, along with board approval of the CIRMP, independent third party assurance, and the annual report being admissible in civil penalty proceedings. That is a consultation, not law.

What a customer can actually see. The risk management program is never submitted to anyone. What goes to the Cyber and Infrastructure Security Centre is a board-approved annual report attesting to the program's state, due within 90 days of the end of the financial year. The program itself stays with the entity, is not public, and is not available to a customer. So the question 'can we see your CIRMP' has one answer, and it is no.

What operators do publish is a set of IT and availability certifications: ISO 27001, SOC 1 and SOC 2 Type II, PCI DSS, Uptime Institute tier certification, and Hosting Certification status. These are real and independently assessed. They are also scoped more narrowly than their names suggest. A data centre provider's ISO certification typically covers the controls it manages as a facility provider, meaning physical security and availability. Asking whether an operator is certified produces a confident yes that does not answer the question. Asking for the scope statement does.

Hosting Certification is the strongest-sounding credential and the most misread. It certifies the provider rather than a control set, across ownership, control and strategic direction, personnel vetting, supply chain, monitoring systems, ancillary services and remote support arrangements. Several of those categories reach the facility plane, but each as a question of who owns and staffs the thing, not whether the control works. The framework requires a report from an accredited Security Construction and Equipment Committee assessor to confirm physical construction against the zone specifications in the Protective Security Policy Framework, and it accepts an IRAP report as evidence without requiring one.

Line those up and the shape of the gap is clear. Construction is assessed, as construction. An information system can be assessed against the Information Security Manual, optionally. Ownership and personnel are assessed thoroughly. The operational technology sitting between the building and the IT estate is assessed by none of them.

A provider holding strategic-level Hosting Certification is exempt from the risk management program obligation and is deemed to have satisfied it through certification. If that is read as written, the single instrument that compels an all-hazards look at a facility is discharged, for the providers most likely to carry sensitive government workloads, by a certification that does not assess control effectiveness in the facility plane. That reading is worth confirming with the regulator before anyone relies on it, and it is worth asking an operator directly whether they hold a program or an exemption.

Case study three: the programme that existed on paper. Illustrative composite. Annual CIRMP reporting was due. The board had approved the programme in principle. When the responsible entity asked for evidence that the controls described in it were operating, nobody could produce it. The programme existed as a document. The evidence did not, because nothing in the year between approvals had been designed to generate any. The four hazard categories are not hard to write about. They are hard to evidence, and the categories that cover the physical and personnel layers are the ones where evidence is least likely to exist, because those layers sit with people who were never asked to produce any.

The remediation is unglamorous and it works: a risk register linked to live controls, evidence collected automatically from the systems that already produce it, and a reporting pack a board can read. The shift from documentation to evidence is the defining compliance problem in this sector, and it is the same shift a customer forces when they ask a question the operator cannot answer.

Key takeaway: The obligation exists, it is narrower than most assume, and it is not visible. Which leaves the question of who holds what.

Who is accountable for each layer?

Published shared responsibility models stop before the bottom two layers, which is why nobody can answer for them. The facility operator holds physical and operational technology, and for most customers that part is invisible.

Every cloud provider publishes a shared responsibility model, and they are useful. They tell you, service model by service model, which security tasks the provider performs and which remain yours. The customer always retains data, identities and endpoints, and responsibility shifts toward the provider as you move from infrastructure through platform to software services. At the base of every version sit a small number of rows covering physical hosts, physical network and the physical data centre, marked as the provider's in every deployment model. The entire physical and operational technology estate is one line. Microsoft's own version is explicit that it is illustrative guidance rather than something that conveys legal conclusions or modifies the terms of any agreement. The artefact most organisations lean on says of itself that it is not a contract.

As generative AI arrived, the providers extended the model upward, publishing separate shared responsibility guidance for AI workloads and then again for agentic patterns. The AI model divides an AI-enabled solution into three layers, the AI platform, the AI application and the AI usage. The agent model then adds orchestration, tools and memory, and places the agent's instructions, tool selection, tool permissions, orchestration logic, memory design, and identity and authorisation with the customer. So the top of the stack now has six named layers described across two documents. The bottom of the stack has one, and it is the same one it had before any of this began. The elaboration only ever went in one direction.

Meanwhile the stack got a party deeper. A model provider now commonly sits between the customer and the platform. Claude is available on Amazon Bedrock, on Google Cloud and on Microsoft Foundry, and equivalent arrangements exist across the market. An organisation running an AI capability may be a customer of a model provider, whose model is served by a platform, whose region spans facilities the customer has never named, some operated and some leased.

Set the five layers against the four parties and the picture resolves. Physical and operational technology sit with the facility operator. Infrastructure sits with the platform. Data fabric is genuinely shared: the foundations belong to the platform, while the platform's configuration, access model, classification and governance belong to the customer. AI fabric splits between the model provider, who holds the model and its safety system, and the customer, who holds what it is allowed to reach.

The customer's own column does not grow as a result of this exercise. It stays where every published model already puts it, at identity, information and devices, plus the platform and reach decisions in the two layers they manage. What changes is that the customer can see what sits underneath, and can therefore reason about the risk they are carrying rather than assuming it away.

What should you establish before you sign?

Six things, all achievable before the contract and none needing a vendor. Four come from your own records in an afternoon. Two are questions to a party you already pay, and the answer is the finding.

Everything above describes a problem you did not create and cannot fix alone. What follows is the part you can do, and the useful thing about it is how little it depends on anyone else. None of the six needs funding, a vendor, or a programme of work. Do them in order, because each one narrows what the next has to cover.

A version you can run in an afternoon. For a single workload, without funding and without involving a vendor, name the four parties, walk the five layers, and mark which of them you could evidence if your board asked tomorrow. The output is one page showing what you know, what you assume, and what nobody has told you. That page is a better basis for a procurement conversation than any assurance report, because it is specific to a workload you actually run.

One caution on scope. Establishing what sits beneath you tells you what risk you hold and who else holds the rest. It does not discharge any obligation you carry, and it does not make a facility more secure on its own. Your privacy, prudential and critical infrastructure obligations remain yours, and this work makes them easier to evidence rather than replacing them.

What success looks like. The next time someone asks what happens to your AI capability if the foundations fail, or are compromised, or change without anyone telling you, you will have an answer with evidence behind it, and you will know which parts of that answer are not yours to give.

The regulation over this sector is going to keep arriving, and most of the new material will be about energy, water and land. Those are legitimate questions and they are not the ones you carry. Yours is narrower and more answerable than it looks. Your AI capability depends on five layers, your programme probably covers two, and the serious failures happen at the boundaries between them where each side assumes the other is holding it. Establishing what sits beneath you does not require a new framework, because the regulator has already named the hazard categories and the operator is already required to work in them. It requires asking the question before something else asks it for you.