ASD ISM 1756 Develop and maintain vulnerability disclosure processes
What it says
Vulnerability disclosure processes, and supporting vulnerability disclosure procedures, are developed, implemented and maintained.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishOrganisations must create and maintain procedures for reporting software vulnerabilities.
This control is about setting up a system for people to report problems in your software, like bugs that hackers could exploit. It's important because if you know about these issues early, you can fix them before someone uses them to steal data or disrupt your operations.
Free. Save your status, tasks and notes.
Why it matters
Without a defined vulnerability disclosure process, flaws may not be reported or coordinated, leaving them exploitable and increasing breach and service disruption risk.
How to implement
IT Team should create a reporting email or form on your website where people can report software issues.
Make sure it's easy to use and find by putting it on a well-trafficked page like the Contact Us section.
Managers should set up a clear process for reviewing and responding to reports.
Assign a person or team to be responsible for checking the reports regularly and responding within a set timeframe, like two business days.
System Owners should build a knowledge base or document that details common vulnerabilities and how they've been addressed in the past.
Update this document whenever a new issue is resolved.
Organisational Leaders should communicate the importance of the reporting system to all employees.
Encourage staff to report any unusual software behaviour through staff meetings and newsletters.
IT Support should work with system developers to prioritise fixing reported vulnerabilities.
Use a simple tracking tool, like an Excel sheet, to track progress and ensure issues are resolved in a timely manner.
Keep it running
Maintain public reporting channels and internal procedures to triage, validate and coordinate fixes, tracking acknowledgements, timelines and remediation to closure.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
To see the vulnerability reporting procedure document.
Look at
Whether it outlines steps for submitting, reviewing, and responding to vulnerability reports.
Good evidence
Includes clear, step-by-step instructions with responsible team members named.
- Check 2 of 5What an auditor asks for
Good evidence
Shows timely and professional interactions with clear resolutions.
- Check 3 of 5What an auditor asks for
Ask for
The list of vulnerabilities addressed in the past year. Check how these were discovered, prioritised, and resolved.
Good evidence
Will show a well-maintained record with dates and actions taken.
- Check 4 of 5What an auditor asks for
Ask for
About staff training materials on reporting procedures.
Look at
Evidence these materials have been distributed and explained.
Good evidence
Provides training records with dates and attendance lists.
- Check 5 of 5What an auditor asks for
Good evidence
Contains detailed and up-to-date information about vulnerabilities and their solutions.
Mappings
Closest match in ISO/IEC 27001: A.8.8, Management of technical vulnerabilities, which partially overlaps with this control.
ISO/IEC 27001: 1 mapping
This control partially overlaps A.8.8.
Annex A 8.8 requires obtaining information on technical vulnerabilities, evaluating exposure, and taking appropriate measures to address them. ISM-1756 relates by establishing vulnerability disclosure processes and procedures that improve how an organisation receives and triages vulnerability information and initiates remediation. ISM-1756 is process-focused on inbound vulnerability reporting, while Annex A 8.8 is broader and includes exposure assessment and implementation of technical treatments.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.