The first 90 days of running a bug bounty program

The first three months of a bug bounty program decide whether it becomes a useful security control or a quiet embarrassment. Programs that go silent in year two almost always have their root cause in the first 90 days: scope was wrong, response cadence slipped, the first hunter wave wasn't retained, and the team that started the program quietly stopped paying attention.

This is a guide for the first 90 days, written from the side that sees what programs look like at month four when something starts breaking. It assumes you've already decided to run a program and you've picked a model (self-hosted, on a platform, public, private). If you haven't, read our VDP vs bug bounty post first.

Days 1–30: setup

The first month is foundational work. Reports will not be coming in at meaningful volume yet. Use the time to build the operational system you'll lean on for the next year.

Week 1: write the scope and policy

Most programs treat this as a one-day task. It's not. Scope and policy decisions made hastily in week one cost you for the entire life of the program. Block out three to five days, in writing, for:

• Asset list (specific hostnames, bundle IDs, repos, IP ranges).
• Out-of-scope list (both assets and finding types).
• Safe-harbor language (start from disclose.io).
• Testing rules of engagement.
• Response SLA you can actually hit.
• Payout structure (or explicit "no payout" statement).

Our post on scope writing has a checklist.

Week 2: set up intake

Where do reports land? Three options, in order of preference:

1. A dedicated security@yourcompany.com inbox that routes to a ticketing system. This is the standard.
2. A submission form on /security that opens tickets directly. Good for filtering low-quality submissions.
3. A platform inbox (HackerOne, Bugcrowd, etc.). If you're going this route, the platform's onboarding handles most of this section.

If you're using your own ticketing system, configure auto-acknowledgement. Hunters expect a confirmation within minutes of submission. A silent inbox is the fastest way to lose your first wave.

Week 3: name a triager

Triage requires single ownership. "The security team" is not an owner. Name a specific person, document the escalation path when that person is on leave, and put their name on the public scope page if appropriate. If you don't have someone in-house who can absorb the work, this is the point at which you outsource to a service like ours, or set aside time on someone's calendar specifically for triage.

Week 4: soft launch

Publish the scope page. Add the /.well-known/security.txt file (it's RFC 9116, takes ten minutes, and security crawlers look for it). Don't announce yet. Let the first reports arrive organically and use them to debug your intake and response process.

By day 30 you should have:

• A live scope page and security.txt.
• A working intake with auto-acknowledgement.
• A named triager and a documented process.
• Maybe two to ten reports, mostly low-impact, used to dry-run the process.

Days 30–60: stabilization

Month two is when patterns emerge and the volume picks up. The work shifts from setup to operation.

Volume rises and quality varies

Reports start coming in faster, often after you've been listed in hunter-discovery directories or after a researcher has shared your program in their network. Expect a wide quality range. Some hunters will send detailed reproductions; others will dump scanner output and ask for a payout.

This is the point at which severity discipline starts to matter. Every report needs a written severity justification, even if it's short. Without that, you'll find yourself in escalating disputes by month three because the precedent is "we paid X for similar."

Adjust scope based on reality

Patterns from the first month will tell you which exclusions you need to add. Common additions in month two:

• A specific scanner-output exclusion (often securityheaders.com or ssllabs.com results).
• Self-XSS exclusion (consistently submitted, consistently invalid).
• A path exclusion for any internal admin panel that's accidentally reachable but not in scope.

Update the scope page, bump the "Last updated" date, and notify existing hunters of substantive changes. Don't quietly tighten the rules without telling people.

First payouts

If you're paying, the first payouts go out in month two. Three things matter:

1. Pay fast. Median time-to-pay above 30 days kills hunter retention. Aim for two weeks from validation to payment.
2. Pay the documented amount. Hunters compare notes. If you pay $X for a high-severity bug, the next high-severity bug from a different hunter should pay $X minus or plus documented modifiers, not whatever feels right that day.
3. Send a clear closeout. Even a short note ("Paid $X. Thanks for the report. Bug is fixed in build N.") matters more than the amount.

Our post on payout amounts covers the math in detail.

Hunter retention starts here

The hunters who report twice in your first 60 days are the ones who will report again in months six and twelve. The ones who report once and never come back have decided you're not worth their Saturday. Those decisions are made on response speed, payout fairness, and whether the scope was clear, in roughly that order.

By day 60 you should have:

• 20–80 reports total, depending on program size and visibility.
• A revised scope page reflecting real submission patterns.
• First payouts sent, with median time-to-pay under 14 days.
• A list of three to five hunters who have submitted twice and are clearly engaged.

Days 60–90: tuning

Month three is when the program gets real. The fire-hose has slowed (or hasn't, in which case you have a different problem), patterns are stable, and you can start optimizing.

Severity calibration

Pull the last 60 days of reports. Plot severity distribution. If 70% of valid reports are coming in as criticals or highs, you have severity inflation. Tighten your scoring, document why, and apply it consistently going forward.

If 70% are coming in as low or informational, you have a scope or visibility problem. Either the wrong hunters are finding you (too much scanner-driven submission) or your scope is too narrow.

Triage automation

By month three, certain patterns are repeatable. Common automations:

• A dedup index keyed by URL and bug class. Most duplicate reports cluster around three to five known issues you haven't fixed yet.
• A scanner-output filter (a small ML classifier or just a regex list) that flags submissions that look like raw scanner dumps.
• A scope-check pass that auto-tags reports against in-scope or out-of-scope assets.

None of this replaces a human triager. It just gets the human to the interesting work faster.

Trends review

Sit down for an hour with three numbers:

• Median time-to-acknowledge, time-to-validate, time-to-pay.
• Severity distribution.
• Hunter mix (top-five hunters by submission count and by total payout).

These three numbers will tell you whether the program is healthy. Median time-to-acknowledge over 24 hours is a problem. Severity distribution skewed toward critical is a problem. A hunter mix where one researcher is 80% of valid reports is a problem (single point of failure for your program quality).

By day 90 you should have:

• 50–250 reports total.
• A severity distribution that matches your engineering reality.
• Two to three repeat hunters whose work you trust.
• Median acknowledgement under 12 hours, median validation under 24 hours.
• A scope page that's been revised at least once based on real submissions.

What kills programs in the first 90 days

Three patterns. Each one is recoverable, but only if you catch it fast.

Slow first response

If you don't acknowledge within a few hours and respond substantively within a few days, the first wave of hunters quietly moves on. They'll show up to your competitor's program instead. You can't earn that wave back; you can only hope a different one arrives later.

The fix is operational: smaller queue or more triage capacity. There is no third option.

Severity inflation by default

Some teams accept whatever severity the hunter assigns, because disputing severity is uncomfortable. Three months in, every borderline report is being pushed toward critical because the precedent says you accept inflated submissions. Walking that back takes years.

The fix is strict severity discipline from week one, including written justifications on every score and willingness to disagree with hunters when the math doesn't add up.

Scope drift

The scope page hasn't been updated in 90 days. Two new products launched. A subdomain takeover happened on a domain that was never in scope but is being submitted weekly. Hunters are confused about what's in and what's out, and the team has stopped writing back to them with explanations.

The fix is a scope-review cadence, written into someone's recurring calendar.

Metrics to track from day 1

Set up these metrics before you launch. They take five minutes each, and they'll tell you whether the program is healthy.

• Reports per week, total and by severity.
• Median time to: acknowledge, validate, score, hand off, pay.
• Share of reports that are dupes or out-of-scope.
• Top hunters by submission count and by payout total.
• Time from fix-deploy to retest.

A spreadsheet is fine for the first 90 days. After that, move it into your tracker if you can.

Where we fit

We onboard programs in the first 30 days routinely. Scope writing, intake setup, triage process, severity calibration. By day 90 we're running the queue, you're getting weekly summaries, and your AppSec team has its mornings back.

If you're starting a program and want a second pair of eyes from day one, book an intro call. If you're already three months in and something feels off, that's also us.