-c.png)
The Complete Guide to Bug Bounty Programs in India
- Ridhi Sharma
- 1 day ago
- 18 min read
For: CISOs, CIOs, Security Managers, Security Researchers
More than 70% of Indian organisations experienced a significant cyber incident in 2024 yet the majority still rely on annual penetration tests as their primary external security check. A penetration test gives you a snapshot. A bug bounty program gives you a live feed.
India's digital economy has expanded faster than its security posture. As Indian companies process more financial transactions, health records, and personal data than ever before, the gap between what automated tools catch and what skilled human researchers find has never been wider. Bug bounty programs exist to close that gap by turning the world's best ethical hackers into a continuous extension of your security team.
This guide covers everything a security leader or researcher needs to know: what bug bounty programs are, how they differ from other security testing approaches, the Indian regulatory context, how to launch and run one, how rewards work, and how to choose the right platform. It is written for practitioners, not vendors which means you will find honest comparisons, practical checklists, and real numbers alongside the strategic context.
Note
This guide is maintained by Com Olho, India's dedicated bug bounty platform. Where we reference our own platform, we say so clearly. The rest is independent guidance.
What this guide covers
1. What is a bug bounty program?
A bug bounty program is a structured security initiative in which an organisation invites ethical hackers also called security researchers to find and responsibly report vulnerabilities in its digital systems, in exchange for a financial reward.
The term 'bug bounty' has been used since the 1990s, but the model has matured significantly over the past decade. Today, leading organisations from global banks and healthcare providers to government agencies use bug bounty programs as a core component of their security strategy, not as an afterthought.
How it works in practice
The organisation defines a scope: the specific applications, APIs, domains, or infrastructure that researchers are permitted to test. Researchers either invited privately or from a public pool probe those assets for security weaknesses. When they find something, they submit a structured report. The organisation triages the report, confirms the vulnerability, and pays the researcher a reward based on the severity and impact of the finding.
The entire process is governed by a program policy that protects both parties: researchers get clear authorisation to test (protecting them legally), and the organisation gets responsible, coordinated disclosure (protecting them from public embarrassment).
Key terms you need to know
Term | Definition |
Bug bounty | A financial reward paid to a security researcher for finding and responsibly disclosing a valid vulnerability. |
Vulnerability | A weakness in a system, application, or process that could be exploited to cause harm, access unauthorised data, or disrupt services. |
Scope | The defined set of assets (URLs, apps, APIs, IPs) that researchers are permitted to test within a program. |
Triage | The process of reviewing, validating, and prioritising vulnerability reports submitted by researchers. |
Safe harbour | Legal protection granted to researchers who follow the program's rules, ensuring they cannot be prosecuted for authorised testing. |
CVSS score | Common Vulnerability Scoring System — a standardised 0–10 scale used to rate the severity of a vulnerability. |
Disclosure | The act of reporting a vulnerability, either privately to the affected organisation (responsible disclosure) or publicly. |
CVE | Common Vulnerabilities and Exposures — a public catalogue of known security vulnerabilities, each assigned a unique identifier. |
Researcher / hunter | A security professional who participates in bug bounty programs, also called an ethical hacker or white-hat hacker. |
VDP | Vulnerability Disclosure Program a structured, rewarded channel for coordinated vulnerability reporting with defined disclosure timelines. |
2. The Indian cybersecurity landscape in 2025
India is simultaneously one of the fastest-growing digital economies and one of the most actively targeted by cyber adversaries. Understanding this context is essential before designing a security program.
The threat picture
India ranked among the top five most-targeted countries globally for cyberattacks in 2024. Financial services, healthcare, and e-commerce are the most affected sectors — precisely the industries that have undergone the most rapid digital transformation in the past five years.
The attacks are not abstract. In recent years, high-profile Indian organisations have suffered breaches exposing hundreds of millions of records. The consequences have included regulatory action, customer trust erosion, and in some cases, direct financial loss running into hundreds of crores.
Why this matters for bug bounty
The majority of successful breaches exploit vulnerabilities that skilled researchers would have found — and disclosed privately — had a structured program been in place. Bug bounty programs are not just a security tool; they are a business risk management tool.
The regulatory environment
India's cybersecurity regulatory landscape has shifted materially in the past three years. Two frameworks are particularly relevant to organisations considering a bug bounty program:
CERT-In Directions (April 2022)
The Indian Computer Emergency Response Team issued mandatory directions requiring organisations in critical sectors to report security incidents within six hours of detection. These directions apply to service providers, intermediaries, data centres, and government organisations. Running a structured vulnerability disclosure or bug bounty program directly supports compliance: it creates a formal channel for reporting security weaknesses and a documented response process.
Digital Personal Data Protection Act (DPDP Act, 2023)
The DPDP Act places explicit obligations on data fiduciaries to implement reasonable security safeguards to protect personal data. The Act does not prescribe specific technical controls, but a bug bounty program with its emphasis on proactive vulnerability identification — is widely considered a reasonable safeguard in line with the Act's intent. Organisations that experience a breach and can demonstrate they ran active security testing programmes are in a demonstrably stronger position.
RBI and SEBI cybersecurity frameworks
The Reserve Bank of India's cybersecurity framework for banks and payment system operators, and SEBI's cybersecurity guidelines for market intermediaries, both require organisations to conduct regular security assessments. Bug bounty programs are increasingly cited by compliance teams as evidence of an active, ongoing assessment program especially when paired with traditional pen testing.
Pro tip
If you are preparing a security program for a CERT-In audit or RBI cybersecurity review, document your bug bounty program its scope, triage process, and remediation timelines — as part of your evidence pack. A managed platform like Com Olho automatically generates the audit trail you need.
3. Bug bounty vs penetration testing vs VDP — which is right for you?
Security leaders are frequently asked to choose between these three approaches. The honest answer is that they are not mutually exclusive — most mature security programs use all three. But if you are starting out, understanding the differences is essential.
Bug Bounty Program | Penetration Test | VDP (Coordinated disclosure) | |
Testing model | Continuous, crowdsourced | Time-boxed, contracted team | Ongoing, open submission |
Researchers | Community of ethical hackers | 1–5 contracted specialists | Community, self-selected |
Cost model | Pay per valid vulnerability | Fixed project fee | Pay per valid vulnerability |
Coverage | Broad, diverse attack surfaces | Deep, defined scope | Broad with coordinated disclosure |
Speed of findings | Ongoing, 24/7 | Within project window | Unpredictable |
Legal clarity | Platform-managed policy | Statement of work | Policy-only |
Best for | Continuous assurance | Compliance, deep dives | Structured disclosure focus |
India platforms | Com Olho, HackerOne | Multiple vendors | Com Olho |
When to choose a bug bounty program
A bug bounty program is the right choice when you want continuous, real-world testing by a diverse group of researchers, are prepared to pay for results rather than effort, have an internal team (or platform support) to triage incoming reports, and have already done the foundational work of understanding your attack surface.
When a penetration test is the right call
Penetration testing is better suited to situations where you need a deep, methodical review of a specific system before launch, need a formal report for compliance or audit purposes, or are testing an environment where broad public researcher access would be inappropriate. Most organisations combine both: a penetration test before a major product launch, followed by a continuous bug bounty program for ongoing coverage.
The VDP as a structured starting point
A Vulnerability Disclosure Program is a structured, policy-governed channel for researchers to report vulnerabilities with defined timelines and coordinated disclosure commitments — and on the Com Olho platform, VDPs include researcher rewards. The distinction from a full bug bounty programme is primarily structural: a VDP typically has a more defined disclosure timeline and a stronger emphasis on coordinated public disclosure after remediation. It is a sensible starting format for organisations that want more control over the disclosure process while still incentivising quality research.
4. Is your organisation ready to run a bug bounty program?
Readiness is the most underrated factor in bug bounty program success. Organisations that launch without the right foundations tend to be overwhelmed by low-quality reports, fail to remediate findings quickly enough, and lose researcher trust — sometimes permanently. Answer these questions honestly before you proceed.
The readiness checklist
✓ Asset inventory
Do you have a clear map of all internet-facing assets — domains, subdomains, APIs, mobile apps, cloud infrastructure? You cannot write a scope if you do not know what you have. Run a subdomain enumeration and asset discovery exercise before you write your first scope line.
✓ Triage capacity
Do you have at least one security engineer who can dedicate 4–8 hours per week to reviewing and validating incoming vulnerability reports? A program that goes silent where researchers submit findings and hear nothing for weeks damages your reputation in the researcher community and defeats the purpose of running the program.
✓ Remediation pipeline
Do you have a defined process for how a validated vulnerability moves from 'confirmed' to 'fixed'? This means agreement with your engineering team on SLAs for different severity levels. A critical vulnerability that sits unpatched for three months is worse than not having found it at all.
✓ Legal sign-off
Has your legal team reviewed and approved the program policy and safe harbour language? This protects both you and the researchers. On a managed platform like Com Olho, standard policy templates are provided but your legal team should still review them for your specific context.
✓ Budget allocation
Have you allocated a rewards budget? This does not need to be large to start a private program with a small scope and a ₹50,000–₹2,00,000 initial budget is a reasonable starting point. The key is that the budget exists and is approved before you invite the first researcher.
✓ Scope definition
Can you define a clear, bounded scope specific URLs, apps, or APIs that excludes anything you are not ready to have tested? A tight, well-defined scope produces better reports than a vague, open-ended one.
Watch out
Do not launch a public program before you have triage capacity in place. The worst outcome is not a zero-day — it is a valid critical vulnerability that sits in your inbox for six weeks because no one is assigned to review reports. This is both a security risk and a reputational one with the researcher community.
5. Types of bug bounty programs
There is no single model for a bug bounty program. The right structure depends on your security maturity, risk appetite, and the sensitivity of your assets.
Public program
A public program is open to any researcher on the platform. Anyone can sign up, review your scope, and start testing. Public programs maximise coverage — the larger the researcher pool, the more diverse the testing approach. They are best suited for organisations with mature triage teams, well-defined scopes, and established remediation processes.
Best for: Large enterprises, established tech companies, fintech platforms with high traffic and broad attack surfaces.
Typical reward range: ₹5,000 for low-severity to ₹2,00,000+ for critical findings.
Private / invite-only program
A private program restricts access to a curated set of invited researchers. The organisation — or the platform on its behalf — selects researchers based on their track record, skills, and the programme's focus areas. This is the most common starting point for organisations new to bug bounty, because it limits volume while maintaining quality.
Best for: Companies launching their first program, organisations in regulated sectors, those with limited triage bandwidth.
Typical reward range: ₹10,000 to ₹1,50,000, depending on severity and asset sensitivity.
Vulnerability Disclosure Program (VDP)
A VDP is a structured security program with a defined disclosure policy and coordinated timeline researchers report vulnerabilities, the organisation commits to specific acknowledgement and remediation SLAs, and findings may be disclosed publicly after a defined period. On the Com Olho platform, VDPs include researcher rewards. The VDP model is well-suited for organisations that want strong control over the public disclosure of findings while maintaining researcher incentives.
Best for: Organisations that want structured disclosure control, government agencies, those aligning with ISO 29147.
Rewards: Included — structured with defined acknowledgement, triage, and remediation SLAs.
Coordinated Vulnerability Disclosure (CVD)
A CVD program is a more structured form of VDP, often with a defined disclosure timeline for example, the organisation commits to acknowledging reports within 5 days, triaging within 10 days, and remediating critical findings within 30 days. At the end of the timeline, the researcher may disclose the finding publicly whether or not it has been fixed. This model is common in government and critical infrastructure sectors.
Best for: Government agencies, critical infrastructure operators, organisations aligning with international security standards.
Program type | Who can test | Rewards | Researcher volume | Best starting point? |
Public | Anyone on platform | Yes | High | No — for mature programs |
Private | Invited researchers | Yes | Low–Med | Yes — recommended first step |
VDP | Open submission | Yes | Variable | Yes — for structured disclosure focus |
CVD | Open submission | Yes | Variable | For govt / critical infra |
6. How to launch a bug bounty program: a step-by-step guide
Launching a successful bug bounty program requires preparation, clear communication, and a commitment to treating researchers as partners rather than adversaries. This six-step process reflects what works in practice — based on how Indian enterprises have successfully launched programmes on the Com Olho platform.
1
Define your scope
Your scope document is the most important thing you will write before launch. It must clearly specify which assets are in scope (testable), which are explicitly out of scope (do not touch), and what types of testing are permitted. Be specific: list exact domains, subdomains, app bundle IDs, and API base URLs. Vague scopes attract low-quality reports. A well-written scope also protects you legally — it defines the boundaries of the authorisation you are granting to researchers.
2
Write your program policy
Your policy sets the rules of engagement. It should cover: the safe harbour grant (what researchers are legally permitted to do), the responsible disclosure expectation, prohibited test types (denial-of-service, social engineering, physical attacks), and your disclosure timeline commitment. On a managed platform, policy templates are provided — but always have your legal team review the final document.
3
Choose your platform and researcher pool
A managed bug bounty platform handles researcher vetting, report submission, triage support, escrow payments, and legal infrastructure. For Indian organisations, a platform with an established Indian researcher community will produce more relevant findings than a global platform with no India focus. For your first program, start private: invite 10–20 vetted researchers rather than opening to thousands.
4
Set your reward structure
Rewards should be calibrated to severity and the sensitivity of the affected asset. A critical vulnerability in your payment processing API is worth significantly more than the same finding in a low-traffic marketing microsite. Define your reward table before launch — researchers read it carefully when deciding whether your program is worth their time.
5
Triage and communicate with researchers
When a report comes in, acknowledge it within 24 hours — even if triage takes longer. Researchers form opinions about your program based on responsiveness. A program that goes silent destroys trust and your reputation in the researcher community. Assign severity ratings using CVSS scores, validate findings in a staging environment, and communicate your remediation timeline clearly.
6
Remediate, reward, and iterate
Pay rewards promptly once a finding is validated — do not wait until a patch is deployed. Delayed payments are a common complaint from Indian researchers and directly reduce the quality of your future researcher pool. Once you have completed your first program cycle, review what you learned and refine scope, reward ranges, and researcher selection before your next cycle.
Pro tip
Before you launch, run a tabletop exercise with your security and engineering teams: "A critical IDOR vulnerability has been submitted that would allow any user to access any other user's financial records. What happens in the next 72 hours?" If you cannot answer that question confidently, your triage process needs work before you go live.
7. Reward structures and what researchers earn in India
Setting the right reward levels is part art, part market analysis. Pay too little and top researchers ignore your program. Pay too much across the board and your budget evaporates on low-severity findings. The goal is a structure that attracts skilled researchers, rewards impact fairly, and remains sustainable.
How severity is classified
Most programs use the CVSS (Common Vulnerability Scoring System) scale combined with a qualitative impact assessment. The standard severity bands are Critical (9.0–10.0), High (7.0–8.9), Medium (4.0–6.9), and Low (0.1–3.9). The reward you pay should reflect both the CVSS score and the real-world impact of the vulnerability.
Severity | Example vulnerability types | Typical reward range (India) |
Critical | Auth bypass, RCE, account takeover, payment manipulation, mass data exposure | ₹75,000 – ₹2,50,000+ |
High | IDOR with data access, stored XSS on critical path, privilege escalation, PII exposure | ₹25,000 – ₹75,000 |
Medium | Reflected XSS, CSRF on sensitive actions, information disclosure, broken access control | ₹8,000 – ₹25,000 |
Low | Minor information disclosure, best-practice deviations, self-XSS, open redirect | ₹2,000 – ₹8,000 |
Industry benchmarks
Industry | Typical critical reward | Typical high reward | Notes |
BFSI (Banking, Financial Services, Insurance) | ₹1,00,000 – ₹2,50,000 | ₹30,000 – ₹75,000 | Highest rewards; payment system findings command premium |
Fintech / Payments | ₹75,000 – ₹2,00,000 | ₹25,000 – ₹60,000 | API security and transaction integrity are top focus |
Healthcare / Healthtech | ₹50,000 – ₹1,50,000 | ₹20,000 – ₹50,000 | PII and health record exposure findings are prioritised |
E-commerce | ₹50,000 – ₹1,00,000 | ₹15,000 – ₹40,000 | Account takeover and payment bypass are most common |
SaaS / Enterprise Tech | ₹30,000 – ₹1,00,000 | ₹15,000 – ₹35,000 | Varies significantly by customer data sensitivity |
Government / PSU | ₹10,000 – ₹50,000 | ₹5,000 – ₹20,000 | Emerging segment; reward levels growing as CERT-In compliance drives adoption |
What researchers actually earn
India has a growing community of full-time and part-time bug bounty researchers. A skilled researcher operating across multiple programs can realistically earn ₹3,00,000 to ₹12,00,000 per year from bug bounty activity alone. Elite researchers — those consistently finding critical vulnerabilities in high-reward programs — can earn significantly more. The Com Olho researcher community includes individuals from across India, with strong representation from Bengaluru, Hyderabad, Pune, Delhi NCR, and Kerala.
8. Legal and compliance considerations in India
Legal clarity is the foundation of a trustworthy bug bounty program. Without it, researchers operate in a legal grey zone, and your organisation is exposed to the risk of a well-intentioned researcher being threatened with prosecution. A properly structured program eliminates this ambiguity.
The safe harbour principle
A safe harbour clause in your program policy is a formal statement that your organisation authorises the researcher to perform security testing within the defined scope, and will not pursue civil or criminal action against a researcher who follows the program rules. This is the single most important legal element of any bug bounty program.
The Information Technology Act, 2000
Section 43 of the IT Act covers unauthorised access to computer systems and imposes civil liability for damage caused. Section 66 creates criminal liability for computer-related offences. Without a formal authorisation framework, security researchers testing your systems — even with good intentions — could fall within the scope of these provisions. A well-drafted program policy, with clear safe harbour language, creates the authorisation that transforms an act that could be illegal into one that is expressly permitted.
Note
Your program policy is not just a document for researchers to read. It is a legal instrument. Have it reviewed by counsel familiar with the IT Act before you publish it. Com Olho's platform includes policy templates designed with this framework in mind, but organisational specifics always require independent legal review.
CERT-In coordination and mandatory reporting
Under the CERT-In Directions of 2022, organisations in covered sectors must report cybersecurity incidents within six hours of becoming aware of them. This has direct implications for how you handle vulnerability reports from researchers. Define clearly: at what severity level does a researcher report constitute a 'cybersecurity incident' requiring CERT-In notification? Your triage process should include this determination step.
Data protection and the DPDP Act
Researchers testing your systems may, in the course of valid security research, encounter personal data. Your program policy should explicitly prohibit researchers from accessing, downloading, or retaining personal data beyond what is necessary to demonstrate the vulnerability. It should also require immediate notification to your security team if personal data is encountered during testing.
Intellectual property and confidentiality
Require researchers to keep program details confidential until you have had the opportunity to remediate findings. Your policy should specify a disclosure timeline typically 90 days from report acknowledgement after which the researcher may disclose findings publicly if they choose. This follows the Google Project Zero standard and is increasingly considered best practice globally.
Pro tip
If your organisation operates in banking, insurance, or capital markets, check sector-specific guidance from RBI, IRDAI, or SEBI on cybersecurity assessments. Some RBI circulars specifically reference the need for 'continuous security testing' — language that directly supports the case for a bug bounty program in your next cybersecurity audit.
9. How to choose a bug bounty platform
The platform you choose shapes everything: the quality of your researcher pool, the efficiency of your triage process, and the experience researchers have when they engage with your program. A bad platform choice costs you time, money, and researcher goodwill.
What to evaluate
Evaluation criterion | What to look for | Why it matters |
Researcher community | India-based researchers with domain expertise in your industry | A researcher who understands Indian payment flows or BFSI infrastructure will find more relevant vulnerabilities |
Triage support | Does the platform provide managed triage, or do you own it entirely? | For teams with limited security bandwidth, managed triage transforms the program from a burden into a service |
Escrow payment system | Are researcher rewards held in escrow and paid in INR? | INR payments avoid FX friction for Indian researchers; escrow ensures payment only on valid findings |
Policy and legal templates | Are program policy templates provided and India-compliant? | Reduces legal setup time and ensures safe harbour language is appropriate for the Indian regulatory context |
Reporting and dashboards | Can you export vulnerability data for audit and compliance reporting? | CERT-In and RBI audits may require documentation of your security testing activities |
Researcher reputation system | Are researchers vetted and rated? | Prevents low-quality submissions and ensures your program attracts serious researchers |
Program support | Is there a customer success team that knows your industry? | Especially important for first-time programs where setup guidance is valuable |
Global platforms vs India-first platforms
Global platforms like HackerOne and Bugcrowd have large researcher pools and strong brand recognition, primarily in US and European markets. For Indian organisations, however, they present some structural challenges: reward tables are typically USD-denominated, support teams operate in different time zones, and their researcher communities are less concentrated in individuals with deep knowledge of Indian regulatory environments, local app architectures, and Indian-specific attack vectors.
India-first platforms like Com Olho are built for the specific context of Indian organisations: INR-denominated rewards, Indian researcher communities, CERT-In awareness, and support teams in Indian time zones. For most Indian enterprises — particularly those in BFSI, healthtech, and e-commerce — this context specificity translates directly into higher-quality, more actionable findings.
10. Frequently asked questions
What is the difference between a bug bounty program and a penetration test?
A penetration test is a time-boxed engagement with a small contracted team typically 1–5 specialists working against a defined scope for a fixed fee. A bug bounty program is continuous, crowdsourced, and pay-per-finding: you pay only when a valid vulnerability is confirmed. Penetration tests are better for compliance documentation and deep methodical reviews; bug bounty programmes are better for continuous coverage across a broad attack surface. Most mature security programmes use both.
Is it legal to run a bug bounty program in India?
Yes, provided the program is properly structured with a clear safe harbour policy that explicitly authorises researcher testing within a defined scope. Under the Information Technology Act 2000, unauthorised access to computer systems carries civil and criminal liability but a properly drafted programme policy creates the authorisation that makes security testing legal. Com Olho's platform includes legal templates designed for the Indian regulatory context, and we recommend all organisations have their programme policy reviewed by legal counsel before launch.
How much does it cost to run a bug bounty program in India?
The cost depends on your reward structure and researcher volume. For a private program on Com Olho with a well-defined scope, organisations typically allocate ₹50,000 to ₹5,00,000 per year in researcher rewards, depending on the sensitivity of the assets and the programme's scope. Unlike a penetration test, you pay only for valid findings so the cost scales with the quality of findings, not a fixed project fee.
What types of vulnerabilities do bug bounty programs typically find?
The most common vulnerability categories found in Indian bug bounty programs include: Insecure Direct Object References (IDOR) allowing unauthorised access to other users' data, authentication bypass, Cross-Site Scripting (XSS), API misconfigurations, broken access control, SQL injection, and sensitive data exposure. In Indian fintech and banking programs, payment flow vulnerabilities and transaction integrity issues are particularly common.
How long does it take to launch a bug bounty program?
With a managed platform, a private program can be launched in 2–4 weeks from the decision to proceed. The timeline typically breaks down as: scope definition (3–5 days), policy review and approval (5–10 days depending on legal team availability), platform setup and researcher invitations (2–3 days), and a soft launch period with a small researcher cohort before broader rollout.
Do I need a large organisation to run a bug bounty program?
No. Private and invite-only programs are well-suited to organisations of any size, including growth-stage startups. The key requirement is not organisational size but security maturity: you need a defined attack surface, a clear scope, someone to manage triage, and a budget for rewards. Some of the most effective bug bounty programs on Com Olho are run by companies with fewer than 100 employees.
Which industries in India use bug bounty programs most actively?
Financial services (banking, insurance, payments) are the most active users of bug bounty programs in India, driven by RBI and CERT-In compliance requirements. Fintech, e-commerce, and healthtech follow closely. Government agencies and public sector undertakings are an emerging segment the CERT-In directions have accelerated adoption in this sector.
What happens if a researcher finds a critical vulnerability?
When a researcher submits a critical finding, your triage team should acknowledge it within 24 hours and validate it in an isolated environment within 48–72 hours. If confirmed, escalate immediately to your engineering team with a defined remediation SLA typically 24–72 hours for critical vulnerabilities. Determine whether the finding constitutes a reportable incident under CERT-In Directions. Pay the researcher's reward promptly upon validation, regardless of whether the patch has been deployed.
Ready to launch India's next bug bounty program?
Com Olho is India's dedicated bug bounty and vulnerability disclosure platform built specifically for Indian organisations, with an Indian researcher community, INR rewards, and support teams who understand the Indian regulatory landscape.
For security teams: Schedule a free consultation and we will help you define your scope, set your reward table, and launch your first private program, typically within two weeks.
For researchers: Join the Com Olho researcher community and access bug bounty programs across India's leading enterprises.
Comments