A security.txt setup checklist should connect a public reporting address to a real response process. Publishing the file is useful only when messages reach a monitored team, the scope is clear, and someone can acknowledge and triage a report.
Prepare the reporting process first
Choose a durable mailbox or reporting portal rather than one employee's address. Name a primary owner and backup, define the systems covered, and create a simple intake record with the reporter's contact, affected asset, reproduction steps, evidence, severity estimate, and status. Decide how quickly the team will acknowledge a report and how sensitive attachments should be exchanged.
CISA describes a vulnerability disclosure policy as a way to tell researchers where to report issues, which testing is authorized, and what communication to expect (CISA). A small organization can use the same practical idea without promising a public bug bounty or authorizing unsafe testing.
Create the standards-based file
RFC 9116 defines the machine-readable security.txt format. For a web service, the canonical location is the HTTPS path `/.well-known/security.txt`, served as plain text with UTF-8 encoding (RFC 9116).
At minimum, include a working `Contact` field and an `Expires` field. Consider adding `Policy` for the full disclosure policy, `Encryption` for a public key, `Acknowledgments` for a recognition page, `Preferred-Languages` for supported languages, and `Canonical` for the file's own URL. Use complete HTTPS or mailto addresses as appropriate.
Set the expiration date far enough ahead for normal maintenance but close enough to force a periodic review. Put the review date on an operational calendar. If the reporting destination changes, update both the file and any linked policy page.
Publish without exposing a dead end
Deploy the file on every hostname that needs its own reporting route. Confirm that the path is reachable without authentication, does not redirect to an unrelated login, and returns the intended content type. If a legacy top-level `/security.txt` exists, redirect it to the well-known location and keep only one authoritative copy.
Do not place private incident details, staff phone numbers, internal system names, or credentials in the public file. The purpose is to route a responsible report, not describe the security architecture.
Test the complete path
Request the URL from an unsigned browser and from a command-line client. Check the status code, final URL, content type, encoding, line endings, required fields, and expiration value. Then send a harmless test message through the listed contact route. Verify that it reaches the monitored queue, creates the expected ticket, and can be handled by the backup owner.
Review mail filtering so reports with code snippets or attachments are not silently discarded. Use a controlled test attachment if policy allows, and provide an alternate contact method when attachments are blocked.
Maintain the disclosure channel
Review the file after domain, hosting, security-provider, or staffing changes. Track acknowledgment time, valid reports, unresolved items, and contact failures. When a report is closed, preserve the timeline and decision without publishing reporter information unless they consent.
Quick completion test
The setup is ready when the HTTPS well-known URL returns valid plain text, contact and expiration fields are current, the mailbox is monitored by two people or roles, a test report reaches the intake system, and the linked policy accurately describes scope and expectations.
Sources
- RFC 9116: A File Format to Aid in Security Vulnerability Disclosure — RFC Editor, April 1, 2022
- CISA Issues Final Vulnerability Disclosure Policy Directive for Federal Agencies — Cybersecurity and Infrastructure Security Agency, Sept. 2, 2020