ASD ISM 1732 Coordinating and sequencing intrusion remediation to prevent re-compromise
What it says
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.
What it means
In plain EnglishPlan 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.
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.
Free. Save your status, tasks and notes.
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.
How to implement
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.
Keep it running
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.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the incident response procedures or playbooks that cover remediation after a confirmed intrusion.
Look at
Look 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.
Good evidence
The 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.
- Check 2 of 5What an auditor asks for
Ask for
Request the remediation plan or incident record from a recent intrusion, or from an exercise if no real intrusion has occurred.
Look at
Check 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.
Good evidence
A 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.
- Check 3 of 5What an auditor asks for
Ask for
Ask for evidence of how business continuity requirements were considered when scheduling remediation, such as meeting notes, risk acceptances or communications with service owners.
Look at
Look 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.
Good evidence
Decisions 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.
- Check 4 of 5What an auditor asks for
Ask for
Request monitoring records or security operations notes covering the period after remediation was completed.
Look at
Check 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.
Good evidence
Post-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.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the post-incident review or lessons-learned report from a recent intrusion or exercise.
Look at
Look 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.
Good evidence
The 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.
Mappings
Closest match in ISO/IEC 27001: A.5.26, Response to information security incidents, which partially overlaps with this control.
ISO/IEC 27001: 1 mapping
This control partially overlaps A.5.26.
ISM-1732 requires intrusion remediation activities to be coordinated and sequenced to minimise re-compromise while maintaining business continuity. Annex A 5.26 overlaps because responding to incidents in accordance with documented procedures typically includes coordinated containment, eradication and recovery steps, including timing and dependencies. Annex A 5.26 is broader as a general incident response requirement, while ISM-1732 provides a more specific emphasis on sequencing remediation to prevent attacker re-entry during clean-up.
ASD Essential Eight: 1 mapping
This control partially overlaps E8-RA-ML2.13.
ISM-1732 requires intrusion remediation activities to be coordinated and sequenced to reduce re-compromise risk while balancing operational risk and continuity needs. E8-RA-ML2.13 overlaps because enacting the incident response plan is the mechanism that typically governs how remediation tasks are coordinated, approved and timed after an incident is identified. E8-RA-ML2.13 is broader at a programmatic level (plan activation across the response lifecycle), whereas ISM-1732 is specifically about sequencing and coordination of remediation steps to prevent re-entry.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.