ASD ISM 1909 Perform root cause analysis for vulnerabilities
What it says
In resolving vulnerabilities, root cause analysis is performed and, to the greatest extent possible, entire vulnerability classes are remediated.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishAnalyse the cause of issues and fix related vulnerabilities completely.
When you find a security problem, it's important to dig deep to understand the root cause and not just patch it up. If you only fix part of the issue, there's a risk similar problems will keep happening, potentially compromising sensitive information or your systems' functionality.
Free. Save your status, tasks and notes.
Why it matters
Without root cause analysis, fixes are patchy and the same vulnerability class reappears across systems, enabling repeat exploitation and possible breaches.
How to implement
IT managers should lead a thorough analysis whenever a security vulnerability is identified.
They can do this by gathering a team that includes the IT staff, system users, and any relevant vendors to discuss what specific sequence of events led to the vulnerability.
System owners should document each identified vulnerability and what caused it.
They should present this in a clear report that describes the issue, how it was discovered, the root cause, and potential solutions.
The IT team should develop and implement a plan to address the root cause of vulnerabilities.
This involves creating a timeline for implementing solutions and monitoring the changes over time to ensure they are effective.
Managers should ensure regular training and awareness programs for their teams, focused on specific vulnerabilities that could affect their systems.
This can involve inviting cyber security experts to provide workshops or webinars.
HR and IT departments should collaborate to ensure that new policies or changes resulting from root cause analyses are communicated effectively across the organisation.
Use internal newsletters or meetings to explain these updates and their importance.
Keep it running
For each vulnerability, document the underlying cause (e.g. coding pattern, misconfiguration) and remediate the whole class via standards, templates and regression tests.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The root cause analysis report: Request reports of recent security vulnerabilities and their analyses.
Look at
The documentation for clearly defined root causes and the steps taken or planned to fix related issues.
Good evidence
Report includes details like timelines, responsible parties, and follow-up steps.
- Check 2 of 5What an auditor asks for
Ask for
Meeting notes or records: Request records from vulnerability response meetings.
Look at
Consistent attendance by key personnel and evidence of thorough discussions focusing on cause and prevention.
Good evidence
Meeting note highlights concrete actions and deadlines.
- Check 3 of 5What an auditor asks for
Ask for
Updated policy documents: Request to see revised policies or procedures that were changed following a root cause analysis.
Look at
Specific references to identified vulnerabilities and how they've been addressed. Good policy updates will be specific, actionable, and rolled out organisation-wide.
- Check 4 of 5What an auditor asks for
Ask for
Training records: Request proof of staff training sessions that directly address vulnerability management.
Look at
Attendance lists, training materials, and feedback forms. Good training records show regular sessions with comprehensive content and engaged participants.
- Check 5 of 5What an auditor asks for
Ask for
System monitoring logs: Request logs that show system behaviour before and after vulnerability fixes.
Look at
Any patterns of recurring issues and how promptly they are addressed following identification. Effective logs reveal a decrease in repeated problems and faster response times.
Mappings
Closest match in ISO/IEC 27001: A.8.8, Management of technical vulnerabilities, which this control partially meets.
ISO/IEC 27001: 1 mapping
This control partially meets A.8.8.
ISM-1909 requires root cause analysis when resolving vulnerabilities and, where possible, remediation of entire vulnerability classes. This deepens the appropriate measures that Annex A 8.8 requires once vulnerabilities are identified and the organisation's exposure is evaluated. Annex A 8.8 covers the whole vulnerability management process (information gathering, evaluation and treatment), whereas ISM-1909 addresses how remediation is performed.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.