Which one a regulated team needs first, and why both
A regulated organization with internet-facing products or public services needs a reporting route before it needs anything else, and that route is often two documents rather than one. A security.txt file is a contact file defined in RFC 9116. Its Contact and Expires fields are mandatory, it must sit under the /.well-known/ path on web services, and it must be served over HTTPS. It tells a finder who to reach and until when the file is valid. It does not state scope, permitted testing, legal protection or response commitments, and RFC 9116 is explicit that a researcher should not treat the file's presence or absence as permission to test. For a small service with a single security mailbox, a correct security.txt may be the first step, but it is rarely the whole answer.
A published vulnerability disclosure policy is the document that carries the terms. Under CISA BOD 20-01, a policy must state which systems are in scope, which types of testing are allowed and prohibited, how to submit reports, a commitment not to pursue legal action for good-faith research that follows the policy, and when reporters can expect acknowledgment. CISA recommends acknowledging reports within 3 business days, completing an initial assessment within 7 days and resolving within 90 days, although BOD 20-01 leaves resolution timelines to agencies. Regulated product makers face parallel duties, since the EU Cyber Resilience Act's Annex I Part II point (5) requires a coordinated vulnerability disclosure policy. Confirm with counsel which of these rules apply to your entity before you copy any template.
The two are complementary: the policy is the terms, and the security.txt file is the pointer that makes the policy findable. Neither replaces scheduled penetration testing, which is the controlled assessment you run on your own schedule, nor a bounty, which pays for valid findings from outside researchers. A disclosure route tells you what outsiders found. It does not show that your controls hold. Before publishing, check that the Contact address is monitored, that the Expires date has an owner who renews it, and that the policy's scope matches what your penetration test covers.
security.txt and a vulnerability disclosure policy compared
This table compares a security.txt file under RFC 9116 with a vulnerability disclosure policy shaped by CISA BOD 20-01 and NIST SP 800-53 RA-5(11). Read each row as a question a regulated team must answer: the file tells researchers how to reach you, while the policy tells them what they may test and what protection they receive. The main takeaway is that the file is a pointer and the policy is the authorization.
| Dimension | security.txt (RFC 9116) | Vulnerability disclosure policy |
|---|---|---|
| Purpose | Describes how to contact the organization about security issues | Authorizes good-faith research and sets rules for reporting and handling findings |
| Format | Plain text file with named fields such as Contact and Expires | Free-form published document, typically a web page, with the elements BOD 20-01 lists |
| Required content | Contact and Expires fields must always be present | Systems in scope, permitted and prohibited testing, submission method, legal safe harbor, acknowledgment timing |
| Authority for testing | Not authorization: researchers should not assume the file grants or denies permission to test | Stated authorization for in-scope good-faith testing, including the commitment not to pursue legal action |
| Who maintains it | Security or IT team keeps contact details and expiry date current | Security leadership with legal review, updated when scope or channels change |
| Where it is published | Under the /.well-known/ path on web services, served over HTTPS | Publicly discoverable page that the security.txt file can point to, per RA-5(11) |
| Response commitments | None defined in the file itself | Acknowledgment timing must be stated under BOD 20-01; CISA recommends 3 business days for acknowledgment |
| Cost to create and keep current | Low one-time setup; recurring effort to renew the Expires date and confirm contacts (confirm internally) | One-time legal and security drafting; recurring review and triage staffing (confirm scope and staffing with counsel) |
What each approach surfaces and what it misses
A security.txt file and a published disclosure policy both describe how outsiders can report problems, but neither finds anything on its own. What each one surfaces depends on who reads it, how clearly it authorizes research, and whether anyone is testing on a schedule.
Inbound reports from external researchers
A published policy and a contact file both act as a front door for researchers who already found a flaw. Reports arrive unprompted, often from people with no contract and no deadline. Check that the intake address is monitored, that someone owns triage, and that reporters can tell whether their testing was in scope. Misses still happen: researchers who never find the channel, and findings reported to the wrong mailbox, will not reach your team.
What a published policy attracts
A full policy states scope, permitted and prohibited testing, how to submit, the commitment not to pursue legal action for good-faith research, and when acknowledgment is expected. That wording tends to attract more careful researchers, who test within the stated limits and report in a usable form. It does not guarantee volume. Confirm whether the policy names systems that are excluded, because researchers who test an excluded system anyway will generate reports you may need to decline.
What a file alone attracts
A security.txt file gives researchers a contact point and an expiry date, which helps them find you. It does not describe scope, testing limits or safe harbor. RFC 9116 is explicit that researchers should not treat the file as permission to test, so a file alone can attract reports that are unclear, out of scope or sent without context. Use it as a pointer to the full policy, and keep the Contact and Expires fields current.
What neither approach detects
Neither a file nor a policy finds a vulnerability. Both depend on someone else discovering the flaw first and choosing to report it. Exposed services, forgotten hosts and misconfigurations stay invisible until an attacker or a tester finds them. Scheduled penetration testing, scanning and attack surface monitoring are the controls that look for problems proactively, and they should be scoped against the same asset list your policy describes.
Reports against scheduled testing
Inbound reports arrive irregularly, cover whatever researchers happen to examine, and vary in quality. Scheduled testing arrives on a known cadence, covers agreed scope and produces a report with reproduction steps and retest evidence. For a regulated product, plan for both: scheduled tests give auditors a repeatable record, while the disclosure channel catches what the schedule missed. Ask your testing provider how it handles reports that arrive during an engagement.
Response timelines CISA recommends and what BOD 20-01 leaves to you
The sequence turns a reported vulnerability into an acknowledged, assessed and tracked case, and the timelines are only useful if the published policy promises what the team can actually deliver.
Publish the reporting channel and acknowledgment commitment
The security team publishes the reporting address in the security.txt file and in the full policy, and states when reporters can expect acknowledgment. Under BOD 20-01, the policy must include that acknowledgment expectation. The step is complete when the contact resolves over HTTPS at the /.well-known/ path and the policy page names the same channel. Confirm the mailbox is monitored outside business hours if your commitments depend on it.
Acknowledge the report within 3 business days
A named triage owner replies to the reporter to confirm receipt. CISA recommends acknowledging vulnerability reports within 3 business days of receipt. The output is a timestamped acknowledgment in the ticketing system, linked to the report, so the team can show when the clock started and when it stopped. If your team cannot staff this window, publish a longer commitment that you can meet.
Triage and confirm the report is in scope
The triage owner checks whether the reported system appears in the scope the policy lists, and whether the testing that produced the report falls within the types the policy allows. Reports outside scope still get a reply that says so, with the reason. The output is a scope decision recorded against the report. This step is where a well-written policy saves time, because ambiguous scope is the most common reason triage stalls.
Complete the initial assessment within 7 days
The product or security team reproduces the issue, confirms whether it is a vulnerability, and estimates which versions or deployments are affected. CISA recommends completing this initial assessment within 7 days of receipt. The output is a written assessment with a severity view and an owner. Tell the reporter the outcome, even when the finding is declined, and record the reason so the decision can be audited later.
Coordinate the fix and agree disclosure timing
Engineering builds and tests the fix, and the team decides which customers, operators or regulators need notice and when. For a regulated product this step often overlaps with coordinated disclosure duties in the EU Cyber Resilience Act, which requires manufacturers to put in place and enforce a coordinated vulnerability disclosure policy. The output is a release or mitigation plan and a draft advisory. Agree the timing with the reporter in writing where possible.
Resolve the vulnerability and track the target date
The team ships the fix or documents a mitigation, then closes the case. CISA recommends resolving reported vulnerabilities within 90 days of receipt. BOD 20-01 itself leaves resolution timelines to agencies, so this figure is guidance for federal agencies, not a requirement on private firms. The output is a closed ticket with a fix version, a verification note and the date of resolution. Track cases that exceed the target so leadership can see the backlog.
Publish only the commitments your team can meet
Before the policy goes live, the owner compares each published timeline with real staffing, on-call coverage and release cadence. A private sector team should publish only commitments it can meet, because a missed promise in a public policy becomes evidence against the organization. Ask whether the team can show past response data, and confirm the figures with the people who will work the queue. Review the policy whenever staffing or release cycles change.
What you receive from each and what auditors will ask to see
Both approaches produce artifacts that an organization must keep current and be able to show. DeployOpen prepares these artifacts, but the organization owns them, publishes them and signs off on them, and independent auditors decide whether the evidence is sufficient.
The published security.txt file
A plain text file served under the /.well-known/ path over HTTPS, containing at least the Contact and Expires fields. Check that the file is reachable on every public host you intend to cover, that the Expires date is renewed before it lapses, and that the contact address is monitored by a person or queue with an owner. A stale file with a past expiry date signals that disclosure handling is unmanaged. Note that the file is a pointer, not a policy, so it should link to the published disclosure policy.
The vulnerability disclosure policy
The approved document that states in-scope systems, permitted and prohibited testing, how to submit reports, the commitment not to pursue legal action for good-faith research that follows the policy, and when reporters can expect acknowledgment. Auditors will compare this document against the scope of your external assets and the authorization language your legal team has signed. Confirm version control, the approval date, the owner and the review cycle, and make sure the policy text matches what the security team actually does.
Intake records for submitted reports
A log of each report received through the contact channel, with the date of receipt, the reporter's identity or pseudonym, the affected asset, the reproduction notes and the classification. Auditors and regulators tend to ask whether reports are recorded at all and whether any are lost between a shared inbox and the ticketing system. Ask your team to confirm the system of record, the retention period set by your own policy and who can access reporter details, since these records often contain personal data.
Acknowledgment and response logs
Timestamped evidence that each report was acknowledged, triaged and answered within the windows your policy states. CISA recommends acknowledging reports within 3 business days, completing an initial assessment within 7 days and resolving within 90 days of receipt, but BOD 20-01 leaves resolution timelines to the agency. If your policy commits to shorter or longer windows, the logs must show whether those commitments were met. Missing timestamps are the most common gap auditors identify.
Remediation and retest tracking
The link between each validated finding and its fix, including the owner, the target date, the fix verification and any compensating control or accepted risk. For a disclosure program, this shows that reports led to action on the affected system rather than closing silently. Check that each closed report references a verified fix or a documented decision, and that disclosed issues are coordinated with the affected vendors or product teams when they are not your own software.
Written scope and authorization evidence
The record of which assets were in scope, which testing methods were allowed, and which researcher activities were excluded, along with the date each change was approved. Regulators and assessors use this to confirm that good-faith research was authorized and that any testing outside the published policy was handled under a separate agreement. Keep the scope document, the policy version in force on each date and any amendments in one controlled location so that the evidence matches what the program promised at the time.
When regulations and frameworks call for each
A security.txt file alone does not satisfy any of the requirements below. It is a contact file under RFC 9116, and it can point to a disclosure policy, but the obligation sits with the published policy and the process behind it. NIST SP 800-53 Rev. 5 control enhancement RA-5(11), Public Disclosure Program, calls for a publicly discoverable reporting channel that authorizes good-faith research. SP 800-53B selects RA-5(11) in the low, moderate and high baselines, so a federal system or contractor boundary authorized at any of those levels should expect an assessor to ask for it. Confirm the baseline that applies to your system categorization with your authorizing official or assessor before you scope the work.
For US federal agencies, CISA BOD 20-01 requires a vulnerability disclosure policy with defined elements: systems in scope, permitted and prohibited testing types, how to submit reports, a commitment not to pursue legal action for good-faith research that follows the policy, and when reporters can expect acknowledgment. CISA recommends acknowledging reports within 3 business days, completing an initial assessment within 7 days and resolving within 90 days, but BOD 20-01 leaves resolution timelines to each agency. Treat those figures as CISA guidance, and ask your agency or contracting officer which timelines they will hold you to. Outside the federal scope, the directive is a useful checklist rather than a binding rule for your organization.
The EU Cyber Resilience Act, Annex I Part II point (5), requires manufacturers of products with digital elements to put in place and enforce a policy on coordinated vulnerability disclosure. Here the policy is an enforceable duty, and the file can only route a reporter to it. Whether the CRA applies to your product, and which obligation dates apply to it, depends on your product classification and the regulation's transition provisions, so confirm both with counsel or your national market surveillance authority. If you are a regulated financial entity or a designated essential or important entity, ask your competent authority which disclosure and testing obligations also reach you.
How a disclosure policy combines with scheduled penetration testing
The sequence turns an open reporting channel into tested, remediated and re-verified controls, so reports from outside researchers feed the same process as scheduled internal and external testing. Each step leaves a record that an auditor or regulator can follow from publication to revalidation.
Define the policy scope and safe harbor terms
Legal, product security and the system owners agree which systems are in scope, which types of testing are allowed and prohibited, how reports are submitted, and when reporters can expect acknowledgment. The policy must also state a commitment not to pursue legal action for good-faith research that follows it, as CISA BOD 20-01 requires for federal agencies. Done means the policy is approved by legal and has a named owner who can answer reports.
Publish the policy and link it from security.txt
Publish the full policy on a stable web page, then create a security.txt file under the /.well-known/ path served over HTTPS, with the required Contact and Expires fields and a link to the policy. The security.txt file is a contact pointer, not the authorization itself, so the policy text remains the document that sets terms. Done means the file resolves over HTTPS and the policy link opens without a login.
Schedule scanning and periodic penetration tests
The security team sets a recurring calendar of regular vulnerability scanning with periodic penetration testing in between, following NIST SP 800-115's suggestion to interleave the two. The penetration test scope is written as a rules of engagement document, using the template in Appendix B of that guide. Done means the calendar, scope owners and rules of engagement are signed off before any test begins.
Triage reports from the disclosure channel
Reports arriving through the published channel are logged, acknowledged and checked against the policy's scope rules, then separated into valid findings, out-of-scope reports and duplicates. Security engineers reproduce each valid finding and assign an owner and severity. Done means every report has a logged decision and an acknowledgment record, which is the evidence reporters and auditors will ask for.
Feed all findings into one remediation queue
Findings from scheduled penetration tests, vulnerability scans and external reports go into the same tracked backlog, so no source is handled differently for audit purposes. Each item records the affected system, the fix owner and the retest condition. Done means every finding has a ticket that links back to its origin, whether the source was a tester, a scanner or a researcher.
Retest fixes and validate detections
Once a fix ships, the original test steps are repeated to confirm the vulnerability is closed. CIS Safeguard 18.4 asks that security measures be validated after each test so detections cover the techniques the testers used, so the blue team checks whether monitoring alerted on the activity. Done means each closed finding has a retest result and a detection check recorded against it.
Review the program and consider a bounty
On a regular cycle, the policy owner reviews report volume, response times and recurring weakness types, then updates scope and contacts in both the policy and the security.txt file. If the program is mature enough to justify paying for findings, a bounty can be added later on top of the policy, because the policy already defines the terms. Done means the review is minuted and any changes are republished with a new Expires value in the security.txt file.
Questions buyers ask before publishing a disclosure policy
Is a security.txt file alone enough to run vulnerability disclosure?
No. A security.txt file is a contact file. RFC 9116 requires the Contact and Expires fields so researchers know where to send reports and when the file goes stale, and it says the file is not a substitute for other public resources on disclosure practices. It does not state which systems are in scope, which testing is allowed, how reports are handled, or whether good-faith researchers will face legal action. Those elements belong in a published vulnerability disclosure policy, and the security.txt file can point to that policy through its Policy field. The two files do different jobs, so most teams that publish one should publish both.
Does publishing a disclosure policy authorize security testing?
Only what the policy itself states, and only as far as counsel has approved the wording. RFC 9116 says researchers should not assume that a security.txt file, or the absence of one, grants or denies permission to test. A disclosure policy can authorize good-faith research on defined systems and testing types, and CISA BOD 20-01 requires a commitment not to pursue legal action for research that follows the policy. That commitment is a legal statement, so the scope, prohibited activities and safe harbor language should be reviewed by qualified counsel before publication. Ask counsel to confirm how the policy interacts with your terms of service and with any third-party hosting or cloud provider rules.
How much does it cost to publish a vulnerability disclosure policy?
No public price is set for this work, and the cost depends on what you ask a firm or your own staff to produce. The main cost components are internal time from legal, security and the system owners who define scope, legal review of the safe harbor wording, and technical work to publish the policy and security.txt file over HTTPS under the /.well-known/ path. The one-time work is drafting and approval. The recurring work is keeping the scope list, contact details and expiry date current. Costs rise with the number of systems in scope, the number of jurisdictions, and whether you also need triage workflows. For a quote, ask for the written scope, the named deliverables, who reviews the legal text, and how updates are handled after publication.
How long does it take to write a disclosure policy?
The timeline depends mainly on how quickly the internal owners can agree on scope and approve the legal language, not on the drafting itself. Before drafting starts, the team needs an inventory of internet-facing systems and products, the testing types you will accept and reject, a named contact or mailbox that is monitored, and your acknowledgment and response commitments. Legal approval is usually the longest step. Confirm the timeline with your own governance calendar and, for scope, the written statement of work if you hire a firm. No fixed duration is set by the sources used here, so ask any provider to commit to a plan in writing.
Can our own team write a disclosure policy without outside help?
Yes, many teams do, provided they cover the required elements. CISA BOD 20-01 requires a policy to state which systems are in scope, the types of testing allowed and prohibited, how to submit reports, a commitment not to pursue legal action for good-faith research that follows the policy, and when reporters can expect acknowledgment. RA-5(11) in NIST SP 800-53 Rev. 5 calls for a publicly discoverable channel that authorizes good-faith research. An internal team needs legal review, a monitored intake channel and someone accountable for triage. If you lack those, DeployOpen can help plan, document and publish the controls and evidence as part of a fixed-scope engagement, with the legal wording still reviewed by your counsel.
What response times should we commit to in a disclosure policy?
Commit only to times your team can meet every time, and check them against the guidance you follow. CISA recommends acknowledging reports within 3 business days, completing an initial assessment within 7 days and resolving within 90 days of receipt. BOD 20-01 itself leaves resolution timelines to agencies, so those figures are guidance for federal agencies rather than a legal requirement for private organizations. Publish the acknowledgment window you can staff, because a missed public commitment damages trust more than a modest one. Ask your security operations lead to confirm the on-call coverage behind each number before it appears in the policy.
Why do regulated products need both a security.txt file and a policy?
A regulated product needs the policy because the policy carries the obligations, and the security.txt file makes the policy easy to find. The EU Cyber Resilience Act, under Annex I Part II point (5), requires manufacturers to put in place and enforce a coordinated vulnerability disclosure policy. Regulators and auditors look for the policy text, the reporting channel and evidence that reports are handled, not for a contact file alone. Whether the CRA or another regime applies to your product is a legal determination, so confirm applicability with counsel and your regulator before relying on this summary. Use the Cyber Resilience Act text on EUR-Lex as the starting point for that review.
How DeployOpen scopes and delivers disclosure and testing support
DeployOpen is a Chainscore Labs company that plans, implements, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and it also runs security testing. For a team deciding how to publish a security.txt file and a vulnerability disclosure policy, that matters because the work usually touches both the public web endpoint and the internal process behind it. DeployOpen can help with the hosting path for the file, the policy text, the intake channel and the testing that sits behind a published disclosure policy. It does not decide on the client's behalf which systems are in scope or what the organization will accept as a good-faith test, and the reader should confirm those decisions with their own legal, product and security owners before any engagement starts.
Most engagements are fixed-scope. Scope, deliverables and timelines are agreed in writing before work begins, so the reader should ask for a written scope that names the assets covered, the policy elements to be drafted or reviewed, where the security.txt file will be served, which Contact and Expires values will be used, and who owns triage after a report arrives. Ongoing support, upgrades and continuous testing are available as retainers. A retainer suits a disclosure program that receives reports over time, because the recurring work (monitoring the Expires date, reviewing intake, retesting after fixes) is ongoing rather than a single deliverable. Ask for the retainer scope in writing too, including what is covered between reports and what triggers additional work.
DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work. A disclosure policy can be drafted, deployed and tested with DeployOpen's help, and the resulting records can be assembled for an assessor, yet the assessor's conclusion is their own. Before committing, confirm with the relevant regulator or assessor which evidence they expect, such as the published policy, intake logs and response records, and make sure the written scope lists those artifacts as deliverables.
