Summary. This toolkit collects the documents a company and its researchers need to run a vulnerability disclosure program and to handle the hard reports, each introduced by its purpose, its owner, and when to use it, with fill-in placeholders and drafting commentary tied to the governing authority. The templates include a public vulnerability disclosure policy, a standalone safe harbor clause, a security.txt file, a researcher reward and release agreement, a neutral acknowledgment letter, a request for more detail, a reward decision letter, a disclosure timeline and coordination agreement, an internal triage and notification memo, and a response letter for a message that reads like extortion. A running example involving a fictional logistics software company shows each document in use. The toolkit is built to be used with the program checklist and the step-by-step guide in the same set, and it flags where counsel, insurer consent, and sanctions screening are required.

A vulnerability disclosure program lives or dies on a dozen documents, most of them short. The public policy and its safe harbor are read by strangers deciding whether it is safe to help you. The letters are read, later, by a regulator, a judge, or a reporter deciding whether you behaved well. This toolkit supplies both kinds, drafted so that each sentence does one job and none of them promises something counsel cannot keep.

How to use this toolkit

Each template states its purpose, its owner, and when to use it, then gives the template in a fenced block with [BRACKETED PLACEHOLDERS], followed by drafting commentary tied to authority. Fill the placeholders, delete the bracketed guidance, and have counsel review anything that creates a legal position (Templates 1, 2, 4, 8, and 10 especially).

These are starting points, not filed-and-forget forms. Computer crime law varies by state and the facts drive everything, so the commentary points to the choices you must make deliberately.

The reasoning behind every document is in Paid Vulnerability Disclosure and the Line Between Research and Extortion. The order in which the documents are used, for both sides, is in Reporting or Receiving a Security Vulnerability: A Practical Guide for Researchers and Companies. The program-building tasks they support are in the Vulnerability Disclosure Program and Safe Harbor Checklist: A Practical Checklist.

Template Owner When to use
1. Vulnerability disclosure policy (public) Program and legal owners Standing; published on the website
2. Safe harbor clause (standalone) Legal owner Inside the policy, or in bounty platform settings
3. security.txt file Program owner Standing; served at /.well-known/security.txt
4. Researcher reward and release agreement Legal owner Off-platform payments and negotiated resolutions
5. Acknowledgment letter Triage team Within 1 to 3 business days of any report
6. Request for more detail Triage team When a report is incomplete
7. Reward decision letter Program owner After verification and remediation
8. Disclosure timeline and coordination agreement Program owner, with legal When a researcher and company coordinate publication
9. Internal triage and notification memo Program owner, under counsel On every validated report
10. "This reads like extortion" response letter Legal owner, with law enforcement input When a message conditions silence on payment

The running example is Fathom Freight Systems, Inc., a fictional Delaware company that sells logistics software to shippers. Fathom is a HIPAA business associate for some customers and processes payment card data for others. Its program owner is VP of Security Dana Ooi; its legal owner is General Counsel Marcus Bell.

Template 1: Vulnerability disclosure policy (public)

Purpose: the public contract between the company and researchers: what they may test, how to report, what the company promises, and the limits. Owner: program and legal owners jointly. When to use: standing; the anchor document of the program.

[COMPANY] Vulnerability Disclosure Policy
Last updated: [DATE]  |  Version: [N]

Introduction
[COMPANY] values the work of security researchers. This policy explains
which systems you may test, how to report what you find, and what we
commit to in return. If you follow this policy in good faith, we will
work with you and will not pursue or support legal action against you
for your research (see "Safe Harbor").

Scope
In scope:
  - [exact hostnames / wildcard patterns]
  - [mobile app identifiers]
  - [APIs and versions]
Out of scope:
  - Any system not listed above, including third-party services we use
    (for example, [cloud provider], [payment processor], [email vendor])
  - Customer-controlled accounts, data, or integrations
  - Physical security, social engineering of our people or customers,
    and denial-of-service testing
If you discover an asset you believe is ours but is not listed, report
it; do not test it.

Rules of engagement
  - Access only the minimum data necessary to demonstrate an issue.
  - Stop testing and report immediately if you encounter personal data,
    credentials, or confidential business information.
  - Do not alter, destroy, or retain data; delete any non-public data
    you obtain and tell us you have done so.
  - Do not use an issue to reach other systems, establish persistence,
    or degrade service.
  - Keep findings confidential until we agree they are resolved or the
    disclosure date in our coordination arrives.
  - Stop if we ask you in writing to stop.

How to report
  Email [security@company] (encrypt with the key at [URL]) or use
  [form URL]. Please include: the affected asset, a description, the
  impact, what data (if any) you accessed, and how to reach you.

What to expect
  - Acknowledgment within [N] business days.
  - A triage decision within [N] business days.
  - Status updates at least every [30] days.
  - Credit in our advisory if you wish.

Rewards
  [We do not currently offer monetary rewards. | We offer rewards for
  eligible reports; see [bounty program URL].] We do not pay for
  information withheld from us, and we do not negotiate payment in
  exchange for your silence.

Safe Harbor
  [Insert Template 2.]

This policy may change; changes apply from the date posted. Prior
versions are archived at [URL].

Drafting commentary. The scope section is the most important paragraph in the document, because scope is the boundary of the authorization you are granting. List third-party services as out of scope expressly: you cannot authorize testing of systems you do not control, and a researcher who tests your cloud provider's console is unauthorized there no matter what your policy says. The "stop if we ask" line matters because a written revocation ends authorization, as the Ninth Circuit held in Facebook, Inc. v. Power Ventures, Inc., 844 F.3d 1058 (9th Cir. 2016). The rewards paragraph states, in plain language, the two things that keep the program on the right side of the extortion statutes: no payment for withheld information, and no payment for silence. Do not cite statutes on the public page; keep 18 U.S.C. § 875(d) and § 1030(a)(7) for Template 9 and your internal files.

Template 2: Safe harbor clause (standalone)

Purpose: the promise not to pursue or support legal action against policy-compliant research, scoped to the laws in play and to its real limits. Owner: legal owner. When to use: inside Template 1, and in any bounty platform's policy settings.

Safe Harbor

If you make a good-faith effort to comply with this policy during your
research, we will consider your research to be authorized, and we will:

  (a) not bring or support a claim against you under the Computer Fraud
      and Abuse Act, 18 U.S.C. [SECTION] 1030, or any similar state law,
      for research conducted in accordance with this policy;
  (b) not bring a claim under the Digital Millennium Copyright Act,
      17 U.S.C. [SECTION] 1201, for circumventing technological measures
      to the extent necessary to conduct that research;
  (c) consider that research authorized, and waive any conflicting
      restriction in our terms of service or acceptable use policy, to
      the extent necessary to conduct it;
  (d) not initiate or recommend a referral to law enforcement for that
      research; and
  (e) if a third party brings legal action against you for research we
      authorized, take reasonable steps to make known that your
      research was authorized under this policy.

This Safe Harbor does not apply to, and we reserve all rights regarding:
  - testing outside the scope above or in violation of the rules of
    engagement;
  - accessing, retaining, or disclosing data in violation of this policy;
  - any demand for payment in exchange for withholding, delaying, or
    deleting a report or for not disclosing an issue; and
  - conduct that violates any law other than as expressly addressed here.

This Safe Harbor is prospective. It applies to research conducted while
this policy is in effect and in accordance with it. Nothing in it, and
no reward or later agreement, authorizes access that was unauthorized
when it occurred. We cannot and do not limit the authority of any
government agency or prosecutor.

Drafting commentary. Each clause maps to a legal risk a researcher actually faces. Clause (a) addresses the CFAA, 18 U.S.C. § 1030 and state analogs such as Cal. Penal Code § 502, and it uses the word "authorized" deliberately, because after Van Buren v. United States, 593 U.S. 374 (2021) authorization is the hinge of the analysis. Clause (b) addresses 17 U.S.C. § 1201, whose statutory security research exemption at 37 C.F.R. § 201.40(b) is narrower than a contractual waiver and is reconsidered every three years. Clause (c) handles terms-of-service conflicts, which the DOJ no longer treats as CFAA violations and which a court rejected as a basis for CFAA liability in Sandvig v. Sessions, 451 F. Supp. 3d 73 (D.D.C. 2020), but which can still support a breach-of-contract claim. The limits section is not optional. A safe harbor with no limits is one counsel will refuse to honor when a researcher turns out to have taken data, and the prospective-only sentence exists because United States v. Sullivan, 131 F.4th 776 (9th Cir. 2025) held that post hoc authorization in a nondisclosure agreement could not launder unauthorized access. Do not promise to defend or indemnify; clause (e) commits only to a statement, which is what most programs can actually deliver.

Template 3: security.txt file

Purpose: the machine-readable pointer that tells researchers and tooling where to report and where the policy lives. Owner: program owner. When to use: standing; served over HTTPS at /.well-known/security.txt.

Contact: mailto:security@[company]
Contact: https://[company]/security/report
Expires: [YYYY-MM-DDTHH:MM:SSZ]
Encryption: https://[company]/.well-known/pgp-key.txt
Policy: https://[company]/security/policy
Acknowledgments: https://[company]/security/thanks
Preferred-Languages: en
Canonical: https://[company]/.well-known/security.txt

Drafting commentary. The format follows RFC 9116. Contact and Expires are mandatory; the rest are recommended. Set Expires less than a year out and put a calendar reminder at month ten, because an expired file signals an abandoned program. Serve it over HTTPS and consider signing it with the PGP key referenced in Encryption. Federal civilian agencies also keep a current security contact in the .gov registrar under CISA Binding Operational Directive 20-01.

Template 4: Researcher reward and release agreement

Purpose: the written terms under which the company pays a researcher outside a bounty platform and both sides release claims. Owner: legal owner. When to use: any off-platform payment or negotiated resolution.

Researcher Reward and Release Agreement

Parties: [COMPANY] and [RESEARCHER] ("Researcher").
Subject report: [TICKET / DESCRIPTION], received [DATE].

1. Payment. [COMPANY] will pay Researcher [AMOUNT] within [N] days of
   this agreement, as compensation for the time Researcher spent
   identifying and documenting the Subject report and for the
   commitments below. Payment is contingent on [COMPANY]'s verification
   that Researcher is not a person with whom [COMPANY] is prohibited
   from transacting under applicable sanctions laws, and on receipt of
   tax documentation.

2. Confidentiality. Researcher will keep the technical details of the
   Subject report confidential until the earlier of (a) [N] days after
   [COMPANY] deploys a fix, or (b) [DISCLOSURE DATE]. Nothing in this
   section limits either party's right or ability to report possible
   violations of law to, or communicate with, any governmental agency
   or law enforcement, or to respond to lawful process.

3. Data. Researcher represents that Researcher accessed only
   [DESCRIBE], retained no [COMPANY] or third-party data, and deleted
   all such data on [DATE], as recorded in the deletion log attached as
   Exhibit A.

4. Covenants. Researcher will not attempt further access to [COMPANY]
   systems except as permitted by [COMPANY]'s published policy, and
   will reasonably assist [COMPANY] in verifying the remediation.

5. Mutual release. Each party releases the other from claims arising
   out of the research and the Subject report, except for obligations
   created by this agreement. This release does not extend to any
   person or claim not expressly named.

6. No admission. This agreement is not an admission by either party.

7. Governing law; miscellaneous. [STATE] law governs. [Entire
   agreement; counterparts; etc.]

Drafting commentary. Frame the payment as compensation for time and for the covenants, not for silence; that framing is the difference the extortion statutes turn on. The sanctions condition in section 1 is not boilerplate: payments to blocked persons can violate the International Emergency Economic Powers Act, 50 U.S.C. § 1705, and the cyber-related sanctions regulations at 31 C.F.R. part 578, and OFAC liability is strict. The confidentiality carve-out in section 2 is required, not optional, because the SEC's whistleblower rule at 17 C.F.R. § 240.21F-17 prohibits using confidentiality agreements to impede reports to the Commission, and a clause that misstates the facts to conceal an incident is what sank the Uber NDAs. The data representation in section 3 should be true; do not recite "no data was accessed" when some was. For the general mechanics of a release, see Drafting a Settlement Agreement and Release: A Practical Guide, and for NDA drafting generally, the Drafting a Nondisclosure Agreement Checklist: A Practical Checklist. If the researcher will be engaged as a contractor, consider the trade secret whistleblower immunity notice in 18 U.S.C. § 1833(b).

Template 5: Acknowledgment letter

Purpose: the first reply to any report: neutral, prompt, and committing nothing. Owner: triage team. When to use: within the SLA in Template 1.

Subject: Your security report to [COMPANY] [TICKET-ID]

Hello,

Thank you for reporting this to us. We have opened ticket [TICKET-ID]
and our security team is reviewing it. Your contact for this report is
[NAME, EMAIL].

We expect to give you an initial assessment by [DATE]. If you have
additional technical detail, reproduction steps, or information about
any data that may have been accessed, please reply here.

We appreciate your help.

[NAME], [COMPANY] Security

Drafting commentary. Say nothing about legal consequences, rewards, or whether the sender acted lawfully. This letter will be read later if the matter goes wrong, and its only jobs are to confirm receipt and to keep a researcher inside a cooperative process. Prompt acknowledgment is a basic element of ISO/IEC 29147 and is the first service-level commitment in most VDPs.

Template 6: Request for more detail

Purpose: to get a complete report without making the request sound like a trap. Owner: triage team. When to use: when a report lacks enough to reproduce, or withholds detail.

Subject: RE: Your security report to [COMPANY] [TICKET-ID]

Hello,

To reproduce and fix this, we need a bit more: [the exact URL or
endpoint], [the steps you took], and [what response you observed]. If
you accessed any data that was not your own, please tell us what
categories of data and confirm whether you retained or deleted it; that
helps us scope our response correctly.

We are treating your report as a good-faith disclosure. To be clear
about how we work: we are glad to discuss recognition or a reward for a
report provided without conditions, but we do not pay for information
withheld from us or for non-disclosure.

Thank you,

[NAME], [COMPANY] Security

Drafting commentary. Use this when a report arrives with the detail held back. The second paragraph does two things: it keeps the door open to a legitimate researcher who simply wrote a clumsy email, and it states the company's position so that a sender who is actually conditioning disclosure on payment hears it clearly. Ask what categories of data were accessed, because the answer starts the notification analysis in Template 9.

Template 7: Reward decision letter

Purpose: to communicate a reward decision and tie it to the written agreement. Owner: program owner. When to use: after verification and, usually, remediation.

Subject: RE: [TICKET-ID] - resolution and recognition

Hello,

Thank you again. We confirmed the issue you reported and [have
deployed / are deploying] a fix. [We would like to recognize your
work. / We are able to offer a reward of [AMOUNT].]

[If a reward:] To process it, we will ask you to sign the attached
Researcher Reward and Release Agreement and provide tax and payment
details. As part of our standard process we verify that we are
permitted to make the payment under applicable sanctions laws.

We would be glad to credit you in our advisory as [NAME/HANDLE], or to
keep your report anonymous, as you prefer. Please keep the details
confidential until [DATE] so our users are protected while the fix
rolls out.

[NAME], [COMPANY] Security

Drafting commentary. Keep the confidentiality request tied to the fix, not to the reward. If there is no reward, recognition and a clear close-out still matter: failing to tell a researcher the issue is resolved is the most common reason researchers publish early. Attach Template 4 for any payment.

Template 8: Disclosure timeline and coordination agreement

Purpose: to record a coordinated publication date and the terms around it, so the timeline is a shared remediation norm rather than anyone's leverage. Owner: program owner, with legal. When to use: when researcher and company coordinate a public advisory.

Coordinated Disclosure Agreement

1. Report date: [DATE]. Default disclosure date: [REPORT DATE + 90
   days] ("Disclosure Date").

2. The parties will coordinate a public advisory on or after the
   Disclosure Date. [COMPANY] will request a CVE identifier [through its
   CNA / through a coordinator].

3. [COMPANY] will keep Researcher informed of remediation progress at
   least every [N] days.

4. The Disclosure Date may be extended by agreement if remediation
   requires more time. It will not be shortened except where the issue
   is being actively exploited or a fix has been released, in which
   case earlier coordinated disclosure may occur.

5. The advisory will credit Researcher as [NAME/HANDLE] unless
   Researcher requests otherwise, and will not include personal data.

6. This timeline is independent of any discussion of compensation and
   does not change based on it.

Drafting commentary. Section 6 is the point of the whole document. A timeline that runs regardless of payment is a coordinated disclosure norm; a timeline that moves with the money is leverage, and a prosecutor reading the thread will see the difference. Ninety days is the common default; the CERT Coordination Center uses 45 days. If publication will include proof-of-concept code, counsel should weigh the trafficking provisions of 17 U.S.C. § 1201, which the Second Circuit applied to code publication in Universal City Studios, Inc. v. Corley, 273 F.3d 429 (2d Cir. 2001); the security research exemption covers the act of circumvention, not distribution of tools.

Template 9: Internal triage and notification memo

Purpose: the internal record that classifies the report, decides notification, and preserves evidence, under counsel. Owner: program owner, prepared under counsel's direction. When to use: on every validated report.

PRIVILEGED AND CONFIDENTIAL - PREPARED AT THE DIRECTION OF COUNSEL
[COMPANY] Vulnerability Triage and Notification Memo

Ticket: [ID]      Date: [DATE]      Prepared by: [NAME]

1. Report summary: [what was reported]
2. Validation: [reproduced? known? affected assets/versions]
3. Severity: [CVSS score and vector]
4. Scope: [in-scope under VDP? safe harbor applies?]
5. Sender classification (circle): research report / mixed / extortion
   - detail delivered?  deadline?  payment demand?  data held?
6. Data access analysis:
   - Was non-public personal or regulated data accessed by anyone
     other than [COMPANY]?  [yes/no + log citation]
   - Categories and volume: [ ]
   - Researcher's deletion representation: [ ]
7. Notification determination:
   - State breach laws (e.g., [Cal. Civ. Code 1798.82]): [analysis]
   - HIPAA breach rule [45 C.F.R. 164.400-414]: [four-factor result]
   - FTC Safeguards Rule [16 C.F.R. 314.4(j)]: [applies?]
   - SEC Item 1.05 materiality [17 C.F.R. 229.106]: [applies?]
   - Contracts (customers, cards): [notice windows]
   - Conclusion and deadlines: [ ]
8. Law enforcement / insurer: [referral? insurer notice given?]
9. Payment analysis (if any): [bounty vs. extortion; sanctions screen]
10. Actions and owners: [ ]

Drafting commentary. Mark it privileged and prepare it under counsel so the analysis has the best chance of work-product protection; companies have lost privilege over forensic reports commissioned outside counsel's direction. The notification section runs on its own clock and is not suspended by any discussion with the sender: that separation is the lesson of the Uber case, where concealment while the FTC was investigating produced convictions under 18 U.S.C. § 1505 and 18 U.S.C. § 4. Record the data-access conclusion with a log citation, because the logs are the independent check on the sender's account; preserve them before remediation, since spoliation is sanctionable under Fed. R. Civ. P. 37(e). The notification sources are developed in Data Breach Response and Notification: The Fifty-State Patchwork, Regulators, and Litigation and Cybersecurity Regulation for Businesses: The FTC Safeguards Rule, NYDFS Part 500, SEC Cyber Disclosure, and State Laws.

Template 10: "This reads like extortion" response letter

Purpose: a short, factual reply to a message that conditions silence, detail, or deletion on payment, written to commit nothing and preserve everything. Owner: legal owner, with law enforcement input. When to use: when a message has the structure of a demand, not a report.

Subject: RE: [SUBJECT]

[NAME],

We received your message. We take the security of our systems and our
users' data seriously and are reviewing the matter.

So that we understand what you are describing, please provide the
technical details of the issue you have identified. We are not in a
position to agree to any terms, make any payment, or enter any
agreement at this time.

We are documenting this matter. All communications should be in
writing to this address.

[NAME]
[COMPANY]

Drafting commentary. This letter deliberately does less than the sender wants. It does not accept the demand, does not treat it as a bounty submission, and does not commit to anything, while it asks for the technical detail the company needs and signals that everything is being preserved. Draft it with counsel and, where a demand involves data theft, after consulting law enforcement (the FBI or the Internet Crime Complaint Center). Do not threaten criminal referral as leverage; several states' ethics rules bar a lawyer from threatening criminal charges to gain advantage in a civil matter, descended from former Disciplinary Rule 7-105 and reflected in ABA Formal Opinion 92-363. If the sender took data and is demanding payment to withhold it, this is an extortion event under the Hobbs Act, 18 U.S.C. § 1951, 18 U.S.C. § 875(d), and the CFAA's computer-extortion clause, 18 U.S.C. § 1030(a)(7); run the playbook in Responding to a Ransomware Attack: A Practical Guide for the First Two Weeks and use the records in the Ransomware Response Toolkit: Decision Memos, Sanctions Screening Records, and Notification Templates. Notify your insurer before incurring any extortion expense; see Placing and Tendering a D&O or Cyber Claim: A Practical Guide.

Putting it together: Fathom Freight Systems

The program. Dana Ooi stands up Fathom's program using Templates 1 through 3. The policy lists 28 in-scope hosts and expressly excludes Fathom's cloud provider's console and its payment processor. The safe harbor (Template 2) authorizes in-scope research under the CFAA and state law, waives § 1201 and terms-of-service claims for that research, commits to a statement of authorization if a third party sues, and states that it is prospective only. Fathom publishes security.txt with an Expires date eleven months out.

The good report. In March a researcher, Lena Varga, reports through the form that a reporting endpoint returns records from other tenants. She says she confirmed the flaw against her own second test tenant and took nothing else. Ooi sends the acknowledgment (Template 5) within a day. The security team reproduces the flaw and fixes it in a week. Under counsel's direction, Ooi fills out the triage memo (Template 9): the data accessed was Varga's own test tenant, so no notification is triggered, and the memo records why. Fathom offers Varga $4,000 and a coordinated advisory. Varga signs the reward and release agreement (Template 4); Fathom screens her against sanctions lists, collects tax forms, pays through accounts payable, and credits her in an advisory published on day 75 under the coordination agreement (Template 8).

The mixed message. In May a report arrives that describes a real flaw but ends: "we can discuss our fee once we are comfortable the details are safe with you." Ooi does not accuse anyone. She sends the request-for-detail letter (Template 6), which states that Fathom will discuss a reward for a report provided without conditions but does not pay for withheld information. The sender replies with the full detail and apologizes; the matter becomes an ordinary report.

The demand. In July a message arrives from an anonymous address: "We have 2.1 million Fathom shipping records including cardholder data. We will keep this private for 3 BTC. 96 hours." Bell, the general counsel, treats it as an extortion event. The support team forwards it untouched. Fathom preserves the logs, which show bulk access from a hosting provider abroad. Bell sends the Template 10 letter and nothing more, notifies Fathom's cyber insurer that day, reports to the FBI field office, and opens a triage memo that this time concludes a breach occurred: Fathom notifies affected individuals, the card networks, the states whose statutes apply, and, because some records belong to a hospital customer's patients, coordinates HIPAA notification with that customer within the 60-day outer limit. Fathom runs a sanctions analysis before even considering a payment, and ultimately does not pay. The bounty program is never involved.

The four episodes use the same ten documents. The difference between them is not the company's mood; it is the structure of each incoming message and what Fathom's own logs show, read the same way every time.

This document is general information, not legal advice for any particular situation; the law changes, and the facts matter.

Related Documents

Related Articles

Related Guides

Related Checklists

Related Toolkits