ASD Essentials for cloud

Who it is for. ASD published the cloud chapter on 15 October 2026 for organisations whose technology environment is delivered entirely through SaaS and PaaS. ASD's reasoning is that parts of the enterprise IT chapter, such as hardening servers, running networks and maintaining platform runtimes, describe work the provider now does, so a SaaS or PaaS customer can't implement or evidence it. The cloud chapter shifts effort to what the customer actually controls: identity, data, tenant configuration, applications, integrations and assurance over the provider.

SaaS or PaaS: pick by what you operate

A SaaS customer uses finished applications, so its responsibilities centre on identities, data, tenant settings, connected integrations and provider assurance. A PaaS customer builds and runs its own code on a managed platform, so it also has to secure what it writes, patch the dependencies it deploys and segment the environments it configures. The chapter's matrix marks every action separately for SaaS and PaaS.

ASD says to judge by what you actually run, not by the procurement label. If a SaaS product is used heavily for low-code apps, scripting or private networking, apply the PaaS approach to it. If a PaaS service gives you direct control of compute or networking, you are close to infrastructure-as-a-service and the enterprise IT chapter may fit better.

Three responsibility markers

C (Customer): you build and run the control yourself and are assessed on how you operate it.

S (Supplied): the provider supplies the capability but you have to switch it on, configure it and run it. Assessment looks at your side. ASD is explicit that a capability left at an insecure default, or applied unevenly, is not yet effective.

P (Provider-inherited): the provider delivers the outcome and you verify it with assurance evidence, for example an IRAP assessment scoped to the services you consume. You stay accountable for confirming it is in place.

ASD calls the markers indicative, not determinative. Responsibilities change with service tier, contract and configuration, especially on PaaS, so confirm the split for each service rather than assuming the marker applies.

Domains and priority phases

The cloud chapter uses the same eight domains as enterprise IT, redefined for cloud. Boundary services covers integrations, APIs, gateways, internet-facing services and remote access between your SaaS or PaaS services and outside environments. Identity services covers identity providers, authentication and authorisation enforcement and credential stores. Privileged environments explicitly includes SaaS admin consoles, PaaS management and deployment services and the cloud control plane. Business systems covers business apps, workflow platforms, data services and custom apps on managed platforms. User devices are the laptops, desktops and phones staff use to reach the services. Governance and culture, and Visibility and response, run across everything.

The phase order matches enterprise IT: phase 1 is identity services and boundary services, phase 2 is critical processes and services plus privileged environments, and phase 3 is business systems and user devices. As in every chapter, ASD says a phase is a sequence, not a rating, maturity level or compliance claim.

Development, test and staging environments are in scope. Any non-production environment that holds production trust, has admin access to production or can deploy into it should be protected to the same level as production.

Actions that stand out for cloud customers

Keep a register of which security responsibilities each provider carries and which you keep, and review it when services change.

Assess and approve applications, integrations and OAuth consent grants before they get access, and review them regularly. Find and reduce single points of dependency on OAuth and federated identity providers.

Use phishing-resistant MFA, disable legacy authentication (or restrict, monitor and set a dated plan to retire it), and constrain non-person identities so they only work from their intended workload or issuer.

Do admin work on cloud management planes only from managed, hardened devices, with time-bound privilege grants, and log every change to services and settings with who, when and what.

Define tenant configuration baselines from vendor and industry hardening guidance, deploy them preferably as policy-as-code with guardrails that block non-compliant settings, and detect drift.

Get executive or delegate approval before turning on SaaS or PaaS AI features, and executive approval before adopting high-risk services that hold sensitive data.

Turn on provider audit logging at a tier and retention period that is actually useful, and send security-relevant logs and configuration changes to a central capability. Detection should cover consent grants, federation changes and privilege elevations.

Back up important data and settings to immutable storage that sits in a separate account, subscription or tenant, add your own backup where the provider's arrangements aren't enough, and agree recovery arrangements with the provider for data loss, malicious deletion and tenant misconfiguration.

Keep customer control of the keys protecting your most sensitive data, including the ability to revoke the provider's access.

Write incident response procedures that cover tenant compromise, identity-provider compromise and incidents on the provider's side, including who notifies whom.

Practitioner checklist

1. Decide per service whether you are a SaaS or PaaS customer, using what you operate rather than the product name. 2. Build the shared responsibility register and collect current assurance (for example IRAP reports) for every P-marked item. 3. For each S-marked item, check that the capability is enabled and configured for your context rather than left at default. 4. Start with phase 1: identity provider settings, MFA strength, legacy auth, consent grants, integrations and internet-facing APIs. 5. Confirm audit logs are on, retained and leaving the tenant. Recent desk examples of why this matters: the ConnectWise SkyKick credential misuse against Microsoft 365 tenants (October 2026) and the Canva exposure through feedback vendor Canny's connection to Canva's Salesforce (September 2026).