ASD ISM 1616 Implementing a vulnerability disclosure program
What it says
A vulnerability disclosure program is implemented to assist with the secure development and maintenance of products and services.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishCreate a program to find and fix software issues to keep products secure.
A vulnerability disclosure program is like having a feedback mechanism for your software, where users can report any security issues they find. This is important because if nobody reports these vulnerabilities, bad actors might exploit them, leading to data breaches or other security incidents.
Free. Save your status, tasks and notes.
Why it matters
Without a vulnerability disclosure program, researchers lack a safe reporting path, so flaws stay hidden or are exploited, leading to breaches and loss.
How to implement
The business owner should appoint a responsible person to oversee the vulnerability disclosure program, ensuring someone is accountable for its success.
This person should have good communication skills and basic knowledge of the organisation's software products.
The IT team should create a clear and accessible way for the public to report security issues, such as a dedicated email address or online form.
Ensure this contact point is easy to find on the organisation's website and is monitored regularly.
The assigned manager should develop a policy outlining how to handle reported vulnerabilities.
This policy should include steps for initial verification, assessment, and remediation of issues and detail how to communicate with the person who reported the vulnerability.
Finance or HR should allocate resources for training staff involved in the program.
Training should cover the importance of addressing vulnerabilities promptly and the specific procedures to follow when a report is received.
IT managers should establish a timeline for reviewing and resolving reported vulnerabilities.
This timeline should prioritise issues based on their severity and potential impact, aiming to address critical vulnerabilities as quickly as possible.
Keep it running
Triage and validate disclosures, set severity and fix SLAs, acknowledge reporters promptly, and publish a clear reporting channel and safe-harbour rules.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The vulnerability disclosure program policy document.
Look at
The steps outlined for receiving, assessing, and responding to vulnerabilities.
Good evidence
Policy is clearly defined, with roles and responsibilities assigned and timelines for responses.
- Check 2 of 5What an auditor asks for
Good evidence
Is a visible and functioning contact point designed for ease of use by the public.
- Check 3 of 5What an auditor asks for
Ask for
Records of reported vulnerabilities and corresponding actions taken.
Look at
The response times and resolutions for different severity levels.
Good evidence
Record shows timely responses and resolutions aligned with the assigned severity level.
- Check 4 of 5What an auditor asks for
Good evidence
Example includes thanking the reporter and keeping them informed throughout the process.
- Check 5 of 5What an auditor asks for
Ask for
Training records of staff involved in the program.
Look at
The frequency and content of the training provided. Good evidence shows regular, comprehensive training sessions with clear objectives related to the disclosure program.
Mappings
Closest match in ISO/IEC 27001: A.8.8, Management of technical vulnerabilities, which partially overlaps with this control.
ISO/IEC 27001: 2 mappings
This control partially overlaps A.8.8.
ISM-1616 requires organisations to implement a vulnerability disclosure program so external and internal researchers can report product/service vulnerabilities and the organisation can triage and remediate them. This overlaps with Annex A 8.8, which requires obtaining information about technical vulnerabilities, assessing exposure, and taking appropriate measures. Both drive vulnerability intake and remediation decisions, but ISM-1616 is specifically about a coordinated disclosure process and engagement channel, whereas Annex A 8.8 is broader vulnerability management across systems in use (not necessarily disclosure-driven).
This control depends on A.8.25.
ISM-1616 requires a formal vulnerability disclosure program to help securely develop and maintain products and services by receiving and actioning reported vulnerabilities. This supports Annex A 8.25 by providing a feedback mechanism from real-world use into the secure development rules and practices. Annex A 8.25 focuses on establishing and applying secure development rules, while ISM-1616 focuses on structured intake, coordination, and response to disclosed vulnerabilities.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.