ASD Essentials for Cloud, Explained

ASD Essentials for cloud is the chapter of the Australian Signals Directorate's (ASD) new Essentials series for organisations whose technology is delivered entirely as cloud software and platform services, with no servers or network of their own (ASD's chapter page). It keeps the same eight domains and priority phases as the enterprise IT chapter, but marks each of its 78 actions (our count of ASD's chapter) with who does the work: you, your provider, or you switching on and configuring what the provider supplies. In our reading it is the chapter for an organisation that runs entirely on a suite such as Microsoft 365 or Google Workspace, although ASD names no products.

ASD published the chapter on 15 October 2026 with chapters for enterprise IT and operational technology, as part of ASD Essentials, which ASD calls "an evolution of the Essential Eight" (The Essentials for senior executives). Our launch post covers the series as a whole.

What is ASD Essentials for cloud?

Every chapter has three layers: principles describe "the security outcomes an organisation aims to achieve", actions describe "what must be done to achieve them" and domains describe "where that work applies" (ASD Essentials for cloud). The same chapter says "Each principle states a cyber security objective drawn from ASD’s Information Security Manual (ISM)", so it stands on the same foundation as the ISM.

Software-as-a-service (SaaS) is a finished application you sign in to, such as email, file storage or accounting; ASD says the provider "operates everything beneath the service". Platform-as-a-service (PaaS) is a managed platform for applications you build yourself: the provider runs the platform, and in ASD's words "the organisation writes the code, selects the dependencies, deploys the workloads". Infrastructure-as-a-service (IaaS) is rented servers, storage and networks that you run much as you would your own, which is why ASD sends IaaS users to the enterprise IT chapter.

The cloud chapter exists because some enterprise IT guidance "describes work the provider now performs and cannot be implemented or evidenced by a SaaS or PaaS consumer" (ASD Essentials for cloud). By our count, its three matrices hold 78 actions: 17 for Governance and culture, 14 for Visibility and response and 47 across the six technical domains.

Does the cloud chapter apply to my organisation?

ASD's landing page for the chapter says it "is designed for organisations that deliver their technology environment through cloud services, and that do not operate their own server or network infrastructure". ASD's Which chapter should I start with? draws the other side of the line: "Where an organisation operates on-premises infrastructure, a hybrid environment or infrastructure-as-a-service, the enterprise IT chapter is the ideal starting point." A file server in the office points there, in our reading; see our enterprise IT chapter post.

Few environments are pure. Where an organisation makes significant use of SaaS features that behave like a platform (low-code development, scripting, private networking), ASD says it "should apply the PaaS-marked approaches to those services, even where the service is procured as SaaS" (ASD Essentials for cloud). Most organisations will need both chapters eventually: "The question is which to begin with, not which to adopt." ASD has not set a transition timeline; its FAQ says it "will advise on expectations for transitioning to the new framework in due course".

Who is responsible for what in the cloud?

Each action in the cloud chapter carries a marker, given separately for PaaS and SaaS, showing "where, under the shared responsibility model, the work of achieving the outcome typically sits". ASD defines three:

• C (Customer): "the organisation both delivers and operates the control".
• S (Supplied): "the provider supplies the required capability, but the Customer must enable, configure and operate it".
• P (Provider-inherited): "the provider delivers the outcome, and the organisation’s task is to verify it through assurance evidence".

Put simply: C is yours to do, S is a provider feature that does nothing until you turn it on and set it correctly, and P is the provider's job, which you still need to show is being done. In the SaaS column of ASD's matrices, by our count, 34 actions are C, 27 are S and 16 are P (one has no marker), so 61 of the 78 sit with the SaaS customer; in the PaaS column, only two are P.

Four actions from ASD's matrices show how the markers fall (MFA is multi-factor authentication):

Action, in ASD's words	PaaS	SaaS
"Use phishing-resistant MFA for users authenticating to systems."	S	S
"Assess and approve applications, integrations and consent grants before permitting access, and review them on a regular basis."	C	C
"Enable provider audit logging at sufficient tiers and retention, and forward security-relevant logs and configuration changes to a central capability."	S	S
"Identify and remediate vulnerable third-party libraries and dependencies before deployment and on an ongoing basis."	C	P

The provider builds MFA, but it protects no one until you enforce it. Which third-party apps may connect to your accounts is your call. Logging tier and retention are your choice, and may depend on what you pay for. Vulnerable code libraries are yours on a platform you build on, and the provider's inside a finished application.

ASD calls the markers "indicative rather than determinative", so confirm the split for each service. The rule underneath is in Which chapter should I start with?: "outsourcing a service does not transfer accountability for the security outcomes that service is expected to achieve."

What does the cloud chapter ask you to do first?

ASD's cloud chapter uses the same eight domains in the same priority phases as enterprise IT (its Figure 3):

1. Phase 1: Boundary services and Identity services.
2. Phase 2: Critical processes and services, and Privileged environments.
3. Phase 3: Business systems and User devices.

The two capability domains, Governance and culture and Visibility and response, "apply across all phases and expand as implementation progresses". For an organisation on a productivity suite, in our reading, phase 1 is the tenant (your organisation's own instance of the service), its sign-in and everything that connects to it from outside; ASD's Asset scoping guide for cloud lists "SaaS and cloud email services and gateways" among its example boundary assets. User devices stay in scope: "desktops, laptops and mobile devices".

ASD stresses that "Priority phases are a sequencing mechanism, not a rating", and its Implementation planning guide says the framework "does not prescribe implementation timeframes".

How is a cloud chapter assessed?

In ASD's cloud chapter, the marker decides what an assessment looks at:

• Customer: "the organisation is assessed on the control as it operates it".
• Supplied: the assessment asks "whether the capability has been enabled, configured to the organisation’s context, and operated consistently", and ASD is blunt: "A capability that exists but has been left at an insecure default, or applied inconsistently, is not yet effective."
• Provider-inherited: the organisation "remains accountable for confirming it is in place", drawing on "current independent assurance recorded against the shared responsibility register, such as an IRAP assessment scoped to the services consumed" (IRAP is ASD's Infosec Registered Assessors Program).

Ratings follow ASD's general Assessment process guide: "Each action is assessed against each applicable domain using a four-tier, outcome-based rating scale: not assessed, not effective, partially effective and fully effective." A principle takes "the lowest applicable action rating", and each domain gets a percentage: not effective scores 0, partially effective 0.5 and fully effective 1, averaged across the domain's applicable principles. The guide "supports organisations assessing their own cyber security environment", and an independent assessor is "not required" (Implementation planning guide).

What does it mean for smaller organisations?

ASD's FAQ says the series "is written primarily for Commonwealth entities, critical infrastructure owners and operators, and large organisations", but the cloud chapter adds that "Small and medium sized businesses that do not operate at enterprise scale can still use this guidance where relevant".

In our view, cloud is the chapter that fits smaller organisations best. ASD's own SaaS example is "a small Commonwealth entity or statutory body whose entire corporate environment runs on a cloud productivity and collaboration suite" (ASD Essentials for cloud). Swap the Commonwealth entity for a practice, a firm or a not-for-profit and, in our reading, that describes many Australian organisations on Microsoft 365 or Google Workspace. ASD names no product, and nothing in the chapter says whether any product meets an action.

The effort is real: even for pure SaaS, 61 of the 78 actions are yours to do or switch on, and some assume resources a small team may lack (ASD Essentials for cloud): backups isolated "through separate accounts, subscriptions or tenants with independent access controls", administration "only from managed, compliant, hardened devices", and audit logging "at sufficient tiers and retention", which may depend on your licence.

ASD's shorter Cloud shared responsibility model: Guidance for individuals and small and medium businesses, linked from the chapter, is the gentler place to start: "As the customer, you will always have some responsibilities." It also advises: "To help you choose a trustworthy CSP, ask for their IRAP assessment." (A CSP is a cloud service provider.)

What should you do now?

1. Confirm which chapter fits. On-premises, hybrid or IaaS starts with enterprise IT.
2. List every cloud service, tenant and integration, including ones staff signed up for. ASD's action: "Identify sanctioned and unsanctioned services, tenants and integrations and promptly bring them under organisational governance."
3. Start a shared responsibility register. ASD's action: "Maintain a register of inherited and retained security responsibilities per provider, and review it as services change."
4. Work on phase 1 first: phishing-resistant MFA for every user, legacy sign-in protocols disabled or restricted, and third-party app consent approved and reviewed.
5. Check every S action against your real settings, not the defaults.
6. Keep current work going. ASD's FAQ does not recommend slowing or stopping uplift programs already approved.

Supplied capability is often already in the licences you hold. Our free coverage check shows which ISM and Essential Eight controls the products you already pay for can reach, in about three minutes.

For help, our ASD Essentials transition review works through the cloud chapter with you and your IT provider: we scope the domains, sort every action into addressed, partially addressed or not addressed, and build the evidence register and the plan. For a smaller organisation, the fixed-price IT Security Review ($399 inc GST) is the simpler first step: a questionnaire, a one-hour consultation and a plain-English report with a prioritised action plan.

Sources

• ASD, ASD Essentials for cloud: the chapter and the matrices counted here. The PDF edition words some actions and markers differently; this post quotes the web page.
• ASD, ASD Essentials for cloud landing page
• ASD, Asset scoping guide for cloud
• ASD, Which chapter should I start with?
• ASD, Frequently asked questions
• ASD, Assessment process guide
• ASD, Implementation planning guide
• ASD, The Essentials for senior executives
• ASD, Cloud shared responsibility model: Guidance for individuals and small and medium businesses (October 2025)

ASD Essentials content © Commonwealth of Australia, CC BY 4.0, via cyber.gov.au.