Vulnerability Disclosure Program and Safe Harbor Checklist: A Practical Checklist

A vulnerability disclosure program (VDP) is a promise in two directions. To researchers, it says: test these systems, in these ways, tell us what you find, and we will not treat you as a criminal. To the company, it says: you will hear about your flaws from people who are telling you, through a channel you control, on a timeline you can meet. Both promises fail in predictable places, almost always because the policy was copied from someone else's website without anyone asking what each sentence commits the company to.

How to use this checklist

Work through the phases in order. Phases 1 through 6 are required for any program; Phase 7 applies only if you will pay rewards; Phase 8 applies to the sectors it names. Each item states what to do, links the governing authority where there is one, and adds a practical note. Items marked with a red-flag box are the ones that most often turn a good-faith report into a dispute.

The legal background is in Paid Vulnerability Disclosure and the Line Between Research and Extortion. The step-by-step handling of an individual report, for both the researcher and the company, is in Reporting or Receiving a Security Vulnerability: A Practical Guide for Researchers and Companies. Templates for the policy, the safe harbor clause, researcher terms, and response letters are in the Vulnerability Disclosure Toolkit: VDP Policies, Safe Harbor Terms, Researcher Agreements, and Response Letters. Device makers should read this checklist alongside Building a Product Security Program for Connected Devices: A Practical Guide.

Phase 1: Governance and ownership

• Name a program owner with authority to fix things. Usually the head of product security or the CISO. The owner must be able to assign engineering work, not just log tickets. Note: a VDP that routes to a team with no remediation authority produces a backlog and, eventually, researchers who publish early.
• Name a legal owner. Counsel reviews the policy text, signs off on safe harbor determinations, and is consulted on any report that involves personal data, a payment request, or a threat. Note: decide in advance which reports must go to legal on day one (see Phase 5).
• Define the program's relationship to the incident response plan. A report that shows personal data was accessed is a potential incident. Write the hand-off into both documents. The incident-side playbook is in the Data Breach and Incident Response Toolkit: From Detection to Notification.
• Map the regulatory reasons the program matters. The FTC treats unreasonable security as an unfair practice under 15 U.S.C. § 45, an authority upheld in FTC v. Wyndham Worldwide Corp., 799 F.3d 236 (3d Cir. 2015), and it has faulted companies for lacking a process to receive and address vulnerability reports, notably in its 2013 consent order with HTC America. Covered financial institutions must run continuous monitoring or periodic penetration testing and vulnerability assessments under the Safeguards Rule, 16 C.F.R. § 314.4(d)(2). Public companies describe their cybersecurity risk management processes under 17 C.F.R. § 229.106.
• Budget for the work the program creates. Triage hours, remediation, platform fees if any, rewards if any, and outside counsel for the hard cases.
• Decide reporting lines to leadership and the board. Severity thresholds that trigger escalation, and a quarterly metrics report (reports received, valid, time to acknowledge, time to remediate). The broader compliance program context is in Building a Cybersecurity Compliance Program That Satisfies Regulators: A Practical Guide.

Phase 2: Scope

• Inventory candidate assets. Domains and subdomains, web and mobile applications, APIs, devices and firmware, open source projects you maintain, and internal tools exposed to the internet. Note: the inventory is the program's foundation; an asset you forgot to list is an asset researchers will find.
• List in-scope assets specifically. Use exact hostnames, wildcard patterns you can stand behind, app store identifiers, and product versions. Avoid "all Company systems."
• List out-of-scope assets expressly. Third-party services (cloud providers, payment processors, SaaS tools, CDNs), customer-controlled tenants, acquired companies not yet integrated, physical offices, and employees. Note: you cannot authorize testing of systems you do not own or control. A Power Ventures-style revocation dispute can begin with a researcher who reasonably thought a vendor-hosted page was yours.
• Decide how to handle out-of-scope reports. Most programs accept them and decide case by case whether to extend safe harbor. Say so.
• Separate production and test environments. Offer a test environment or test accounts where feasible; it reduces the chance that research touches real customer data.
• Set a rule for newly discovered assets. Assets found during testing that are not listed: report, do not test further.
• Schedule scope reviews. At least quarterly, and whenever you launch a product or close an acquisition.

Phase 3: Authorization and safe harbor language

Red flag: a safe harbor that says "we will not take legal action" without saying against what conduct, under which laws, and with what limits. It promises too much to the company's lawyers and too little to the researcher.

• State the authorization expressly. Say that research conducted in accordance with the policy is "authorized" for purposes of the Computer Fraud and Abuse Act, 18 U.S.C. § 1030. Note: after Van Buren v. United States, 593 U.S. 374 (2021), the scope of a person's authorization is the central question; the policy is where you define it.
• Cover state computer crime laws. Name them generally ("and any similar state law"), and consider naming the statutes in states where you operate, such as Cal. Penal Code § 502, which has its own civil action.
• Cover the DMCA anti-circumvention provisions. Commit not to bring a claim under 17 U.S.C. § 1201 for circumvention of technological measures in the course of in-scope research. Note: the Copyright Office's security research exemption at 37 C.F.R. § 201.40(b) is narrower than a contractual waiver and is reconsidered every three years; the tenth triennial proceeding opened in 2026 (91 Fed. Reg. 34796). Background is in The DMCA Anti-Circumvention Provisions: Section 1201, Digital Locks, and the Triennial Exemptions.
• Waive conflicting terms of service and acceptable use restrictions to the extent necessary for in-scope research, without waiving the rules of engagement in the policy itself. Note: contract claims, not the CFAA, decided the end of the hiQ litigation; see Data Scraping After hiQ v. LinkedIn: Copyright, Contract, and Computer Fraud Claims.
• State the company's position on referral to law enforcement. Typical language: the company will not initiate or recommend a complaint to law enforcement for policy-compliant research. Note: do not promise that no prosecutor will act. You cannot bind the government, and the Department of Justice's 2022 good-faith research charging policy (Justice Manual 9-48.000) is policy, not law.
• Commit to tell third parties that research was authorized. If a third party sues or complains about policy-compliant research, the company will make known that the research was authorized. Note: this is a commitment about your statements, not a promise to defend or indemnify.
• Define the limits of the safe harbor. It does not cover research outside scope, conduct prohibited by the policy, data retained or disclosed in violation of the policy, or demands for payment conditioned on non-disclosure.
• Say expressly that the safe harbor is prospective. It applies to research conducted while the policy is in effect and in accordance with it. Do not suggest that a reward or later agreement can authorize past unauthorized access. Note: the Ninth Circuit held in United States v. Sullivan, 131 F.4th 776 (9th Cir. 2025) that intruders' unlawful access could not be laundered through post hoc authorization in a nondisclosure agreement.
• Add an extortion exclusion. Reports accompanied by a demand for payment in exchange for silence, deletion, or the technical detail are outside the program. Cite nothing in the policy; the statutes (18 U.S.C. § 875(d), § 1030(a)(7), the Hobbs Act at 18 U.S.C. § 1951) are for counsel, not for the public page.
• Reserve the right to amend, with notice. Changes apply prospectively from the posted date; keep an archive of prior versions so you can show what was in force on any date.
• Get the language reviewed by litigation counsel, who will be the one trying to rely on it or distinguish it later.

Phase 4: Rules of engagement

Red flag: a policy that permits testing but says nothing about personal data. That gap is how a research report becomes a breach notification.

• Require data minimization. Access only the data needed to demonstrate the issue; stop and report as soon as personal data, credentials, or confidential business information is encountered. Note: minimization is also what lets you conclude, case by case, that a report did not trigger notification under laws such as Cal. Civ. Code § 1798.82 or the HIPAA breach rule at 45 C.F.R. part 164.
• Require deletion and a statement of deletion. Researchers must delete any non-public data obtained and confirm in writing when they report.
• Prohibit high-risk methods. Denial of service, social engineering of employees or customers, physical intrusion, spam, and destructive testing, unless separately authorized.
• Prohibit pivoting and persistence. No use of an exploited issue to reach other systems, no installation of backdoors, and no retention of access.
• Limit automated scanning to rates and tools the policy permits, if it permits them at all.
• Require the researcher to stop when asked. A written instruction to stop testing ends authorization for that activity.
• Require confidentiality until resolution. Researchers keep details confidential until the issue is fixed or the disclosure date arrives (Phase 6).
• Address minors and employees. Employees and contractors report through internal channels; check the platform's age rules if you run a bounty.

Phase 5: Intake channel and security.txt

• Create a dedicated intake address or web form that reaches the program team directly. Note: never route reports through general support queues.
• Offer encrypted submission. Publish a public key or use a web form over TLS with authenticated storage.
• Publish security.txt under RFC 9116. Serve it over HTTPS at /.well-known/security.txt. Include the required Contact and Expires fields, and the useful optional fields Policy, Encryption, Acknowledgments, Preferred-Languages, and Canonical. Consider signing it. Note: the Expires field is mandatory; set a calendar reminder to update it before it lapses, because an expired file tells researchers the program may be abandoned.
• Publish the policy at a stable URL and link it from the website footer, the security page, product documentation, and app store listings.
• Register security contacts where registries exist. Federal agencies must keep the security contact current in the .gov registrar under CISA BOD 20-01. Consider becoming a CVE Numbering Authority if you ship software at scale.
• Define what a complete report contains, without making submission burdensome: the asset, a description, impact, data accessed if any, and contact details. Do not require researchers to sign an agreement before reporting.
• Define the day-one legal triggers. Route to counsel immediately any report that (a) says personal data was accessed, (b) requests payment outside a published bounty, (c) includes a deadline or a threat, or (d) comes from a journalist or regulator.
• Preserve every submission and every reply in a system with retention controls; the file is evidence if a dispute follows.

Phase 6: Triage, service levels, and disclosure

• Adopt a written handling process aligned with ISO/IEC 30111 (receipt, verification, remediation development, release, post-release) and the disclosure practices of ISO/IEC 29147 (communication with reporters, advisories). Note: the standards are not law, but regulators and customers increasingly treat them as the benchmark for "reasonable."
• Publish service levels you can meet. Common targets: acknowledgment within 1 to 3 business days; triage decision within 5 to 10 business days; status updates at least every 30 days.
• Adopt a severity scheme (most companies use FIRST's CVSS) and remediation targets by severity.
• Integrate the notification check. Every validated report gets a recorded answer to one question: was non-public personal or regulated data accessed by anyone other than the company? If yes, hand off to the incident process. The fifty-state analysis is in Data Breach Response and Notification: The Fifty-State Patchwork, Regulators, and Litigation.
• Preserve logs on validation. When a report is validated, preserve the relevant access logs before remediation changes the system; spoliation is sanctionable under Fed. R. Civ. P. 37(e) if litigation follows.
• Set the disclosure timeline. State a default (90 days is common), the circumstances in which you will ask for more time, and the circumstances in which earlier disclosure may occur (active exploitation, fix released). Note: the timeline must be the same whether or not a reward is paid.
• Decide on public advisories and CVE assignment. Who writes advisories, who approves them, and how researchers are credited.
• Commit to tell the researcher when the fix ships. Failure to close the loop is the most common reason researchers publish early.

Red flag: different timelines or different treatment for reports that come with a reward request. Any variation tied to money undermines the program's defense that the timeline is a remediation norm.

Phase 7: Bounty program design (if you will pay)

• Decide platform or self-hosted. Platforms (HackerOne, Bugcrowd, Intigriti, YesWeHack and others) handle intake, identity checks, tax forms, and payment, under their own terms. Note: read the platform's terms; they add confidentiality obligations, a disclosure process, and sometimes their own safe harbor text that must be reconciled with yours.
• Publish a reward table by severity and asset class, with the right to award above or below for quality. Note: a published table makes it easier to recognize a demand that falls outside the program.
• Define eligibility. Exclude employees, contractors with access, their families, and anyone the company cannot lawfully pay.
• Screen every payee against sanctions lists before payment. 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; blocked and rejected transactions must be reported under 31 C.F.R. part 501. Platforms usually screen, but the company remains responsible. The general sanctions framework is in Export Controls and Economic Sanctions: The EAR, ITAR, and OFAC for Ordinary Businesses.
• Collect tax information as your finance team requires before paying.
• State that rewards are discretionary and that duplicate, out-of-scope, or non-compliant reports may not qualify.
• Exclude extortion expressly. No reward for reports conditioned on payment, for data taken in violation of the rules, or for demands with deadlines. Note: routing an intruder's demand through the bounty program was the core of the Uber prosecution.
• Prepare a standard researcher agreement for off-platform payments. Mutual release, covenant not to test outside scope, confidentiality tied to remediation, and a carve-out for communications with regulators and law enforcement. The SEC's whistleblower rule at 17 C.F.R. § 240.21F-17 bars using confidentiality agreements to impede reports to the Commission. If the agreement imposes confidentiality on an individual engaged as a contractor, consider the whistleblower immunity notice described in 18 U.S.C. § 1833(b).
• Check the cyber insurance policy. Bounty payments are typically not covered and do not need consent; extortion payments typically require insurer consent. Know which is which before a demand arrives. See Placing and Tendering a D&O or Cyber Claim: A Practical Guide.

Red flag: a one-off "consulting fee" or payment above the reward table to a person who withheld detail or set a deadline. Treat it as an extortion event and follow the playbook in Responding to a Ransomware Attack: A Practical Guide for the First Two Weeks, not the bounty process.

Phase 8: Sector overlays

• Federal civilian agencies: comply with CISA BOD 20-01. The directive required agencies to publish a VDP with prescribed elements (scope, permitted testing, submission instructions, a commitment not to recommend legal action against good-faith researchers, and response expectations), to keep .gov security contacts current, and to expand scope to all internet-accessible systems on a schedule. Agencies also follow the federal guidelines developed under the IoT Cybersecurity Improvement Act. Note: check CISA's site for any later directive or guidance that supplements it.
• Federal contractors supplying IoT devices: build to NIST SP 800-216. The Internet of Things Cybersecurity Improvement Act of 2020, Pub. L. No. 116-207, directed NIST (under its computer standards authority in 15 U.S.C. § 278g-3) to publish guidelines on receiving and disseminating vulnerability information, and restricts agency procurement of covered IoT devices from contractors that do not comply, subject to waivers. Note: bills pending in Congress would extend VDP requirements to federal contractors generally; check status before advising.
• Medical device manufacturers: include coordinated disclosure in the premarket cybersecurity plan. Section 524B of the Federal Food, Drug, and Cosmetic Act requires sponsors of "cyber devices" to submit a plan to monitor, identify, and address postmarket vulnerabilities, including coordinated vulnerability disclosure. Quality system obligations under 21 C.F.R. part 820 apply to the processes.
• Consumer connected products sold in the UK and EU. The UK's product security regime under the Product Security and Telecommunications Infrastructure Act 2022, in force since 29 April 2024, requires manufacturers of consumer connectable products to publish a vulnerability disclosure policy. The EU Cyber Resilience Act, Regulation (EU) 2024/2847, requires manufacturers to report actively exploited vulnerabilities from 11 September 2026, and its essential requirements, including a coordinated vulnerability disclosure policy, apply from 11 December 2027. Note: scope and product classification turn on local rules, so confirm them with UK or EU counsel. The product-side duties are in Connected Device Security and Software Liability: Regulators, Standards, and the Duty to Patch.
• Health care and financial services. Tie the program's notification check to the HIPAA breach rule (45 C.F.R. §§ 164.400-414), the FTC Safeguards Rule notification requirement (16 C.F.R. § 314.4(j)), and bank incident notification rules (12 C.F.R. part 53).
• Public companies. Make sure the disclosure committee hears about critical validated reports that might bear on materiality under Item 1.05 of Form 8-K (17 C.F.R. part 249).

Phase 9: Launch and maintenance

• Run a tabletop using three scenarios: a clean report, a report with personal data, and a demand with a deadline.
• Train the people who might receive a report by accident: support, social media, sales, and executive assistants. They should forward, not answer.
• Publish, then announce on the security page and in release notes.
• Review annually: scope, safe harbor language, service-level performance, the security.txt Expires date, the Copyright Office's triennial exemptions, and any change in the DOJ charging policy.
• Keep a versioned archive of the policy and security.txt.
• Report metrics to leadership quarterly.

Deadlines and recurring dates

Common failure points

1. Copied policy, mismatched scope. The policy lists assets the company no longer owns and omits the ones it does.
2. Safe harbor with no limits, which counsel later refuses to honor, or limits so broad that no researcher believes it.
3. No personal data rule, so the first serious report becomes a notification event.
4. Expired security.txt, which tells researchers the channel is dead.
5. Silent fixes. The company patches and never tells the researcher, who publishes on day 91.
6. Bounty used as an extortion channel. A payment to someone who took data, labeled as a bounty.
7. Confidentiality terms without regulatory carve-outs, which create exposure under SEC Rule 21F-17 and look like concealment.
8. No one trained to forward. The report reaches a support agent, who closes it as spam.

Worked example: Brightwater Analytics

Brightwater Analytics is a 600-person software company selling a hosted analytics product to hospitals and retailers. It has no VDP. In January a researcher emails the CEO about an exposed administrative interface; the email sits for three weeks before anyone answers.

Brightwater's general counsel uses this checklist to build a program in eight weeks. Phase 1 names the VP of security as owner and an in-house privacy lawyer as legal owner, and adds a hand-off clause to the incident response plan. Phase 2 produces an inventory of 41 internet-facing hosts; 33 go in scope, and the policy excludes the cloud provider's management console, customer-configured integrations, and a recently acquired subsidiary's systems. Phase 3 produces a safe harbor that authorizes in-scope research under the CFAA and similar state laws, waives § 1201 and terms-of-service claims for that research, commits not to initiate law enforcement complaints, says it is prospective only, and excludes payment-for-silence demands. Phase 4 adds a stop-on-personal-data rule, because Brightwater processes protected health information as a HIPAA business associate. Phase 5 publishes security.txt with an Expires date eleven months out and a calendar reminder at month ten. Phase 6 commits to acknowledgment within two business days, a 90-day default disclosure date, and a notification check on every validated report. Brightwater decides against a bounty for its first year (Phase 7), but drafts a researcher agreement for discretionary payments and adds a sanctions screen to accounts payable. Phase 8 confirms that its hospital customers' contracts require notice of security incidents within 72 hours, which the incident hand-off now captures.

In month four a report arrives through the new form: an access-control flaw in the reporting module. The researcher confirms she saw only her own test tenant's data. Brightwater acknowledges in a day, fixes in nine, records that no notification is triggered and why, credits her in an advisory, and pays $2,500 under the standard agreement after screening. In month six a second message arrives demanding money to keep a "data sample" private. Because the policy's extortion exclusion and the day-one legal triggers are already written, the support team forwards it untouched, and counsel runs the extortion playbook instead of the bounty process.

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

Related Documents

Related Articles

• Paid Vulnerability Disclosure and the Line Between Research and Extortion: why the safe harbor's limits and extortion exclusion matter.
• The DMCA Anti-Circumvention Provisions: Section 1201, Digital Locks, and the Triennial Exemptions: the exemption your § 1201 waiver supplements.
• Connected Device Security and Software Liability: Regulators, Standards, and the Duty to Patch: sector rules that require disclosure programs.
• Failed Software Implementations: Contract, Fraud, and Warranty Claims When an IT Project Goes Wrong: failed technology projects and the contract, warranty, and fraud claims that follow.

Related Guides

• Reporting or Receiving a Security Vulnerability: A Practical Guide for Researchers and Companies: handling each report once the program exists.
• Building a Product Security Program for Connected Devices: A Practical Guide: the device-maker program around the VDP.
• Building a Cybersecurity Compliance Program That Satisfies Regulators: A Practical Guide: where the VDP fits in the compliance program.
• Pursuing or Defending a Failed Technology Project Claim: A Practical Guide: failed technology projects and the contract, warranty, and fraud claims that follow.

Related Checklists

• Cybersecurity Regulatory Compliance Checklist: A Practical Checklist: the regulatory obligations behind Phase 8.
• Ransomware Readiness and Response Checklist: A Practical Checklist: readiness for the extortion scenarios the program excludes.
• Vendor Cybersecurity Diligence Checklist: A Practical Checklist: asking vendors whether they run a VDP.
• Troubled Technology Project Checklist: A Practical Checklist: failed technology projects and the contract, warranty, and fraud claims that follow.

Related Toolkits

• Vulnerability Disclosure Toolkit: VDP Policies, Safe Harbor Terms, Researcher Agreements, and Response Letters: the policy, clauses, and letters this checklist calls for.
• Product Security Toolkit: SBOMs, Vulnerability Disclosure, and Recall Decisions: triage worksheets and advisory templates.
• Data Breach and Incident Response Toolkit: From Detection to Notification: the incident side of the hand-off.
• Ransomware Response Toolkit: Decision Memos, Sanctions Screening Records, and Notification Templates: sanctions screening records for any payment.
• Technology Project Dispute Toolkit: Notice of Breach Letters, Cure Plans, and Project Record Protocols: failed technology projects and the contract, warranty, and fraud claims that follow.