Scoping assets into domains.

At a glance

• Scoping turns ASD's broad domains into a named list of your own systems and assets.

• Place each asset by the role it plays, not by who owns it or what product it is.

• An asset goes in every domain that describes it. An action that applies through two domains is still done once.

• Start small: scope the priority phase 1 domains first, and the two capability domains early. Do not try to list everything at once.

• Write down every decision, including what you left out and why, in a scope statement for each domain.

Why scoping comes first

Each action is rated separately in each domain it applies to, against the assets in that domain. That list of assets is your scope, and ASD says it sets what every later rating covers.

ASD keeps the domain definitions broad on purpose. Your organisation is responsible for making, documenting and justifying its own scoping calls.

Before you start

Your operating context

Before you map any assets, ASD says to write down your operating context. It includes your:

• Regulatory obligations.
• International partnerships.
• Stakeholder expectations.
• Risk tolerance and appetite.
• Resources and funds to improve cyber security.

It shapes calls such as whether a link to another agency is a boundary service, or which processes are critical.

Do not try to list everything at once

Scoping is not a hunt for every asset in the organisation. ASD says to scope only the priority phase 1 domains at first (Boundary services and Identity services), and the two capability domains early. You scope the other domains in later phases, using what you learned.

Start from what you already have: inventories, registers, business impact assessments and architecture documents. You do not need a perfect inventory first. ASD treats visibility gaps as findings to record, not a barrier to starting, because actions in the Visibility and response domain support automated asset discovery and inventory.

Which domain does it belong in?

ASD's practical test is the role an asset plays, not who owns or runs it, or what kind of product it is. ASD gives one question for each of the six technical domains. The two capability domains are scoped differently (see below).

Use the questions as a guide. ASD says to test each asset against every domain, not just the first one that fits. While you scope the phase 1 domains, record any later domain an asset clearly belongs in too, as the register below does for the VPN.

The six technical domains

Each card gives the domain's priority phase, what a compromise could lead to, typical assets and some of ASD's questions.

Boundary services

Priority phase 1

Systems at the edge of your network that pass traffic or data between places with different levels of trust. ASD says these can include internet-facing services, gateways between networks, and links to other agencies, cloud services and operational technology (OT). OT means systems that run physical equipment, such as building controls.

If it is compromised: An attacker can get into your internal network, intercept data, disrupt services for customers or partners, or use it to attack others.

Typical assets

• VPN and other remote access services.
• Routers and switches between the internet and your network.
• Websites, web apps and API endpoints.
• Email gateways.
• Network and web application firewalls.

Boundary services: Questions to help you decide

• Can someone reach it straight from the internet?
• Does it link outside users to your internal environment?

Identity services

Priority phase 1

The services that decide who and what to trust across the organisation: directories, sign-in and authorisation services, federation platforms (which let one sign-in work across organisations or cloud apps) and credential stores such as password vaults.

If it is compromised: An attacker who controls it may be able to pretend to be your users, raise their own access and move between systems.

Typical assets

• Directory and identity platforms, on premises and in the cloud.
• Federation and certificate services.
• Password managers and secrets vaults.
• Systems that create accounts or access rights in other systems, such as an HR system.

Watch out: An app that manages its own users is not an identity service for that reason alone. It counts when a compromise of its identity functions would give an attacker access to other systems.

Identity services: Questions to help you decide

• Does it sign users in to systems other than itself?
• Does it create or remove accounts, or manage roles or identity details (such as job title), that other systems rely on?
• Does it store or hand out passwords, keys or secrets that people or other systems use?
• Does it enforce access policies across the organisation, such as conditional access?

Critical processes and services

Priority phase 2

The core processes and services you need to deliver your main outcomes, or that support the health and safety of your people.

If it is compromised: Your ability to deliver your main outcomes can suffer directly. Attackers may use ransomware or destructive attacks to stop these, or steal valuable information.

Typical assets

• Data stores holding intellectual property or personal information.
• Finance and payment systems.
• Key business applications.
• Email and other key communication platforms.
• Backup and disaster recovery systems.
• Code repositories with critical code.

Watch out: A data store is placed here based on how sensitive or irreplaceable its data is. It remains a business system too if it also supports everyday work.

Critical processes and services: Questions to help you decide

• If it stopped, would you be unable to deliver essential services?
• Is its data unique, sensitive or very costly to rebuild?
• Do many other systems depend on it?

Privileged environments

Priority phase 2

The systems and tools used for high-impact admin work, and the platforms that grant, control and record elevated access.

If it is compromised: An attacker with privileged access can change settings, turn off controls and keep a foothold, while being harder to tell apart from real admins.

Typical assets

• Secure admin and privileged access workstations.
• Privileged identity and access management tools.
• Jump servers.
• Cloud management platforms.
• Admin tools, such as directory and hypervisor consoles.
• Configuration and endpoint management platforms.

Watch out: Having admin accounts does not put a system in this domain. The domain covers the tools used to do admin work, and to grant and control admin access. Actions about accounts and credentials apply in every domain where those accounts exist.

Privileged environments: Questions to help you decide

• Does it let people do admin tasks, or gain more access than standard users?
• Could a compromise give broad control over other assets?

Business systems

Priority phase 3

The everyday systems that keep the organisation running. On its own, each one may not be critical.

If it is compromised: It can be a stepping stone to more sensitive systems. Disruption across several business systems can affect how the organisation coordinates, communicates and does its admin and logistics work.

Typical assets

• Corporate management systems.
• Cloud applications.
• IT service management systems.
• Office productivity apps.
• Collaboration and messaging tools.

Business systems: Questions to help you decide

• Do other teams or processes rely on it staying available?
• Does it connect to other core business systems?

User devices

Priority phase 3

The computers and mobile devices you issue to staff: desktops, laptops, virtual desktops, and phones and tablets your organisation manages.

If it is compromised: An attacker can gain a foothold and move from there through your environment. Phishing and drive-by attacks often start here, and devices are common points where data can leave.

Typical assets

• Desktop computers and laptops.
• Virtual desktops for standard users.
• Phones and tablets your organisation manages.

Watch out: This domain depends on how a device is used, not what kind of device it is (see the laptop example above).

User devices: Questions to help you decide

• Do standard users use it for daily work, such as email and business apps?
• Could a compromise let someone capture passwords, reach internal systems or take data?

Typical assets and questions are a selection of ASD's examples and scoping questions, in our plain words.

The two capability domains

ASD's Asset scoping guide for enterprise IT leaves these two out, because they describe organisational capabilities rather than assets and systems. ASD says their assets are mostly programs and documents, such as security policies, training programs, risk registers and incident response plans. It says to scope both early, expect them to grow as more technical domains come into scope, and record that planned growth in each scope statement.

• 

  Governance and culture

  See its 9 actions in Governance and culture
• 

  Visibility and response

  See its 12 actions in Visibility and response

Assets in more than one domain

Many assets play more than one role. Record each one under every domain that describes it. Start with the domain that comes first in the priority phases, and add the later domains' actions as you reach them.

That does not double the work. ASD says an action that applies through two domains is done once. Take a VPN that admins use to reach servers. It sits in Boundary services and Privileged environments. It picks up the extra Privileged environments actions, but an action it already has through Boundary services is not done twice.

How a shared asset is assessed

You do the work once, but each domain is assessed separately against its own assets and risk context. So the same action on a shared asset may be rated differently in each domain. Assessing a domain explains how.

Tricky cases

Non-production environments

Development, test and staging systems are in scope too. ASD says to place them in domains like any other asset. Look at what they do and connect to, the data and access rights they hold, and how they could affect production.

Does your organisation run more than one business?

It is tempting to make each division, brand or subsidiary a domain. ASD says domains split an environment by function, not by business structure. A business unit may be an environment of its own instead: its own set of IT systems, split into the six technical domains.

Business A environment

Its own six technical domains

Business B environment

Its own six technical domains

Shared function, scoped once: for example one identity service used by both businesses. Its scope statement covers both environments and names them.

Scope each domain separately in each environment, and follow the phase order within each one. Report each environment's security posture, plus a combined view for the parent organisation.

ASD adds three cautions:

• A shared function typically has a higher consequence of compromise, so reflect that when you prioritise within a phase.
• The combined view should not hide a weak domain in any one environment.
• Business units with different risks or regulatory obligations should each keep their own operating context and priorities.

Cloud and OT

This page covers enterprise IT. ASD's separate Asset scoping guide for cloud uses the same rule and adds cloud items, such as tenant settings and personal devices. OT has its own chapter. Our chapter guide helps you choose between enterprise IT and cloud.

A scoping workshop

ASD gives a repeatable method to run for each domain. It keeps your decisions consistent and produces the records the gap analysis and assessment need.

Record your decisions

The workshop ends with a version-controlled scope statement for each domain. ASD says it lists:

• The assets in scope, grouped by asset category.
• What you left out, with the reason.
• Assets that sit in more than one domain.
• Gaps in your asset visibility.

Our suggestion: a simple scoping register

ASD does not set a format. A spreadsheet with one row per asset is enough, or add columns to the asset register you already have. Include each asset's category, because ASD's scope statement groups assets by category. The owner column is for follow-up only; it does not decide the domain.

How an assessor will use it

ASD says an assessor should, where possible, start from your existing scope and check that it is accurate, complete and current. Assessing a domain explains what happens to any gaps.