ASD Essentials IT.RES-04.1 Perform Post-Incident Reviews to Identify Security Gaps Behind Each Incident Stage
What it says
Perform post-cyber security incident reviews to identify the security gaps that enabled each stage of the cyber security incident.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishReviews each incident that meets the organisation's severity threshold to find the security gaps that let each stage of the incident happen.
Attackers usually work in steps: they get in, gain a foothold, widen their access and reach their goal. Each step works because a protection was missing, weak or set up wrongly. To meet this, review every incident at or above the seriousness level the organisation sets. Retrace each step and name the gap behind it, such as a system missing updates or a reused password. Then fix each gap and track the fix to closure.
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 these reviews, the gaps that let an attacker get in, gain more access and move between systems stay open, inviting a repeat attack. Fixes deal with the visible symptom, not the gaps behind the other steps.
How to implement
The head of security should set the seriousness level that triggers a review, who leads and joins it, and a risk-based deadline, in the incident response plan.
Add a review status field to the incident register.
The review lead should gather the register entry, tickets, logs and investigation findings.
Then build a timeline that splits the incident into steps, from first entry to final impact.
The review team should record, with evidence, the exact gap that let the attacker move forward at each step.
Dig into vague causes like human error until you find the safeguard or process that should have stopped that step.
The review lead should write a report linking each step to its gap, and check other systems for the same gap.
Turn every finding into a fix with an owner, a risk-based priority and a target date.
The security team should track every fix to closure, reporting overdue ones to the security oversight committee.
Close a fix only on evidence, such as a retest, and log unfixable gaps as risks with an approved plan to manage them.
Keep it running
The incident register is the trigger: when an incident at or above the set level closes, book its review while evidence is fresh. Check the register against completed reviews so none is missed. Keep reviews blameless, focused on gaps, not people. This action applies organisation-wide, in every priority phase, so review these incidents wherever they happen. Follow each one through every system and account it touched, not just where it was noticed.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the review procedure and the seriousness level that makes reviews compulsory.
Look at
Whether reviews are optional, or the procedure only asks for a summary of what happened.
Good evidence
Every incident at the set level must be reviewed, tracing each step to its gap.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the incident register with seriousness ratings, and the list of completed reviews.
Look at
Whether some incidents at the set level have no review, or only an unfinished draft.
Good evidence
Every incident at the set level has a completed review linked to its register entry.
- Check 3 of 5What an auditor asks for
Ask for
Request a sample of completed review reports with the evidence behind each timeline.
Look at
Whether findings went unwritten, timelines stop at the first step, or causes stop at human error.
Good evidence
Each report traces the incident from entry to impact and names the gap behind every step.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the fixes raised from the sampled reviews.
Look at
Whether findings have no fix, or fixes lack an owner, priority or target date.
Good evidence
Every finding has an owned, prioritised fix with a target date, tracked to closure.
- Check 5 of 5What an auditor asks for
Ask for
Ask for proof of closure for sampled finished fixes and the governance reports that tracked them.
Look at
Whether fixes closed without proof, or the same gap helped a later incident.
Good evidence
Fixes are proven in place, and fixed gaps do not reappear in later incidents.
ASD indicators of good practice (6)
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(1)
- NE-1Post-incident reviews are not conducted.
Partially effective(2)
- PE-1Post-incident reviews are conducted for some incidents but not all that meet the severity threshold defined by the organisation.
- PE-2Reviews are conducted but findings are not documented or actioned.
Fully effective(3)
- FE-1Post-incident reviews are conducted for all incidents meeting the severity threshold defined by the organisation.
- FE-2Findings identify the specific gaps that enabled each stage of the incident.
- FE-3Remediation actions arising from findings are implemented and tracked to closure.
Mappings
Closest match in ISO/IEC 27001: A.5.27, Learning from information security incidents, which this control partially meets.
ISO/IEC 27001: 1 mapping
This control partially meets A.5.27.
IT.RES-04.1 requires post-incident reviews to identify the security gaps that enabled each stage of a cyber security incident. This is a specific way of gaining the knowledge from incidents that Annex A 5.27 requires to be used to strengthen and improve information security controls. Annex A 5.27 goes further by requiring that knowledge to be acted on, while IT.RES-04.1 focuses on identifying the gaps.
ASD Information Security Manual: 3 mappings
This control partially overlaps ISM-0125.
IT.RES-04.1 requires post-incident reviews to identify the security gaps that enabled each stage of an incident; ISM-0125 requires a cyber security incident register to be developed, implemented and maintained, a record those reviews can draw on.
- ISM-1526System Owners Continuously Monitor Security and Manage Threats, Risks and ControlsPartially overlaps
This control partially overlaps ISM-1526.
IT.RES-04.1 requires post-incident reviews to identify the security gaps that enabled each stage of an incident; ISM-1526 requires system owners to continuously monitor each system's security and manage its threats, risks and controls, which the gaps found can inform.
This control partially overlaps ISM-1803.
IT.RES-04.1 requires post-incident reviews to identify the security gaps that enabled each stage of an incident; ISM-1803 requires the incident register to record each incident's dates, description, response actions and who it was reported to, details that support such reviews.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.