Setting bug bounty payout amounts (without overpaying or insulting hunters)

The dollar amount on a bug bounty payout is doing more work than most teams realize. It tells hunters what you think your security is worth. It tells them whether you take their time seriously. It sets the expectation for every future submission they'll send you.

Get the number wrong in either direction and there's a real cost. Underpay, and your best hunters move on quietly, you'll never see the P1s they would have found. Overpay, and you flood your queue with inflated reports from people chasing the number, and your operational overhead balloons before your AppSec team is ready.

This post is what we'd say to a security team setting their first payout table, written from the side that has filed more than a thousand reports across more than a hundred programs.

The two failure modes

The first failure mode is underpaying. Symptoms: low report volume, mostly informational submissions, no engagement from named hunters, unrealistic complaints about scope. The bug bounty is doing nothing that a VDP wouldn't do, except it's also confusing because there's a payout column on the policy page.

The second failure mode is overpaying. Symptoms: high volume, reports that argue aggressively for severity inflation, repeat submissions of the same dispute by the same hunter, opportunists pushing borderline issues into "critical" territory because the critical row says $50,000. Your triage queue triples in size and the quality goes down.

Both failure modes are recoverable. The first by raising amounts and quietly inviting the people you want back. The second by tightening the policy, getting strict on severity, and, sometimes, dropping the maximum amount. The second is harder to recover from because you've already paid out at the inflated rate, and the hunters who benefited won't be quiet about a downgrade.

Industry-typical ranges

These are rough, current as of 2026, for technology companies (SaaS, fintech, e-commerce). Hardware, finance, and regulated industries trend higher; consumer mobile apps trend lower.

| Severity | Smaller mid-market | Established mid-market | Enterprise / sensitive | |---|---|---|---| | Critical | $1,000 – $5,000 | $5,000 – $20,000 | $20,000 – $100,000+ | | High | $500 – $2,000 | $1,500 – $7,500 | $7,500 – $25,000 | | Medium | $150 – $750 | $500 – $2,000 | $1,500 – $5,000 | | Low | $50 – $250 | $100 – $500 | $250 – $1,000 |

Three things to notice about that table:

1. The ratios are stable across columns. A typical critical is roughly 4x a typical high, 12–15x a typical medium, 30–50x a typical low. If your table doesn't follow that pattern, you're probably compressing or stretching one tier in a way hunters will notice.
2. There's no "right" column. It depends on what you're protecting. A retail SaaS with no PII pays toward the left. A healthcare platform with HIPAA exposure pays toward the right. Pretending you have less to protect than you do is a common, expensive mistake.
3. The table is the start, not the answer. Modifiers, covered below, adjust each payout up or down based on the specific bug.

For a deeper dive into severity itself, our post on what 'critical' actually means is the version of the talk we'd give before this conversation.

Modifiers that should move a bounty up

Things that justify paying more than the table baseline:

Report quality. A well-written report, clean repro, clear impact statement, suggested fix direction, evidence that's complete, saves the triage team hours and tells you the hunter understood the bug deeply. A 10–20% premium for excellent reports is reasonable. It also selects for the hunters you want.

Novelty. A bug class you haven't seen before, an exploit chain that took real cleverness to find, a finding in a part of your product that's been pen-tested before, pay above baseline for surprise. The marginal information value of a novel bug is much higher than a routine one, and you want hunters spending time on the hard stuff.

Asset criticality. A medium-CVSS bug on a payment endpoint can pay more than a high-CVSS bug on a marketing subdomain. Your business-context severity should drive the bounty number, not just the CVSS score. Some programs publish per-asset multipliers; others just adjust per-bug.

Hunter relationship and reputation. Top-tier hunters bring more than the bug. They bring a track record of validity, low-noise submissions, and the willingness to work with you on borderline cases. Paying them above baseline once or twice a year is cheap relative to what they save you in queue overhead.

Modifiers that should move a bounty down

Things that justify paying less than the table baseline:

Borderline severity. If a bug technically meets a tier but only in an edge case (specific user role, specific time of day, specific browser), pay at the bottom of that tier. Don't promote it to the top half because the hunter argued well.

Inflated initial pitch. If the report opened with "I found a critical RCE" and reproduction shows a medium-severity SSRF, pay medium, and quietly note the pattern. Some hunters consistently inflate; over time, you'll learn whose severity arguments to trust.

Asset is non-production or sandboxed. A bug in your build sandbox or your demo environment is not the same as a bug in production. Pay accordingly. Many programs explicitly carve these out as "informational only" with no payout, that's also fine if the policy is clear up front.

Bug class is one you've solicited testing on. If you ran a public statement that you wanted XSS testing this quarter and asked for repro evidence, pay at baseline, not above. The hunter is responding to a request, not surprising you.

Common mistakes

A short tour of the wrong patterns:

Tying payouts to a percentage of revenue or some abstract formula. A real example we've seen: "We'll pay 0.001% of annual revenue per critical." This is silly. Hunters don't care about your revenue, they care about whether the payout is competitive with what other programs of your shape are paying.

Paying exactly the CVSS-to-dollar ratio. A 9.8 isn't $9,800. CVSS is a base score; the bounty needs to reflect business context. Some programs publish a "CVSS only, no exceptions" table because they want predictability, that's defensible, but it leaves money on the table for the bugs that matter most.

Paying differently for the same bug submitted by different hunters. This kills hunter trust faster than almost anything else. If two hunters report the same bug within 48 hours, they should both get paid the same amount (the dedup policy decides who, but if you pay both, pay equally). Top hunters compare notes, you'll be found out.

Negotiating downward on a report you've already accepted. If you've validated the bug and applied a severity, don't haggle. Pay the table amount minus any pre-agreed modifiers. Trying to talk hunters down after the fact is the surest way to make them never return.

Not publishing a payout table at all. "Contact us for bounty amounts" is a yellow flag for serious hunters. They want to know upfront what kind of program this is. Vague payout language attracts hunters who haven't done the math, and repels the ones who have.

How to set your initial table

A simple ordered approach if you're starting from zero:

1. Pick your column. Smaller mid-market, established mid-market, or enterprise, based on what you're protecting and what you can afford to pay sustainably.
2. Run the ratios. Critical : High : Medium : Low at roughly 4 : 1.5 : 0.4 : 0.15. Round to clean numbers ($10,000 / $2,500 / $1,000 / $250 is a typical mid-market shape).
3. Decide on a maximum. Most programs cap their critical at somewhere between 3x and 5x the baseline critical, reserved for exceptional findings. Without a cap, you'll be in a negotiation on every submission someone wants to call "critical+".
4. Write your modifiers down. Even if you don't publish them, document internally what raises and lowers a bounty. Without this, every hunter conversation re-derives the math from scratch and you end up paying differently for similar bugs.
5. Pre-fund the first six months. You'll pay more than you expect in month one. Approve the budget before you launch, not after the first invoice.

When to revise

Six-month checkpoint: look at three things.

• Median time-to-pay. If it's over 30 days, your operational process is the bottleneck, not your amounts. Fix that before changing payouts.
• Hunter retention. Are the hunters who reported month one still reporting in month six? If yes, your amounts are roughly right. If no, they're probably too low, or your triage is too slow.
• Severity distribution. If 70% of valid reports are coming in as criticals, you have a severity-inflation problem, not a payout-amount problem. Tighten your scoring before you cut payouts.

A bounty program is a market. The clearing price changes over time, typically upward, as the program becomes known and hunters expect parity with competitors. A program that hasn't revisited its payouts in two years is almost certainly underpaying.

Where we fit

We don't set your payout amounts. That's a strategic decision your security leadership needs to own. But we do recommend bounty amounts on every report we triage, based on the table you've published, the quality of the report, the modifiers we documented during triage, and our cross-program experience for what bugs of similar shape pay elsewhere.

If you'd like a second pair of eyes on a payout table you're drafting, or on whether your existing one is calibrated correctly, book an intro call. We'll tell you honestly where it's overpaying, where it's underpaying, and what your hunters probably think about both.