AI agents investigate every alert, add context, and prepare cases for response, on a full-stack SecOps platform that captures and correlates all your security data.
Cloud-based SIEM platform providing visibility across all your data sources
Every alert investigated, with a verdict and the evidence behind it
Manage your external footprint, publicly available data, and Dark Web leaks
Log management and threat detection across any of your log sources
Get ultimate assurance that your environment is free from threat actors
Fully featured distrubuted NDR for on-premises and public cloud environments
A SecOps platform purpose-built for industrial and OT environments
Integrated endpoint agent providing deep visibility, response and forensics
Deploy honeypots and honeytokens and stay ahead of threat actors
24x7 security operations from our Australian SOC. AI investigates every alert, and experienced analysts validate findings and contain threats around the clock.
24x7 managed detection and response across endpoint, network, cloud, identity, and log sources
AI investigations and 24x7 MDR on the Microsoft Sentinel you already own
Eyes-on-glass SOC and continuous threat hunting
Expert hunters and AI agents find attacker activity your alerts missed
Quickly recover from cyber attacks and breaches
ThreatDefence is the only SecOps as a Service company providing broad coverage across your entire technology stack with evidence-based security.
We provide security teams with full-stack SecOps infrastructure – you get deep visibility from day one, gain control over your security data, and get access to a comprehensive set of ready-to-use tools, detections, workflows, playbooks and scenarios.
24x7 SOC, Continuous Monitoring, Threat Containment and Incident Response
Visibility and actionable insights for all IT assets
Leverage our Cyber Range to train defenders based on real-world scenarios and simulations
OT and industrial cyber security services for critical infrastructure
Monitoring, evidence and a 24x7 SOC in one platform
Compliance monitoring, evidence and board reporting
Privacy Act reform impacts, obligations, and practical security considerations
Monitoring and compliance support for critical infrastructure environments
A practical guide to securing critical infrastructure with continuous monitoring
A practical buyer’s guide for schools evaluating SIEM and SOC services
A practical guide to selecting the right SIEM and SOC service for local government
Articles on security operations, AI and compliance
Events, awards and company news
Read what our customers say about us
Solution briefs and datasheets
How we keep your data secure
Technical support and knowledge base
Guides, case studies, and advisories in one place
How AI agents investigate alerts and run security operations
Free ebook: a practical guide to adopting an AI SOC platform
A practical guide to incident response and digital forensics
Where SOAR playbooks fit and where AI agents take over
Free ebook: modern security operations with Microsoft Sentinel
How the framework is structured and what changes from the Essential Eight
November 10, 2026
November 6, 2026
We provide end-to-end SecOps solutions for Managed Security Service Providers (MSSPs), Managed Service Providers (MSPs), and Value-Added Resellers (VARs).
Find out how you can become a ThreatDefence partner.
Protect your entire technology stack and build your SecOps on your own pace
White-labeled AI SOC for every client tenant, co-managed with our SOC team
Launch your SOC business without any upfront investment
Embed security operations, threat intelligence and exposure data in your product
Sovereign SOC for Australian MSPs and MSSPs, with onshore analysts and client data
Set the rules for closing alerts automatically, with evidence checks and review
How MSPs deliver branded security monitoring with a SOC partner
ThreatDefence was an official partner of the Cyber Resilience Summit NSW, 29 October 2026 at Hilton Sydney.
Our team was back at BSides Canberra, and our cyber quiz was a hit again.
Two days in Perth with our partner Ever Nimble, on security operations and cyber resilience.
Sponsors of the AUSCERT Cyber Security Conference on the Gold Coast.
Sponsors of the Gartner Security & Risk Management Summit in March.
Sponsors of the Cyber Security for Critical Assets Summit in Perth, February 2026.
Expert conversations with speakers and attendees at CyberCon Melbourne 2025.
User devices and Business systems make up priority phase 3 of ASD Essentials for enterprise IT: workforce endpoints on one side, everyday applications and their supporting infrastructure on the other.
ASD describes User devices as Endpoints issued to the workforce, including desktops and laptops and Business systems as Supporting enterprise functions that collectively enable organisational operations.
Endpoints issued to the workforce, including desktops and laptops
Supporting enterprise functions that collectively enable organisational operations
User devices covers desktops, laptops, virtual desktops and enterprise-managed mobile devices. Business systems covers the applications that keep everyday operations running without any single system being individually critical. Both are widely distributed and commonly targeted, and ASD’s example phase 3 work aims at constraining what an adversary can do from any foothold.
constraining what an adversary can do from any foothold
Much of the ground is familiar from the Essential Eight: Office macros, application hardening, application control and patching. ASD Essentials widens it into secure configuration, trustworthy software, access management and ongoing verification that each control still works.
The hard part is coverage. Macro restrictions and application control can be working well on workstations while the servers behind business applications lack equivalent execution controls, configuration baselines or reliable evidence. The reasons for ASD’s implementation sequence are covered in ASD Essentials explained.
The User devices domain in ASD Essentials takes in every endpoint the general workforce uses to reach organisational systems: desktop computers, laptops, virtual desktops and enterprise-managed mobile devices such as phones and tablets.
ASD scopes a device by how it is used. Hardware and operating system do not decide the domain, so a virtual desktop used for ordinary office work sits alongside the physical workstation doing the same job.
Enterprise-managed mobile devices are explicitly included. ASD has explained that the Essential Eight was designed for internet-connected IT networks, and enterprise mobility was outside that design. Phones and tablets are one place where the broader framework reaches further than an existing program may.
Purpose also decides where an administrator’s workstation belongs:
Devices used for email, collaboration, document processing and business applications belong to User devices.
Devices used to perform administrative work belong to Privileged environments.
Devices used for both standard and administrative activities belong to both domains.
ASD’s implementation planning guide offers a scoping question: Does it provide the general workforce with direct access to the environment?
Does it provide the general workforce with direct access to the environment?
The answer changes how a device is assessed. A typical case is the administrator who browses and reads email on the workstation also used for administration. That device may need to be considered in both domains, even when a separate privileged account is kept for the administrative work.
Personally owned devices need particular care. ASD’s texts name enterprise-managed mobile devices and do not directly settle how BYOD is treated. Organisations should document how personally owned endpoints reach organisational applications and agree their treatment with the assessor.
User devices are common entry points for compromise. Phishing, social engineering and drive-by attacks reach a workstation through ordinary activity, and untrusted documents, unauthorised software and local data handling open the way to code execution or information loss.
A useful device inventory separates standard, administrative and mixed-use devices, includes managed mobile endpoints and virtual desktops, and flags any device missing from management or security reporting.
In ASD Essentials, Business systems covers the applications and supporting infrastructure that together keep an organisation running day to day, even where no single application is critical to its primary outcomes.
ASD’s asset scoping guide gives corporate management systems, cloud applications, IT service management systems and office productivity applications as examples, along with collaboration and messaging tools.
The implementation planning guide offers a direct test: Does it support day-to-day operations without being individually critical?
Does it support day-to-day operations without being individually critical?
These systems are judged collectively. One application going down may have limited effect, but disruption across several connected systems can stop staff completing ordinary work. A compromise of one application can also open the way to information or accounts used elsewhere.
ASD’s scoping guidance raises several considerations:
Identify the upstream and downstream functions that depend on the system and the consequences of disruption.
Record connections with other business systems and the services those connections support.
Consider whether compromise could introduce or increase risk through connected suppliers and applications.
Identify accounts, roles and permissions managed within the application. A practical addition is any access that works independently of the enterprise directory.
A system can belong to more than one domain. An application essential to a primary organisational outcome may also belong to Critical processes and services. One that provisions accounts into other systems may also sit in Identity services, and one reachable from the internet in Boundary services.
ASD’s AI guidance indicates that AI embedded in general-purpose SaaS applications may fall within Business systems. The surrounding application and its operational purpose still matter to the scoping decision.
A business system is more than the application name in a software register.
For each one, record the application, supporting servers and services, operating systems, identities, credentials, data and relevant integrations. Where a system overlaps other domains, show those relationships in the register. Assigning it to a single domain hides them.
Include known exclusions and gaps in asset visibility. An inventory holding only the applications managed by the central IT team can miss systems that still support business operations, for example a tool one department bought and administers itself.
The test of the finished record is whether each application can be traced to the infrastructure and access paths that need protection.
For User devices, the enterprise IT matrix assigns actions on asset management, secure deployment, access control, software execution, vulnerability management, configuration and logging.
The table below lists the principles and actions assigned to the domain. Principle names are ASD’s own.
Existing endpoint security tools can contribute to several of these actions, but having a tool installed does not show that its controls are effective.
An endpoint management console can hold an approved hardening policy that some devices have never received. An application control policy can be assigned across the fleet and still run in audit mode on some workstations.
An assessment separates the intended configuration from actual deployment coverage and from observed enforcement.
Regular and proven backups, network segmentation, content filtering and awareness training are mapped to other domains and do not appear against User devices. Business systems carries backups, segmentation and outbound content inspection, which the mapping section below addresses.
Macro controls built for the Essential Eight’s Restrict Microsoft Office macros strategy still count under ASD Essentials. They no longer stand as a separate mitigation strategy with its own principle: macro protection now contributes to broader ones.
ASD’s transition guide maps existing macro controls to Trustworthy software and Secure configuration management.
ASD explains that macro restrictions address only part of the broader requirement to control software execution.
address only part of the broader requirement to control software execution
The existing Microsoft Office macro protections are all worth keeping:
Disable macros for users without a demonstrated business requirement.
Block macros in files originating from the internet.
Scan macros for suspicious or malicious code.
Prevent users from changing enforced macro security settings.
Maintain appropriate Trusted Location and trusted publisher arrangements.
Each of these settings closes one defined execution mechanism. By themselves they do not control scripting engines, administrative tools or other software capable of running code.
Macro restrictions belong in an approved configuration baseline. Office settings applied by hand to individual machines leave no single record of what was intended.
The baseline names the required policies, the devices and users they apply to and any authorised exceptions. Central deployment records then show that the settings reached that population.
Each exception needs a documented business reason, an owner and a review or expiry date. A typical failure is the macro exception granted for one team’s spreadsheet that is still in place long after the spreadsheet was retired. The business requirement has ended and the gap in the control remains.
A configuration policy assigned to a device group is useful evidence of intent. The assessment also needs to know whether the settings were applied.
Export per-device policy status, reconcile it with the asset inventory and investigate devices that are missing or reporting unexpected settings. Configuration drift monitoring then picks up policies that have changed or stopped being enforced.
Having a macro policy is the starting point. The assessed outcome is a policy that stays effective across the applicable fleet.
Under ASD Essentials, application control reaches past the workstation fleet. Only supported, verified and organisation-authorised software is meant to run on applicable workstations and business systems, including the servers that support business applications.
The Trustworthy software principle includes the following action:
Permit only supported, verified and organisation-authorised software to execute on systems, with exceptions minimised, formally risk accepted, time-bound, monitored and regularly reviewed.
ASD’s transition guide lists User devices against this action with an ML1 label and Business systems with an ML3 label.
Existing workstation application control is a foundation. For organisations that previously targeted Maturity Level Two, though, Essential Eight application control may offer limited server coverage.
The common gap follows from that: a mature execution policy on workforce workstations, and servers behind business applications that sit outside any equivalent control.
Execution control identifies which software is authorised for each applicable system and stops unauthorised software from running.
Approved software is supported and integrity-verified. The approved software list is reviewed on a schedule, and exceptions are minimised, formally risk accepted, time-bound and monitored.
Workstations and servers get separate coverage checks because their application sets and operational requirements differ.
On workstations, review the assigned application control policies, the enforcement mode and the block events. On business servers, start from the server inventory and mark which systems have an effective execution policy.
A policy running only in audit mode records what tried to execute. It does not show that unauthorised software was stopped.
A separate Trustworthy software action addresses administrative and management tools:
Restrict administrative and management tooling to approved software sets and executed from only authorised, known locations.
ASD marks the existing Essential Eight contribution on User devices as partial, with an ML1 label.
General application allowlisting does not necessarily mean that administrative tools execute only from approved locations.
PowerShell, scripting engines and remote management tools on standard workstations deserve particular attention. They support legitimate administration, and they are also execution paths that Office macro restrictions do not address.
The organisation needs to be able to name its approved administrative toolset and show that restrictions cover both the software and the locations it is permitted to run from.
User application hardening now contributes to Secure configuration management: approved settings, deployed consistently, with changes from the approved state detected.
ASD’s transition guide recognises existing hardening of web browsers, Office productivity suites, PDF software, PowerShell, command-line activity and application security settings.
The same principle applies to Business systems, including the servers supporting business applications.
A configuration baseline draws on vendor and industry hardening guidance, allows for operational requirements and is approved before deployment.
It states the intended settings and the assets they apply to. Version history, change approvals and deployment records then show what configuration was expected on any given date.
Central deployment reduces the variation that creeps in when settings are applied by hand, system by system.
Business application servers need baselines of their own. A workstation hardening policy tells an assessor nothing about whether the operating systems and applications behind business services have approved configurations.
ASD’s implementation planning guide uses an approved user device baseline to show how evidence can come out of normal operations:
Enrolment records show the baseline deployed across managed devices and are reconciled with the asset inventory.
Centrally deployed settings have approvals and version history behind them.
Baselines are reviewed on a set cycle, quarterly in ASD’s example, with dated records.
System-generated control decision logs support the assessment, so nothing rests on unsupported assertion.
A deployment record shows only that a baseline was applied at a point in time. Drift after that point has to be investigated and tracked to closure.
On business application servers, drift can be found through scheduled technical assessments and, where supported, automated monitoring matched to system criticality and change rate.
ASD’s indicators rate drift detection that covers only some applicable assets as partially effective. A fully effective rating also needs evidence that identified drift is followed through to remediation.
Execution control and configuration management work as a pair. Application control restricts what software can run. Configuration monitoring confirms that approved system and application settings are still in place.
Patching contributes to Vulnerability management across both User devices and Business systems.
A patch report that works as evidence lists the applicable assets, the release and installation dates of each update and the systems where patches are still outstanding. ASD’s indicators look for risk-based timeframes, prioritisation using exploitation and exposure, and verification that vulnerabilities have been treated.
Where operational constraints delay remediation, compensating controls and exclusions need to be documented and approved.
Patch compliance calculated only from devices reporting to a management console may overstate coverage. A laptop that has stopped checking in, for example, can drop out of the calculation altogether, which flatters the percentage. Reconcile patch records with the asset inventory before using them as evidence.
Access control on user devices and in business applications has to reach local accounts, privileges and credentials as well as centrally managed identities.
On workforce devices, verify these directly:
Avoid shared local administrator passwords across the fleet and enforce credential uniqueness for applicable systems and accounts.
Review local administrative rights and other privileges against current roles, duties and business requirements.
Removing an account from an enterprise directory group does not necessarily remove every local privilege or credential on a device. A technician added directly to a laptop’s local administrators group during a support call, for example, stays there until someone checks the device.
Local administrator password management records and group membership reports are stronger evidence than a general statement that centralised identity controls are in place.
Business applications may maintain their own user accounts, service accounts, roles, secrets and permissions.
An access review run against the enterprise directory can miss privileges held directly within an application. Check each relevant access path against the people, systems and services that still need it.
Service accounts and application-specific credentials are part of the same review. Their ownership and purpose may differ from ordinary interactive user accounts, but they remain within the system’s access and credential scope.
Phishing-resistant MFA, default accounts and legacy authentication are covered in the Identity services guide.
An existing Essential Eight implementation supplies reusable controls and evidence for User devices and Business systems. The fit is uneven, though. No strategy is replaced directly by a single ASD Essentials principle.
ASD’s transition guide shows where previous work contributes to the new actions, where that contribution is partial and where the scope expands.
The ML and partial labels below are ASD’s own notation, which the guide does not define. They are useful for gap analysis. They are not ASD Essentials effectiveness ratings.
The table shows where existing evidence can be reused. It does not show that the matching ASD Essentials action is fully effective.
Existing patch reports may support Vulnerability management, for example, but their coverage still has to be checked against all applicable assets. Workstation application control, likewise, does not automatically extend to business servers.
The transition guide lists User devices against the Content filtering action covering outbound connections. The enterprise IT matrix, however, maps that action only to Boundary services and Critical processes and services.
ASD names the chapter as the authoritative source for requirements. The practical reading is to treat the action as outside the User devices assessment unless an assessor confirms otherwise.
Business systems carries the outbound inspection action, IT.PRO-09.1:
Inspect outbound content flows to detect unauthorised transfer of sensitive or high-value data.
ASD’s indicators expect outbound inspection across every applicable egress path, rules covering classified, regulated and high-value data, and alerts triaged within defined timeframes.
Business systems also carries the Regular and proven backups and network segmentation actions.
The Essential Eight’s Regular backups strategy maps to backups and restore testing, with an ML1 label, and backup isolation marked partial at ML1. In the enterprise IT chapter these backup actions are mapped to Business systems. User devices does not carry them.
Network segmentation actions IT.PRO-18.1 and 18.2 also apply to Business systems. They address zoning by business criticality and trust level, and limiting lateral movement to explicitly approved pathways and services.
The transition guide maps the Essential Eight’s segmentation contribution to Privileged environments. Existing Essential Eight work may therefore provide limited reusable evidence for segmentation across ordinary business applications and their servers.
The related principles are covered in the ASD Essentials Privileged environments guide. The broader mapping and transition pathway are covered in Moving from the Essential Eight to ASD Essentials.
Evidence for User devices and Business systems has to show controls operating across every applicable device and system, including the ones missing from a management console.
ASD warns that enterprise-wide controls can receive different effectiveness ratings in different domains. Workstation baseline coverage may be strong while application control across business servers is incomplete.
Reconcile endpoint and server management exports against the asset inventory. A report limited to enrolled devices can conceal unmanaged assets and the gaps in control coverage that go with them.
The collection methods are common practice rather than ASD requirements.
A dated fleet-wide report from a management console is generally stronger coverage evidence than a screenshot of one device.
Where screenshots are used, each one needs to show the date, the policy and the device group the settings apply to. The assessor also needs enough information to work out which systems the report left out.
ASD’s assessment process guide asks whether evidence is recent enough to represent the current implementation. Reports collected at intervals across the assessment period go further. They show that controls operated consistently, where a single export shows one day.
Start evidence collection from the complete asset population, then work out which systems have each control. Starting from the console answers a narrower question, because a console only knows the devices enrolled in it.
A workable order is to compare the asset inventory with device enrolment, map approved baselines and application control policies to those assets, then list the systems missing from reporting.
Check policy mode separately. A workstation shown as compliant with its assigned application control policy may still be in audit mode, with no execution restrictions enforced.
On business servers, the same exercise shows which application workloads are covered and where operational exceptions exist.
The result sorts every system into effective coverage, approved exception, incomplete deployment or control status unknown.
Separate standard and administrative activity: Identify workstations used for administration and move that activity into appropriately scoped Privileged environments.
Complete the device inventory: Include virtual desktops and enterprise-managed mobile devices, then reconcile inventory records against management enrolment.
Extend software execution controls: Review scripting engines, remote management tools and other execution mechanisms beyond Office macros, and bring applicable business servers under application control.
Control exceptions: Give application control, macro and baseline exceptions documented reasons, owners, expiry dates and review records.
Find silent devices: Forward PowerShell, command-line and application control events to central storage under IT.DET-01.2, and investigate devices that stop reporting them.
These fixes turn existing endpoint policies into control coverage that can be verified. They also expose differences between the workstation fleet and business systems that an enterprise-wide compliance report can hide.
The OT and cloud chapters of ASD Essentials treat User devices and Business systems differently from enterprise IT. An organisation working across these environments applies the relevant chapter to each scope.
The OT chapter does not include User devices in its technical domain mapping.
ASD says typically configured end-user devices should be prohibited within OT environments, and every device within the OT system is treated as privileged.
Business systems remains a phase 3 domain in the OT chapter. ASD notes that a business system supporting OT processes may also form part of the OT system.
Relevant actions emphasise registers of unpatchable assets, compensating controls and services that remain available when OT environments are isolated.
This matters where a conventional business application supports operational processes. Its business function and its relationship to the OT environment decide the scope. The application’s name alone does not.
The cloud chapter keeps User devices and extends the domain to endpoints used to access SaaS and PaaS services, including mobile devices.
Business systems covers general business applications and custom applications delivered through SaaS and managed PaaS platforms.
Relevant actions address awareness training before access, approval of applications, integrations and consent grants, monitoring for anomalous use of legitimate identities, and recovery arrangements agreed with the provider.
An organisation with both conventional enterprise IT and SaaS or PaaS services separates the relevant assets and access paths when it selects the applicable chapter and records its scope.
ThreatDefence runs a 24x7 SOC with its team based in Australia and a 3 min average response under guaranteed SLAs. Threat hunting and an incident response retainer are included in the standard service.
Response actions stay within the authority each customer approves, and case records can be exported for an assessor or at the end of a contract. Australian customers’ data and AI processing stay in Australia. ThreatDefence does not certify organisations; the assessor determines ASD Essentials ratings.
The endpoint and DFIR module collects workstation telemetry. For example, when a Word document starts encoded PowerShell, analysts can investigate the execution chain, collect forensic evidence from the affected device and hunt for the same artefacts across the fleet.
Network detection and response detects lateral movement between network segments and exfiltration through outbound flows.
Organisations can rate their environments action by action in the free ASD Essentials Navigator, with principle and domain results that update as they go. Readers new to the framework can start with the five-minute ASD Essentials explainer, which walks through principles, actions, domains, priority phases and ratings.
Open the ASD Essentials Navigator Start the 5-Minute Explainer Explore ASD Essentials Compliance
See how ThreatDefence automates security monitoring, compliance and cyber risk management in one platform.
CountryAustraliaUnited StatesNew ZealandUnited KingdomCanadaSingaporeOtherI'm an MSP, MSSP, or reseller
Δ
Yes. Existing Microsoft Office macro restrictions and user application hardening contribute evidence for Trustworthy software and Secure configuration management. ASD expects approved settings, consistent deployment and monitoring for configuration drift. Macro restrictions address only part of the broader requirement to control software execution, so PowerShell, scripting engines, administrative tools and other execution mechanisms need attention as well. Existing policies remain useful, provided their effectiveness can be shown across the applicable devices.
ASD places User devices and Business systems in phase 3 because the earlier phases put protections around boundary, identity, privileged and critical environments first. Those protections help contain a compromise before an organisation turns to its widely distributed endpoints and everyday applications. ASD’s example phase 3 work aims at constraining what an adversary can do from any foothold. Phase 3 describes an implementation priority. It gives no permission to delay existing endpoint security or Essential Eight improvements.
Yes, enterprise-managed mobile devices are explicitly included in User devices under ASD’s enterprise IT asset scoping guidance, alongside the desktops, laptops and virtual desktops used for standard workforce access. ASD’s texts do not directly settle the treatment of personally owned devices. Organisations using BYOD should document how those endpoints reach organisational systems, identify the management and security controls that apply and agree the assessment scope with the assessor. Personal ownership is no basis for assuming an exclusion.
Yes. Existing application control contributes to Trustworthy software and is the starting point for assessing permitted execution. ASD’s transition guide labels User devices coverage “(ML1)” and Business systems coverage “(ML3)”, using notation the guide does not define. An organisation that previously targeted a lower Essential Eight maturity level may have workstation coverage and no equivalent control on business servers. Application control evidence needs to show effective enforcement, approved software, integrity verification and properly managed exceptions across each applicable system population.
No. ASD’s indicators for unique credentials (IT.PRO-13.6) rate shared local administrator credentials across a device fleet as not effective. Unique credentials deployed to only some device populations rate as partially effective. A fully effective rating needs unique credentials for each local administrative account. Where uniqueness cannot be enforced, compensating controls, monitoring of shared credential use and a remediation plan are needed. Reconcile management reports against the device inventory to find the actual coverage.
Yes. Business systems includes applications that keep their own accounts, roles and entitlements controlling what users can do. The identity actions that apply cover unused accounts, secrets storage, phishing-resistant MFA, legacy authentication and unique credentials. Periodic privilege reviews under IT.PRO-12.1 also apply. Enterprise directory controls may not reach accounts held locally within an application, so those access paths need to be identified and reviewed separately, including relevant service accounts and application-specific credentials.
No. In the enterprise IT chapter, Regular and proven backups is mapped to Boundary services, Identity services, Critical processes and services, Privileged environments and Business systems. User devices is absent from that mapping, while Business systems does carry these actions. The Essential Eight’s Regular backups strategy contributes to backups and restore testing (ML1) and backup isolation (partial, ML1) in the transition guide. The chapter’s domain mapping is a separate matter from an organisation’s own broader operational backup and recovery arrangements.
Yes. Network segmentation actions IT.PRO-18.1 and 18.2 apply to Business systems. They cover grouping systems into zones based on business criticality and trust level, and restricting lateral movement to explicitly approved pathways and services. ASD’s transition guide maps the Essential Eight’s segmentation contribution to Privileged environments, and ordinary Business systems is outside that mapping. Existing Essential Eight work may therefore provide limited reusable evidence for business application segmentation, which is assessed against the applicable actions.
AI embedded in general enterprise SaaS applications may fall within Business systems. ASD’s AI guidance indicates that AI supporting core organisational outcomes is more likely to belong to Critical processes and services, while public-facing AI services and APIs may be relevant to Boundary services. AI tools capable of administrative actions belong within Privileged environments. The application’s purpose and permissions decide the scope. Executive accountability for AI use sits under GOV-08 in Governance and culture.
ASD Essentials Identity Services and ITDR
ASD Essentials Critical Processes and Privileged Environments
ASD Essentials Explained: Framework, Chapters and Enterprise IT