ASD ISM 1717 Implement security.txt for vulnerability disclosure
What it says
A 'security.txt' file is hosted for each of an organisation's internet-facing website domains to assist in the responsible disclosure of vulnerabilities in the organisation's products and services.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishEnsure a 'security.txt' file is available on each website to aid in reporting vulnerabilities.
A 'security.txt' file is like a signpost on your website that tells security researchers where they can report any problems they find. This is important for finding and fixing security issues quickly to prevent hackers from causing harm to your business.
Free. Save your status, tasks and notes.
Why it matters
If a security.txt file is not hosted on internet-facing domains, researchers may not know how to report issues, delaying fixes and increasing breach risk.
How to implement
The IT team should create a 'security.txt' file for the website.
This file should include contact information, like an email address, where security researchers can report vulnerabilites they find.
Website administrators should ensure the 'security.txt' file is placed in the well-known location on the website, typically under the '.well-known' directory, so that it is easy to find.
The security team should regularly review and update the 'security.txt' file.
Make sure the contact information is current and add any additional details, such as social media contacts or a link to a vulnerability disclosure policy.
Management should communicate the existence of the 'security.txt' file to all relevant staff.
Ensure everyone knows how to handle incoming vulnerability reports, including who should be notified and what steps to take next.
The IT team and management should monitor for any reports received through the 'security.txt' file regularly.
Set up processes to prioritise and quickly address any reported vulnerabilities to prevent potential issues.
Keep it running
Keep security.txt current (contacts, PGP, policy) on every public domain, and triage/track reports so responses and remediation are timely.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The location of the 'security.txt' file: Request the exact URL where the file is hosted on the website.
Look at
Whether it is in the expected location, usually '.well-known/security.txt'.
Good evidence
It is accessible and contains valid contact information for reporting.
- Check 2 of 5What an auditor asks for
Ask for
Confirmation of the contact details: Request to see the contact details listed in the 'security.txt'.
Look at
An email address or web form link specifically for reporting vulnerabilities.
Good evidence
Clear instructions on how researchers can report issues.
- Check 3 of 5What an auditor asks for
Ask for
The update schedule: Request the schedule or policy for reviewing the 'security.txt' file.
Look at
The frequency and whether recent updates align with the schedule.
Good evidence
Documented evidence that shows regular updates, such as a log or change history.
- Check 4 of 5What an auditor asks for
Ask for
Evidence of staff communications: Request emails or meeting notes where the 'security.txt' file and procedures were discussed with staff.
Look at
Areas where roles and responsibilities are clearly mentioned.
Good evidence
Evidence that staff understand the process and their role.
- Check 5 of 5What an auditor asks for
Ask for
Received vulnerability reports: Check how reports have been documented and handled.
Look at
The response times and actions taken.
Good evidence
Efficient handling of reports with follow-ups and issue resolution recorded.
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 organisations to obtain information about technical vulnerabilities and take measures to reduce exposure. ISM-1717 establishes a vulnerability disclosure facilitation mechanism (security.txt) to help receive vulnerability reports for internet-facing domains, which contributes to obtaining vulnerability information used in Annex A 8.8 processes. The overlap is in vulnerability information intake, but Annex A 8.8 also requires exposure evaluation and remediation, while ISM-1717 does not address assessment or treatment actions.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.