Configuring Your Program

Why It Matters

Good configuration is the difference between a credible VDP and a vague policy researchers ignore. Scope clarity protects your engineering team from off-topic reports, SLA targets keep your response times honest, and a well-defined bounty matrix sets researcher expectations before they submit.

Kit provides defaults for many settings, but scope, contact details, ownership, and public policy need a deliberate review before activation.

Enabling VDP

Navigate to VDP to enable your program. The full pipeline is included with every active Kit subscription.

Once your program is created, navigate to VDP > Program Settings to configure it. Your program starts in Draft status and will not accept reports until you set the status to Active.

General Tab

The General tab controls your program identity and disclosure policy.

Field	Description
Program Name	Displayed on your disclosure policy page and researcher portal
Status	Draft, Active, or Paused. Set to Active when configuration is complete
Disclosure Policy	Rich text field pre-populated with safe harbor language. Supports formatting, links, and lists.
Prohibited Actions	Actions researchers must not perform (e.g., social engineering, physical attacks, denial of service)

Keep your program in Draft while you configure the remaining tabs. Switch to Active only when you are ready to accept submissions.

Scope Tab

Scope defines what researchers should and should not test. Vague scope generates vague reports, so be specific.

Field	Description
In-Scope Targets	Hosts, URLs, or IP ranges researchers should test (one per line). Example: app.yourcompany.com, api.yourcompany.com
Out-of-Scope Categories	OWASP-style category exclusions (e.g., “Denial of Service”, “Physical Attacks”)
Excluded Vulnerability Types	Specific vulnerability classes you will not accept (e.g., “Self-XSS”, “Missing rate limiting on non-critical endpoints”)

If you leave in-scope targets empty, all targets are implicitly in scope. This is rarely what you want. At minimum, list your primary application domains.

Scope settings tell researchers which targets and findings are allowed. During triage, check each report against those rules; saving the scope does not automatically reject reports outside it.

Bounty Matrix Tab

Kit subscription: This tab requires an active Kit subscription. Bounties remain optional.

The bounty matrix defines payout ranges for each severity tier. Amounts are displayed on your disclosure policy page so researchers know what to expect.

Severity	Default Min	Default Max
Super Critical	$5,000	$10,000
Critical	$1,500	$5,000
High	$500	$1,500
Medium	$150	$500
Low	$50	$150
Informational	$0	$0

Adjust these ranges to match your budget and risk tolerance. When a CVSS assessment is recorded on a report, Kit shows the suggested bounty range for the matching severity tier.

Bounty Vote Visibility

Below the matrix, the same tab carries a vote visibility setting. It controls whether a bounty proposal’s tally (the running count, who voted which way, and any counter-amounts) is readable before a teammate has cast their own vote.

	What colleagues see before they vote
Blind (default)	The amount, who proposed it and why, plus how many responses are sealed and how many people are still pending. No stances, no names, no counter-amounts.
Live	Everything, from the first vote onwards.

Blind is the default because the first number on screen anchors the ones after it. Pick live only if you want the room to see each other’s positions as they form. Either setting is saved with the rest of the tab and survives later tier edits; you can also change it by asking your connected AI assistant to reconfigure the program (see AI Integration).

SLAs Tab

SLAs define your team’s response time commitments. The SLA clock starts at report submission. Your dashboard shows each report’s status as on-track, at-risk, or breached.

Acknowledgment SLA applies to all severities uniformly: it is the maximum time from submission to first response. Default: 72 hours.

Resolution targets vary by severity:

Severity	Default Resolution Target
Super Critical	24 hours
Critical	72 hours (3 days)
High	168 hours (1 week)
Medium	336 hours (2 weeks)
Low	720 hours (30 days)
Informational	720 hours (30 days)

Override any of these values to match your team’s capacity. Aggressive SLAs look good on paper but lose credibility if you routinely breach them. Set targets you can meet, then tighten them over time.

SLA indicators appear on each report card in the triage board:

• On Track (green): more than 25% of the SLA window remains
• At Risk (yellow): 25% or less of the SLA window remains (75% or more elapsed)
• Breached (red): the SLA deadline has passed

Breach Alerts

A report that misses its acknowledgment SLA pages the team three ways at once: a reply in the report’s Slack thread, a DM or email to whoever is on call, and a PagerDuty incident if you have PagerDuty connected. A breach nobody can clear is news the first time and noise the fifth, so two fields at the bottom of this tab cap how often that alert comes back.

Field	Default	Range	Description
Repeats after a breach	3	0–20	How many times a breached report is paged again after the first alert. Set it to 0 to alert once and never repeat.
Time between breach alerts	6 hours	6–720	How long Kit waits before alerting again about a report that is still unacknowledged.

The first alert always fires; only the repeats are capped. The last alert in the budget says so in Slack, with a last reminder — no further alerts for this report suffix, so the silence that follows reads as a spent budget rather than a broken integration.

Snoozing a report suppresses the breach repeats as well, but never the first alert.

The counter resets when a report leaves the open pipeline (Submitted, Triaged, Needs Clarification, Validated, In Progress), so a report that is later reopened starts a fresh budget. Moving a report from one open status to another does not reset it.

Queue Notice

When reviews fall behind, tell researchers so instead of letting them guess. The Queue notice section lives in VDP > Security Portal Settings, not in Program Settings.

Field	Description
Turn on now / Turn off	Switches the notice on or off. The line next to it says whether researchers see it now.
Message	Plain text, up to 1,000 characters. Leave it blank to use Kit’s default message, which each researcher reads in their own language. Your own text is shown exactly as written.
Expected response time	Optional, for example “2–3 weeks”. Shown under the message; leave it blank to leave it out.
Also message researchers whose report misses your acknowledgment target	Optional automatic email, described below.

While the notice is on, researchers see it on your submission form, the receipt page, the acknowledgment email and every open report in the researcher portal. A preview under the fields shows exactly what they will read.

With the automatic message turned on, Kit emails the notice once, and adds it to the report thread, when a report passes your acknowledgment SLA and nobody on your team has touched it yet: not triaged, assessed or answered. Being assigned, including automatically, does not count as a response. Only reports submitted after you turn the automatic message on are included, so switching it on does not mail your whole backlog. The report timeline records each notice Kit sends.

Turn the notice off once you have caught up. Turning it off also stops the automatic message.

Researcher Update Requests

A researcher who has heard nothing can ask for news from the report page in the researcher portal with Request an update, and add an optional note that only your security team sees.

• The button unlocks once the report passes your acknowledgment SLA without a response, or after 14 days with no activity from your team the researcher can see.
• A researcher can ask once every 7 days per report, and only while the report is open.
• Each request alerts the program’s security admins and posts in the report’s Slack thread. The report shows an Awaiting reply callout until someone replies to the researcher, changes the status, assigns the report or records a new assessment.
• Each request also fires the csirt.report.escalation_requested webhook event if you subscribe to it. The researcher’s note is never included.

Triage Tab

Triage settings control how incoming reports are routed and processed.

Field	Default	Description
Default Assignee	None	Team member who receives new reports automatically. Set this to your primary security contact.
Escalation Severities	Critical, Super Critical	Severity tiers that trigger an escalation alert via email and Slack
Deduplication	Enabled	Flag potential duplicate reports before they reach your board
Require Retest	Off	Require researcher verification that a fix works before resolving
Max Appeals	3	Maximum number of appeals a researcher can file on a dismissed report

On-call rotation settings (mode, schedule, members, and auto-assignment) have their own dedicated page. See On-Call Rotation for details.

If you do not set a default assignee, new reports appear unassigned on the triage board. Your team can still pick them up manually, but assignment ensures nothing is missed.

An escalation posts a line in the report’s Slack thread and, once the report is validated, pages whoever is on call by Slack DM or email. Configure Slack integration under Account Settings > Integrations.

Components Tab

Kit subscription: Components are included and optional. Reports still work without component routing.

Components label reports by product area and let Kit suggest an area for triage to confirm. When a component is confirmed, Kit assigns its default assignee if one is configured and the report is still unassigned. After validation, Kit notifies the component’s Slack channel if one is configured. Create components only when the ownership boundary is real; a decorative catalog adds another field without improving routing.

See Routing Reports to Teams for matching rules, confirmation, default assignment, and Slack routing.

Payouts Tab

Kit subscription: This tab requires an active Kit subscription.

The Payouts tab configures how bounty disbursements are handled.

Field	Default	Description
Supported Payment Methods	PayPal	Select the methods you support: Bank Transfer, PayPal, and Check
Require Tax Documents	Yes	Researchers must upload a W-9 (US) or W-8BEN (international) before receiving payout
Require Agreement	Yes	Researchers must accept your disclosure agreement before payout
Minimum Payout	$50	Minimum amount for an individual disbursement. Kit will not initiate a bounty payout below this threshold
Currency	USD	Currency for all bounty amounts and payouts
Finance Email	Blank	The inbox that schedules payments. When set, initiating a payout emails it a payment request with a secure link where finance confirms the payment, or reports that it failed, without a Kit account. Leave blank to record payments yourself. See Finance Team Confirmation

Tax document requirements exist for your legal compliance. Disabling this setting means researchers can receive payouts without providing tax documentation. Consult your finance team before turning it off.

Spam Tab

Spam settings protect your program from submission flooding and low-quality bulk reports. They measure a burst (reports arriving close together), not a researcher’s total history with you.

Field	Default	Description
Max Reports per Window	5	How many reports one email address or IP can file inside a single window before it is blocked
Window Duration	5 minutes	The window, measured from the report that opened it. A report arriving after it closes opens a fresh one and resets the counter
Block Duration	1 hour	How long an automatic block lasts. Blocks applied by hand from the Spam Records screen always run one week

The defaults are conservative. If legitimate researchers are getting blocked, raise Max Reports per Window or shorten the Window so their reports fall into separate windows. If you are receiving heavy spam, lower the threshold and lengthen the Block Duration.

A blocked submitter sees a non-specific notice. Kit does not tell an abuser which filter caught them. Blocks lift on their own when the Block Duration expires, and the counter resets on the next report after its counting window has ended. You can also see and release any block from VDP > Spam Records.

See Submission Limits and Spam Blocks for the full picture: every gate a submission passes, how to read a spam record, and what to tell a researcher who was refused.

Takedown Tab

The Takedown tab controls whether the program also accepts third-party abuse and brand-impersonation notices. Configure it only if your team owns that response path. A takedown notice has its own intake, evidence, status, and audit trail; it is not a vulnerability report with a different label.

See Takedown Notices before enabling the intake path.

security.txt Tab

This tab configures the fields used to generate your /.well-known/security.txt file per RFC 9116. Kit serves this file automatically when your program is active.

Field	Default	Description
Contact Email	None (required)	The email address researchers use to report vulnerabilities. Published in the Contact: field.
Expiration	365 days	Days from generation until the security.txt expires. RFC 9116 requires an Expires: field.
Policy URL	Auto-generated	URL to your disclosure policy page. Defaults to your Kit-hosted policy.
Acknowledgments URL	None	URL to your Hall of Fame page, if enabled
Hiring URL	None	Link to your security team’s job postings
Encryption URL	None	URL to your PGP public key for encrypted communication

You must set a contact email before your security.txt will be served. For full details on security.txt configuration, formatting, and verification, see security.txt Setup.

Email Tab

The Email tab provisions a security@ handler on a ready inbound-email integration. Kit prefers Startupkit Email when both providers are ready; otherwise it uses an existing ready Cloudflare Email Routing integration. Provisioning registers the handler in Kit; it does not configure the domain. Startupkit Email’s catch-all or Cloudflare’s active worker routes matching mail once the provider setup is working.

A Cloudflare-backed inbox receives mail, but researcher messages still send from Kit’s platform address. Sending from the program address requires Startupkit Email with send-as active.

Removing the identity stops new mail through that address; confirm how researchers will contact the team before removing it. Account branding still controls the logo and colors used in researcher mail. See Communicating with Researchers for message behavior.

Quick Checklist

• Set program name and customize disclosure policy text
• Define in-scope targets and out-of-scope categories
• Configure the bounty matrix or acknowledge that the program offers no bounties
• Set SLA targets per severity tier
• Decide the breach-alert repeat budget: how many times a breached report pages you again, and how far apart
• Decide whether to use the queue notice, and its automatic message, when reviews fall behind
• Assign a default triage owner
• Create component routes only where ownership is clear
• Configure payout methods and tax requirements
• Review spam thresholds: set them above the largest batch of real reports you’d want to receive at once
• Decide whether this program accepts takedown notices
• Set contact email for security.txt
• Provision and test the program email identity
• Configure Slack integration for escalation alerts
• Set status to Active when ready

Next Steps

• security.txt Setup: detailed guide to RFC 9116 compliance and verification
• Triaging Reports: how to use the Kanban board, assess severity, and resolve reports
• Submission Limits and Spam Blocks: every reason a submission can be refused, and how to release someone caught by mistake
• Routing Reports to Teams: component labels, default assignment, and Slack routing
• Takedown Notices: the separate abuse-report workflow