ASD Essentials IT.RES-03.1 Respond to Cyber Security Incidents Using Documented, Tested and Approved Procedures
What it says
Use documented, tested and approved cyber security incident response procedures when responding to cyber security incidents.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishHandles incidents with written, tested and approved response procedures, rather than steps made up under pressure.
Every incident should be handled with a written plan, not improvised. The plan says who does what, who to escalate to, and the steps for incidents such as ransomware. To meet this, leaders approve the plan, and it sets target times and results for stopping the spread, removing the threat and restoring systems. Test it on a set cycle, follow it in every incident, and fix what falls short.
Free. Save your status, tasks and notes.
Where this action applies
What's in each domain?Visibility and response: a capability domain, which ASD applies across all phases from the start.
Why it matters
Without tested steps, responses are made up on the spot. It takes longer to stop the attack, evidence can be lost, and the attacker may stay in or come back while services stay down. With no targets, the same failures keep happening.
How to implement
The head of security or incident response lead should write an incident response plan.
Cover roles and decision-makers, who to escalate to at each level of seriousness, likely incident types, reporting, evidence handling and plans for when systems fail.
Incident response leads and system owners should write a playbook (a step-by-step guide) for each likely incident type.
Set risk-based target times and the intended result for stopping the spread, removing the threat and recovering, at each level of seriousness.
The accountable executive or head of security should formally approve the plan and each playbook, recording the version and date.
Re-approve after any major change, and remove old copies so responders always use the approved version.
The incident response lead should test the plan on a risk-based cycle, using discussion exercises and hands-on drills.
With no real incidents, base exercises on the most likely and damaging scenarios, timing each stage against the targets.
The incident manager should follow the plan and matching playbook once an incident is declared, logging when each stage was reached.
Find why each target was missed, assign and track fixes, and update the plan, playbooks and security measures.
Keep it running
The incident response lead keeps the approved plan and contacts where responders can reach them if core systems are down. Between incidents, run exercises on the set test cycle, choosing scenarios real incidents have not tested. This action applies organisation-wide, in every priority phase, so extend the steps to new systems and incident types as they come into scope.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the incident response plan, its playbooks and the approval record.
Look at
Whether there is a plan, or it sets roles and escalation but leaves target times or results vague.
Good evidence
An approved plan sets clear roles, escalation, target times and results for each stage.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the test cycle and all exercise and incident records since the last assessment.
Look at
Whether the plan went untested within the cycle, or exercises only talked it through without measuring results.
Good evidence
The plan was exercised or used within the cycle, with results measured against the targets.
- Check 3 of 5What an auditor asks for
Ask for
Request a sample of incident records from the period, covering minor and serious incidents.
Look at
Whether responders improvised, or incidents kept missing their targets for stopping the attack or recovery.
Good evidence
Incidents followed the plan and met targets suited to their seriousness, complexity and impact.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the cause analysis and improvement actions for each missed target or result.
Look at
Whether causes go unexamined, actions lack owners, or the same failures keep coming back.
Good evidence
Each miss has an analysed cause and tracked actions, and the plan and playbooks were updated.
- Check 5 of 5What an auditor asks for
Ask for
Ask which exercises are relied on when no real incident occurred, with their scope and results.
Look at
Whether exercises were generic talk-throughs instead of realistic scenarios timed against the targets.
Good evidence
Exercises on the most likely and damaging scenarios show recorded times and results meeting the targets.
ASD indicators of good practice (11)
The indicators below are quoted as published from ASD's Assessment evidence guide for enterprise IT. These optional indicators help an assessor judge the action in each domain where it applies: if any not effective statement is true, the action is rated not effective; if every applicable fully effective statement is true and no other statement is, it is rated fully effective; otherwise it is rated partially effective. ASD says the indicators "do not replace expert judgement, nor are they intended to serve as a checklist".
Not effective(3)
- NE-1No documented cyber security incident response plan or procedures exist.
- NE-2Incident response activities are conducted on an ad hoc basis without any defined roles, escalation paths, procedures or response objectives.
- NE-3Available incident records demonstrate systemic failures to contain, eradicate or recover from cyber security incidents within organisationally defined timeframes, and the causes of these failures are not addressed.
Partially effective(3)
- PE-1A cyber security incident response plan exists but has not been exercised or invoked within the organisationally defined test cycle.
- PE-2The cyber security incident response plan defines roles, escalation paths, and response procedures, but target timeframes or intended response outcomes are not clearly defined.
- PE-3Incident records or exercise results demonstrate that response activities do not consistently meet organisationally defined timeframes or intended outcomes, but identified deficiencies are documented and subject to improvement actions.
Fully effective(5)
- FE-1An approved cyber security incident response plan is in place and defines roles, escalation paths, response procedures, target timeframes and intended containment, eradication and recovery outcomes.
- FE-2The incident response plan and associated procedures have been exercised or invoked within the organisationally defined test cycle.
- FE-3Incident records demonstrate that cyber security incidents are contained, eradicated and recovered from within organisationally defined target timeframes and achieve the intended response outcomes, taking into account incident severity, complexity and business impact.
- FE-4Where target timeframes or intended outcomes are not achieved, the causes are analysed, improvement actions are assigned and tracked, and relevant plans, procedures and controls are updated.
- FE-5Where no relevant cyber security incident has occurred during the assessment period, appropriately scoped exercises demonstrate the organisation’s capability to achieve its target timeframes and intended response outcomes.
Mappings
Closest match in ISO/IEC 27001: A.5.26, Response to Information Security Incidents, which asks for the same thing.
ISO/IEC 27001: 2 mappings
This control is equivalent to A.5.26.
IT.RES-03.1 requires documented, tested and approved cyber security incident response procedures to be used when responding to cyber security incidents. Annex A 5.26 likewise requires information security incidents to be responded to in accordance with documented procedures, so both address the same requirement. IT.RES-03.1 goes slightly further by also requiring the procedures to be tested and approved.
This control partially overlaps A.5.24.
IT.RES-03.1 requires documented, tested and approved cyber security incident response procedures to be used when responding to cyber security incidents. It shares common ground with Annex A 5.24, which requires incident management processes, roles and responsibilities to be defined, established and communicated in advance, since the procedures must exist before they can be used. IT.RES-03.1 adds testing, approval and use of the procedures during response, while Annex A 5.24 also covers roles, responsibilities and communication of the processes.
ASD Essential Eight: 4 mappings
- E8-AC-ML2.11Cyber security incident response plan is enacted after incident identificationPartially overlaps
This control partially overlaps E8-AC-ML2.11.
IT.RES-03.1 requires documented, tested and approved procedures to be used when responding to cyber security incidents; E8-AC-ML2.11 requires the incident response plan to be enacted once an incident is identified, the core of that requirement.
This control partially overlaps E8-AH-ML2.18.
IT.RES-03.1 requires documented, tested and approved procedures to be used when responding to cyber security incidents; E8-AH-ML2.18 requires the incident response plan to be enacted after an incident is identified, and IT.RES-03.1 adds that the procedures be tested and approved.
- E8-MF-ML2.12Cyber security incident response plan enacted after incident identificationPartially overlaps
This control partially overlaps E8-MF-ML2.12.
IT.RES-03.1 requires documented, tested and approved procedures to be used when responding to cyber security incidents; E8-MF-ML2.12 requires the incident response plan to be enacted following identification of an incident, the point where those procedures are put to use.
This control partially overlaps E8-RA-ML2.13.
IT.RES-03.1 requires documented, tested and approved procedures to be used when responding to cyber security incidents; E8-RA-ML2.13 requires the incident response plan to be enacted once an incident is identified, so the two overlap on using the plan during a real incident.
ASD Information Security Manual: 3 mappings
This control partially overlaps ISM-0043.
IT.RES-03.1 requires documented, tested and approved procedures to be used when responding to cyber security incidents; ISM-0043 covers the documented part, listing what each system's incident response plan must include, from incident types and expected responses to evidence integrity.
This control partially overlaps ISM-0576.
IT.RES-03.1 requires documented, tested and approved procedures to be used when responding to cyber security incidents; ISM-0576 requires an incident management policy and response plan to be developed, implemented and maintained, providing the documented basis for that response.
This control partially overlaps ISM-1784.
IT.RES-03.1 requires documented, tested and approved procedures to be used when responding to cyber security incidents; ISM-1784 requires the incident management policy and response plan to be exercised at least annually, which covers the tested part.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.