ASD Essentials

ASD Essentials overview: The Essentials for senior executives

Executive summary

Australian organisations continue to face cyber threats from increasingly capable malicious cyber actors. State-sponsored actors remain a serious threat, while cybercriminals and other malicious actors use a range of techniques to gain access, escalate privileges and disrupt operations. Cyber threats affect organisations across all sectors, regardless of size or profile. For decision-makers, the consequences go beyond technology systems to operational continuity, reputation and compliance with legal, regulatory and contractual obligations.

The Essentials ensures consistent foundations are applied to cyber security as technologies change. Evolution in artificial intelligence is a modern example: the framework can be used whether an organisation consumes, develops or deploys AI (see AI considerations).

The Australian Signals Directorate's Australian Cyber Security Centre (ASD's ACSC) developed ASD Essentials as an evolution of the Essential Eight to help organisations direct cyber security investment towards the areas of greatest need. Through a prioritised, outcome-focused approach, it guides organisations in sequencing their efforts to protect critical functions, reduce risk earlier, and scale improvements across enterprise IT, cloud and operational technology environments.

For senior executives, three key aspects are relevant:

1. Posture reporting gives greater visibility. Rather than a single maturity level, posture is reported by domains: groupings of business functions and assets that share similar risks. Domains can be prioritised, so the most critical assets are protected first.
2. Existing Essential Eight investment remains valuable. The framework builds on the Essential Eight rather than replacing it. See Transitioning from the Essential Eight.
3. Executive accountability is more explicit. Greater emphasis on formal executive and board-level accountability, including oversight of organisational risk, investment and resourcing. See Executive oversight.

ASD Essentials overview: The Essentials for senior executives

The ASD Essentials series framework

The Essentials shows what to protect, how to protect it, and where to begin. It is a modern, principles-based approach to cyber security for Australian organisations, designed to be future-focused, flexible, compatible and threat-informed.

Why it matters to leaders

Implementation journey

1. Understand: context, risks and obligations.
2. Select: relevant priorities and domains.
3. Plan: activities, investment and sequencing.
4. Implement: actions that achieve outcomes.
5. Assess and report: effectiveness and improvement.
6. Sustain: maintain, reassess and refine.

Separate chapters cover different technology environments: Enterprise IT, Operational Technology and Cloud. The series builds upon investments made under the Essential Eight.

ASD Essentials overview: The Essentials for senior executives

Purpose and the publication suite

This guidance helps senior executives understand the framework and the role they play in its successful implementation. It outlines key considerations for governance, investment, risk management, reporting and oversight, and identifies the questions decision-makers should ask before approving investment and throughout implementation.

ASD Essentials overview: The Essentials for senior executives

Benefits of the ASD Essentials series

The series gives organisations a clear view of what to protect, what outcomes to achieve and where to begin. Each chapter uses the same principles, actions and domains model, supporting a consistent approach across technology environments.

• Priority phases help organisations sequence technical implementation in a prioritised, risk-informed manner rather than uplifting the entire environment at once.
• Actions describe what must be achieved without prescribing a vendor, product or architecture.
• Existing Essential Eight controls can contribute to actions where they achieve the required outcomes.
• Reporting by domain gives decision-makers clear visibility of effective outcomes, outstanding gaps and priorities for investment or risk treatment.
• Each chapter uses the same principles, actions and domains model.

Priority phases set out the order in which ASD recommends domains be addressed, reflecting where effort delivers the greatest and most rapid reduction in risk.

ASD Essentials overview: The Essentials for senior executives

Improved visibility of security posture: domains and risk

Domains organise cyber security around business functions and the assets that support them. By grouping areas with similar risks, they let organisations prioritise where effort has the greatest impact. Reporting posture by domain gives clearer visibility of strengths, weaknesses and risk exposure. The table below summarises the enterprise IT domains.

Priority phases for enterprise IT: Phase 1 is Boundary and Identity services; Phase 2 is Critical processes and services and Privileged environments; Phase 3 is Business systems and User devices. Governance and culture, and Visibility and response, apply across all phases. See the enterprise IT chapter.

ASD Essentials overview: The Essentials for senior executives

Transitioning Essential Eight investment

Existing Essential Eight investment remains valuable. Many controls contribute to actions in the series chapters, but organisations should assess those controls against the new framework rather than assume they are equivalent.

For example, organisations that invested in multi-factor authentication (MFA) can build on that capability. The series continues to recognise MFA as important, while also addressing a broader range of identity-related risks.

Organisations should identify which existing controls meet or contribute to applicable actions, where controls need to be extended and where new capability is required. Detailed guidance is in Transitioning from the Essential Eight.

ASD Essentials overview: The Essentials for senior executives

Executive oversight of implementation

Cyber security requires ongoing governance, investment and sustainment. The framework supports a continuing program that aligns governance, architecture, operations and resourcing with organisational risk.

It strengthens executive oversight by requiring clear accountability at executive and board levels. It encourages organisations to define their cyber security risk appetite and ensure sufficient people, funding and resources to implement, maintain and continuously improve security over time. These requirements apply across all priority phases, so implementation and sustainment should be considered together as an ongoing capability.

ASD Essentials overview: The Essentials for senior executives

What senior executives should expect

• A clear understanding of the sequencing model. Priority phases recommend implementation order. They are not maturity ratings and do not indicate assurance. Saying 'we have reached priority phase 2' describes scope, not how secure the organisation is. Posture is expressed through effectiveness ratings.
• Formal executive and board-level accountability, including responsibility for setting, monitoring and adjusting risk appetite.
• Alignment with operating context: regulatory obligations, critical functions, stakeholder expectations, risk appetite and resources.
• A current-state baseline. Assess applicable actions in relevant domains and identify gaps, including existing Essential Eight investments.
• Realistic implementation and sustainment expectations. It is not a one-time activity. There is no completion date for effective cyber security.
• Sustainable resourcing. Funding proposals should distinguish implementation, ongoing operation and assessment or assurance costs.
• Evidence of effectiveness. Claims should be supported by evidence, validated through simulated exercises and independent testing where appropriate.
• Clear reporting arrangements: assessed posture, material gaps, remediation progress, accepted risk and domains not assessed.
• Continued regulatory compliance during the transition, following any direction from relevant regulators.

ASD Essentials overview: The Essentials for senior executives

Questions senior executives should ask

Ask these when considering an implementation proposal and revisit them as the program progresses. The answers should inform investment decisions, risk acceptance and reporting.

• Which of our key functions and assets sit in each domain, and which domains hold the assets whose compromise would be most consequential?
• What did our Essential Eight investment buy us under the framework, and what is genuinely new work, such as governance principles and expanded detection and response?
• When will we see the first posture report, what will it cover and what will be reported as not assessed? Are the reasons justified?
• What specific risk reduction do priority phase 1 investments provide? Which observed attack paths does hardening those domains disrupt for us?
• Where does the plan depart from ASD's recommended sequencing, and what is the documented, risk-based justification?
• How will effectiveness be validated, and will independent assessment or adversary-simulation testing be used, and on what cycle?
• What are the ongoing operational costs and resourcing needs once priority phase 3 is reached, and how will resourcing be reviewed against threat trends and incident outcomes?
• How are exceptions, compensating controls and accepted risks governed? Who owns them, when do they expire and when are they re-approved or closed?
• What disruptions to operations and user experience are anticipated during implementation, and how will they be managed?
• How will we continue to meet current regulatory reporting obligations during the transition?

These are not exhaustive. Considered well, they turn the framework into a well-governed, strategic investment rather than a compliance exercise.

ASD Essentials overview: The Essentials for senior executives

Conclusion

The framework gives senior executives a structured way to oversee cyber security investment, implementation and sustainment. Priority phases help sequence effort, while assessment by domain shows where security outcomes are effective and where material gaps remain.

Existing Essential Eight investment continues to provide a foundation, but should be assessed against the applicable principles and actions in the relevant chapter. Effective implementation now requires clear accountability, sustained resourcing, evidence of effectiveness and reporting that enables executives to understand and manage cyber security risk.

Transitioning from the Essential Eight

Purpose and the transition principle

ASD has evolved the Essential Eight into the ASD Essentials for enterprise IT to address contemporary threats and modern enterprise environments. Essential Eight investment remains valuable, but the new chapter describes, scopes and assesses outcomes differently and often applies existing controls more broadly.

This guidance explains how each Essential Eight strategy maps to principles and actions, where controls and evidence can be reused, where they may need strengthening, and a recommended transition approach. It is for security architects, program leads, CISOs, assessors and executives. Organisations that have not implemented the Essential Eight can implement the enterprise IT chapter directly.

Transitioning from the Essential Eight

Why existing controls may need strengthening

• Principle breadth. Many strategies map to principles with a broader outcome. For example, Restrict Microsoft Office macros contributes to the broader Trustworthy software principle; it addresses only part of controlling software execution.
• Domain scope. The Essential Eight applied across the whole IT environment; actions are now implemented and assessed in each applicable domain. A control fully effective in one domain may be only partially effective in another.
• Evidence. Existing configuration and deployment records show how a control is implemented. Assessors also consider coverage, consistency, currency and evidence quality, so deployment records may need operational evidence of sustained effectiveness (validation testing, exercises, monitoring records).

Transitioning from the Essential Eight

Key concepts translated

Transitioning from the Essential Eight

What is new

Governance and risk management

The Governance and culture domain adds principles for executive cyber security accountability, cyber security resourcing, security risk management assurance, supplier cyber security assurance, artificial intelligence accountability and legacy system management. These were not assessed in the Essential Eight maturity model.

Asset and risk identification

Asset identification extends beyond Essential Eight discovery: infrastructure, operating systems, applications, identities, credentials and data must be identified as distinct assets, alongside threat-informed risk assessment.

Expanded and new protect principles

• Identity, credential and access management covers MFA plus accounts, credentials, authentication protocols and credential storage.
• Application control and macro restrictions contribute to broader Trustworthy software and Secure configuration management requirements.
• New principles with no direct equivalent: Content filtering, Cyber security awareness training and Cyber supply chain security.

Visibility and response

Logging, monitoring and incident response requirements that sat inside individual strategies are brought together in the Visibility and response domain, with principles for event logging, detection, incident identification, detection efficacy, incident coordination, response and post-incident insights. It applies across all phases and expands as technical domains are implemented.

Transitioning from the Essential Eight

Considering existing maturity levels

Maturity level ratings do not convert automatically. Previous implementation is a useful baseline and higher maturity may reduce transition effort, but every organisation still assesses each action in each applicable domain.

Organisations at Maturity Level Two

Many controls will contribute to early priority phases, such as phishing-resistant MFA, patching internet-facing services, privileged access, application control and centralised logging. Do not assume actions are fully effective in every domain. Likely extra work: extending controls to assets or domains not previously covered, addressing Governance and culture, expanding Visibility and response, and producing evidence of sustained effectiveness.

Organisations at Maturity Level Three

A broader range of controls and evidence is reusable (vulnerability management, application control, privileged access, event logging, configuration hardening, restoration testing). However some actions have no direct equivalent, including credential exposure, supply chain security, domain-based implementation and the two capability domains, so a gap analysis remains necessary. Maturity Level One organisations can use the same approach but should expect more actions to need implementation.

Organisations undertaking an Essential Eight program

Begin transitioning without discarding completed work. Map controls, evidence and results to the relevant actions, fold in planned work that remains relevant, and use priority phases to focus remaining investment. Continue to meet any regulatory or contractual Essential Eight obligations.

Transitioning from the Essential Eight

Strategy-by-strategy transition mapping

The enterprise IT chapter remains the authoritative source for requirements. Confirm that existing controls and evidence remain current before relying on them.

Transitioning from the Essential Eight

Reusing existing assessment evidence

Organisations assessed against the Essential Eight may hold assessment reports, configuration extracts, ruleset exports, control test results, logging architecture, exception registers, risk registers and remediation plans. Reuse them where current and relevant. Deployment evidence shows what is implemented, but deployment alone does not demonstrate effectiveness.

Stronger support comes from evidence of operation over time: validation results, monitoring records, configuration drift reports, review records, restoration tests, exercises and detection engineering artefacts. If evidence is current, reliable and comprehensive, new evidence is not needed simply because it was collected for another framework. Review exceptions, compensating controls and accepted risks too: expired or outdated ones should not be relied on. See Collecting evidence.

Transitioning from the Essential Eight

Recommended transition pathway

1. Establish the transition baseline. Record the current Essential Eight position: latest assessment, controls, exception and risk registers, remediation plans and planned uplift. Do not start work solely to hit a superseded target unless a regulator requires it or it addresses material risk.
2. Scope the priority phase 1 domains: Governance and culture, Visibility and response, Boundary services and Identity services. Reuse existing inventories and documentation, and include multi-domain assets in each relevant domain.
3. Conduct a gap analysis. Classify each action as already effectively addressed, partially addressed or not addressed. These are findings, not formal ratings.
4. Plan implementation. Use a domain-focused approach for domain-specific gaps; design cross-domain capabilities once and apply them in phase order.
5. Deliver and measure. Prepare for assessment as controls are delivered, considering coverage, consistency, currency and evidence quality. Document gaps and remediation for partially effective ratings.
6. Progress through the phases. Phase 2: Critical processes and services, and Privileged environments. Phase 3: Business systems and User devices. Governance and culture, and Visibility and response expand across all phases. Set a reassessment cadence.

Reporting during transition

Use the reporting approach in the Assessment process guide. Report unassessed domains or actions as not assessed, which does not imply ineffective. Where a regulator still requires Essential Eight terminology, continue to meet those obligations.

Transitioning from the Essential Eight

Common transition pitfalls

• Treating priority phases as maturity levels. They sequence implementation; they are not maturity, compliance or assurance ratings.
• Claiming equivalence instead of assessing. A previously compliant control is evidence, not an automatic rating.
• Assessing the enterprise instead of the domain. Enterprise-wide implementation does not guarantee the same rating in every domain.
• Ignoring the capability domains. Governance and culture, and Visibility and response, apply across all phases and should not wait for technical domains.
• Attempting to transition every domain at once. Use priority phases to focus effort while maturing the two capability domains.
• Reusing stale evidence. Only where it still represents the current environment.
• Overlooking new requirements. Some actions have no Essential Eight equivalent and need planning and resourcing.

Implementation planning guide

Purpose, audience and planning considerations

This supplemental guide turns the Essentials requirements into an implementation strategy: securing executive commitment, defining scope, identifying gaps, planning and delivering remediation, preparing for assessment and sustaining outcomes. The roadmap runs: Executive commitment, then a cycle of Scoping assets, Gap analysis, Plan implementation and Deliver and measure (with Reuse at the centre), then Sustain. It is written for security architects, program leads and CISOs, and uses enterprise IT for examples but applies to any chapter. Read it with the Assessment process guide and, for Essential Eight organisations, Transitioning from the Essential Eight.

• Plan around ASD's priority phases, not the whole chapter at once. Define scope, costs and delivery for phase 1 domains, and treat later phases as forward plans refined by lessons learned.
• Design for assessment from day one. Assessments focus on effectiveness. Build ongoing assurance, monitoring and documentation as controls are implemented; reconstructing evidence later causes rework.
• Design capabilities once as patterns. Many capabilities apply across domains; build them as repeatable patterns applied in phase order.

Implementation planning guide

Securing executive commitment

The framework makes the executive role explicit. Under Executive cyber security accountability, the board or executive committee is accountable, including setting, monitoring and adjusting risk tolerance and appetite. Security risk management assurance and Cyber security resourcing are monitored by the same body. Executive commitment is assessable content within Governance and culture. See Executive oversight.

The need for change

• The threat environment has changed. Highly capable adversaries now pose a credible threat to a broader range of organisations, so the series applies sophisticated tradecraft threat modelling across all principles, actions and chapters.
• Existing investment is carried forward. Every Essential Eight strategy maps to at least one principle; prior investment is redirected and extended, and evidence from other frameworks can be reused.
• Measurable progress shows early. Early phases focus on domains where actions disrupt commonly observed tradecraft.

Structuring the business case

Structure the investment ask in tranches that mirror priority phases, so every element traces to something the executive can later see reported. Cost each tranche as capability build, operating uplift and assessment. Capability build declines as early patterns (logging, baselines, authentication) are reapplied; operating uplift grows as more environments enter sustainment; assessment stays broadly steady.

Anticipating executive questions

Reporting commitments

• The standard reporting format organised by priority phase and domain.
• A domain-level radar view for board reporting, overlaid across successive assessments.
• The detail view of partially effective and not effective principles with remediation, so visible progress does not obscure outstanding risk.
• Honest use of not assessed as a neutral status, distinct from not effective.

Implementation planning guide

Scoping domain assets

Scoping translates broad domains into named systems and assets engineers can harden and assessors can examine. The scope statement establishes what counts as coverage for each later rating, so each organisation must make, document and justify its scoping decisions.

Start with operating context

Record regulatory obligations, international partnerships, stakeholder expectations, risk tolerance and appetite, and available resources before mapping assets. Context informs decisions such as whether an interagency connection falls under Boundary services.

Place assets by role, not owner

Non-production, business units and limits

• Include non-production environments (development, testing, staging). Where one holds production trust or administrative access, or can connect to or deploy to production, protect it equivalently.
• Functions, not business units. Domains decompose an environment by function. A parent organisation with two businesses scopes domains per environment and scopes shared functions (common identity, shared gateway, shared security operations) once, then reports each environment with a consolidated parent view that does not mask weaknesses.
• Scoping is not enterprise-wide asset discovery. Initially scope only phase 1 domains. Imperfect visibility is a finding to record, not a barrier, because Visibility and response includes asset discovery actions.
• Start with six asset categories: infrastructure, operating systems, applications, identities, credentials and data.

A workshop method for scoping

1. Assemble the evidence base: configuration database extracts, network and identity architecture, business impact assessment, internet-facing service registers, cloud tenancy inventories.
2. Identify candidate assets in each category. For Identity services: domain controllers and federation servers; directory and certificate authority applications; user, privileged, service and machine accounts; keys and tokens; directory databases, trust metadata and audit logs.
3. Test against the domain definition and consequence of compromise. Record every inclusion and exclusion with a brief rationale.
4. Resolve multi-domain assets. Document against each relevant domain, applying the earliest-phase actions first. An internet-facing customer app may sit in Boundary services (phase 1) and Critical processes and services (phase 2).
5. Baseline the scope statement: a version-controlled statement per domain listing in-scope assets by category, exclusions with rationale, multi-domain assets and visibility gaps.

Scoping the two capability domains

Governance and culture covers strategies, policies, procedures, training programs, roadmaps and risk registers. Visibility and response covers asset registers, incident response plans and detection and response platforms. Scope both early and record their intended growth through later phases.

Implementation planning guide

Conducting a gap analysis

Gap analysis determines whether existing controls address the applicable actions for scoped assets and defines the remaining work. It does not assign effectiveness ratings. Instead each action is classed, domain by domain, as:

• Addressed: no work identified; document controls and evidence so effectiveness can be assessed later.
• Partially addressed: document gaps in scope, consistency or enforcement.
• Not addressed: record the new work to plan and resource.

Record findings against each domain, because an action may be addressed in one domain and absent in another.

Inputs and outputs

Inputs: build documentation, previous assessment reports, configuration and logging documentation, exception registers and remediation plans, verified as current. An expired review, an exception that lapsed without re-approval or an outdated baseline is itself a finding. Outputs: a record of applicable actions and findings per domain, evidence of actions already satisfied, coverage gap detail and asset visibility deficiencies.

Implementation planning guide

Planning implementation

Phase sequencing

Priority phases are based on ASD threat intelligence, common control gaps and implementation opportunities. Address earlier phases before later ones; each builds on the last. Departures, such as for specific threat intelligence or regulatory drivers, should be documented, risk-based decisions.

Delivery approaches

• Domain-focus: take one domain and apply all applicable principles before moving on. Gives clear, demonstrable outcomes against a defined scope and aligns with tranches and budget cycles. The recommended default for organisations early in the journey.
• Principle-focus: take one principle and apply it across domains in phase order. Gives more consistent coverage and better value from enterprise-wide tooling and licensing.

Established programs may combine both. Procurement and licensing arrangements, funding preferences and risk appetite should drive the choice, and different approaches can suit different controls.

Prioritising with the ATT&CK mapping

Within a phase, identify the threat groups, campaigns and techniques most relevant to your environment (ASD advisories, sector, commercial and open-source intelligence), find the techniques most consistently observed against your sector, and use the mapping to find the actions that mitigate them most directly. Actions mapped to the few techniques that account for most of the threat become early investment candidates. This also informs remediation urgency for partially effective ratings. It is intended for organisations with enough maturity to use threat intelligence; others may prioritise by context, risk and resources. The mapping informs prioritisation within a phase, not across phases, and does not replace risk management. See Using the ATT&CK mapping.

Implementation planning guide

Deliver and measure

A fully effective rating requires the intended outcome to be achieved consistently, with supporting evidence.

Designing controls for the assessment dimensions

Indicators of good practice and the evidence register

Use the IGPs from the Assessment process guide for self-assessed ratings, and record the effectiveness rating and implementation status in separate fields. A single not effective statement normally justifies a not effective rating; partially effective needs evidence of genuine, worthwhile security benefit rather than partial activity. IGP statements consistently require defined review cycles, documented approvals, timely completion and reassessment after change, so every control should have a scheduled review, documented approval and a remediation plan for known deficiencies.

Document how existing controls satisfy each action, even where no remediation is needed, in a per-domain evidence register mapping each action to its control, scope coverage, evidence sources and current self-assessed rating. It serves as the self-assessment working paper, the independent assessment evidence package and the posture reporting detail. Independent assessors bring fresh judgement and are optional where proportionate and affordable.

Operational evidence of effectiveness

Deployment evidence alone is insufficient. Establish a validation program proportionate to capability and resources: control validation testing, penetration testing, red team and purple team exercises, and breach and attack simulation (not required for every action). Use ATT&CK to design and scope them, for example attempting to run unsigned binaries to validate Trustworthy software. Schedule validation after remediation where assurance is needed before ratings are reported.

Implementation planning guide

Sustainment planning and reusable patterns

Controls must be maintained, reassessed and refined as the threat environment, operating context and framework evolve. Sustainment is a planned deliverable of the program, not what happens after it.

Design as reusable patterns

Build cross-cutting capabilities (multi-factor authentication, configuration baselines and drift detection, centralised logging, vulnerability management, backup architecture) once as documented patterns instead of per-domain projects. One MFA pattern means one solution, one exception process and one evidence model, instead of four of each. A pattern should record:

• Intent: principles and actions supported, and the adversary techniques mitigated.
• Applicability: domains and phases, including domain-specific tailoring.
• Solution: technology-agnostic design, approved baseline, integration points, logging and governance artefacts.
• Evidence model: how coverage, consistency and currency are demonstrated and where operational evidence is retained.

Reassessment, exceptions and resourcing

• Reassessment cadence. Set a regular, risk-based cadence, brought forward after material change or relevant incidents, including periodic independent assessment where external assurance is needed. If a previously effective action has degraded, return to gap analysis and remediation.
• Exceptions as a lifecycle. Review exceptions, compensating controls and accepted risks at every reassessment. Maintain an exception register from the outset with owners, approvals, review requirements and expiry dates.
• Resource the steady state by capability pattern: licences, integration, data ingestion and retention, workforce, training, baseline reviews, drift remediation, detection tuning, validation and evidence maintenance. Plan governance sustainment (accountability reviews after change, reporting cadence, training currency) the same way.

Implementation planning guide

Assembling the implementation strategy and checklist

The framework does not prescribe timeframes. Progress at a pace that reflects capability, resources and risk, with a clear sequence of work and artefacts per phase.

Planning checklist

• Executive accountabilities, reporting arrangements and risk appetite are formally defined and assessable under Governance and culture.
• Operating context was documented before scoping decisions.
• Versioned scope statements exist for every domain in the current cycle, with exclusions and rationale.
• Every remediation item has a delivery approach, domains in phase order and an owner.
• Prioritisation is threat-informed, and any departure from sequence is a documented risk-based decision.
• Every control has a risk-based review cadence, approval records, drift or coverage monitoring and an evidence register entry.
• Validation exercises are scheduled for each phase and mapped to the techniques the actions mitigate.
• Cross-cutting capabilities are documented as patterns with intent, applicability, solution and evidence model.

Assessment process guide

Introduction, scope and stages

This supplemental guide explains how organisations assess the effectiveness of their implementation of an Essentials chapter. The purpose is to determine whether the outcomes described by each principle are being achieved, by assessing the effectiveness of the supporting actions. It helps organisations understand progress by assessing principles and actions in each domain over time, and identify and plan remediation from findings.

It supports organisations assessing their own environment. It does not replace regulatory or compliance requirements and is not intended for assessing suppliers or third parties (ASD will provide that guidance later). Use it with the relevant chapter, the Implementation planning guide and the series introduction.

Stage 1: Planning and preparation

• Agree scope. One, several or all domains may be assessed, in any order. Document any excluded domains or assets and why.
• Engage stakeholders: system owners, security team, infrastructure and platform owners, managed service providers. Confirm who can authorise activities, and establish early whether third-party access and evidence can be obtained.
• Develop the plan: domains, assets, principles and actions in scope; methods and tools; existing evidence as the starting point; access needed; sampling methodology; evidence handling, storage, retention and disposal; where the report will be kept; timeframe, milestones and dependencies.

Stages 2 to 4

Plan approval confirms the organisation accepts scope and methods (including technical testing, tools and scripts), that resources are available, and that operational-risk activities are authorised in advance. Material changes need agreement and updated approval; limitations such as access not obtained should be recorded.

Assessment is done domain by domain. The assessor confirms assets and functions, works through each principle and rates each applicable action on coverage, effectiveness, consistency, currency and evidence quality, recording evidence and, for anything below fully effective, the specific gaps. Any sampling and its basis are documented.

Aggregation and reporting uses the weakest link rule and reports by priority phase and domain, with a summary view and a detailed view. See Aggregation and reporting of findings.

Assessment process guide

Using the three layers for assessment

Assessors do not assess controls in isolation. The principle is the enduring security outcome, the action is what must be done, and the domain is where it is applied and assessed. Priority phases give a recommended sequence but do not change how an action is rated; domains not yet assessed are recorded as not assessed.

The same action may be rated differently across domains because assets and risk context differ. IGPs support consistency but do not replace professional judgement.

Why the three layers matter

A checklist asks whether a control exists. An Essentials assessment asks whether an action achieves the intended outcome for the assets in scope. Guide each rating with three questions:

1. What outcome does the principle require for this domain?
2. Does the action achieve that outcome for the assets in this domain?
3. Is there sufficient evidence that the action operates effectively across the domain (coverage, effectiveness, consistency, currency, evidence quality)? An action applied to only some assets, or enforced inconsistently, is not fully effective.

Assessment process guide

Assessing actions and indicators of good practice

Each action is rated against each applicable domain on a four-tier, outcome-based scale. The approach is informed by the UK NCSC Cyber Assessment Framework, which also uses IGPs.

Indicators of good practice (IGPs)

For each action, IGPs describe typical characteristics of the not effective, partially effective and fully effective ratings. They support informed judgement and consistency; they are not a checklist. For example, for the action to record all administrative actions with user, timestamp and target: not effective means actions are not logged or logs lack detail on who, when and what; partially effective means logging is enabled but misses some platforms or the target; fully effective means comprehensive logging on all platforms capturing identity, timestamp, target and nature of change.

Rating an action based on IGPs

• If any not effective statement applies, the action is not effective.
• If all applicable fully effective statements apply and none of the others do, it is fully effective.
• In all other cases it is partially effective.

Supporting expert judgement

• Assess the outcome achieved. An alternative but effective implementation is still fully effective.
• Partial activity is not partial effectiveness. A deployed control delivering no benefit is not effective regardless of effort.
• A single not effective statement is normally decisive, though a documented compensating arrangement that demonstrably achieves the outcome can justify a higher rating.
• Interpret IGPs in the context of the domain. Departures from the IGPs must be documented with the outcome achieved, evidence and compensating arrangements.

Assessment process guide

Assessing domains

Each domain is assessed independently, in any order, in parallel or selectively, and each against its own assets and risk context. This differs from the implementation sequence of priority phases. A complete, accurate scope is essential; an incomplete scope produces misleading results.

Scoping a domain

Use the organisation's existing domain scope where possible (see Scoping domain assets), validating that it is accurate, complete and current against asset inventories, system registers and architecture documentation. Minor gaps are reflected in assessment scope; significant gaps that call completeness into question are recorded as findings and may need wider asset discovery first.

Assets that span multiple domains

An asset supporting more than one domain is included in each. Each domain is assessed separately so ratings may differ. Evidence for a shared asset can be reused across domains where actions are the same, but must be evaluated against each domain's actions and risk context. For example, a customer-facing internet application is assessed in both Boundary services and Critical processes and services.

Assessing across the domain

Only actions mapped to the domain are assessed. For each, examine four dimensions:

• Coverage: applied to all relevant assets in the domain.
• Consistency: applied consistently across those assets.
• Currency: evidence recent enough to reflect current implementation.
• Evidence quality: sufficiently reliable and relevant to show the outcome is achieved.

A domain is considered addressed when all applicable actions operate as intended and are fully effective. A domain not yet assessed is recorded as not assessed, reflecting sequencing rather than failure. A domain's result stands on its own and does not carry across to another.

Assessment process guide

Collecting evidence

Essentials actions are technology-agnostic, so existing control catalogues (the ISM or others) can be sources of evidence, but the assessment focuses on whether the outcome is achieved, not on the catalogue. Identify and use relevant existing evidence before generating new evidence.

Mapping a control catalogue and reusing evidence

Mapping existing controls to actions is a starting point, not proof that the outcome is achieved. Different organisations can use different controls and achieve the same rating. Evidence from other catalogues (configuration baselines, assessment reports, control test results, audit findings, risk registers) can be reused if representative, reflecting controls in operation at the time, reliable, consistent and comprehensive. Three cautions:

• Deployment is not effectiveness. Enabled or configured does not prove the outcome is achieved.
• Evidence must be current. Seek more recent evidence where needed.
• Controls may only partially satisfy an action. Identify the remaining gaps.

Where evidence shows deployment but not sustained effectiveness, supplement it with red team and purple team exercises, control validation testing, breach and attack simulation and penetration testing (see ATT&CK mapping).

The quality of evidence

The levels are a guide, not a rule. Seek the highest quality reasonably practicable and consider all available evidence and domain risk. Where evidence is insufficient, rate not assessed and document the limitation; where it shows the outcome is not being achieved, rate not effective.

Assessment process guide

Using tools in an assessment

Tools help collect information, identify gaps and confirm an action is working. The guide recommends no specific tools: choose approved tools per the assessment plan and consider native capabilities first. Record the tool, version, configuration, permissions, licensing constraints and limitations, and critically assess output for stale data, misconfiguration, restricted access and false positives or negatives.

• Tools and evidence quality. Evidence quality depends on what the tool demonstrates, not the fact a tool was used. Results from a sample do not automatically demonstrate an outcome across a domain.
• Simulations and active testing can provide strong evidence by directly testing whether an action works in the live environment (for example attempting to run unapproved software or simulating techniques the action should prevent or detect). They carry operational risk, so must be documented in the plan, approved with target systems, scope and limits, and run by suitably skilled personnel, using qualified external capability where needed.

Assessment process guide

Using the ATT&CK mapping

Most actions map to one or more MITRE ATT&CK techniques, only where they directly help prevent, detect or limit a technique. The mapping is a guide, not a scoring mechanism: actions are still rated against intended outcomes. It informs prioritisation and validation, and informs the rating and remediation plan.

• Informing prioritisation. Compare observed adversary techniques with mapped actions to find gaps needing earlier attention, particularly for partially effective and not effective actions. It informs remediation urgency but never changes the rating.
• Validating effectiveness. Design testing that exercises the relevant behaviours and observe whether controls prevent or detect them in the live environment. This yields high-quality evidence.

Limitations

• ATT&CK evolves continuously. ASD updates its mapping periodically, but high-impact decisions should consider current MITRE content.
• Mapping does not prove implementation effectiveness; it is necessarily generalised.
• Threat intelligence is incomplete. Adapting adversaries may be understated by past observations, so it should inform prioritisation alongside broader risk management.

Assessment process guide

Aggregation and reporting of findings

Aggregating action ratings to principle ratings

A principle is rated separately in each domain where it applies. The principle rating is the lowest applicable action rating (the weakest link rule):

• Not effective: one or more applicable actions are not effective.
• Partially effective: all actions assessed, none not effective, at least one partially effective.
• Fully effective: all applicable actions are fully effective.

Example: the Identity, credentials and access management principle has six actions in Identity services; four are fully effective and two partially effective, so the principle is partially effective there. In Boundary services it is rated separately. If actions have not been sufficiently assessed, the principle is not assessed for that domain.

Reporting posture

Results are reported by priority phase and domain, showing the number of principles at each rating. A percentage summarises each domain: not effective scores 0, partially effective 0.5 and fully effective 1; the sum is divided by the applicable principles. For example, 5 fully effective, 4 partially effective and 1 not effective gives (5 + 2 + 0) / 10 = 70%.

Summary view and detailed view

The report must include both. The summary view shows progression across domains; the detailed view identifies the principles and actions driving each rating and remediation in progress. The summary alone can obscure outstanding risk. Limitations that affected the assessment are recorded.

Visualising posture and progression

A radar chart gives a high-level view of posture, and overlaying successive assessments shows progression. Use a domain-level view for executive, board and regulator reporting, and a principle-level view for a single domain for CISOs, architects and assessors. Visualisations must never be used in isolation: aggregating into a single point can hide individual gaps, so always present them with the structured reporting.

ASD Essentials for enterprise IT

ASD Essentials for enterprise IT

Enterprise IT refers to the IT environments of organisations whose scale, complexity, regulatory exposure or reliance on technology demands a structured, deliberate approach to cyber security. They typically include multiple interconnected systems supporting different business functions, identity and access arrangements spanning a workforce and extended user population, dedicated cyber security and IT functions with defined roles, and formal governance over technology investment, risk and compliance. Smaller organisations can still use the guidance where relevant; what differs is how outcomes are achieved and how much responsibility sits with providers.

The chapter defines eight domains (the table in domains and risk context) and three priority phases:

• Phase 1: Boundary services and Identity services. Common pathways for initial access. Weaknesses undermine controls elsewhere; addressing them together protects external access pathways and the identities used to reach systems.
• Phase 2: Critical processes and services and Privileged environments. Privileged environments give adversaries elevated access after intrusion; critical processes carry significant consequences. Together they reduce the chance an adversary escalates and affects critical outcomes.
• Phase 3: Business systems and User devices. Widely distributed and common targets, addressed after earlier protections are established so compromise is less likely to spread.

Governance and culture, and Visibility and response, apply across all phases and expand as implementation progresses. Non-production environments are in scope and assigned to domains like any other asset.

Matrix 1: Governance and culture

Matrix 2: Visibility and response

Matrix 3: Technical domains (principles and actions)

These actions apply across the six technical domains: Boundary services, Identity services, Critical processes and services, Privileged environments, Business systems and User devices. Per-domain applicability and MITRE ATT&CK technique mappings are in the full ASD publication at cyber.gov.au.

ASD Essentials for cloud

ASD Essentials for cloud

This chapter is for organisations whose technology is delivered entirely through software-as-a-service (SaaS) and platform-as-a-service (PaaS). For them, some enterprise IT guidance describes work the provider performs and cannot be implemented or evidenced by a consumer, such as running servers, operating networks and maintaining platform runtimes. The cloud chapter focuses effort on what determines a consumer's posture: identity, data, configuration, applications, integrations and provider assurance.

Service models

• SaaS: the organisation consumes finished applications; responsibilities concentrate on identity, data, tenant configuration, connected integrations and provider assurance.
• PaaS: the organisation builds and runs applications on a provider platform, so it also secures what it builds, patches what it deploys and segments the environments it configures.

Few environments map to a single model. Where a SaaS service exposes low-code development, scripting or private networking, apply the PaaS-marked actions to it. A PaaS user with direct control over compute or networking may be near the IaaS boundary and should consider Essentials for enterprise IT. Judge what you actually operate, not the procurement label.

Shared responsibility

Markers are indicative. Confirm and document the actual division of responsibility for each service you rely on.

Domains and priority phases

The eight domains match enterprise IT, with cloud-specific descriptions: Boundary services cover integrations, APIs, gateways, internet-facing services and remote access; Identity services cover identity providers, authentication and authorisation enforcement and credential stores; Privileged environments include SaaS administration interfaces, PaaS management and deployment services and cloud control-plane capabilities; Business systems include business applications, workflow platforms, data services and custom applications on managed platforms; User devices are endpoints used to access SaaS and PaaS. Priority phases follow the same order as enterprise IT: Identity and Boundary services first, then Critical processes and Privileged environments, then Business systems and User devices, with the two capability domains applying across all phases. See the asset scoping guide for cloud.

Matrix 1: Governance and culture (PaaS / SaaS responsibility)

Matrix 2: Visibility and response

Matrix 3: Technical domains (principles and actions)

These apply across the six technical domains. Per-domain applicability and MITRE ATT&CK technique mappings are in the full ASD publication at cyber.gov.au.

Asset scoping guide for cloud

Asset scoping guide for cloud

This supplementary guide complements the cloud chapter with descriptions of each domain, consequences of compromise and prompting questions. The questions and examples are prompts rather than exhaustive lists. An asset is in scope for every domain that describes it, and all actions applicable to those domains apply. Where the same action applies through more than one domain it is implemented once; multi-domain membership widens the set of actions without multiplying the work for actions already in that set.

ASD Essentials for OT

ASD Essentials for OT

Operational technology (OT) systems detect or cause a direct change to the physical environment through monitoring or control of devices, processes and events. The chapter targets operators of complex systems control, automation and safety across critical service sectors: public transit, critical supply chain logistics, power, water and wastewater, medical services and large-scale industry. The term vital OT refers to the subset of critical systems that it is unacceptable to have offline for an extended period, considering the ability to maintain safe minimum viable output through manual processes and business continuity plans.

Domains in OT

Eight domains apply, with two capability domains across all technical domains. User devices is written to stress that endpoint-type devices introduce extreme risk to OT, so all devices in an OT system must be treated as privileged. Non-production environments are in scope and, where they can reach or change production, protected to the same level.

Priority phases

Technical domains are sequenced differently from enterprise IT to reflect safety: OT cyber security prioritises safe, continuous operation, with greater emphasis on protecting critical processes, controlling connectivity and administrative access, and compensating controls where patching or replacing legacy equipment is not possible.

• Phase 1: Boundary services and Critical processes and services. Protects the pathways into OT while protecting the systems with the greatest safety, operational, environmental or service-delivery consequence.
• Phase 2: Privileged environments and Identity services. Control administrative and privileged access; weaknesses allow escalation, movement and unauthorised change.
• Phase 3: Business systems. Addressed after critical operations, connectivity and privileged access, reducing the chance a business system becomes a pathway to critical OT.

Matrix 1: Governance and culture

Matrix 2: Visibility and response

Matrix 3: Technical domains (principles and actions)

These apply across Critical processes and services, Boundary services, Identity services, Privileged environments and Business systems. Per-domain applicability and MITRE ATT&CK technique mappings are in the full ASD publication at cyber.gov.au.

ASD Essentials overview: AI considerations within the Essentials

AI considerations for all environments

The Essentials framework applies whether an organisation consumes, develops or deploys AI. The series is technology-agnostic and focuses on outcomes that apply to AI-enabled and traditional systems. Treat AI as a source of risk, a capability that can support defence, and an asset to be identified and governed.

AI as a threat

AI has not fundamentally changed how adversaries gain access and move, but it has made existing attacks faster, cheaper and available to more people. It helps with reconnaissance, finding vulnerabilities and developing exploits or malware, and synthetic voice and video can impersonate trusted people to deceive help desks or payment and access approvers. AI systems themselves can be targeted: indirect prompt injection through emails, documents or web content processed by AI agents with tool or data access; tampered models from public sources; and sensitive data sent to unapproved AI services. The response is layered protection, so an attacker who defeats one safeguard meets another.

AI as a solution

AI-enabled security can process large data volumes, correlate events, identify vulnerabilities, triage alerts and synthesise threat intelligence. It depends on governance: AI security products are themselves AI assets to assess, configure and monitor. Use them to support Essentials actions, not replace them. Accountability remains with people, and AI outputs should be validated before informing significant decisions.

AI as an asset

AI systems are assets within scope, including internally developed or fine-tuned models; hosting and training infrastructure; externally provided AI services; AI-enabled platforms; training data; prompts, outputs and inferences; interfaces, connectors and APIs; and accounts and non-person identities used by AI agents. AI tools can be given their own identities, permissions and access, which should be governed like any other. When scoping, consider function, connectivity, criticality, access and the consequence of compromise.

Executive AI accountability

Under the ISM Executive artificial intelligence accountability principle, the board or executive committee is accountable for ensuring AI is secure, controllable, human-supervised and used ethically and accountably. Establish executive accountability supported by processes for approval, risk assessment, oversight and ongoing review of AI use cases. See Executive oversight.

ASD Essentials overview: AI considerations within the Essentials

AI in enterprise IT

Core AI systems are likely scoped to Critical processes and services; AI embedded in general platforms to Business systems; public-facing AI services and APIs to Boundary services; AI agents and their non-person identities to Identity services; and AI tools capable of administrative actions to Privileged environments. See Enterprise IT chapter.

ASD Essentials overview: AI considerations within the Essentials

AI in cloud environments

Responsibilities for AI are distributed between the organisation and its providers. Obtain executive or delegate approval before enabling SaaS or PaaS AI functions; high-risk services storing sensitive data fall under the executive approval arrangements in Essentials for cloud. Record AI capabilities in the shared responsibility register: which controls the organisation operates, which the provider supplies for configuration, and which outcomes the provider delivers for verification through assurance. Where an organisation runs its own infrastructure to host or train models, consider whether the enterprise IT chapter better reflects its responsibilities.

Domain mapping mirrors enterprise IT: core AI to Critical processes and services, AI in general SaaS to Business systems, AI APIs and connectors to Boundary services, AI agents' non-person identities to Identity services, and AI with access to SaaS administration or cloud control planes to Privileged environments.

ASD Essentials overview: AI considerations within the Essentials

AI in operational technology

AI in OT needs extra care because security decisions can affect safety, operational continuity and physical processes. AI can help adversaries understand industrial protocols and control logic faster, and OT patching constraints increase reliance on compensating controls and isolation. AI-enabled monitoring may depend on vendor cloud services; ensure these do not undermine OT isolation, vital OT and its logging and detection remain available when outside systems are down, and AI-recommended or automated actions cannot compromise safety functions.

Models and decision support that provide input to control are likely in Critical processes and services; AI tools on engineering or operator workstations belong in Privileged environments. See Essentials for OT.