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 rates asset and risk identification, centralised event logging, detection and incident response together in one enterprise IT capability domain, Visibility and response. ASD describes it as the “procedures and capabilities for detecting, analysing and responding to cyber security events and incidents”.The domain applies in every priority phase, and its coverage grows as more systems enter scope. ASD’s transition guide says the capability domains “should not be deferred until the technical domains are complete.”
The Visibility and response principles run in the order an incident does. The organisation identifies its assets and security risks, collects and protects event records, detects suspicious activity, decides when an incident has occurred and responds.
ASD’s implementation planning guide names asset registers and detection and response platforms as the main scope, along with incident response plans and procedures. Most detection and response requirements draw on the Detect (DET) and Respond (RES) families of ASD’s Information Security Manual.
Collecting logs, detecting threats and identifying incidents are separate pieces of work, each rated through its own actions. Central storage holds the evidence. Detection logic picks out the activity that needs attention. Triage decides whether that activity meets the organisation’s incident thresholds.
A healthy logging platform does not show that automated detections fire or that incidents are handled within defined timeframes. The rules can sit untested and alerts can wait past the triage target while every log arrives on time.
Some logging and detection actions are assessed inside the individual technical domains, outside Visibility and response.
Log forwarding is one of them. If systems in the User devices domain stop sending their logs, the gap counts against the User devices assessment, even when the central logging platform is working correctly. The platform and the systems that forward to it are assessed through different actions.
ASD Essentials and SIEM covers the logging actions and security log sources across the technical domains.
The evidence to collect for Visibility and response has to show logging, detection, triage and incident response operating as intended. An ASD Essentials assessment rates effectiveness, and no rating follows from owning a particular security product.
Under ASD’s indicators, detection that relies entirely on manual review is not effective. That puts automated alerting, defined triage timeframes, working correlation and the records of testing and improvement on the list of things to prove.
The collection methods are common practice rather than ASD requirements.
System-generated exports and timestamped tickets are generally stronger evidence than screenshots because they show what happened and when. Where a system offers no export, a screenshot will do if the date, the scope and the tenant or system are all visible in it.
A source that appears in a connector list may still be sending nothing. A typical case is a firewall that stays listed as connected long after an expired certificate or a failed agent upgrade stopped its events. Comparing the expected source inventory with last-event timestamps finds these silent systems, along with the partial collection that a configured integration can hide.
For detection, a list of enabled rules is only the starting point. The records need to show that the required event categories raise alerts, that rules were tested and tuned, and that investigations drew on more than one source.
ASD’s assessment process guide asks whether evidence is recent enough to reflect the current implementation. Log health, triage performance, coverage reviews and exercise records need to span the assessment period, because an export from a single day shows only that day.
Keeping these records current between assessments is covered in Essential Eight reporting.
Essential Eight monitoring and incident response controls carry forward into ASD Essentials Visibility and response, but each one has to be checked for coverage and effectiveness against a broader set of actions.
The Essential Eight spread this work across its strategies. ASD’s transition guide explains that it included logging, monitoring and incident response requirements within individual mitigation strategies.
included logging, monitoring and incident response requirements within individual mitigation strategies
Centralised logging was already part of the Essential Eight from Maturity Level Two, so some of the groundwork may be in place. Existing investments that may be reused include:
Centralised MFA events, privileged access activity and account management records.
Application control records, PowerShell activity and command-line logging.
Controls preventing unauthorised access, modification or deletion of event records.
Processes for analysing security-relevant events and investigating findings.
Existing escalation, reporting and incident response procedures.
ASD’s transition guidance names the areas where these capabilities may need strengthening: forwarding configuration changes, correlating activity across multiple sources, extending detection logic, reviewing coverage, exercising response procedures and incorporating lessons from incidents.
For example, authentication and endpoint logs that are already collected may support several actions as they stand. The organisation still has to show that its detection logic covers the required behaviour, that alerts are triaged within defined timeframes and that coverage gaps are reviewed.
A control carried over from the Essential Eight remains useful. Its presence alone does not make the corresponding ASD Essentials action fully effective.
Moving from the Essential Eight to ASD Essentials explains how to map existing controls and reuse assessment evidence.
Visibility and response is assessed differently across enterprise IT, operational technology and cloud environments. The systems, the available evidence, the operational authority and the consequences of an incident all change from one to the next.
The purpose stays the same in every chapter: detecting security events and supporting an appropriate response. Which actions apply, and which domain holds them, has to be checked chapter by chapter.
In OT, Visibility and response puts more weight on operational dependencies, isolation planning, incident coordination and recovery.
The OT chapter includes actions addressing:
Record the criticality and dependencies of operational assets.
Identify points where complete isolation can be enacted.
Set up alternative communications between sites and personnel.
Collect forensic artefacts within pre-approved areas.
Rehearse procedures for rapidly disconnecting remote access.
Support recovery without supplier assistance.
The OT Visibility and response matrix contains no DET principles. Detection-related actions appear in the OT technical domains, including continuous traffic capture at OT-connected demilitarised zone boundaries.
The OT chapter also has no DET-03, DET-05 or RES-04 actions.
An enterprise IT evidence checklist does not transfer to OT unchanged. It would ask for triage times, coverage reviews and post-incident reviews, which map to actions the OT chapter does not contain. The organisation needs evidence for the actions actually assigned to the OT domains, particularly its approved isolation points, communication arrangements and response procedures.
The cloud chapter keeps the enterprise IT principles for Visibility and response and adapts the detection and response actions to cloud activity and shared responsibilities.
Cloud detection logic includes anomalous control-plane activity such as consent grants, federation changes and privilege elevations. Within the corresponding action, these take the place of the enterprise IT emphasis on suspicious software execution.
Cloud response procedures also address tenant and identity-provider compromise, token and session revocation, unauthorised consent grants and provider notification arrangements.
Responsibility differs between service models:
Many cloud detection actions carry this designation. The provider supplies the capability, and the organisation enables, configures, operates and monitors it.
For SaaS, detection logic and baselining carry this designation. The organisation has no direct operational control here, so it verifies the provider’s capability through assurance evidence.
Cloud assessment evidence follows the responsibility assignment. Where the provider operates the detection logic, the provider’s assurance records may be the appropriate evidence, since the organisation cannot export a configuration it has no access to.
The cloud chapter provides the applicable actions and responsibility assignments.
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.
The platform investigates identity threats, including session token replay, and network threats, including lateral movement, alongside SIEM data on one platform under one licence.
Response actions remain within the authority each customer approves. Case records can be exported for an assessor or at the end of a contract. Australian customers’ data and AI processing remain in Australia.
ThreatDefence does not certify organisations. The assessor determines ASD Essentials ratings.
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
Δ
No. ASD Essentials names no SIEM or other product category. The actions ask for protected centralised logging, automated detection and the ability to investigate evidence across systems. A SIEM is the common way to provide these, and equivalent tools or services may also support them. The assessment examines whether the actions operate effectively, whatever technology sits behind them.
No. ASD prescribes no monitoring hours. Its indicators assess whether alerts are triaged within the response timeframes the organisation has defined and escalated when incident thresholds are met. A short response target may still call for 24x7 monitoring through an internal or outsourced SOC, since relevant alerts can arrive outside business hours. The evidence is actual triage performance measured against the documented targets.
Yes. An MSP or SOC provider can operate logging, detection, triage, investigation and incident response on an organisation’s behalf. Accountability stays with the organisation, which still has to show that the arrangement is effective. Supplier assurance under GOV-11 makes current provider evidence important. The organisation should be able to obtain the relevant log records, investigation histories, response decisions and evidence of operating performance.
The enterprise IT domain includes IDE-01, IDE-04, the secrets scanning action of PRO-13, DET-01, DET-02, DET-03, DET-05, RES-03, RES-04 and RES-05. These cover asset and risk identification, exposed secrets, logging, detection, incident identification, response and improvement. Baselined high-risk access activities under DET-04 sit within the priority phase 1 and 2 technical domains, while log forwarding is rated within each applicable technical domain.
No. ASD’s indicators for IT.DET-02.2 rate detection that relies entirely on manual log review, without automated rules or alerting, as not effective. Automated logic covering only some of the required categories is partially effective. The categories are unauthorised configuration changes, anomalous authentication and suspicious software execution. Rules that are deployed but never tested or tuned on the organisation’s defined cycle are also partially effective.
Yes. The PRO-13 action to Identify and remediate unsecured keys, secrets and credentials by regularly scanning codebases, configuration files, file shares and user collaboration platforms is assessed in Visibility and response rather than Identity services. ASD’s indicators expect scanning across those locations on a defined schedule, followed by assessment and rotation or revocation of exposed secrets within defined timeframes. Leaving discovered secrets in place is not effective.
Identify and remediate unsecured keys, secrets and credentials by regularly scanning codebases, configuration files, file shares and user collaboration platforms
Asset discovery is assessed within Visibility and response through IT.IDE-01.1. The action asks for an approved asset inventory mechanism that supports automated discovery to detect new and changed physical and non-physical assets. ASD’s indicators rate manually maintained inventories without automated discovery as not effective. Discovery that is reconciled with the inventory only manually or inconsistently is partially effective. Maintaining current asset records under IT.IDE-01.2 is assessed in each technical domain.
an approved asset inventory mechanism that supports automated discovery to detect new and changed physical and non-physical assets.
The OT Visibility and response matrix contains no DET principles. Detection activities, including continuous traffic capture at OT-connected demilitarised zone boundaries, appear within technical domains instead. The OT chapter also has no DET-03, DET-05 or RES-04 actions. Its Visibility and response actions emphasise asset criticality, isolation points, alternative communications, approved forensic collection, remote access disconnection and recovery without supplier assistance. See ASD Essentials for OT.
ASD Essentials Assessment and Checklist
ASD Essentials SIEM, Detection Rules and Threat Hunting
ASD Essentials Explained: Framework, Chapters and Enterprise IT