Most of the Perth businesses we support no longer own a server. Email, files, finance, CRM and line-of-business apps all run as subscriptions. For those businesses, a lot of the old Essential Eight never quite fitted: you cannot patch a server you do not run, or harden a network someone else operates.
ASD Essentials for cloud, published on 15 October 2026 alongside the enterprise IT and OT chapters, is the ASD’s answer. It is written for organisations whose technology is delivered entirely through software-as-a-service (SaaS) and platform-as-a-service (PaaS), and it puts the effort where a cloud customer can actually change the outcome: identity, data, configuration, integrations and provider assurance. For the wider transition, see our Essential Eight to ASD Essentials tracker.
The ASD draws the line by what you operate. If your environment is SaaS and PaaS only, start with the cloud chapter. If you run on-premises servers, a hybrid environment or infrastructure-as-a-service, start with Essentials for enterprise IT, because you still own the operating systems, networks and identity infrastructure that chapter covers.
The chapter is blunt that labels do not decide this. If you make heavy use of low-code apps, scripting, automation or private networking inside a SaaS product, the ASD says to apply the PaaS actions to that service even though you bought it as SaaS. If a PaaS service gives you direct control of compute or networking, you are close to infrastructure-as-a-service and should consider the enterprise IT chapter instead. In practice, plenty of businesses will need both chapters for different parts of their environment.
The most useful thing in the cloud chapter is a marker against every action showing where responsibility usually sits, separately for SaaS and PaaS:
C (Customer). You deliver and operate the control. You are assessed on it directly.
S (Supplied). The provider supplies the capability, but you have to enable, configure, operate and monitor it. The ASD is explicit that a supplied capability left at an insecure default, or applied inconsistently, is not yet effective.
P (Provider). The provider implements the control and your job is to verify it, using current independent assurance such as an IRAP assessment scoped to the services, features, regions and support arrangements you actually use.
The S marker is where most real-world gaps live. Conditional access, audit logging and alerting all ship inside the big SaaS platforms, and plenty of businesses assume that because the feature exists, they are covered. Under this chapter, an unconfigured feature counts for nothing. The ASD also notes the markers are indicative: you are expected to confirm and document the actual split for each service you rely on.
The Governance and culture domain carries several actions that are new for most cloud-only businesses:
Executive approval before switching on AI. Material SaaS or PaaS AI functions need executive or delegate approval before they are enabled, including a review of the data they can reach, their permissions, retention, logging, agents and connectors. If your business has turned on an AI assistant across its productivity suite without a documented decision, that is a gap under this chapter. Our AI governance service covers exactly this decision.
Executive approval for high-risk services. Adopting SaaS or PaaS services that store sensitive data or support critical business functions also needs executive sign-off.
A shared responsibility register. You maintain a register of the security responsibilities you inherit from each provider and the ones you retain, and review it as services change.
Sovereignty and supplier policies. Policies that meet your data sensitivity and sovereignty requirements, and that restrict software on your cloud services to reputable suppliers.
Prefer provider-managed services. Where it suits the business, choose cloud services that maximise what the provider manages and minimise what you have to run yourself.
The cloud chapter uses the same eight domains as enterprise IT, redefined for cloud. Privileged environments now include SaaS admin consoles and cloud control planes. Boundary services include integrations, APIs, gateways and remote access. The priority phases follow the same order as enterprise IT: identity services and boundary services first, then critical processes and services and privileged environments, then business systems and user devices.
The actions we expect to cause the most work for SaaS businesses are these:
Consent grants and integrations. Applications, integrations and consent grants have to be assessed and approved before they get access, and reviewed regularly. Detection logic has to catch anomalous control-plane activity, including consent grants, federation changes and privilege elevations. Malicious OAuth apps that a user approves with one click are a common route into cloud tenants, and this chapter closes that door.
Shadow IT. You need to identify sanctioned and unsanctioned services, tenants and integrations and bring them under governance quickly.
Single points of dependency. Identify and mitigate the dependencies created by OAuth and federated identity providers. If one identity provider fails or is compromised, what else goes down with it?
Onboarding and exit. A controlled process to onboard, configure and exit services, including verifying that data is retrieved, deleted and that access is revoked when you leave.
Incident response for cloud. Response procedures have to cover tenant and identity-provider compromise, provider-side incidents, token and session revocation, removal of unauthorised consent grants and confirming a trusted state before resuming operations. Coordination plans need the provider’s notification arrangements and escalation contacts written in.
PaaS customers carry more: hardening development pipelines and their credentials, scanning third-party libraries and dependencies, and checking the integrity of images and components before deployment.
The ASD published an Asset scoping guide for cloud alongside the chapter. It describes each domain, the consequence of compromise, and prompting questions to decide which of your services belong where. One question deserves early attention: whether material security logs are unavailable to you, restricted by service tier or retained for less time than you need. With the large SaaS platforms, that answer often comes down to the licence you are on, and it is far better to find out during scoping than during an incident.
The guide also settles a common worry. A service can sit in several domains at once, for example an internet-facing app that is also a critical service. That widens the set of actions that apply, but an action that applies through two domains is implemented once, not twice.
For a cloud-only business, most S-marked actions are configured by whoever manages your tenant. That is often your MSP. The chapter’s message is the same as the rest of ASD Essentials: outsourcing the work does not outsource the accountability. You need evidence that supplied capabilities are switched on and configured properly, and you need it to stay current. If we look after your environment through our managed security services, that is a fair question to ask us.
Decide which chapter applies. List what you actually operate. Pure SaaS and PaaS points to the cloud chapter; any servers, hybrid identity or infrastructure-as-a-service brings in enterprise IT for those parts.
Start the shared responsibility register. For each major service, record what the provider does, what it supplies for you to configure, and what you own. Mark every S item you have not yet configured or evidenced.
Review AI features and consent grants. Find out which AI functions, agents and connectors are enabled, and which third-party apps have consent to your data, and get a documented decision on each. Talk to us on 1300 EPIC IT if you would like help working through it.
ASD Essentials for cloud is one of three chapters of ASD Essentials, the ASD framework that replaces the Essential Eight, published on 15 October 2026. It is written for organisations whose technology is delivered entirely through SaaS and PaaS, and focuses on identity, data, configuration, integrations and provider assurance.
It depends on what else you run. A business that is entirely SaaS should start with ASD Essentials for cloud. If you also run on-premises servers, hybrid identity or infrastructure-as-a-service, the ASD recommends starting with the enterprise IT chapter, and many businesses will use both for different parts of their environment.
They show where responsibility for each action usually sits. C means the customer delivers and operates the control. S means the provider supplies the capability but the customer must enable, configure and monitor it. P means the provider implements it and the customer verifies it with assurance evidence such as an IRAP assessment.
Yes. ASD Essentials for cloud requires executive or delegate approval before enabling material SaaS or PaaS AI functions, including a review of the data they can access, permissions, retention, logging, agents and connectors.
The same as enterprise IT. Phase 1 is identity services and boundary services, phase 2 is critical processes and services and privileged environments, and phase 3 is business systems and user devices. Governance and culture and Visibility and response run across all phases.
Summarised from ASD Essentials for cloud and the Asset scoping guide for cloud. © Commonwealth of Australia 2026, used under CC BY 4.0. See the ASD’s chapter selection guidance for more.
