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 prescribes no SOC, MDR provider or XDR product, but its detect and respond actions describe the work a SOC does every day: logging, detection, triage, investigation and response.
A managed detection and response (MDR) provider can carry much of the daily work, while the organisation stays accountable for security outcomes.
Incident response under ASD Essentials covers how a cyber security incident is declared, contained, eradicated and recovered from, along with external reporting and the post-incident review. ASD’s AI guidance adds considerations for governing and monitoring AI agents used in security operations.
This guide sets SOC operations, MDR, incident response planning and AI triage against the principles and actions ASD published on October 15, 2026.
Most of what a security operations centre (SOC) does sits in the Visibility and response domain in ASD Essentials: central logging, detection, triage, incident response and post-incident reviews. That domain applies in every priority phase, so monitoring and response start at the outset and widen as each technical domain is implemented.
Staffing the SOC is a Governance and culture question. GOV-04 Cyber security resourcing calls for sufficient cyber security personnel and resources with the required skills to operate and monitor security controls. Its second action asks for a periodic review of resourcing against threat trends, incident outcomes and organisational changes.
sufficient cyber security personnel and resources with the required skills
The work divides by skill. Detection engineers maintain rules and coverage, analysts investigate findings and incident responders support containment and recovery. An outsourced or co-managed SOC is held to the same test: each party has the skills and capacity for the work it has been assigned.
Coverage hours apply to the customer as well as the provider. A 24x7 service can still stall overnight if nobody on the customer side is available to approve containment, grant system access or confirm that an administrator’s activity was legitimate.
The mapping below follows the enterprise IT chapter. The OT chapter orders its priority phases differently and needs its own monitoring scope.
An investigation may show that a preventive control was bypassed, that an attacker used an approved administrative tool or that a missing log source hid activity. SOC records are evidence of what was detected and investigated. They do not show that every control is effective, so assessors still need configuration, coverage and validation evidence from the teams that own the preventive controls.
The enterprise IT chapter also takes in non-production environments. Development, testing and staging systems may hold real credentials or connect to production. Their monitoring is set by that exposure and by what each system does, whatever the environment is called.
SOC or MDR onboarding can follow ASD’s priority phases, beginning with Boundary services and Identity services. For each domain, write down which systems are covered, which events are collected, which detections run and how findings are investigated. Then check that the events arrive with enough detail to investigate. A firewall that forwards only its deny records, for example, cannot show what happened over a connection it allowed.
Under managed detection and response (MDR), a provider performs much of the daily Visibility and response work in ASD Essentials. It may work through the organisation’s existing endpoint, identity and network security products, or through a broader SIEM or XDR platform.
Receiving alerts, investigating the activity behind them and taking action are different services, and an agreement may cover only some of them. A provider that sees endpoint alerts but cannot examine identity changes or network activity may struggle to scope an incident. It can report that a host is compromised without being able to say which accounts were used from it or where they went next.
ASD prescribes no division of responsibility between an organisation and its provider. The allocation below reflects common practice, and each organisation still has to work out its own responsibilities for every applicable action.
DET-04 applies in Boundary services, Identity services, Privileged environments and Critical processes and services. A provider that only investigates endpoint alerts may miss the legitimate administrative tools and access paths used across those domains. Privileged environments in ASD Essentials explains the baselines that separate approved administration from malicious use of legitimate tools.
The choice of model turns on what the organisation can already do, the hours it needs covered and who holds the authority to respond.
In-house SOC: Internal personnel run detection, investigation and response. That takes sufficient staff, engineering capability and access to specialists.
Outsourced SOC or MDR: A provider operates the agreed monitoring and investigation. The organisation supplies business context, authorises response and stays accountable for security outcomes.
Co-managed SOC: The provider may supply 24x7 triage or fill response gaps while internal analysts handle specialist investigations, incident decisions, critical systems or privileged environments.
Each arrangement has to settle:
Who investigates and responds overnight, on weekends and during staff absences.
Who develops, validates, tunes and retires detections.
Whether the service works with current SIEM, endpoint, identity and other security tools.
How an investigation, with its evidence, findings and open actions, moves between teams.
Test the division with representative incidents. Walking a compromised administrator account found on a weekend through the arrangement shows who acts at each step, which a service description cannot.
Cross-domain detection joins events from different systems, because many incidents look routine inside any single product. ASD’s DET-03 action states:
Use indicators from across identities, applications, data and infrastructure activity rather than isolated signals when identifying cyber security incidents.
A forwarded product alert does not always carry the evidence behind it. The authentication events, process activity, administrative changes and network records an analyst needs may call for additional collection or permissions.
Take an unfamiliar sign-in followed by an unexpected privileged role assignment and an endpoint detection. Each could be closed on its own as low risk. Read together, they raise questions the investigation has to answer: whether the same identity was involved, which systems were accessed, what administrative changes were made and whether the endpoint activity supports the suspected compromise. The case record keeps:
The accounts, devices, applications and services involved.
Relevant activity before and after the initial detection, with timestamps.
Original events, searches, detection findings and related records.
Approved changes, expected administrative activity and known exceptions.
The analyst’s conclusion, alternative explanations and remaining uncertainty.
Recommended or completed actions, approvals and their observed results.
A closed alert without these details offers little assurance, whatever XDR, SIEM or other product label the provider uses.
Coverage can also lapse without anyone noticing. A provider should be able to explain what happens when a log source stops sending, an integration loses its permission or a change introduces activity that no existing rule covers.
Incident response in the enterprise IT chapter of ASD Essentials rests on RES-03 Cyber security incident response (containing, eradicating and recovering), RES-04 Cyber security incident insights (learning and improving) and RES-05 Cyber security incident coordination (responsibilities and coordination).
ASD does not publish a stage-by-stage mapping of its respond principles to an incident response lifecycle. The table below is our reading of how they support the common stages.
The stages overlap, and findings during recovery may send the team back to eradication. For an identity compromise, revoke active sessions and refresh tokens as well as resetting passwords, because a password change alone may leave existing sessions valid.
At every stage, record what happened, when, who decided and whether the intended outcome was achieved.
ASD’s report on the Commonwealth’s cyber security posture in 2025 found that 90% of surveyed entities had an incident response plan. With plans that common, an assessment turns on other questions: whether the plan covers the systems that matter, defines achievable outcomes and has been tested.
ASD’s fully effective indicator for the response action describes an approved plan covering roles, escalation paths, response procedures, target timeframes and intended containment, eradication and recovery outcomes. A workable plan addresses:
The domains, systems, cloud services, providers and non-production environments covered.
The incident lead, the person authorised to accept business disruption and deputies for both.
Containment and recovery timeframes by severity, with the outcomes that mark completion.
Containment measures responders and any SOC or MDR provider can execute without further approval.
Internal escalation paths, legal counsel, insurers, service providers and external reporting parties.
The logs and forensic artefacts to preserve and how to obtain them when normal administrative access is compromised.
Who speaks to employees, customers and the media, with alternatives when normal email is unavailable.
Keep the main plan short enough to use during an incident and move the technical detail into playbooks. Set targets responders can meet with the access and authority they have. A containment target means little if the only person who can approve isolation cannot be reached overnight.
Before an incident, the organisation decides which actions its provider or internal SOC team may take independently and which wait for approval. That SOC response authority is written per system and per action type, because permission to investigate an endpoint does not necessarily include permission to isolate it.
Responders may, for example, be authorised to revoke compromised sessions or isolate supported workstations, while disabling a critical service or making a disruptive network change needs additional approval. Record these permissions, and when they apply, in both the provider’s agreed responsibilities and the incident response procedures. The authority also covers:
When an alert requires examination and who can access the supporting records.
When the provider contacts the incident lead and how an unanswered escalation proceeds.
Which actions may begin immediately and which require approval.
Which systems and activities remain the organisation’s responsibility.
How decisions, approvals and action results are captured in the incident case.
Declaring an incident is a formal decision that an event meets the organisation’s incident criteria, and someone has to own it. ASD’s coordination principle includes the responsibilities for declaring cyber security incidents, so the plan names who decides, on what criteria and how the declaration is recorded. Typical triggers include:
responsibilities for declaring cyber security incidents
Record the declaration time, severity, affected systems and supporting evidence. Keep separate timestamps for the first relevant event, SOC detection, declaration and the start of containment. With a single timestamp per incident, nobody can tell slow detection from a slow decision or slow action, and response cannot be measured against the approved targets.
Incident response playbooks turn the approved plan into procedures for specific compromise scenarios. Following the ASD Essentials priority order, write the Boundary services and Identity services playbooks first, then extend to Privileged environments from priority phase 2.
An identity compromise may begin with stolen credentials, an unexpected authentication method or unauthorised use of an existing account.
Risky sign-ins, unexpected MFA method registration, unusual sign-in locations or reported authentication prompts.
Revoke sessions and refresh tokens, disable the account where necessary and block the source.
Sign-ins, mailbox rules, application consent grants, file access and newly registered devices during the suspected compromise period.
Remove unauthorised authentication methods, forwarding rules and application consent grants, then reset credentials.
Re-enrol the user with phishing-resistant MFA and restore access once the compromise is addressed.
A password reset alone does not finish the job. If nobody checks for new authentication methods, application access or another route back in, persistence can stay in place. Detection coverage for these scenarios is discussed in ASD Essentials and identity threat detection.
This playbook covers Boundary services such as remote access gateways, web applications and file transfer systems.
Known vulnerability exploitation, web shells, unexpected outbound connections or vendor advisories confirming active exploitation.
Restrict access to the service or take it offline, preserving logs and memory where possible before rebooting.
Credentials stored on the device, configuration changes and connections into the internal network.
Apply the fix or rebuild from a clean image, rotate stored credentials and remove attacker-created accounts.
Restore access after verifying the fix and monitor for repeated exploitation attempts.
A patch may close the vulnerability without removing persistence. Before closing the incident, work out what happened after initial access and whether other systems or credentials were affected. Where integrity is uncertain, rebuilding may be more appropriate than returning the service to operation.
Privileged account misuse can affect every system a compromised administrator or service account manages.
Administrative activity outside approved hours or tools, unexpected privileged role assignments, changes to logging or security controls, and access from outside the privileged environment.
Disable the account, revoke sessions and protect other administrator and break-glass accounts.
Changes to group memberships, security policies, audit settings, backups and other systems the account can reach.
Reverse unauthorised changes, remove attacker-created accounts and roles, and examine directory services for persistence.
Reissue credentials through the approved secure administration process and verify that logging still works.
Disabling the account stops further use of it. Unauthorised role assignments, persistence mechanisms and security policy changes made through it may still be in place until someone checks for them and reverses them.
The cloud and OT chapters of ASD Essentials each address response in their own terms, so enterprise IT procedures cannot be assumed to be sufficient there.
ASD’s response action for SaaS and PaaS calls for 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 operations resume. Coordination includes provider notification arrangements and the division of investigative responsibilities under shared responsibility.
ASD’s OT chapter calls for a rehearsed plan to disconnect remote access quickly, per-site copies of playbooks, drawings and break-glass secrets that remain available independently of affected systems, alternative communications between sites and staff, and forensic artefact collection within pre-approved areas.
In the cloud procedure, note which evidence and which actions depend on the provider, so responders know what has to be requested. OT containment follows the site’s approved operational procedures, since an action suited to an office workstation may be unsafe on a system supporting industrial operations.
A SOC or MDR service may handle routine investigation and initial containment without covering major-incident forensics. An incident response retainer arranges that specialist help in advance. First agree where routine monitoring ends and specialist response begins, then review:
Response time: How quickly specialists engage, including overnight and on weekends.
Scope: Forensic investigation, containment support, recovery, follow-up hunting and reporting assistance.
Access: Whether responders already have the tools, accounts and log access, or these must be arranged mid-incident.
Coordination: How the team works with the SOC, managed service providers, the insurer and legal counsel.
In a typical handover, the MDR provider revokes a compromised account’s sessions, then a specialist team reconstructs the compromise, the data accessed and any spread, working from the same case records.
A supplier may be where the incident started, or the only party able to take a particular action. Put supplier contact paths and notification timeframes in both the plan and the supplier arrangements. Where cyber insurance applies, check whether the policy specifies approved responders or notification procedures, and reflect them in the retainer and the plan.
ASD’s fully effective indicator for incident coordination calls for documented external reporting triggers, contacts and timeframes covering the parties identified by the organisation’s legal, regulatory, contractual and organisational obligations.
ASD accepts cyber security incident reports through cyber.gov.au and notifies organisations it believes may be affected by malicious activity. Its Annual Cyber Threat Report 2025-26, published October 26, 2026, reports that ASD responded to more than 1,500 incidents and issued over 4,400 notifications.
The Commonwealth cyber security posture report for 2025 found that only 35% of entities reported at least half of the incidents observed on their networks to ASD.
Who else has to be told depends on the organisation and the incident. Law enforcement may also need notification.
Privacy, critical infrastructure and sector regulators may set different triggers, recipients and deadlines.
Contracts may require notification when customer data or services are affected.
Policies may prescribe notification steps that affect coverage.
List each obligation in the plan with its trigger, responsible person and deadline, and have legal counsel confirm the list in advance. The incident lead may need to judge a notification threshold while responders are still scoping the compromise, well before recovery is complete.
Keep dated copies of reports, confirmations and external communications. For any early reporting decision, record the facts known at the time and the basis for the decision.
ASD’s guidance on choosing a chapter explains that outsourcing a service does not transfer accountability for the security outcomes the service is expected to achieve. The organisation still has to find out whether the provider’s detection, investigation and containment work for the systems in scope:
outsourcing a service does not transfer accountability
Ask for current monitoring, investigation and response records. Assurances given at purchase describe the service as it was sold.
Confirm integrations, permissions and security features are configured or authorised for the agreed coverage.
Identify missing telemetry, unsupported environments and incomplete detection coverage by domain.
Assign remediation for detection, response and underlying control gaps.
Document and formally accept risks that cannot be fully addressed, and review those decisions regularly.
The record of one incident often sits on both sides. When a provider recommends disabling a compromised account but the organisation holds that authority, it takes the provider’s investigation record and the organisation’s approval record together to show what happened.
ASD’s assessment process guide advises assessors to engage managed service providers early and confirm that the necessary access and evidence can be obtained. Before relying on the provider for evidence, agree how an assessor will examine source coverage, detection configuration, investigation records and response activity.
Summary reports may fall short. An assessor may need original events and complete cases, with enough access to sample across assets and domains, because a strong record for one endpoint does not show equivalent coverage for identity, boundary or privileged environments. Retrieval also has to keep working if the provider changes or the service ends.
SOC and MDR evidence has to show that triage, investigation and response worked during the assessment period. Installed tools, alert counts and platform availability are context. They do not show whether incidents were identified, decisions met their timeframes or response outcomes were achieved.
ASD’s indicators include triage performance that is “tracked and reported” and incident records judged against the organisation’s own target timeframes. The collection methods are common practice rather than ASD requirements.
A dated export from a ticketing system or provider portal is stronger evidence than a dashboard of current alert counts. Screenshots help when they show the date, scope and tenant or system, but the case itself still has to explain what was investigated and why.
Cover the whole assessment period and sample across alerts, severities and domains. Include closed alerts, since they are the evidence that expected activity was told apart from incidents.
Log source, retention and detection rule evidence is covered in ASD Essentials and SIEM.
A plan that has not been exercised or invoked within the organisation’s own test cycle can be rated partially effective at best under ASD’s indicators (IT.RES-03.1.PE-1).
An executive tabletop and a technical exercise test different things. The tabletop covers declaration, business decisions, escalation and communications. The technical exercise covers evidence collection, containment permissions, tooling and recovery. Many organisations run an executive tabletop at least annually and technical exercises more often, with extra reviews after significant changes to systems, providers or key personnel.
Test the plan’s own targets. An exercise might ask the team to identify a compromised privileged account, reach the authorised decision-maker and execute a supported containment action within the specified timeframe. Record the actual timings and decisions. Where a timeframe or outcome was missed, explain it with reference to severity, complexity and business impact, and give each improvement action an owner and closure evidence.
Include the SOC or MDR provider, so the exercise tests the complete operating model.
Reviewing only some incidents that meet the defined severity threshold, or leaving findings undocumented or unactioned, is rated partially effective under IT.RES-04.1. A useful review records:
First evidence of compromise, detection, declaration, containment, recovery and closure, with the delays between them.
How the attacker gained access and which controls should have prevented or detected it.
Detections, actions and decisions that helped contain or resolve the incident.
Missing logs, unclear authority, unavailable personnel and tools or procedures that failed.
An owner, due date and completion evidence for each fix.
Look past the initial entry point. An attacker may enter through a compromised account, move through an unmonitored administrative path and stay active because a detection did not fire. Each stage points to a separate fix. Feed the results into detection rules, playbooks and the next gap analysis.
A related threat hunt can check for the same techniques elsewhere and add confidence that attacker activity has ended. Reviews of near misses and exercises can surface weaknesses before a more serious incident.
An outsourced SOC or MDR provider is itself a supplier, and its capability, system access and data handling all need assurance. GOV-11 Supplier cyber security assurance asks organisations to select suppliers using cyber supply chain risk assessments proportionate to the risk introduced, keep the supporting assurance evidence and act when that assurance lapses or the supplier’s risk changes.
ASD’s assessment process guide covers an organisation’s own environment and leaves the posture of its suppliers out of scope. ASD has indicated that separate supplier assessment guidance will follow.
Read any certification or attestation report for its scope, assessment period, exceptions and the systems covered. A provider’s ISO 27001 certification or SOC 2 report can contribute to supplier assurance, but neither determines the customer’s ASD Essentials action ratings. ASD’s assessment evidence guide cross-references the ISM, the Essential Eight, NIST CSF 2.0, NIST SP 800-171r3 and AESCSF v2, and does not include ISO/IEC 27001 or SOC 2 in those mappings.
Certification also says nothing about whether every log source is connected or whether incidents meet approved targets.
A provider may hold sensitive logs, investigation evidence and access to organisational systems. The review covers:
Where logs, case records and AI processing reside, and who can access them.
Which provider accounts can reach the environment, how they are protected and how permissions are reviewed.
Which other organisations may access customer systems or security information.
How the provider reports incidents affecting its own systems or services.
How investigation records, detection content and other evidence remain available after the service ends.
An Australian SOC team does not, by itself, show where all processing, backups, support access or AI services occur. Each needs its own answer.
Where a provider processes organisational data with AI or runs agents connected to security tools, include that in supplier assurance. ASD’s AI guidance points to where providers retain prompts and outputs and whether organisational data is used for model training. Its cloud guidance also addresses where AI processing occurs.
Find out which agent identities the provider uses, what permissions they hold, which decisions stay under human review and how AI activity is logged. A provider using AI for triage should be able to show how incorrect closures are found and corrected.
Use these alongside ASD’s questions to ask managed service providers, which include incident response considerations.
Who investigates alerts outside business hours, and what triage and response timeframes apply?
Is hunting included in the standard monitoring service, and how are findings recorded?
Is an incident response retainer included, and who leads a major incident?
Can the provider export dated investigation and monitoring records for the relevant ASD Essentials domains?
A platform demonstration shows what the product can do. Representative records show what the service did, so ask for a completed case, a detection validation result and a coverage report showing unmonitored systems. Repeat these checks at service reviews, especially when coverage, personnel, data handling or supplier risk changes.
AI in security operations falls within ASD Essentials when it processes organisational data, investigates activity or interacts with security tools. ASD’s AI considerations within the Essentials, published on October 15, 2026, explains how existing principles and actions apply to it.
AI considerations within the Essentials
ASD recognises alert triage, event correlation and threat intelligence as areas where AI may help defenders, to support the actions in the ASD Essentials series rather than replace them.
to support the actions in the ASD Essentials series rather than replace them.
It also states that accountability for security outcomes remains with people.
accountability for security outcomes remains with people.
GOV-08 Executive artificial intelligence accountability places responsibility for AI oversight and risk management with executive leadership. It has no direct Essential Eight equivalent. AI-enabled security products fall within its scope, so SOC AI risks belong in the risk register, as ASD’s GOV-08 indicators expect. The ASD Essentials Governance and culture guide explains GOV-08 and its evidence requirements.
Commonwealth entities should also consider PSPF Policy Advisory 001-2026 on cyber readiness in the frontier AI era, dated May 27, 2026, and Direction 002-2026 on AI-enabled risks and legacy technology, dated September 29, 2026.
Scope SOC AI by function, connectivity, criticality, permissions and the consequences of compromise. ASD’s AI guidance for enterprise IT states that AI agents and their non-person identities are relevant to identity services, while AI tools capable of administrative actions belong within privileged environments.
AI agents and their non-person identities are relevant to identity services, while AI tools capable of administrative actions belong within privileged environments.
Give each agent a defined purpose and an accountable owner. Review its effective permissions, including what it can reach indirectly through integrations and automation workflows. A read-only agent that can trigger a workflow running under an administrative account has, in effect, that account’s reach.
An AI investigation routinely reads content the attacker wrote or influenced. Email bodies, command lines, filenames, documents and web pages may all carry text meant to redirect an agent.
ASD identifies indirect prompt injection through emails, documents or web content processed by AI agents with access to tools or data, and recognises that prompt injection cannot be completely prevented.
through emails, documents or web content processed by AI agents with access to tools or data,
prompt injection cannot be completely prevented.
Since injection cannot be ruled out, security depends on limiting what a manipulated model can do:
Triage agents generally get read-only access, with response permissions kept in controlled workflows.
Text aimed at an AI assistant inside a command line or malicious email is evidence. It gives no authority to change detection rules, close unrelated cases or execute administrative actions.
Actions affecting accounts, endpoints or network controls follow the approved response authority, since prompt filtering alone is insufficient.
ASD’s AI guidance for cloud asks that content retrieved by AI systems be inspected for malicious instructions.
ASD’s AI guidance for enterprise IT says centralised event logging should capture relevant prompts, outputs, retrieval activities and administrative actions, while accounting for the sensitivity and volume of AI interaction data. A usable record identifies the agent identity, sources accessed, queries, findings, requested changes and executed actions, along with human approvals, rejected recommendations and overridden conclusions.
relevant prompts, outputs, retrieval activities and administrative actions
Under DET-04, a baseline of the tools an agent normally calls and the environments it queries flags unexpected access, such as a query against an unrelated environment or an attempt to use a privileged tool. The baseline catches this even when the agent’s written conclusion looks reasonable.
AI triage can support DET-03 by examining alerts against documented incident thresholds and preparing findings for the SOC. The action does not say whether a person or an AI system makes the initial assessment. The outcome it looks for is timely decisions, appropriate escalation and evidence that the process works.
The documented triage process should identify which alert classes AI can assess or close, which findings need analyst review and which alerts always go to a human investigator. An AI verdict of account compromise has to cite the original sign-in and endpoint events and explain why they support it. A bare low-risk label is insufficient.
ASD does not prescribe an automation level or a model of response modes. Its guidance asks that AI tools capable of administrative actions operate through privileged environments, with their actions recorded and significant AI-generated conclusions validated. The graded modes below reflect common SOC practice, and each operates within the approved RES-03 procedures.
operate through privileged environments
The AI investigates and recommends, while an authorised analyst decides whether to proceed.
The AI prepares an action, and an authorised person confirms the target and expected effect before execution.
The AI executes a narrowly scoped action the organisation has explicitly authorised, commonly a reversible one with tested recovery.
More automation rests on measured performance, such as analyst agreement and incorrect closures, with the authorisation recorded. Confidence scores alone are too thin a basis.
The mode can vary by action, such as an isolation request an analyst must approve. However the agent words its recommendation, what counts is the permission and approval the workflow enforces.
A completed AI investigation shows what was examined, how the verdict was reached and whether any action followed the approved procedure. Keep:
Recorded against the workflow’s decision thresholds.
The events and searches behind the conclusion, so an analyst can reproduce it.
Whether the AI recommended or executed an action, and who authorised it.
Any changed verdict or rejected recommendation, with the reason.
Regular reviews of AI closures, agreement rates and incorrect decisions.
Confidence scores support review and do not replace evidence. Sampling checks whether the agent retrieved the relevant records and applied the correct thresholds. For each incorrect closure, record what was missed. The results feed DET-05 detection coverage reviews and RES-04 post-incident reviews, especially where an error reveals missing telemetry, weak detection logic or an ineffective investigation procedure.
For AI in ASD Essentials for cloud, the cloud chapter’s GOV-08 action calls for executive or delegate approval before enabling material SaaS or PaaS AI functions, and ASD’s cloud AI guidance treats agents with SaaS administrative or cloud control plane access as privileged.
executive or delegate approval before enabling material SaaS or PaaS AI functions
In ASD Essentials for OT, detection and response have to account for operational safety and availability.
ASD also asks organisations to ensure automated actions recommended or taken by systems with input from AI cannot compromise safety functions.
ensure automated actions recommended or taken by systems with input from AI cannot compromise safety functions.
AI that depends on vendor cloud services should not weaken OT isolation. Log AI recommendations, automated actions and operator overrides, and keep authority in the response process with the personnel responsible for operational safety.
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.
ThreatDefence delivers managed detection and response through its own AI SOC platform, and for supplier assurance it is ISO 27001 and PCI DSS certified and holds a SOC 2 report.
DFIR runs on the same platform as SIEM, NDR and identity threat detection. Containment can range from host isolation and session revocation to sender blocking and password resets.
See how cyber incident response works with the service.
Organisations can also rate their environment 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
Δ
No. ASD Essentials describes security outcomes, such as protected central logging, timely alert triage, cross-domain incident identification and tested response procedures. It prescribes no SOC operating model or security product.
An internal SOC, an outsourced MDR provider or a co-managed arrangement can each work if the required capabilities operate effectively for the systems in scope. Outsourcing does not transfer organisational accountability, and a managed arrangement brings supplier assurance work with it.
No. ASD Essentials does not ask for an incident response retainer or any particular commercial arrangement. An assessment looks at whether the organisation can respond effectively using documented, tested and approved procedures.
The organisation still needs forensic, containment and recovery capability within reach when an incident occurs. A retainer can secure specialist availability, engagement times and access arrangements in advance, which matters most where those skills are not kept in-house.
No. ASD leaves target response timeframes to each organisation. The fully effective indicator for IT.RES-03.1 expects an approved plan defining roles, escalation paths, procedures, target timeframes and intended containment, eradication and recovery outcomes.
A plan without defined timeframes or outcomes is rated partially effective. Incident records and exercises are then judged against the organisation’s own targets, taking account of severity, complexity and business impact.
Use exercises. One of ASD’s fully effective indicators for IT.RES-03.1 states that where no relevant incident occurred during the assessment period, “appropriately scoped exercises” show that the organisation can achieve its target timeframes and intended response outcomes.
Keep the scenario, participants, decision log, actions, actual timings, outcomes and improvement records. An exercise that includes the SOC or MDR provider also shows whether escalation, approval and containment work across organisational boundaries.
Not by name. IT.RES-05.1 asks organisations to integrate external coordination obligations into incident response, with documented triggers, contacts and timeframes for parties identified by legal, regulatory, contractual and organisational requirements.
ASD’s evidence guide links the action to ISM-0140, the Essential Eight requirement from Maturity Level Two to report incidents to ASD as soon as possible after they occur or are discovered. Keep evidence of submissions and notification decisions.
Yes, where the evidence shows the triage process meets the relevant actions and effectiveness indicators. ASD recognises alert triage as a task AI can support, while DET-03 focuses on documented thresholds, timely decisions, appropriate escalation and performance.
Keep AI verdicts, supporting events, queries, analyst reviews and quality sampling records. The assessor judges from those records whether AI-assisted triage is effective. A confidence score or a claim of automation will not carry the rating.
Yes. ASD treats AI-enabled security products as AI assets within the scope of ASD Essentials, and GOV-08 places responsibility for AI oversight and risk management with executive leadership.
An AI register can record SOC AI capabilities, models, agents, accountable owners, permissions, connected systems, data handling and provider relationships, along with which AI recommendations need human approval and what records are kept.
ASD sets no fixed number of SOC analysts. GOV-04 asks for sufficient cyber security personnel and resources with the required skills to operate, monitor, maintain and manage security controls, with periodic review against threat trends, incident outcomes and organisational changes.
Staffing depends on the systems monitored, alert workload, coverage hours, automation and specialist support. Alerts left uninvestigated overnight may indicate insufficient coverage, and ASD’s indicators expect skills gaps to be addressed through recruitment, training or contracted services.
ASD Essentials SIEM, Detection Rules and Threat Hunting
ASD Essentials Visibility and Response
Essential Eight and ASD Essentials Compliance Monitoring and Reporting