ASD ISM 1732Coordinating and Sequencing Intrusion Remediation to Prevent Re-Compromise
Official control statement
Intrusion remediation activities are coordinated and sequenced to minimise opportunities for re-compromise of a system while balancing operational risk and business continuity requirements.
Quoted as published. Everything else on this page is written by Control Stack.
In plain English
Plan the order and timing of clean-up actions after an intrusion so the attacker cannot get back in, while keeping disruption to the business within tolerable limits.
What this means in practice
When an intruder has been found inside a system, the clean-up is rarely a single action. Passwords need resetting, malware needs removing, compromised hosts need rebuilding, footholds such as web shells or rogue accounts need closing, and the vulnerability the attacker used needs fixing. This control says those activities must be coordinated (everyone knows who is doing what) and sequenced (done in a deliberate order), with two goals held in balance. The first goal is to minimise opportunities for re-compromise. If remediation is piecemeal, the attacker is tipped off early and can dig in elsewhere, or a foothold that was missed lets them straight back in after the "fix". For example, resetting passwords before removing the attacker's remote access means they simply harvest the new credentials; rebuilding one server while another is still compromised means the clean server is reinfected. Sequencing the work so that footholds are removed together, credentials are reset after access is cut, and the entry point is closed before systems come back online denies the attacker that second chance. The second goal is to balance operational risk and business continuity requirements. Pulling every affected system offline at once may be the cleanest option, but it can halt critical services. Remediation therefore has to be timed and staged with an understanding of what the business can tolerate, which functions must stay running, and what the risk is of leaving a compromised component up a little longer. The control asks organisations to make that trade-off consciously rather than either rushing in and breaking the business, or moving so cautiously that the attacker retains access.
Framework
ASD Information Security Manual (ISM)
Control effect (Control Stack)
Responsive
Classifications
NC, OS, P, S, TS
ISM last updated
Sept 2026
Control Stack last updated
29 Sept 2026
E8 maturity levels
N/A
Topic
Handling and containing intrusions
Why it matters
Uncoordinated or badly sequenced remediation commonly leads to re-compromise: the attacker sees partial clean-up, retains an overlooked foothold or freshly harvested credentials, and returns, often more quietly than before. The organisation then pays for the incident twice, with a longer period of attacker access, more data at risk and reduced confidence that the environment was ever truly cleaned. Conversely, remediation carried out without regard to operational risk can cause avoidable outages of critical services, with financial, safety or service-delivery consequences that may exceed the harm from the intrusion itself.
Operational notes
In practice this control is exercised by the incident response team once the scope of an intrusion is understood well enough to plan clean-up. A single remediation lead should own the plan, listing every affected system, account and foothold, the action required for each, its dependencies, and the order in which actions will run. Where possible, actions that cut attacker access (blocking command-and-control, disabling rogue accounts, removing persistence) are grouped into a tightly timed window so the attacker cannot react between steps, and credential resets follow rather than precede that window.
Business owners of affected services need to be consulted on timing so that the plan reflects genuine continuity requirements: which services can be taken down, for how long, and whether interim measures (such as network isolation rather than shutdown) can hold risk at an acceptable level until a maintenance window. The trade-offs made, and who accepted the residual risk of any deferral, should be recorded.
During execution, progress against the sequence is tracked, deviations are called out, and monitoring for signs of re-compromise continues for a period after remediation completes. Afterwards, the post-incident review should assess whether the sequencing worked and whether any re-entry was observed, feeding lessons back into incident response procedures.
Implementation tips
- The incident response lead should build a written remediation plan for each confirmed intrusion that lists every affected system, account and persistence mechanism, the action required for each, and the order and timing in which those actions will be carried out, so nothing is cleaned in isolation.
- The remediation lead should group actions that remove attacker access (blocking command-and-control, disabling attacker-created accounts, removing web shells and scheduled tasks, isolating compromised hosts) into one coordinated window, and schedule credential and key resets to occur only after that access has been cut.
- The incident manager should confirm with each affected system's business owner what downtime is tolerable, which functions must remain available, and whether containment measures such as network isolation can be used instead of shutdown, and record the agreed timing and any accepted residual risk in the incident record.
- The security operations team should keep enhanced monitoring in place on remediated systems, entry points and previously abused accounts for an agreed period after clean-up, and define in advance who will act, and how, if signs of re-compromise appear.
- The incident response team should write the coordination and sequencing approach into the organisation's incident response procedures and rehearse it in exercises, so that the expected order of remediation steps and the process for weighing operational risk against re-compromise risk are known before a real intrusion occurs.
Audit / evidence tips
- AskAsk for the incident response procedures or playbooks that cover remediation after a confirmed intrusion.Look atLook for explicit guidance on coordinating and ordering remediation actions, in particular removing attacker access before resetting credentials and closing the entry point before restoring systems, and on how business continuity requirements are weighed.GoodThe procedures describe a deliberate sequence designed to deny re-entry, name who owns the remediation plan, and require consultation with business owners on timing and acceptable operational risk.
- AskRequest the remediation plan or incident record from a recent intrusion, or from an exercise if no real intrusion has occurred.Look atCheck whether all affected systems, accounts and footholds were identified, whether actions were assigned to named people, and whether the order and timing of actions were set out in advance rather than improvised.GoodA single coordinated plan exists, covers the full scope of the compromise, and shows access-removal actions grouped together with credential resets and system restoration following in a logical order.
- AskAsk for evidence of how business continuity requirements were considered when scheduling remediation, such as meeting notes, risk acceptances or communications with service owners.Look atLook at whether critical services were identified, whether downtime or deferral decisions were discussed with the business, and whether the residual risk of any delay was recorded and accepted by someone with authority.GoodDecisions to take systems offline, isolate them or defer clean-up were made consciously, documented, and balanced against both re-compromise risk and the continuity needs of the affected services.
- AskRequest monitoring records or security operations notes covering the period after remediation was completed.Look atCheck whether remediated systems, previously abused accounts and the original entry point were watched for signs of the attacker returning, and whether there was a defined trigger and response for any such signs.GoodPost-remediation monitoring was in place for a set period, findings were recorded, and any indication of re-compromise was acted on through the incident process rather than missed.
- AskAsk for the post-incident review or lessons-learned report from a recent intrusion or exercise.Look atLook for an assessment of whether the remediation sequence worked, whether any re-compromise occurred, whether the operational impact was as expected, and what changes were made to procedures as a result.GoodThe review candidly evaluates coordination and sequencing, identifies any gaps that could have allowed re-entry or unnecessary disruption, and tracks improvements back into the incident response procedures.
Cross-framework mappings
How ISM-1732 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
sync_altPartially overlaps(1)expand_less | ||
| Annex A 5.26 | ISM-1732 requires intrusion remediation activities to be coordinated and sequenced to minimise re-compromise while maintaining business c... | |
E8
| Control | Notes | Details |
|---|---|---|
sync_altPartially overlaps(1)expand_less | ||
| E8-RA-ML2.13 | ISM-1732 requires intrusion remediation activities to be coordinated and sequenced to reduce re-compromise risk while balancing operation... | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in Cyber security incidents
See all Guidelines for cyber security incidents controls, or browse the full ASD ISM library.