GOV-09
Security risk management responsibilities
Executive approval before adopting high-risk services; shared responsibilities documented.
ASD Essentials
Understand
ASD Essentials for cloud.
ASD's Essentials for cloud is the chapter for organisations whose technology is delivered entirely as software-as-a-service (SaaS) and platform-as-a-service (PaaS). This guide explains what it covers, how it differs from enterprise IT and how to get started.
Reviewed 18 October 2026 · Current to ASD's Essentials for cloud, published 15 October 2026
At a glance
- domains
- 8
- principles
- 30
- not in enterprise IT
- 2
- service models
- 2
Nearly every action has two letters for who does the work.
ASD's Asset scoping guide for cloud gives example assets for each domain.
Control Stack has no pages for individual cloud actions: see what ASD has not published.
What the chapter covers
The ASD Essentials for cloud chapter provides guidance for organisations whose technology environment is delivered entirely through software-as-a-service (SaaS) and platform-as-a-service (PaaS).
Now the provider's job
A growing number of organisations run no servers or platforms of their own. ASD's examples of enterprise IT work they cannot do or evidence:
- Running and hardening servers
- Operating networks
- Maintaining platform runtimes (the software a platform uses to run your code)
Where the chapter focuses
The areas that decide a cloud customer's security, including:
- Identity
- Data
- Configuration
- Applications
- Integrations
- Provider assurance
Provider assurance means evidence that a provider is doing its share.
ASD wrote it for large organisations, critical infrastructure and government. Smaller businesses can use it where relevant: the outcomes matter just as much, but how you reach them, and how much sits with providers, differ.
Run your own servers, a hybrid environment or infrastructure-as-a-service (IaaS)? ASD says start with enterprise IT. See choosing between enterprise IT and cloud.
The eight domains
The cloud chapter keeps the enterprise IT domain names and rewrites five of the eight descriptions for cloud.
Technical domains
- Boundary servicesLinks between your cloud services and other environments.Rewritten for cloud
- Identity servicesSign-in and access for people and software.Rewritten for cloud
- Critical processes and servicesThe cloud services, workflows and data your primary outcomes depend on.
- Privileged environmentsAdmin consoles and the tools that deploy and manage services.Rewritten for cloud
- Business systemsEveryday SaaS and PaaS services not classed as critical.Rewritten for cloud
- User devicesStaff desktops, laptops and mobile devices used to reach your services.Rewritten for cloud
Capability domains
- Governance and culturePolicies, roles, risk and culture, including shared responsibilities.
- Visibility and responseDetecting, analysing and responding to cyber security events and incidents.
How each domain differs from enterprise IT
Boundary services
The links between your cloud services and the outside world and other environments: integrations, gateways, internet-facing services, remote access and APIs (the interfaces software uses to talk to other software).
Compared with enterprise IT: Enterprise IT centres this domain on network boundaries and edge devices. The cloud chapter centres it on the connections around your services. Its scoping guide adds federation (trusting another organisation's sign-in) and links between tenants (separate customer instances of a service).
Identity services
The services that sign people and software in, and decide what they can reach. ASD calls this domain the trust anchor for every other technical domain: the others all rely on it to know who is who.
Compared with enterprise IT: Enterprise IT describes enterprise-wide services such as directories. The cloud chapter names identity providers instead, and its scoping guide adds tokens, federation and the service accounts that apps use.
Critical processes and services
The cloud apps, platform services, workflows and data that your most important outcomes depend on.
Compared with enterprise IT: The same description as enterprise IT. The scoping guide adds cloud items, such as apps and automation you build on PaaS.
Privileged environments
Where admin work happens: SaaS admin consoles, PaaS management and deployment services, and the control plane (the tools and settings that configure and manage a service).
Compared with enterprise IT: It starts with the enterprise IT description, then names SaaS admin interfaces, PaaS deployment services and the control plane.
Business systems
The everyday SaaS and PaaS services that keep work going but are not classed as critical, such as office apps, workflow tools and custom apps.
Compared with enterprise IT: Enterprise IT describes supporting functions in general. The cloud chapter names SaaS and PaaS services, including custom apps on managed platforms.
User devices
The desktops, laptops and mobile devices staff use to reach your cloud services, with the browsers and apps on them.
Compared with enterprise IT: Enterprise IT names desktops and laptops issued to staff. The cloud chapter adds mobile devices, and its scoping guide includes personal and unmanaged devices.
Governance and culture
Policies, risk processes, roles and security culture, including who looks after each cloud service and its shared responsibilities.
Compared with enterprise IT: The same description as enterprise IT.
Visibility and response
Spotting and handling incidents. ASD's scoping questions ask whether each service's audit logs can be seen, kept and exported.
Compared with enterprise IT: The same description as enterprise IT.
The Asset scoping guide for cloud
ASD's separate scoping guide gives each domain questions and example assets, to help you decide what is in scope. Its main rule matches enterprise IT: an asset can sit in more than one domain, and a shared action is done once. The chapter also puts development, test and staging environments in scope (see non-production environments).
ASD's example assets, by domain
Boundary services
- API endpoints
- SaaS and PaaS integrations and connectors
- remote access services used to access SaaS and PaaS
Identity services
- identity providers and single sign-on platforms
- credential stores, including enterprise password managers and secrets vaults
- systems that provision accounts or entitlements into other systems, such as a human resource system that drives joiner, mover and leaver processes
Critical processes and services
- email systems and other key communication platforms
- customer data, personally identifiable and sensitive personal information within SaaS and PaaS services
- custom business applications, workflows and automation services hosted on PaaS platforms
Privileged environments
- SaaS administration portals and management consoles
- PaaS management consoles and deployment interfaces
- management APIs and automation interfaces
Business systems
- office productivity applications
- collaboration and messaging SaaS platforms
- workflow, automation and low-code platforms supporting business operations
User devices
- enterprise managed mobile devices, such as mobile phones and tablets
- unmanaged or bring your own devices (BYOD) accessing SaaS and PaaS services
- web browsers, client applications and extensions used to access cloud services
Governance and culture
- approved cloud service registers
- cloud shared responsibility matrices
- risk registers for cloud services
Visibility and response
- SaaS and PaaS audit logs and activity logging configurations
- security information and event management (SIEM) solutions integrating SaaS and PaaS telemetry
- incident response plans and procedures for SaaS and PaaS services
One of ASD's scoping questions, for privileged environments:
Can an automation identity, deployment pipeline, integration, delegated administrator or management API perform privileged actions?
Priority phases
The chapter groups the technical domains into priority phases: ASD's recommended order, chosen to cut the most risk, fastest. ASD gives the cloud order in Figure 3 of Essentials for cloud (see Sources). Governance and culture, and Visibility and response apply across all phases and grow as the work goes on. See also sequencing the work.
The principles
A principle is a security outcome, drawn from ASD's Information Security Manual (ISM). Its code, such as GOV-01, traces it to the ISM and sets no order. The cloud chapter uses 30. All 28 enterprise IT principles appear, plus two more.
- Not in enterprise IT
- Also in enterprise IT
Govern7
- GOV-01 Executive cyber security accountability
- GOV-03 Security risk management assurance
- GOV-04 Cyber security resourcing
- GOV-08 Executive artificial intelligence accountability
- GOV-09 Security risk management responsibilities (not in enterprise it)
- GOV-11 Supplier cyber security assurance
- GOV-14 Legacy system management
Identify2
Protect13
- PRO-01 Secure system lifecycle
- PRO-04 Secure configuration management
- PRO-05 Secure administration
- PRO-06 Vulnerability management
- PRO-07 Trustworthy software
- PRO-08 Cryptographic protection (not in enterprise it)
- PRO-09 Content filtering
- PRO-10 Regular and proven backups
- PRO-12 Least privilege access
- PRO-13 Identity, credential and access management
- PRO-14 Cyber security awareness training
- PRO-16 Cyber supply chain security
- PRO-18 Network segmentation and segregation
Detect5
Respond3
ASD's three matrices, principle by principle
ASD lists the principles in three matrices (tables): one for each capability domain, and one for the technical domains. Six principles appear in more than one matrix. In the technical matrix, each action is ticked against the technical domains it applies to. Where it applies, ASD also maps the action to the MITRE ATT&CK techniques (the methods attackers use) it is meant to address.
Principles that are not in the enterprise IT chapter are marked.
Matrix 1: Governance and culture capability domain
| Code | Principle |
|---|---|
| GOV-01 | Executive cyber security accountability |
| GOV-08 | Executive artificial intelligence accountability |
| GOV-04 | Cyber security resourcing |
| GOV-09 | Security risk management responsibilitiesNot in enterprise IT |
| GOV-03 | Security risk management assurance |
| GOV-11 | Supplier cyber security assurance |
| GOV-14 | Legacy system management |
| PRO-14 | Cyber security awareness training |
| PRO-06 | Vulnerability management |
Matrix 2: Visibility and response capability domain
| Code | Principle |
|---|---|
| IDE-01 | Asset identification |
| IDE-04 | Security risk identification |
| PRO-13 | Identity, credential and access management |
| DET-01 | Centralised event logging |
| DET-02 | Cyber security event detection |
| DET-03 | Cyber security incident identification |
| DET-05 | Detection capability efficacy |
| RES-05 | Cyber security incident coordination |
| RES-03 | Cyber security incident response |
| RES-04 | Cyber security incident insights |
Matrix 3: Technical domains
| Code | Principle |
|---|---|
| IDE-01 | Asset identification |
| PRO-01 | Secure system lifecycle |
| PRO-16 | Cyber supply chain security |
| PRO-13 | Identity, credential and access management |
| PRO-12 | Least privilege access |
| PRO-05 | Secure administration |
| PRO-04 | Secure configuration management |
| PRO-06 | Vulnerability management |
| PRO-07 | Trustworthy software |
| PRO-08 | Cryptographic protectionNot in enterprise IT |
| PRO-10 | Regular and proven backups |
| PRO-18 | Network segmentation and segregation |
| PRO-09 | Content filtering |
| PRO-14 | Cyber security awareness training |
| DET-01 | Centralised event logging |
| DET-04 | Baselined high-risk access activities |
| DET-02 | Cyber security event detection |
Two principles enterprise IT does not have
PRO-08
Cryptographic protection
Strong encryption, and your control of keys protecting your most sensitive data.
What their actions ask for
GOV-09 Security risk management responsibilities
- Get executive approval before adopting high-risk SaaS or PaaS that holds sensitive data and business functions.
- Where you can configure, monitor, assure and operate a platform, make your security requirements a condition of using it.
- Understand and document the shared responsibility arrangements, and build them into your security risk management.
PRO-08 Cryptographic protection
- Protect data in transit and at rest with best-practice cryptography, and turn off weak or outdated options.
- Manage keys securely through their whole life, from creation to revocation.
- Keep control of the keys that protect your most sensitive data, including the power to revoke the provider's access.
Cloud work in familiar principles
Most principles match enterprise IT, but their cloud actions ask for cloud work. Some of them:
IDE-01
Asset identification
Find sanctioned and unsanctioned services, tenants and integrations; govern them promptly.
PRO-16
Cyber supply chain security
Approve apps, integrations and consent grants before access; review them regularly.
PRO-05
Secure administration
Do cloud admin work only from managed, compliant, hardened devices.
DET-01
Centralised event logging
Enable provider audit logging at sufficient tier and retention; centralise it.
PRO-10
Regular and proven backups
Keep backups apart from production; set up recovery arrangements with the provider.
PRO-06
Vulnerability management
Where it fits your needs, prefer more provider-managed security.
RES-03, RES-05
Cyber security incident response and Cyber security incident coordination
Use tested procedures for tenant, identity-provider and provider-side incidents, with provider contacts.
GOV-08
Executive artificial intelligence accountability
Get executive or delegate approval before switching on AI features. See cloud and OT considerations for AI.
Each point in full
IDE-01
Find sanctioned and unsanctioned services, tenants and integrations, and promptly bring them under your governance.
PRO-16
Assess and approve apps, integrations and consent grants (permission for an app to reach your data) before they get access, and review them regularly. Find and reduce places where many apps rely on one sign-in service, such as an OAuth or federated identity provider.
PRO-05
Do admin work on the control plane only from managed, compliant, hardened devices.
DET-01
Turn on provider audit logging, at a service tier that records enough and keeps logs long enough, and send security logs and configuration changes to one central place.
PRO-10
Keep backups in separate accounts, subscriptions or tenants, and agree recovery arrangements with the provider. Cloud capabilities that need absolute availability for mission critical objectives should be able to be rebuilt quickly on another provider if needed.
PRO-06
Where it suits your needs, prefer cloud services in which the provider manages more of the security and you manage less.
RES-03, RES-05
Use tested incident response procedures that cover a compromised tenant or identity provider and incidents on the provider's side, with provider notifications and escalation contacts built in.
GOV-08
Get executive or delegate approval before switching on AI features in SaaS or PaaS.
What is different from enterprise IT
The same three layers: principles, actions and domains. What changes is the work a cloud customer can do itself.
| Topic | Enterprise IT | Cloud |
|---|---|---|
| Environment | On-premises, hybrid or IaaS | SaaS and PaaS only |
| Principles | 28 | 30: the same 28, plus GOV-09 and PRO-08 |
| Domains | 8 | Same 8 names, 5 rewritten |
| Who does the work | Not marked | Letters on nearly every action |
| Scoping help | Enterprise IT scoping guide | Cloud scoping guide |
Two service models
PaaS Platform-as-a-service
You build and run your own apps on a platform the provider runs.
One of ASD's examples An entity that runs a public digital service on a managed app platform and managed database.
SaaS Software-as-a-service
Finished apps you sign in to. The provider runs everything underneath.
One of ASD's examples A small Commonwealth entity or statutory body running on a cloud productivity and collaboration suite, a records or case system and a few connected SaaS apps.
PaaS customers keep extra jobs: securing what they build, patching what they deploy and segmenting the environments they set up. Unsure which you have? See services that sit between models.
Two letters for who does the work
You share security work with the provider (the shared responsibility model). Nearly every action has one letter for PaaS and one for SaaS.
- C: You do itCustomer. You deliver and run it.
- S: The provider supplies it, you set it upSupplied. You switch it on, set it up and run it.
- P: The provider does itProvider-inherited. You check the evidence.
ASD says the letters show the most common pattern, not a rule, so confirm the split for each service. See also outsourced services.
Four actions and their letters, quoted
| Action | PaaS | SaaS |
|---|---|---|
| Identify and remediate vulnerable third-party libraries and dependencies before deployment and on an ongoing basis. PRO-01 Secure system lifecycle | C | P |
| Harden development pipelines and their credentials, restricting who can approve and deploy changes to production. PRO-01 Secure system lifecycle | S | P |
| Use phishing-resistant MFA for users authenticating to systems. PRO-13 Identity, credential and access management | S | S |
| Isolate backup repositories from production cloud environments through separate accounts, subscriptions or tenants with independent access controls, preventing unauthorised modification or deletion. PRO-10 Regular and proven backups | C | C |
ASD, Essentials for cloud, Matrix 3
Reading each row
- Vulnerable code libraries. Yours in PaaS (C), because you choose and deploy the code. In SaaS the provider runs the code, so the work is inherited (P).
- Development pipelines. Supplied in PaaS (S): you switch on, set up and run what the provider supplies. Inherited in SaaS (P).
- Phishing-resistant multi-factor authentication (MFA). Supplied in both (S). It is not effective until you switch it on, set it up and use it consistently.
- Backups kept apart from production. Yours in both (C).
One action in the chapter has no letters: the Content filtering (PRO-09) action on checking outbound flows from cloud services for unauthorised transfer of data.
A register of who does what
The chapter asks you to write the split down:
From the Governance and culture matrix, quoted
- Shared responsibility arrangements for cloud services are understood, documented and incorporated into security risk management activities.
- Maintain a register of inherited and retained security responsibilities per provider, and review it as services change.
ASD, Essentials for cloud, Matrix 1
List what each provider does for you (inherited) and what you keep (retained). For the provider's jobs, you stay accountable for checking they are in place, using current independent assurance recorded in that register. ASD's example is an IRAP assessment (an independent security assessment) that covers the services you use.
Getting started now
Our suggestion, not ASD's list. Codes in brackets are the cloud principles behind a step.
Check the chapter fits
List your services and mark each one SaaS or PaaS.
List every service
Include tenants, integrations and anything nobody approved, and bring them under governance (IDE-01).
Write down who does what
Start a register for each provider of the jobs it does and the ones you keep, and review it as services change (GOV-11, GOV-09).
Switch on what is supplied
Set up and consistently run the features marked S, such as phishing-resistant MFA and provider audit logging (PRO-13, DET-01).
Scope and plan
Place your assets in the eight domains, then follow ASD's Figure 3 order, with the two capability domains from the start.
To plan the wider program, see implementing the Essentials.
What ASD has not published
Frequently asked questions
Answers drawn from ASD's Essentials for cloud and its Asset scoping guide for cloud.
What is ASD Essentials for cloud?
It is the ASD Essentials chapter for organisations whose technology is delivered entirely as software-as-a-service (SaaS) and platform-as-a-service (PaaS). It uses the same three layers as the other chapters (principles, actions and domains), and focuses on areas including identity, data, configuration, applications, integrations and provider assurance.
How is the cloud chapter different from enterprise IT?
It leaves out work a SaaS or PaaS customer cannot do or evidence because the provider does it, such as running servers and networks. It marks nearly every action with who does the work, rewrites five of the eight domain descriptions for cloud and adds two principles: GOV-09 Security risk management responsibilities and PRO-08 Cryptographic protection.
What do C, S and P mean in the cloud chapter?
They are ASD's markers for who does the work on each action: C for Customer, S for Supplied and P for Provider-inherited. The section "Two letters for who does the work" explains each one.
Our cloud provider has an IRAP assessment. Is that enough?
Not on its own. For work marked P, ASD says you stay accountable for confirming it is in place, using current independent assurance such as an IRAP assessment scoped to the services you use. That covers only the provider's part. Work marked C or S is still yours to do.
Are development and test environments in scope?
Yes. ASD says non-production environments, including development, testing and staging, are in scope, placed in domains like any other asset. If one holds production credentials or admin access, or can change or deploy to production, protect it to the same level as production.
Does the cloud chapter cover AI features in SaaS?
Yes. Under executive artificial intelligence accountability (GOV-08), the cloud chapter adds an action: get executive or delegate approval before enabling SaaS or PaaS AI functions. ASD's AI considerations within the Essentials says more about AI in cloud.
Sources
The ASD publications this page explains or points to.
Quoted ASD material © Commonwealth of Australia 2026, licensed under CC BY 4.0.
Everything else on this page is written by Control Stack.