How do you run a bug bounty programme for your Indian startup?
Key takeaways
- The scope must name exact domains, APIs and mobile applications, and state that everything else is out of scope by default, in one document you can link from a policy page.
- A 72-hour response time on valid reports is the practical rule that keeps researchers engaged; slower response is the most common reason a programme is abandoned.
- Publish the severity-to-bounty matrix before launch, as a table with 4 severity rows, because a bounty negotiated per report becomes a negotiation with every report.
- A safe harbour referencing sections 43 and 66 of the IT Act, 2000 is what gives a researcher a legal basis to test your systems.
- Budget for a first-year programme in the region of Rs 3,00,000 to Rs 15,00,000, with a single critical finding capable of consuming a year's budget.
As of 24 October 2026: the service descriptions, prices and turnaround figures on this page are current.
What does the scope document have to contain?
Six parts. The in-scope list, naming exact domains, API base paths, mobile application packages and any staging or trial environment you want tested. The out-of-scope list, which should be explicit and should cover third-party and hosted services, since a researcher who tests a cloud provider's infrastructure on your behalf has not found a bug in your product. The authentication approach, describing how a researcher obtains test accounts, or explicitly stating that no accounts are provided and unauthenticated testing is the whole point. The permitted techniques list and the prohibited techniques list, with denial of service, social engineering of your staff, and physical attacks named explicitly. The data handling rules, covering what a researcher must do when they encounter personal data, which under the DPDP Act, 2023 is a real obligation on you to specify. And the disclosure policy, stating how long you have to fix before public disclosure, usually 90 days.
How do you set bounty amounts that make sense in India?
Publish a matrix rather than a negotiation. A workable structure: low severity, such as a missing security header or a low-information leak, at 5% of the base; medium, such as an open redirect or an IDOR that exposes non-sensitive records, at 15% of the base; high, such as authentication bypass or access to another tenant's data, at 30% of the base; and critical, such as remote code execution, a full database dump or an account takeover of a customer, at 100% of the base. Set the base so that critical lands in a defensible band. For an Indian startup, a critical finding in the Rs 25,000 to Rs 2,50,000 range is normal, and you should budget for one or two of them a year rather than assuming zero. If the base is too high to be credible, the programme reads as performative and nobody bothers.
What does the triage operation look like day to day?
A named owner, weekly, with a service level attached. A report arrives, you acknowledge it within 24 hours, you reproduce it within 48 hours, and you give the reporter a substantive reply within 72 hours even if the verdict is pending. Severity is decided against the published matrix, not against what is convenient, and a disagreement is explained rather than ignored. A retest or a fix confirmation is sent, and the closure is recorded. Where a report involves live customer data, the first action is to contain, and CERT-In's 6-hour reporting requirement applies if the finding is a live incident rather than a research report. Budget one to two days a week for this once the programme is running, because triage is the workload that quietly kills programmes.
What should the first 90 days look like?
Days 1 to 15: write the scope, the safe harbour and the matrix, and get them reviewed by whoever owns the data and the product. Days 16 to 30: publish the policy page, open the private reporting channel, and test the flow end to end with two friendly researchers, one of whom finds something you already knew about, so you learn what a bad report looks like before the public does. Days 31 to 60: announce the programme, monitor reports, close everything inside the 72-hour rule, and fix in priority order. Days 61 to 90: review the numbers, which is the number of valid reports, the number of triaged within 72 hours, the average time to fix, and the total paid out. If the 72-hour compliance rate is below 90%, fix your process before you add more scope, because a programme that is slow on response is a programme that is being abandoned quietly.
| Severity | Example finding | Bounty |
|---|---|---|
| Critical | Remote code execution, full database access, account takeover | Rs 2,50,000 |
| High | Authentication bypass, cross-tenant data access | Rs 75,000 |
| Medium | IDOR on non-sensitive records, stored XSS in an admin view | Rs 37,500 |
| Low | Verbose errors, missing headers, minor information leaks | Rs 12,500 |
| Informational | Best-practice observations with no demonstrated impact | No bounty, acknowledged in the report |
What are the frequently asked questions?
Get a straight answer on this
Send us your domains, your API endpoints and your mobile application package names, and we will return a draft scope, a bounty matrix and a safe harbour clause.
Send us the details See pricing