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.
ASD Essentials for cloud covers organisations running entirely on software-as-a-service (SaaS) and platform-as-a-service (PaaS), and sorts every action by who implements it: the customer or the provider.
The Australian Signals Directorate’s chapter applies ASD Essentials principles, actions and domains to cloud services and marks each action as a control the customer operates, a capability the provider supplies or an outcome the provider implements. An organisation can then assess its own cloud security responsibilities without producing evidence for infrastructure it does not operate.
Organisations that still run servers, networks or infrastructure services may also need the enterprise IT chapter.
ASD Essentials for cloud is written for organisations that consume SaaS and PaaS without operating infrastructure or platforms of their own. Traditional enterprise IT controls can describe work these organisations have no means of doing, such as hardening underlying servers, operating provider networks or maintaining platform runtimes.
The cloud chapter concentrates on what the consumer can control or verify: identity, data, tenant configuration, applications, integrations and provider assurance.
ASD gives an example of each service model:
A small Commonwealth entity running its corporate environment on a cloud productivity suite and a few connected applications.
An entity delivering a public-facing digital service using a managed application platform and managed database.
The split follows operational responsibility. A SaaS consumer manages access, configuration and integrations around a finished application. A PaaS consumer also secures the applications and workloads it builds.
ASD’s overview guide is slightly wider on where to start. It names the cloud chapter as the starting point for an organisation that operates predominantly through SaaS or PaaS and needs a clear view of which responsibilities sit with it and which with the provider.
Organisations operating their own servers, directories, networks or infrastructure-as-a-service (IaaS) should consider the enterprise IT chapter. The enterprise IT chapter guide covers how to pick a starting point when environments overlap.
ASD asks organisations to classify each service as SaaS or PaaS by the technology they actually operate. The name on a subscription or procurement agreement does not settle it, and the chapter describes service model boundaries as a matter of degree.
a matter of degree
A product sold as SaaS can expose capabilities that hand its customer responsibilities normally associated with PaaS.
The boundary cases need particular attention:
Where an organisation makes significant use of low-code development, custom applications, scripting, automation or private networking, apply the PaaS-marked actions to those capabilities.
Where a managed platform exposes direct control over compute or networking, consider whether the enterprise IT chapter better describes the organisation’s responsibilities.
A productivity suite is a common case. It may operate primarily as SaaS while also supporting substantial custom applications and automated workflows. The provider still runs the underlying service, but the organisation controls what its applications do, which permissions they receive and how they are configured.
Record the classification for each service, with the features in use and the reason the chosen model applies. An assessor can then follow the decision from the service inventory to the applicable SaaS or PaaS actions.
PaaS customers generally carry more of the security work than SaaS customers because they develop, deploy and configure applications on managed platforms. SaaS customers mostly configure a finished service and verify that the provider performs the work beneath it.
ASD gives each cloud action separate SaaS and PaaS responsibility markers. The two columns part ways where customers control software dependencies, deployment pipelines, workload isolation and platform configuration.
Most actions carry the same marker under both service models.
Third-party libraries show how the split works. A PaaS customer selects and deploys its application dependencies, so finding and remediating vulnerabilities in them falls to that customer. A SaaS customer ordinarily relies on the application provider to do that work and verifies the outcome through assurance.
Configuration baselines follow the same logic. A PaaS provider may supply tools for assessing configuration and detecting drift, but enabling and operating them is the customer’s job. For a SaaS application, the corresponding responsibility is provider-managed and verified through assurance.
ASD describes the markers as indicative rather than determinative. The actual division may differ with the provider, subscription tier, service configuration and available customer controls. Where a service departs from the published matrix, record the difference.
Each action in ASD Essentials for cloud carries a Customer, Supplied or Provider marker. The responsibility marker says who implements the action and what evidence supports its assessment. The distinction is between operating a control, configuring a provider-supplied capability and verifying a provider-delivered outcome.
The multi-factor authentication (MFA) action Use phishing-resistant MFA for users authenticating to systems. is marked Supplied for both SaaS and PaaS.
Use phishing-resistant MFA for users authenticating to systems.
A subscription that includes phishing-resistant MFA does not satisfy that action. The evidence has to show the capability enforced for the users in scope.
Work through each service against the applicable actions, one marker at a time:
Identify the organisation-owned control, who operates it and the evidence showing that it works.
Confirm the provider makes the capability available, then record how the organisation enables, configures and monitors it.
Obtain independent assurance and confirm that its scope covers the service and arrangements actually used.
Keep these decisions in the shared responsibility register, alongside the service model, provider, subscription tier and relevant evidence.
The register reflects the operating arrangements in place. A provider’s marketing description of a security feature is no evidence that the feature is enabled, enforced or included in independent assurance.
ASD has published an asset scoping guide for the cloud chapter but no cloud assessment workbook or evidence guide, so the checks below follow the cloud action text and its markers. The collection methods are common practice rather than ASD requirements.
A dated configuration export or system report is generally stronger evidence of current operation than an isolated screenshot. A screenshot is still useful when it identifies the tenant, the scope and the collection date.
Evidence gathered across the review period also shows consistency. A current MFA policy export captures the configuration on the day it was taken. Earlier exports and exception records help show whether the control stayed effective through the period assessed.
The ASD Essentials assessment guide explains how assessors evaluate evidence and aggregate action ratings.
Cloud provider assurance is how a customer finds out whether a supplier carries out the security responsibilities assigned to it. ASD addresses it mainly through GOV-11 Supplier cyber security assurance, within Governance and culture.
The cloud chapter includes several related actions:
Conduct a proportionate cyber supply chain risk assessment before engaging suppliers and keep the supporting evidence.
Review assurance when it expires, no longer covers a service or feature in use, or when supplier risk changes.
Maintain a register of inherited and retained security responsibilities per provider, and review it as services change.
Maintain a register of inherited and retained security responsibilities per provider, and review it as services change
Establish policies that meet your data sensitivity and sovereignty requirements.
Establish policies that meet your data sensitivity and sovereignty requirements
Restrict software used on cloud services to reputable suppliers.
Provider-marked actions rely on current independent assurance recorded against the shared responsibility register.
ASD names an IRAP assessment as one example. The report needs to cover the services, features, regions and support arrangements the organisation actually consumes.
For each report, check the assessment scope, the date, the exclusions and any limitations it identifies. A provider may hold assurance for one geographic region or service tier that does not extend to every feature the organisation has enabled.
Where a report excludes a relevant service, or no longer reflects the provider’s arrangements, the gap is the organisation’s to address. The provider’s general assurance statement does not close it.
IRAP assessors are ASD-endorsed individuals who conduct independent security assessments. ASD states that they do not accredit, endorse or register systems, and that completing an assessment does not mean compliance.
An appropriately scoped IRAP report can support Provider-marked actions. It cannot show that a customer has enforced MFA, approved application consent grants or configured the audit logging available in its subscription.
ASD’s chapter-selection guidance is also clear that outsourcing a service does not transfer accountability for its security outcomes. Assigning an action to a provider does not, by itself, make a domain effective. A provider feature that has not been enabled or configured remains an unmet responsibility.
ASD Essentials for cloud keeps the enterprise IT domain names and adapts several descriptions to cloud services and the responsibilities customers still hold. The cloud chapter puts its technical domains in a recommended sequence, with Governance and culture and Visibility and response developing across all of them.
The cloud-specific descriptions include:
Integrations, APIs, gateways, internet-facing services and remote access.
Identity providers, authentication and authorisation enforcement, and credential stores.
SaaS administration interfaces, PaaS management and deployment services, and cloud control planes.
Business applications, workflow platforms, data services and custom applications on managed platforms.
Desktops, laptops and mobile devices used to access SaaS and PaaS services.
Critical processes and services keeps its enterprise IT meaning: the processes and services needed to deliver an organisation’s primary outcomes.
The cloud chapter presents the sequence in a figure:
Identity services and Boundary services.
Critical processes and services and Privileged environments.
Business systems and User devices.
ASD recommends implementing technical domains in the sequence shown. Unlike the enterprise IT and OT chapters, the cloud chapter does not assign phase numbers in its text.
in the sequence shown
The order puts identity and service boundaries first. A compromised identity provider or an unapproved integration can affect several cloud applications even when each of those applications is correctly configured.
Governance and culture and Visibility and response apply throughout the sequence. That places provider assurance, identity monitoring and incident response alongside the technical controls from the start, with none of them deferred until the other domains are complete.
The Identity services and Boundary services guides cover those technical domains in detail.
The cloud-specific actions in ASD Essentials cover what customers still control: identities, applications, data, integrations and administrative capabilities. An organisation consuming managed services may have fewer infrastructure duties and still carry substantial responsibility for how those services are used.
Important examples include:
Assess and approve applications, integrations and consent grants before permitting access, and review them on a regular basis.
Identify and mitigate single points of dependency created by OAuth and federated identity providers.
Authorise each identity, assign an owner, constrain it to its intended context and record its activity.
Disable legacy authentication protocols or restrict and monitor them under a time-bound decommissioning plan.
Identify sanctioned and unsanctioned services, tenants and integrations and promptly bring them under organisational governance.
Retain customer control over the keys protecting the organisations most sensitive data, including the ability to revoke provider access.
Onboard, configure and exit services through a controlled process that verifies data retrieval, deletion and access revocation.
Require executive or delegate approval before enabling material SaaS or PaaS AI functions, including review of accessible data, permissions, retention, logging, agents and connectors.
Application consent deserves attention because an integration can access organisational data without a user interacting with the connected application each time.
For PRO-16, an approval record identifies the application, the permissions requested and the authorisation decision. The regular review then asks whether the integration still has a legitimate purpose and whether its access is still appropriate.
Non-person identities get the same treatment. Service accounts, application identities and integration credentials need a known owner and permissions constrained to their intended use.
Cloud backup covers more than application files. Restoring an operational service may also need tenant settings, identities, policies, integrations and configuration.
Check the provider’s backup arrangements against the organisation’s recovery needs. Where those arrangements are insufficient, the chapter calls for customer-controlled backup, isolated repositories and restoration testing against defined recovery objectives.
Encryption and key management turn on how much control the customer holds. A provider-supported encryption feature is a different thing from an arrangement that lets the customer control the relevant keys and revoke provider access.
The chapter calls for executive or delegate approval before a material SaaS or PaaS AI function is enabled. The approval review covers the data the function can access, permissions, retention, logging, agents and connectors.
Assess the feature as it is configured in the tenant. An AI function integrated with organisational information or connected applications may have a different access scope from the same function operating without those connections.
Governance and culture also directs organisations to prefer services that maximise provider-managed security responsibilities and minimise customer-managed components, where consistent with organisational, security and business needs.
Monitoring cloud threats depends on provider audit records, central monitoring and response procedures suited to tenant, identity and service compromise. An organisation that does not operate the underlying infrastructure still needs a record of what happened inside the cloud services it consumes.
ASD’s logging action states: Enable provider audit logging at sufficient tiers and retention, and forward security-relevant logs and configuration changes to a central capability.
Enable provider audit logging at sufficient tiers and retention, and forward security-relevant logs and configuration changes to a central capability.
Confirm which events the subscription produces, how long they remain available and whether the central monitoring capability receives them.
A workable collection check compares a sample of source events with the records arriving centrally. Treat missing administrative actions, delayed delivery or insufficient retention as coverage limitations.
ASD calls for detection logic covering anomalous control-plane activity, including consent grants, federation changes and privilege elevations.
The action is marked Supplied for PaaS and Provider for SaaS. A PaaS consumer operates the supplied detection capability. A SaaS consumer verifies the provider-delivered outcome through assurance.
Investigate related activity together. An unfamiliar application consent grant, followed by an application sign-in and unusual mailbox reads, may be more significant than any of those events viewed alone.
Analysts also need enough identity and application context to tell whether the sequence was authorised. A legitimate integration can produce unusual activity, and a malicious one may operate through permissions that appear technically valid.
ASD calls for cloud incident response procedures covering tenant and identity-provider compromise, provider-side incidents, token and session revocation, removal of unauthorised consent grants and validation of a trusted state before resuming operations.
tenant and identity-provider compromise, provider-side incidents, token and session revocation, removal of unauthorised consent grants and validation of a trusted state before resuming operations
A password reset alone may leave existing sessions, application grants or other access paths active. The response procedure has to deal with each of those mechanisms and then verify that the compromised access has been removed.
Agree the provider’s involvement before an incident: notification arrangements, escalation contacts and the division of investigative responsibilities under shared responsibility.
The Visibility and response guide covers the wider monitoring and incident response expectations across ASD Essentials.
ThreatDefence operates 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.
Australian customers’ data and AI processing stay in Australia. Response actions remain within the authority each customer approves, and case records can be exported for an assessor or at the end of a contract.
Detections for risky application consents and privileged role changes address the consent grants and privilege elevations identified in the cloud chapter. When a cloud identity is compromised, analysts can revoke sessions or remove an MFA method within the customer’s approved response authority.
ThreatDefence can also provide supplier assurance evidence for an organisation’s shared responsibility register, including ISO 27001 and PCI DSS certification and a SOC 2 report.
ThreatDefence does not certify organisations against ASD Essentials. An assessor determines ASD Essentials ratings using the applicable actions and supporting evidence.
Before a formal assessment, the free ASD Essentials Navigator lets organisations rate each action for their own environment and see how principles and domains roll up. 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
Δ
The enterprise IT chapter is generally the starting point for an organisation operating its own servers, directories, networks, hybrid infrastructure or IaaS. Those environments carry operating system, application and network responsibilities that enterprise IT addresses.
The cloud chapter can also be applied to SaaS and PaaS services. Include connections between the environments, such as directory synchronisation and federation, when setting scope and monitoring requirements. The appropriate starting point depends on the organisation’s own operating responsibilities.
No. A provider’s IRAP assessment can support Provider-marked actions when it is current and its scope matches the services, features, regions and support arrangements consumed.
The organisation still has to show its own Customer and Supplied actions, including enforced phishing-resistant MFA and application consent reviews. IRAP assessors do not accredit, endorse or register systems on ASD’s behalf. Their reports provide independent assurance. They do not set an organisation’s ASD Essentials rating or compliance status.
PaaS consumers generally carry more security responsibilities because they build applications, choose dependencies, deploy workloads and configure application environments. SaaS consumers ordinarily configure finished services and rely on provider assurance for more of the underlying security work.
Vulnerable third-party libraries, for example, are Customer-marked under PaaS and Provider-marked under SaaS. ASD provides separate markers for each model, but the actual responsibility still depends on the service tier, configuration and provider arrangements.
Customer means the organisation implements and operates the control. Supplied means the provider makes the capability available and the organisation enables, configures, operates and monitors it. Provider means the supplier implements the action, while the organisation verifies the outcome through current independent assurance.
ASD describes the markers as indicative rather than determinative. Document how each action applies to the service in use, including any differences from the published marker.
No. ASD Essentials for cloud covers SaaS and PaaS. The enterprise IT chapter is the recommended starting point for IaaS because the customer still holds responsibilities for operating systems, applications, identity infrastructure and network architecture even though another party supplies the infrastructure.
PaaS services exposing direct control over compute or networking may approach that boundary. Organisations should examine what they operate and consider whether the enterprise IT chapter better describes their responsibilities.
Yes, where the provider’s arrangements are insufficient for the organisation’s recovery needs. The cloud chapter covers important data and settings, including identities, policies, integrations and tenant configuration, and calls for implementing customer-controlled backup where provider arrangements are insufficient.
implementing customer-controlled backup where provider arrangements are insufficient
Isolate backup repositories through separate accounts, subscriptions or tenants with independent access controls, and test restoration regularly against recovery time and recovery point objectives. Recovery arrangements with the provider should address data loss, malicious deletion and tenant misconfiguration.
Yes. The cloud chapter’s PRO-16 action states: Assess and approve applications, integrations and consent grants before permitting access, and review them on a regular basis.
The action is Customer-marked for both SaaS and PaaS, so each organisation needs its own approval and review process, with records identifying the application, permissions and authorisation decision. Detection and incident response actions also address consent grants, including removing unauthorised grants during a compromise.
Yes. The cloud DET-01 action states: Enable provider audit logging at sufficient tiers and retention, and forward security-relevant logs and configuration changes to a central capability.
The action is Supplied for both SaaS and PaaS: the provider supplies the logging capability and the organisation configures collection and forwarding. Confirm which records the subscription produces, check that they arrive centrally and protect stored logs against unauthorised access, modification or deletion.
ASD presents the cloud priority sequence in a figure. Identity services and Boundary services form the outer ring. Critical processes and services and Privileged environments form the middle ring. Business systems and User devices sit at the centre.
The chapter recommends implementing technical domains in the sequence shown but does not assign phase numbers in its text. Governance and culture and Visibility and response apply across the sequence and develop alongside the technical controls.
ASD Essentials Explained: Framework, Chapters and Enterprise IT
ASD Essentials for OT and Critical Infrastructure
ASD Essentials Identity Services and ITDR