Understand
Which Essentials chapter applies to you?
The ASD Essentials comes in chapters, one for each kind of technology environment: enterprise IT, cloud and operational technology (OT). This guide explains who each chapter is for, how to pick where to start and what order to work in.
Reviewed 17 October 2026 · Current to ASD's "Which chapter should I start with?" and the cloud and OT chapters, published 15 October 2026
At a glance
ASD has three chapters today: enterprise IT, cloud and operational technology (OT). More may follow.
You may need one chapter or several, and there is no set order for working through them.
ASD gives four questions to pick a starting point: what you operate, what you must do, where the gap is and where the risk is.
Choosing between enterprise IT and cloud? If you run on-premises, hybrid or rented (IaaS) infrastructure, ASD says enterprise IT is the ideal start. If you mostly use cloud apps or platforms (SaaS or PaaS) and need a clear split of security jobs with the provider, start with cloud.
Using a provider does not hand over your accountability for security outcomes.
The three chapters
A chapter is the Essentials written for one kind of technology environment. The chapters are not separate frameworks. Each principle (an outcome to achieve) keeps its intent across chapters, and the domains (the business functions and assets the work applies to) stay the same. What can change is which principles apply, the actions, which assets sit in each domain and the order of the domains. Our overview explains how the three layers fit together.
For organisations that run their own technology: on-premises, hybrid or infrastructure-as-a-service (IaaS).
- You look after the operating systems, applications, identity infrastructure and network architecture.
- Running some of it on another party's infrastructure does not materially change what you must do.
- 28 principles, 58 actions and 8 domains. The six technical domains are grouped into three priority phases.
- Covered in full on Control Stack.
Essentials for cloud
For organisations whose technology is delivered entirely as software-as-a-service (SaaS) and platform-as-a-service (PaaS).
- Leaves out work the provider does for you, such as running servers and networks.
- Focuses on identity, data, configuration, applications, integrations and provider assurance.
- Uses the same domain names, and has its own asset scoping guide.
Essentials for OT
For operators of operational technology (OT): systems that monitor or control physical equipment and processes.
- Its principles apply to all OT, from simple automation to large critical infrastructure systems. Its target audience includes operators of complex control, automation and safety systems in critical service sectors.
- Puts safe operation first, so it orders the domains differently.
Control Stack covers the enterprise IT chapter. For cloud and OT, use ASD's own publications, listed under Sources.
Four questions to choose your chapter
ASD asks four questions to find your starting point. Weigh the answers together. We work through them with one example: a regional water utility with 250 staff.
Question 1: What do you operate?
List the technology environments you run or manage, what each does for the business and what it holds. ASD says a sufficient overview is enough, not a full asset discovery exercise.
Where environments connect, note where they meet. ASD warns that a compromise in one often opens a path into another.
The utility It lists three environments: its office network and staff sign-in (enterprise IT), the treatment plant's control systems (OT) and a cloud billing system (cloud). It notes where they meet: a link that lets engineers reach the plant from the office network, and a vendor's remote access link into the plant.
Question 2: What are you required to do?
Laws, contracts and sector rules often point at a particular environment. Some obligations require you to show a specific level of security for a defined environment. If one of yours does, the chapter for that environment is a logical place to start.
Weigh obligations together with the two risk questions below, not instead of them. In ASD's words, "an obligation establishes a floor, not a priority order."
The utility Suppose a customer contract asks the utility to show how it protects the plant's control systems. That makes the OT chapter a logical start. But the contract sets only a minimum, not the order of the work.
Question 3: Where is the biggest gap?
Compare each environment today with the outcomes its principles describe. One that has had years of investment may need less work than one that has not.
ASD gives OT as a common example of a large gap. But ASD says a large gap is not, by itself, a reason to start there. Weigh it with consequence and likelihood.
The utility The utility's office network has had steady upgrades. The plant controllers are 20 years old and cannot be patched without stopping treatment. The OT gap is bigger, but that alone does not settle it.
Question 4: Where is the greatest risk?
For each environment, ask two things: how bad would a compromise be (the consequence), and how likely is one (the likelihood)?
Likelihood rises when an environment is reachable from the internet, has many users, has unclear access controls or is known to be targeted across your sector. It is lower when it is isolated and few people can reach it.
- If OT is compromised
- Staff safety, physical processes or an essential service could be affected.
- If enterprise IT is compromised
- Sensitive data could be lost, operations disrupted, or the identity systems that control all access lost.
- If a cloud environment is compromised
- It could expose data you hold with a provider, or the admin consoles that control your services.
- High consequence, lower likelihoodASD says: Write the position down and review it. New connections, remote access or integrations can change the risk.
- High consequence, higher likelihoodASD says: Give it attention first.
- Lower consequence, lower likelihoodOur suggestion: It can usually come later. Record why.
- Lower consequence, higher likelihoodOur suggestion: Weigh it with your obligations and gaps.
| Lower likelihood | Higher likelihood |
|---|---|
| High consequence | |
| ASD says: Write the position down and review it. New connections, remote access or integrations can change the risk. | ASD says: Give it attention first. |
| Lower consequence | |
| Our suggestion: It can usually come later. Record why. | Our suggestion: Weigh it with your obligations and gaps. |
The utility A plant compromise could stop safe drinking water, a severe consequence. The vendor's remote access link raises the likelihood. The office network faces the internet and every staff member uses it, so its likelihood is high too.
Our suggestion
Putting it together for the utility
The plant has the most severe consequence, the contract points at it and the vendor link raises its likelihood. So the utility could start with the OT chapter for the plant. Enterprise IT runs alongside for the office network, whose likelihood is high too, with the links between them treated as Boundary services. The billing system is scoped into that enterprise IT work, and the cloud chapter can follow, with the reasons written down.
Choosing between enterprise IT and cloud
ASD says the choice between these two chapters depends on the services you use and how much of the technology underneath you control.
Enterprise IT chapter
On-premises
Your own servers and network, in your own building or data centre.
- Apps: you run it.
- Operating systems: you run it.
- Hardware: you run it.
Infrastructure-as-a-service
Rented virtual servers and networks that you set up and run yourself.
- Apps: you run it.
- Operating systems: you run it.
- Hardware: the provider runs it.
Hybrid means a mix of your own on-site servers and cloud services.
Cloud chapter
Platform-as-a-service
A managed platform you build and run your own apps on.
- Apps: you run it.
- Operating systems: the provider runs it.
- Hardware: the provider runs it.
Software-as-a-service
A finished app you sign in to, such as online email or payroll.
- Apps: the provider runs it.
- Operating systems: the provider runs it.
- Hardware: the provider runs it.
In every model, your data, who can sign in and how the service is set up stay your job.
Start with enterprise IT if
- You run on-premises infrastructure, a hybrid environment or IaaS.
- You manage the operating systems, apps, sign-in systems and network yourself. Some of it may run on someone else's hardware.
ExampleA 300-person council runs its own directory and file servers, some rented virtual servers and about 20 SaaS apps. That is hybrid, so it starts with enterprise IT. Its SaaS apps are in scope from the start: ASD's enterprise IT scoping guide lists cloud applications as example assets for the Business systems domain. Later it adds the cloud chapter, for the split of security work with each provider.
Start with cloud if
- You mostly use PaaS or SaaS, and need a clear split of which security jobs are yours and which are the provider's.
The cloud chapter itself is written for technology delivered entirely as SaaS and PaaS. ASD sets no exact line between mostly cloud and hybrid. ASD calls enterprise IT the ideal start for hybrid organisations, because they still look after their own operating systems, apps, sign-in systems and network. If that describes you, start with enterprise IT.
ExampleA 40-person charity runs everything in a SaaS office suite and a SaaS donor system. It has no servers. It starts with cloud.
Most organisations will need both chapters over time. The question is which to begin with, not which to adopt.
Not sure which service model you have?
Few environments fit one model neatly. The cloud chapter gives two pointers.
- SaaS that behaves like a platform. Some SaaS lets you build things, such as low-code apps, scripts or private networking. If you use these heavily, ASD says to apply the cloud chapter's PaaS approaches to them.
- PaaS that behaves like infrastructure. If a platform gives you direct control over computing or networking, you are close to IaaS. ASD says to consider whether the enterprise IT chapter fits your responsibilities better.
Service model boundaries are a matter of degree, and organisations should make a considered judgement about what they actually operate rather than what the procurement label says.
Our suggestion
A little OT still counts
ASD says the OT chapter's principles apply to all OT, from simple automation to large critical infrastructure systems. So if you have some plant equipment or building controls, list them as their own environment when you answer the four questions. Note where they connect to your network. Then aim for the OT chapter's principles there, using its actions where relevant, even if most of your work starts in enterprise IT or cloud.
Sequencing the work
Each chapter groups its domains into priority phases: ASD's recommended order for the domains, chosen to cut the most risk, fastest. The phases are a sequence, not a rating, as our overview of the ASD Essentials explains.
An organisation working at an early phase is not operating at a lower standard than one working at a later phase; it is at a different point in the same program of work.
Why ASD chose this order
- How attackers work. Domains attackers most often use to get in and move towards valuable assets come first.
- Where controls are weakest. Gaps that are common and often exploited across Australian organisations raise a domain's priority.
- What can be done quickly. Domains with mature, widely available solutions can often be done faster, and lay a foundation for the rest.
Same domains, different order
The OT chapter changes the order because OT puts the safe, continuous running of physical processes first. It also leaves User devices out, as the note under its order explains. Compare the two:
Essentials for enterprise IT
Across all phases: Governance and culture, and Visibility and response
Essentials for OT
- Boundary services
- Critical processes and services
- Privileged environments
- Identity services
- Business systems
Across all phases: Governance and culture, and Visibility and response
User devices: not in the OT technical mapping, because the OT chapter treats every device inside the OT system as privileged.
Changing the order
ASD calls its order "a starting position, not a constraint". It gives these examples of valid reasons to change it:
- Threat intelligence shows a later domain is being actively targeted.
- A law or contract needs certain capabilities in place first.
- A technology refresh, system replacement or current project makes it efficient to do a domain sooner.
- You have already made strong progress in the early domains, so more risk falls by focusing elsewhere.
Example. A hospital will replace every staff laptop next year. In enterprise IT, User devices sits in priority phase 3. The hospital brings that work forward to match the refresh, and records why.
If you change the order, keep three things in mind.
- Write down why. ASD says this helps you explain the order to executives, boards or regulators, and adjust it later.
- Later domains still need doing. A new order changes only what comes first, not the total work.
- Start the capability domains early. ASD says the two capability domains, Governance and culture, and Visibility and response, should be set up early and strengthened over time.
Report by domain, whatever the order
Whatever order you follow, ASD says to measure and report by domain, so a gap shows which part of the organisation is exposed. If a domain comes later in your order and you have not assessed it yet, report it as not assessed. Keep that clearly apart from a domain you assessed and found lacking. Our assessment guide explains how domain scores work.
Outsourced services and managed service providers
ASD is clear: paying a managed service provider, cloud provider or vendor to host, run or support a system does not hand over your accountability for its security outcomes.
What stays with you
Know who does what. Be clear which security jobs are the provider's and which are yours.
Get current evidence. Collect enough evidence that the provider is doing its part, and keep it current. Promises made at contract signing are not enough on their own.
Own any gap. If a job is not done, or you cannot show it is, the risk is yours. Work out its impact, then see whether the provider, another safeguard or a change to the arrangement can close it. If you cannot fully close it, document the remaining risk, formally accept it and review it regularly.
Switch it on, and report by domain. A security feature you have not enabled or configured is a job not done. Record outsourced gaps against the relevant domain, as for your own systems.
Example. The 300-person council pays a managed service provider to run its firewalls and remote access (the Boundary services domain). It asks for current patch reports rather than trusting the contract. It also finds that the portal contractors use for remote access offers multi-factor sign-in, but the council never switched it on. It records that gap against Boundary services.
A domain should not be considered effective, simply because responsibility for it has been assigned to a third-party.
How the cloud chapter marks who does what
In SaaS and PaaS you share security work with the provider (a shared responsibility model). The cloud chapter gives each action two letters, one for SaaS and one for PaaS. Each is one of these three.
C, Customer
You do it.
You deliver and run it, and are assessed on it as you run it.
S, Supplied
The provider supplies it. You switch it on and run it.
You must enable, configure and run it consistently, and all parties need to agree what the provider is accountable to supply. A feature left at an insecure default, or applied inconsistently, is not yet effective.
P, Provider-inherited
The provider does it. You check.
You stay accountable for checking it is in place, using current independent assurance.
Frequently asked questions
Common questions about choosing and sequencing the Essentials chapters, answered from ASD's publications.
We run some servers and also use cloud apps. Which chapter comes first?
It depends on the mix. ASD says enterprise IT is the ideal start for a hybrid environment, where you still look after your own operating systems, apps, sign-in systems and network. Starting there does not leave your cloud apps out, because ASD's asset scoping guide for enterprise IT lists cloud applications as example business systems. If you mostly use cloud apps and platforms (SaaS or PaaS) and need a clear split of security jobs with each provider, ASD says start with cloud. That chapter is written for organisations that run no infrastructure of their own. Most organisations will need both chapters over time.
If a provider runs the system, is its security still our responsibility?
Yes. ASD says outsourcing a service does not transfer accountability for its security outcomes, and the section on outsourced services lists what stays with you.
Can a small business use the Essentials?
Yes. ASD writes the Essentials mainly for Commonwealth entities, critical infrastructure and large organisations, but says smaller businesses can still use it where relevant. The outcomes matter just as much. What differs is how you achieve them and how much sits with providers and vendors. ASD also publishes separate guidance for small businesses.
Sources
The ASD publications this page explains. ASD's Essentials reading guide shows how the series fits together. ASD also publishes asset scoping guides for the enterprise IT and cloud chapters, and an Essentials glossary.
- Which chapter should I start with? (on cyber.gov.au)
- Frequently asked questions (on cyber.gov.au)
- Essentials reading guide (on cyber.gov.au)
- What is the Essentials? (on cyber.gov.au)
- Essentials for enterprise IT (on cyber.gov.au)
- Essentials for cloud (on cyber.gov.au)
- Essentials for OT (on cyber.gov.au)
- Asset scoping guide for enterprise IT (on cyber.gov.au)
- Asset scoping guide for cloud (on cyber.gov.au)
- Essentials glossary (on cyber.gov.au)
- Assessment process guide (on cyber.gov.au)
Quoted ASD material © Commonwealth of Australia 2026, licensed under CC BY 4.0.
Everything else on this page is written by Control Stack.