On 1 July 2026, “we run it on-premises because we always have” stopped being an adequate starting point for Commonwealth technology investment.
Australia’s Whole-of-Government Cloud Computing Policy—often called the Cloud-First Policy—has changed the default. For new digital and ICT initiatives and upgrades, affected agencies must adopt cloud solutions unless they can justify an alternative.
That is a meaningful shift. But it is not an instruction to put every workload into a hyperscale public cloud. It is not a deadline for an indiscriminate data-centre exit. And it does not make security, sovereignty, resilience or cost management someone else’s problem.
The better reading is more useful: cloud must now be the first architecture considered, while the chosen design still has to survive scrutiny across its full lifecycle.
What changed on 1 July—and what did not
The Digital Transformation Agency (DTA) released the policy on 8 December 2025, with a seven-month runway before commencement. The Australian Government Architecture entry now records it as mandatory from 1 July 2026.
It applies to all digital and ICT investments made by non-corporate Commonwealth entities (NCCEs). Corporate Commonwealth entities may choose to apply it. The national intelligence community is outside its scope, as the policy’s applicability statement makes clear.
The policy also reaches beyond the initial purchase. Agencies are expected to consider it during procurement, cloud transition, data migration, solution delivery and, importantly, when moving away from a cloud product.
The default has changed; architectural judgement has not disappeared. Public, private and hybrid cloud models are all supported, and the policy expressly allows hybrid and multi-cloud approaches. An agency can still conclude that a particular workload should not move to cloud. The difference is that “not cloud” now needs a reasoned case—and the resulting design should still be secure, portable and capable of future cloud interoperability.
This reframes investment conversations. The question is no longer simply, “Can this run in cloud?” It is: “Which operating model best meets the service, security, data, resilience and economic requirements, and what evidence supports that decision?”
The five requirements form an operating model
The policy is sometimes summarised through themes such as sovereignty and resilience. Those themes matter, but the official requirements are more concrete.
1. Prioritise cloud when modernising ICT. Agencies must adopt cloud for new initiatives and upgrades unless an alternative is justified, include strategic cloud planning in their Digital Investment Plan, and prioritise decommissioning legacy systems. This makes cloud planning a portfolio discipline, not a project-by-project exception process.
2. Use contemporary cloud to enable innovation, including AI. Entities must provide sufficient computing capability, design for interoperability and portability, and use available AI and cyber risk clauses in procurement. Open standards, APIs and data portability are encouraged. In practical terms, an architecture that can scale an AI pilot but cannot export its data, policies or workloads is only partly ready.
3. Adopt cloud responsibly and securely. Governance roles, legal and policy alignment, service-level measures, continuous monitoring, logging, incident response, exit strategies and migration plans all sit here. Resilience is therefore not just multi-zone deployment. It includes observable service health, tested recovery, accountable operation and a credible way out.
4. Actively manage and optimise cost. Agencies must identify transition, migration and operating costs; track suitable unit economics; and use relevant government procurement arrangements where possible. The policy points towards FinOps because variable consumption without product ownership, tagging discipline and demand accountability is not financial agility—it is delayed surprise.
5. Build cloud skills across the APS. Workforce planning must address the ability to manage cloud environments. Suppliers can transfer capability, but an agency cannot outsource informed accountability. Someone inside still needs to understand the design, the risk decisions, the bill and the exit path.
Together, these requirements describe an operating model: architecture, procurement, cyber security, finance, service management and workforce capability have to move as one system.
Sovereignty is about control, not just coordinates
In 2026, “sovereign cloud” is becoming procurement language rather than conference language. That is healthy—provided buyers ask what the term actually means.
Data residency answers where data is stored. Sovereignty can also involve who owns and controls the provider, who can administer the environment, which jurisdictions can create legal exposure, where support personnel operate, how encryption keys are controlled, which subcontractors sit in the delivery chain and whether the Commonwealth can continue or exit the service during disruption.
The Hosting Certification Framework makes this wider view visible. It addresses privacy, sovereignty and security through matters including ownership, control, operations and supply chains. Its Strategic, Assured and Uncertified levels offer different protections, selected according to an agency’s risk profile and the sensitivity or classification of its data.
This does not mean every workload needs the highest level of every control. It means the architecture decision record should connect data classification and mission impact to the hosting, administration, key-management, network and support model selected.
Cloud-first is not a migration instruction. It is a requirement to make architecture, risk, cost and exit decisions explicit.
The same precision should be applied to resilience. Multiple availability zones may protect against a local infrastructure failure, but not necessarily identity compromise, control-plane dependency, a bad deployment replicated everywhere, concentration risk or a contract that makes recovery elsewhere impractical. A credible design names the failure modes and proves how the service responds.
Assurance is a stack, not a single badge
For suppliers, the policy increases the value of evidence that can be used in an agency’s own risk decision. Four adjacent mechanisms are especially important, but they do different jobs.
The Protective Security Policy Framework establishes government protective-security policy. The Information Security Manual, maintained by the Australian Signals Directorate (ASD), provides a cyber security framework and control catalogue. The HCF focuses on the privacy, sovereignty, ownership, control and supply-chain characteristics of hosting services.
IRAP sits differently again. Through the Infosec Registered Assessors Program, ASD-endorsed professionals independently assess security posture and recommend mitigations. Crucially, ASD states that IRAP assessors do not accredit, certify or endorse a system, and an assessment does not inherently prove compliance with every control tested.
That distinction matters in procurement. “IRAP assessed” is not a universal pass. Buyers still need to examine the scope, service version, assessment date, inherited controls, findings and remediation status. A cloud platform’s report does not automatically cover a SaaS product built on top of it, nor the tenant configuration operated by an agency or managed service provider.
The strongest supplier response is therefore an evidence chain: service boundaries, data flows, subcontractors, hosting certification identifiers, control-responsibility matrices, relevant assessment reports, remediation tracking, operational metrics, incident paths, recovery tests and exit procedures. Evidence should be mapped to the offered service—not buried in a generic corporate assurance pack.
At the time of writing, the HCF website also says the framework is under reform and that registrations for prospective providers and supplementary assessments have been paused since 3 November 2025. Existing certified providers are not affected. Teams planning bids should track that reform rather than assume the process or evidence requirements are static.
AI readiness starts below the model layer
AI readiness is now an infrastructure concern because AI changes compute density, data movement, observability, cost profiles and capacity planning. The policy requires access to sufficient cloud computing capability for technologies such as AI, while also requiring portability and attention to lock-in.
Those requirements pull in opposite directions if handled lazily. The fastest route to a useful model may rely on a provider-specific service; the safest long-term position may demand portable data, replaceable model endpoints and policy controls that are not trapped inside one platform. Good architecture does not pretend that tension disappears. It identifies which dependencies are deliberate, prices their exit cost and isolates them behind stable interfaces where worthwhile.
The APS AI Plan reinforces the direction. GovAI is described as a secure, Australian-based, vendor-agnostic hosting and model-brokerage platform, including access to onshore models. That connects AI adoption to sovereignty, reuse and common capability—not merely to model selection.
Physical infrastructure is part of this picture. The government’s separate Expectations of data centres and AI infrastructure developers, announced on 23 March 2026, cover national interest and sovereignty, energy, water, Australian skills and local research capability. They do not amend existing legal obligations, but they signal that compute capacity will increasingly be judged alongside energy-system impact, water resilience and social licence.
An industry NEXTDC explainer captures the resulting market ripple: systems integrators, managed service providers, software vendors, telecommunications providers and infrastructure operators will all encounter stronger questions about security, sovereignty, resilience and interoperability. Its supplier perspective is useful context, but the government policy and each agency’s risk assessment remain the sources of obligation.
The policy reaches beyond the APS boundary
Only NCCEs are directly required to comply, but government services are assembled through long supply chains. A SaaS vendor may rely on a public cloud, which relies on a data-centre operator, carriers, identity services, support teams and offshore software components. Policy requirements travel down that chain through architecture reviews, tender criteria, contracts and assurance requests.
This creates differentiation for suppliers that can answer hard questions quickly. Where is each data class processed, stored, logged and backed up? Which staff can access production? What changes during an incident? Which controls belong to the provider, integrator, product team and agency? Can telemetry feed the agency’s monitoring environment? How are costs allocated per service outcome? How does the agency retrieve its data and continue operations at termination?
Enterprises outside government should pay attention too. The Australian Government Architecture promotes consistency, interoperability, reuse, lower risk and value for money. Those are not public-sector-only concerns. Government procurement often sharpens capabilities—control mapping, cost allocation, exit planning and supply-chain visibility—that regulated enterprises soon expect from the same providers.
The commercial implication is straightforward: a polished security page is less valuable than current, service-specific and reusable evidence. Providers that treat assurance as part of product engineering will respond faster and create less friction than those rebuilding a compliance story for every bid.
What to do over the next 12 months
The policy is already in force. The next year should be about converting intent into repeatable decisions and operational evidence.
For agency technology leaders: segment the portfolio by service criticality, data sensitivity, lifecycle and technical constraints. Put new investments and material upgrades through a cloud-first decision record. Maintain a funded legacy decommissioning roadmap, not just a migration list. Make resilience tests, service metrics and exit exercises part of normal governance. Establish unit economics that connect cloud spend to products or public-service outcomes.
For architects and engineering leaders: document the shared-responsibility model at control level. Design identity, logging, key management, network paths and recovery across the whole service, not just the cloud account. Use open interfaces selectively, record accepted proprietary dependencies, and test data export before it becomes urgent. Treat AI capacity, data governance and model portability as one design problem.
For suppliers: map HCF, PSPF, ISM and IRAP evidence to each offered service and its current boundary. Make subcontractors, operational locations and inherited controls transparent. Prepare measurable reliability, incident, cost and exit commitments. Build capability transfer into delivery so the agency is stronger at contract end, not more dependent.
For everyone: review the evidence when the service changes. Cloud platforms evolve continuously; assurance that describes last year’s boundary can become misleading even while the PDF remains current.
Cloud-first will not succeed because more workloads appear on a cloud consumption report. It will succeed if agencies retire genuine legacy risk, deliver more resilient services, keep control of sensitive information, understand the economics of what they run and preserve room to change.
That is the real architectural test now underway.