Bug Bounty Programme Brief Template: Scope and Rewards

Researchers decide in minutes whether a bug bounty is worth their time, and a vague brief with unclear scope, no safe harbour and an unpublished reward table loses the best of them while attracting noise. A programme brief is the public document a researcher reads before testing: what is in scope, what is not, how to test without causing harm, what each severity pays, how fast you will respond and what legal protection they have. This template gives a publishable brief with [Organisation] placeholders and internal notes. It is distinct from a vulnerability disclosure policy (VDP), which invites reports without payment; keep your VDP as the baseline and run the bounty on top of it, using the Vulnerability Disclosure Policy Template. It is for application security, product security and legal teams launching a public or private programme. Have counsel review the authorisation wording for your jurisdiction before publishing.

How to use this template

Two audiences: the numbered sections are public text written to researchers ("you"). Lines marked "Internal note" are for your team only and must be removed before publishing.
Replace every bracketed item: [Organisation], [[email protected]], [asset lists], [amounts] and timings. Publish only commitments you can meet with your current triage capacity.
Start private, then go public: invite a small group of researchers for the first [60 to 90] days to measure report volume and triage load, then widen scope and audience.
Link it from security.txt: RFC 9116 defines /.well-known/security.txt, which must contain Contact and Expires fields and can carry a Policy field pointing to your VDP and bounty brief.
Decide the model first: if you are unsure whether you need a bounty, a VDP or penetration testing, read the Bug Bounty and Vulnerability Disclosure Guide before using this template.

What a strong brief contains

Element	Why researchers care	Section
Precise in-scope asset list with asset types	Avoids wasted effort and disputes	3
Explicit exclusions and non-qualifying findings	Sets expectations before testing starts	4
Safe harbour statement	Legal protection for good-faith research	5
Testing rules (rate limits, test accounts, data handling)	Lets them test without breaking your service	6
Reward table by severity and asset tier	The main reason to participate	8
Response SLAs	Shows the programme is staffed	9
Disclosure terms	Defines when and how findings may be published	10

1. Programme overview

[Organisation] runs this bug bounty programme to find and fix security vulnerabilities in our products and services before they can be exploited. We reward valid, previously unknown vulnerabilities reported under the rules below. This brief was issued on [date] and last updated on [date]. Changes apply to reports submitted after the update date.

This programme operates alongside our vulnerability disclosure policy at [https://example.com/security/vdp]. Anyone may report a vulnerability under that policy; this brief adds rewards for eligible findings on the assets listed in section 3.

Internal note: name the programme owner, the triage team and the budget holder here in your internal copy.

2. Eligibility

You must be the first to report the vulnerability, and it must not already be known to us or public.
You must not be a current or recent [within 12 months] employee or contractor of [Organisation] or its subsidiaries, or a family member of one.
You must not be resident in, or reporting from, a country subject to sanctions that prohibit payment to you.
You must comply with this brief and with applicable law. Rewards may be withheld for reports that break these rules.
[Optional: participants under [18] require consent from a parent or guardian.]

3. In-scope assets

Only the assets listed below are eligible for rewards. Subdomains not listed are out of scope unless marked with a wildcard.

Asset	Type	Tier	Notes
[app.example.com]	Web application	Tier 1	[Production; use test accounts from section 6]
[api.example.com]	API	Tier 1	[OpenAPI specification at URL]
[*.example.com]	Wildcard domain	Tier 2	[Excludes assets in section 4]
[Mobile app, iOS and Android, current store version]	Mobile	Tier 2	[Bundle IDs]
[AI assistant at chat.example.com]	AI feature	Tier 2	[See AI rules in section 6]
[Desktop agent version x.y]	Downloadable software	Tier 3	[Latest version only]

Internal note: Tier 1 holds the assets with the most sensitive data or widest reach. Confirm with each owner that the asset can withstand testing and that monitoring teams know the programme is live, so researcher traffic is not escalated as an incident.

4. Out of scope

4.1 Excluded assets

[Third-party services we use, such as hosted support desks, payment processors and marketing platforms], unless the vulnerability is in our configuration of them.
[Corporate IT systems, staging environments, acquired brands not yet integrated].
Physical locations, staff and social engineering of any kind.

4.2 Non-qualifying findings

Reports from automated scanners without a demonstrated impact.
Missing security headers, cookie flags or best-practice settings without a working exploit path.
Clickjacking on pages with no sensitive state-changing action.
Self-XSS and issues requiring physical access to an unlocked device.
Denial of service through volume, and rate-limiting observations without security impact.
Disclosure of software version numbers or banners alone.
Vulnerabilities in outdated browsers or operating systems no longer supported by their vendor.
Leaked credentials found in public sources: report these under the VDP so we can revoke them. [Decide whether to reward these; many programmes pay a fixed amount.]

5. Safe harbour

If you make a good-faith effort to comply with this brief while researching, we consider your research authorised. We will not pursue or support legal action against you for that research, including under anti-hacking or anti-circumvention laws, and we will not ask law enforcement to investigate you. If a third party brings legal action against you for activities conducted under this brief, we will make it known that your actions were authorised.

Good faith means accessing systems only to find and demonstrate a vulnerability, avoiding harm to people, data and service, and using findings to improve security. Extortion, demanding payment outside this programme, or holding data to ransom is not good faith and voids this protection.

Internal note: the US Department of Justice policy announced on 19 May 2022 says good-faith security research should not be charged under the Computer Fraud and Abuse Act and defines good faith in similar terms. Safe harbour from [Organisation] does not bind other parties or other jurisdictions; have counsel review this section.

6. Rules of engagement

Accounts: use only accounts you create or test accounts we provide at [URL]. Add [your handle] to the account name or a custom header, such as X-Bug-Bounty: [handle].
Data: access only the minimum data needed to demonstrate impact. If you reach personal data, credentials or other users' data, stop, do not copy it, and report immediately. Delete any data you hold once the report is resolved.
Rate limits: no more than [10] requests per second against any asset. Do not run tests that degrade service.
Prohibited: denial of service, spam, social engineering, physical testing, persistence, malware, destructive actions, pivoting into internal networks beyond the minimum needed to show impact, and testing of other customers' tenants.
Credentials and tokens: if you find an API key, token or secret, report it and do not use it beyond confirming it is valid in the least intrusive way.
AI features: prompt injection, jailbreaks and data leakage are in scope only where they show a security impact such as access to another user's data, unauthorised tool actions or disclosure of secrets. Model output quality, bias or harmful content without a security impact does not qualify. See the AI Bug Bounty Programmes Guide.
Stop on request: stop testing any asset immediately if we ask you to.

7. How to report

Submit reports through [platform URL or [email protected], PGP key at URL]. One vulnerability per report, unless several issues are chained to show impact. Include:

The affected asset, endpoint and parameter.
The vulnerability type and your severity estimate with a CVSS v4.0 vector.
Clear reproduction steps and any proof of concept needed to confirm the issue.
The impact you demonstrated and the data or functions reachable.
Your test account identifiers and the dates and times of testing.

8. Rewards

Rewards depend on severity, the asset tier and the quality of the report. We assess severity using CVSS v4.0, adjusted for real business impact, and its qualitative ratings: Low 0.1 to 3.9, Medium 4.0 to 6.9, High 7.0 to 8.9, Critical 9.0 to 10.0.

Severity	Tier 1	Tier 2	Tier 3
Critical	[amount]	[amount]	[amount]
High	[amount]	[amount]	[amount]
Medium	[amount]	[amount]	[amount]
Low	[amount or recognition only]	[amount or recognition only]	[recognition only]

Duplicates: only the first valid report of an issue is rewarded. Reports of the same root cause on several endpoints count as one.
Bonuses: [we may pay a bonus for exceptional reports, clear chains or a suggested fix].
Payment: paid within [30] days of the report being triaged as valid, not when it is fixed. Taxes are your responsibility.
Decisions: reward and severity decisions are made by [Organisation]'s triage team. You may request a review once, with reasons, within [14] days.
Recognition: with your consent we will list you on our acknowledgements page at [URL].

Internal note: set amounts from your budget and from what similar programmes in your sector publish. Paying on triage rather than on fix builds trust. Ring-fence the annual budget so the programme does not pause mid-year.

9. Response commitments

Stage	Our target
First response (acknowledgement)	[1 to 3] business days
Triage decision (valid, duplicate, informative, not applicable)	[5 to 10] business days
Reward decision and payment	[within 30 days of triage]
Remediation target	Critical [14 days], High [30 days], Medium [90 days], Low [best effort]
Status updates	At least every [14] days until resolved

Internal note: CISA BOD 20-01 recommends acknowledging VDP reports within 3 business days and resolving within 90 days; those are good outer bounds for a bounty. Missed response targets are the main reason researchers leave a programme.

10. Confidentiality and disclosure

Do not share details of a vulnerability with anyone other than [Organisation] until it is fixed and we have agreed disclosure.
We aim to agree public disclosure within [90] days of the report or [30] days after the fix, whichever is sooner. If we need longer, we will explain why.
We will credit you in any advisory we publish, unless you ask us not to, and request a CVE where the issue affects software our customers run.

11. Changes and contact

We may change this brief at any time; the version and date at the top show the current terms. Questions about the programme go to [[email protected]]. This brief does not create an employment or contractor relationship.

Implementation guidance

Prepare triage capacity first: name a triage owner, a backup and engineering contacts for every Tier 1 asset. Run the first reports through your normal vulnerability handling process; see the PSIRT Guide.
Clear the obvious: run your own scans and a penetration test on in-scope assets before launch, so the first weeks are not spent paying for known issues.
Private pilot: invite [20 to 50] researchers for [60 to 90] days with a reduced scope, measure volume and response times, then adjust rewards and exclusions.
Brief internal teams: tell the SOC, fraud and site reliability teams how to recognise researcher traffic (header, account naming) so they do not block or escalate it unnecessarily.
Go public in stages: widen scope tier by tier. Pause or narrow scope (not rewards) if triage falls behind, and say so in the brief.
Close the loop: feed root causes into secure development training and fix classes of bugs, not just instances.

Measures that show it is working

Median time to first response and to triage decision against the published targets.
Valid report rate (signal to noise) and share of duplicates.
Median time to remediate by severity, against section 9.
Critical and high findings per quarter, and repeat findings of the same class.
Researcher retention: share of rewarded researchers who submit again.

Framework mapping

Framework	Reference	How the brief supports it
NIST SP 800-53 Rev. 5	RA-5(11) Public Disclosure Program	Provides a public reporting channel for vulnerabilities in organisational systems
NIST SP 800-53 Rev. 5	CA-8 Penetration Testing	Complements scheduled testing with continuous external testing
NIST CSF 2.0	ID.RA-08	Processes for receiving, analysing and responding to vulnerability disclosures are established
NIST CSF 2.0	ID.RA-01, ID.IM-02	Vulnerabilities identified and recorded; improvements identified from security tests

Standards and references

Related NHI Mgmt Group resources: Bug Bounty and Vulnerability Disclosure Guide · Vulnerability Disclosure Policy Template · Bug Bounty and VDP Platform Buyers Guide · CVSS v4 Guide · Vulnerability Disclosure Maturity Model. This template is not legal advice.

Bug Bounty Programme Brief Template: Scope, Rules, Rewards and Response Commitments