ASD ISM 1731 Plan and coordinate intrusion remediation from trusted separate systems
What it says
Planning and coordination of intrusion remediation activities are conducted using trusted systems separate from a compromised system.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishOnce a system is compromised, the response team plans and coordinates the clean-up on a separate, trusted system so the attacker cannot watch or interfere with the remediation effort.
When a system has been compromised, it can no longer be trusted. An attacker who still has a foothold may be reading email, watching chat channels, capturing keystrokes or reading documents stored on that system. If the response team uses the compromised system to write up the remediation plan, schedule the eviction, share indicators of compromise or coordinate who is doing what, the attacker gets a front-row seat. This control requires that the planning and coordination of intrusion remediation activities happen on trusted systems that are separate from the compromised system. In practice that means the incident response team has somewhere clean to work: separate devices, separate accounts and separate communication channels that the attacker has no reason to have access to. It matters because an attacker who can see the remediation plan can adapt to it. They can establish new persistence before the planned eviction window, delete evidence the team intends to collect, or simply lie low and return once the team declares victory. Keeping the planning and coordination off the compromised system removes that advantage and gives the organisation a genuine chance of a clean, one-shot eviction.
Free. Save your status, tasks and notes.
Why it matters
If remediation is planned and coordinated on the compromised system, the attacker can read the plan, learn which accounts, hosts and timings are involved, and act ahead of the response team. Typical consequences are the attacker moving to new persistence mechanisms before the eviction, tampering with or deleting evidence, re-entering after the clean-up, or exfiltrating the response team's own documentation and credentials. The result is a failed or repeated remediation, a longer and more expensive incident, and lower confidence that the environment is ever truly clean.
How to implement
The incident response lead defines in the incident response plan which trusted systems and communication channels the team will use to plan and coordinate remediation, and documents that these are separate from the systems that may be compromised.
The IT or security team provisions the trusted systems ahead of time (for example, standalone laptops or a separate out-of-band collaboration tenancy) with their own identities and credentials that are not managed by, or synchronised with, the production environment.
The incident response lead issues a standing instruction, triggered when a compromise is declared, that all remediation planning, task tracking, indicator sharing and status updates move to the trusted systems and stop on the compromised system.
The security team keeps a current contact list, escalation details and incident templates stored on or reachable from the trusted systems so the team can start coordinating without touching the compromised environment.
The incident response lead includes a switch-over to the trusted systems in incident response exercises, so team members practise planning and coordinating remediation from the separate systems and any access or tooling gaps are fixed before a real incident.
Keep it running
Day to day, this control is mostly about readiness. The incident response plan should already name the trusted systems and communication channels the team will switch to when a compromise is declared, so nobody has to improvise while an attacker is active. Trusted systems are typically kept separate from the production environment (for example, standalone devices, a separate tenancy or an out-of-band collaboration service with independent identities) so they do not share the accounts, identity provider, email or file stores that may be compromised.
When an intrusion is confirmed, the incident lead moves all planning and coordination to the trusted systems and tells the team not to discuss the response on the compromised environment. That includes remediation plans, task lists, timelines, indicators of compromise, meeting invitations and status updates. Anything already drafted on the compromised system should be treated as potentially exposed.
Keep it practical: the team needs quick access to the trusted systems, pre-provisioned accounts and a current contact list held outside the compromised environment. Exercise the switch-over during incident response drills so the team is comfortable working from the separate systems under pressure.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the incident response plan or intrusion remediation procedure.
Look at
Check whether it specifies that planning and coordination of remediation take place on trusted systems separate from a compromised system, and names what those systems and channels are.
Good evidence
The plan clearly identifies the separate trusted systems and communication channels and states that they are used for remediation planning and coordination once a compromise is declared.
- Check 2 of 5What an auditor asks for
Ask for
Ask for a description or inventory of the trusted systems set aside for incident coordination.
Look at
Look at how they are separated from the production environment, including whether they use independent accounts, identity providers and communication services rather than the ones that could be compromised.
Good evidence
The trusted systems are genuinely separate, with their own identities and services, so a compromise of the production environment does not give an attacker access to them.
- Check 3 of 5What an auditor asks for
Ask for
Ask for records from a recent intrusion or incident response exercise.
Look at
Trace where the remediation plan, task lists and team communications were created and shared during the response.
Good evidence
Records show the planning and coordination were carried out on the separate trusted systems, not on the compromised system.
- Check 4 of 5What an auditor asks for
Ask for
Ask how the response team is told to move to the trusted systems when a compromise is confirmed.
Look at
Look for a defined trigger, a named person responsible for issuing the instruction, and evidence it was communicated during a real incident or exercise.
Good evidence
There is a clear trigger and instruction, and team members can describe how and when they switch to the trusted systems.
- Check 5 of 5What an auditor asks for
Ask for
Ask to confirm that no remediation planning or coordination artefacts were created or shared on the compromised system during a recent intrusion.
Look at
Check the compromised system's email, chat, file stores and calendars for remediation plans, task lists, indicators of compromise or meeting invitations relating to the response.
Good evidence
No planning or coordination artefacts are found on the compromised system, and any material drafted there before the switch was treated as exposed and moved to the trusted systems.
Mappings
Closest match in ISO/IEC 27001: A.5.24, Information security incident management planning and preparation, which this control partially meets.
ISO/IEC 27001: 3 mappings
This control partially meets A.5.24.
ISM-1731 requires organisations to coordinate intrusion remediation from a separate system than the one compromised, addressing integrity and trust in incident response operations. Annex A 5.24 requires the organisation to plan and prepare incident management processes, roles and responsibilities, within which using separate systems for remediation coordination is a practical control implementation. Annex A 5.24 is broader planning/governance for incident management, while ISM-1731 is a specific operational requirement about the tooling/environment used during remediation.
This control partially meets A.5.26.
ISM-1731 requires that intrusion remediation planning and coordination be performed from trusted systems separate from any compromised system. Annex A 5.26 requires organisations to respond to information security incidents in accordance with documented procedures, covering the overall incident response process. ISM-1731 is a specific operational requirement within incident response (the trusted, out-of-band coordination environment), whereas Annex A 5.26 is broader and does not mandate that particular separation.
This control partially overlaps A.5.28.
ISM-1731 requires organisations to plan and coordinate intrusion remediation activities from trusted systems separate from compromised systems. Annex A 5.28 focuses on having procedures to identify, collect, acquire and preserve evidence for information security events, which commonly needs trusted tooling and systems to avoid tampering by an attacker. The overlap is in incident-response handling on trusted resources, but Annex A 5.28 is evidence-centric while ISM-1731 is remediation coordination-centric.
ASD Essential Eight: 3 mappings
This control partially meets E8-RA-ML2.13.
ISM-1731 requires that planning and coordination of intrusion remediation occur on trusted systems that are separate from any potentially compromised system. E8-RA-ML2.13 requires the organisation to enact its incident response plan once an incident is identified, and using separate trusted coordination systems is a practical measure that strengthens safe execution of that plan. E8-RA-ML2.13 is broader about initiating response activities, while ISM-1731 is a specific safeguard about where remediation coordination must occur to prevent attacker observation or interference.
This control partially overlaps E8-RA-ML3.2.
ISM-1731 requires remediation planning and coordination to occur on trusted systems that are separate from the compromised environment. E8-RA-ML3.2 mandates using Secure Admin Workstations for administrative activities, which can serve as the trusted, segregated platform from which remediation actions are coordinated and executed. The overlap is the use of hardened, trusted endpoints, but E8-RA-ML3.2 is broader across all admin tasks while ISM-1731 is specifically about intrusion remediation coordination in response to compromise.
This control supports E8-AC-ML2.11.
ISM-1731 requires planning and coordination of intrusion remediation to be conducted using trusted systems separate from a compromised system. E8-AC-ML2.11 requires that the organisation enact its cybersecurity incident response plan after incident identification, and ISM-1731 provides a concrete operational control that helps ensure the response plan can be executed securely without adversary visibility. E8-AC-ML2.11 addresses the governance trigger to commence response, whereas ISM-1731 constrains the tooling and environment used for remediation coordination.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.