A security researcher finds a serious vulnerability in your platform. They report it to you, expecting recognition, a bounty payment, or at minimum a safe process to disclose responsibly. Without a written bug bounty agreement in place, you have no contract governing what the researcher can do with the information, what your obligations are, or whether their discovery constitutes unauthorized access under federal law.
Companies run bug bounty programs and vulnerability disclosure programs (VDPs) for good reason: external security research catches real vulnerabilities that internal teams miss. But the same programs, if legally unstructured, create exposure for your business and the researchers you’re inviting to probe your systems. This guide covers what your bug bounty program terms must include and why the Computer Fraud and Abuse Act makes written authorization more than a formality.
1. The CFAA Problem: Why Written Authorization Is Non-Negotiable
The Computer Fraud and Abuse Act (18 U.S.C. § 1030) makes unauthorized access to computer systems a federal crime. “Unauthorized” is the key word. Courts have interpreted the CFAA broadly in some cases, and the absence of written authorization from a company can expose a security researcher to criminal or civil liability even when their intent was entirely constructive.
Your bug bounty program terms function as written authorization. They define the specific systems and testing methods a researcher is permitted to use, and they create a legal record that the activity was consented to. Without them, a researcher who discovers a vulnerability by testing your API endpoints has no documented authorization for that activity.
This also protects your company. A researcher who acts outside the scope of your program, accesses data they were not authorized to access, or discloses a vulnerability publicly before you have patched it, has violated the agreed terms. Without written terms, you have no contractual basis to enforce those limits.
2. Bug Bounty Program vs. Vulnerability Disclosure Policy: The Difference Matters
A vulnerability disclosure policy (VDP) is a public statement explaining how your company receives, processes, and responds to security reports. It sets expectations for researchers but does not typically offer financial rewards. A bug bounty program includes financial compensation tied to severity or validity of findings.
Both require legal agreements, but with different emphases:
- A VDP agreement focuses on the disclosure process: how reports are submitted, response time commitments, safe harbor language, and what you will and will not do with the finding
- A bug bounty agreement adds payment terms, eligibility criteria, dispute resolution for payment disputes, tax documentation requirements, and scope definitions that protect both parties from misunderstandings about what was authorized
CISA (Cybersecurity and Infrastructure Security Agency) has published binding operational directive BOD 20-01 requiring US federal agencies to publish VDPs, and many private sector companies have adopted similar policies as a best practice. ISO/IEC 29147 is the international standard for vulnerability disclosure practices. Neither source provides legal drafting guidance, which is where your written agreement becomes essential.
3. Scope Definition: The Clause Most Programs Get Wrong
Scope is where most program terms fail. A vague scope clause creates a legal gray area: the researcher believes they were authorized to test a system because it was related to your product; your team believes that system was outside the program.
Your scope section must specify:
- Exactly which domains, applications, IP ranges, or systems are in scope
- Which are explicitly out of scope (infrastructure shared with other customers, third-party systems you do not control, production databases containing customer data)
- Which testing methods are permitted (e.g., automated scanning, injection testing, authentication bypass) and which are prohibited (social engineering of employees, physical access attempts, denial-of-service testing)
- Whether testing is permitted against live production systems or only staging environments
The scope section is also where you should address what happens with customer data. If a researcher discovers a vulnerability by accessing data they were not supposed to reach, your terms need to require immediate reporting and prohibit any further use, retention, or disclosure of that data. Leaving this unaddressed creates significant exposure under state privacy laws and, where applicable, GDPR.
4. Safe Harbor Language: What Researchers Need to Participate
Experienced security researchers will not participate in a program that does not include a safe harbor clause. A safe harbor provision states that the company will not pursue civil or criminal legal action against researchers who act within the program’s defined scope and follow the disclosure rules.
Your safe harbor clause should:
- Explicitly state that authorized testing activity does not constitute unauthorized access under the CFAA
- Waive claims under applicable state computer crime statutes for in-scope activities
- Confirm that you will not refer the researcher to law enforcement for in-scope activities
- Limit the protection to activity that complies with the program’s scope and rules
Safe harbor does not give researchers unlimited protection. It covers authorized, in-scope activity that follows your disclosure rules. Researchers who access production databases, exfiltrate data, or disclose publicly before your patch cycle is complete are not covered.
Any relationship with an external researcher who will have access to your systems should also be covered by a confidentiality agreement. Your NDA for technology companies can be adapted to cover researchers, protecting your vulnerability details during the remediation window.
5. Disclosure Timeline and Coordinated Disclosure Rules
The tension between researchers and companies usually peaks during the disclosure window. Researchers want to publish their findings, which advances their professional reputation. Companies want time to patch before the vulnerability is public. Your terms need to set clear, binding timelines.
Industry practice, reflected in programs from Google, Microsoft, and the HackerOne platform, typically gives companies 90 days to patch a critical vulnerability before a researcher may publish. Your terms should:
- Define the disclosure timeline clearly (e.g., 90 days from acknowledgment of a valid report)
- Specify what triggers the clock (your acknowledgment, or the researcher’s submission)
- Explain what happens if you need more time, and what your obligations are to the researcher if you extend the timeline
- Address what constitutes a “public disclosure” that would end your confidentiality window
- Set out your process for coordinating with the researcher on publication timing
Researchers who submit to programs with clear, fair disclosure timelines are far less likely to go public prematurely. Vague or unreasonably long timelines push researchers toward platform-standard policies or unilateral disclosure.
6. Payment Terms: What a Bug Bounty Agreement Must Include
If your program offers financial rewards, your agreement must address the payment relationship with legal precision. Ambiguous payment terms are the most common source of disputes between companies and researchers.
Your payment terms should cover:
- How bounty amounts are determined (by severity tier, CVSS score, or company discretion)
- Whether the company’s payment decision is final or subject to appeal
- Eligible payment methods and any geographic restrictions (some payment platforms do not operate in all countries)
- Tax documentation requirements: researchers receiving payments above IRS thresholds will receive a 1099, and your terms should require accurate identity verification and tax information before payment
- Conditions that void payment eligibility (duplicate submissions, out-of-scope findings, violations of program rules)
If you run your program through a third-party platform such as HackerOne, Bugcrowd, or Intigriti, those platforms have their own payment and legal frameworks. You still need your own program terms governing scope, authorization, and disclosure, because the platform’s terms govern the platform relationship, not your specific authorized testing scope.
7. Connecting Bug Bounty Terms to Your Broader Legal Framework
Your bug bounty program does not sit in isolation. Researchers who test your product will encounter your API terms of use and your platform’s terms of service. Your bug bounty agreement should make clear that authorized testing activity under the bug bounty program supersedes any prohibitions in your general terms on automated access, testing, or reverse engineering, but only within the defined scope.
This alignment across your legal documents matters. A researcher who tests your API under your bug bounty program should not face a claim that they violated your general API terms by using automated tools, if those tools were within the authorized scope of the bug bounty program.
A terms of service lawyer with technology law experience can review your entire document set, including your ToS, API terms, NDA, and proposed bug bounty terms, to make sure these documents are internally consistent and that your authorization language is legally sufficient to provide the protection your researchers and your company both need.
Frequently Asked Questions
Do I need a lawyer to set up a bug bounty program?
You do not need a lawyer to create a basic vulnerability disclosure page, but you do need qualified legal drafting for the authorization and safe harbor language in your bug bounty agreement. The CFAA implications, payment terms, and multi-jurisdiction considerations are not well handled by general templates, and errors create real legal exposure for both your company and the researchers you invite.
Can security researchers face criminal liability even if they report a vulnerability responsibly?
Under the CFAA as currently interpreted, accessing computer systems without clear written authorization carries legal risk regardless of intent. Your bug bounty program’s safe harbor clause provides the authorization that removes that risk for in-scope activity. Without it, researchers face legal uncertainty, which reduces quality research participation.
What is the difference between a bug bounty and a vulnerability disclosure program?
A bug bounty program pays researchers for valid findings. A vulnerability disclosure program (VDP) provides a formal channel for receiving reports without necessarily offering financial rewards. Both require written program terms covering authorization, scope, and disclosure rules. The bug bounty program additionally needs payment terms and eligibility criteria.
What happens if a researcher finds data they were not supposed to access?
Your program terms should require immediate reporting and prohibit any further access, copying, or use of data discovered outside the authorized scope. The researcher’s safe harbor protection should not extend to unauthorized data access, and your terms should make this explicit. You may also have independent notification obligations under state breach notification laws depending on what data was accessed.
Can I limit my program to invited researchers only?
Yes. Private bug bounty programs that invite specific researchers give you more control over who is authorized to test your systems. The same legal requirements apply: you need written program terms covering scope, authorization, safe harbor, and disclosure rules, but a private program lets you vet participants before extending authorization.
Conclusion
Security research benefits every company that takes it seriously, and the companies that attract the best researchers are the ones with clear, fair, and legally sound program terms. A bug bounty agreement written without attention to the CFAA authorization requirements, scope clarity, and coordinated disclosure rules creates legal risk on both sides of the relationship.
If you are launching a bug bounty program or vulnerability disclosure policy, contact Hansen Tong at TOSLawyer.com to get program terms that protect your company and give researchers the authorization clarity they need to participate.