Vulnerability Disclosure Policy: A Guide for Indian Companies

A Vulnerability Disclosure Policy (VDP) is a public document that tells security researchers how to report a flaw in your systems safely and legally — what's in scope, how to submit a report, what response to expect, and a promise that good-faith researchers won't face legal action for finding the bug. Unlike a bug bounty program, a VDP needs no payout budget, no dedicated triage team, and no vendor platform — just a clear channel and a documented process. Every Indian company with an internet-facing product, from a five-person startup to a listed bank, should have one, because researchers are already finding your bugs whether you've built a channel for them or not.

The real question isn't whether someone will find a vulnerability in your systems — it's whether they'll have a safe, obvious way to tell you, or whether they'll post it publicly, sell it, or walk away. This guide covers what a VDP contains, why it matters with zero security budget, safe harbor language, intake and triage process, response SLAs, coordinated disclosure timelines, and how a VDP differs from a bug bounty program.

What a Vulnerability Disclosure Policy Actually Is

A VDP is a set of rules of engagement, published where a researcher can find it — usually at /.well-known/security.txt, a dedicated /security page, or both. At minimum, a usable VDP states:

1. Scope — which domains, apps, and systems are covered, and which are excluded
2. How to report — a dedicated address or form, and what to include (reproduction steps, affected URL, impact)
3. Rules of engagement — what testing is authorized (no data destruction, no social engineering staff, no service-degrading scans)
4. Safe harbor — a commitment not to pursue legal action against good-faith researchers
5. Response expectations — how quickly the company will acknowledge, triage, and (if applicable) fix and disclose

Why Every Company Needs One — Even Without a Bug Bounty Budget

The most common objection is "we're too small to need this" or "we can't afford to pay bounties." Both miss the point. A VDP isn't a payment program — it's a reception channel. Without one, a researcher who finds a live vulnerability in your product has three options: report it to an unofficial inbox that may take weeks to reach anyone technical, go public immediately, or say nothing. None of those beat a dedicated, monitored channel that routes straight to someone who can act.

The OWASP Vulnerability Disclosure Cheat Sheet frames this plainly: organizations with no provision for receiving reports don't stop vulnerabilities from being found — they just lose control of what happens after. The US government made VDPs mandatory for federal civilian agencies under CISA's Coordinated Vulnerability Disclosure process, precisely because a documented intake channel reduces vulnerabilities surfacing via public disclosure or exploitation instead of private reporting.

For Indian companies, this matters in two additional ways: CERT-In's incident reporting framework expects organizations to have internal processes for handling reported vulnerabilities, and enterprise customers — especially in BFSI and government-adjacent sectors — increasingly ask vendors directly, in security questionnaires, whether a disclosure policy exists.

Safe Harbor Language for Researchers

Safe harbor is the clause that determines whether a good-faith researcher trusts your policy enough to use it. Without it, researchers assume reporting a bug could expose them to a cease-and-desist letter, a police complaint under India's IT Act, or a lawsuit — even when their intent was entirely defensive. A weak or missing safe harbor clause is the single biggest reason researchers skip a company's official channel and go public instead.

Effective safe harbor language commits to three things:

1. No legal action against researchers who discover and report a vulnerability in good faith, within scope, without exfiltrating or destroying data.
2. Authorization — an explicit statement that testing within the defined scope is authorized, which matters because unauthorized-access provisions in Indian law (Sections 43 and 66, IT Act 2000) are otherwise broad enough to read as covering routine security testing.
3. No retaliation — a commitment not to publicly call out or blacklist a researcher who followed the rules, even for a low-severity or duplicate finding.

Intake Process: How Reports Should Come In

The intake process is the operational backbone of the policy — a well-written safe harbor clause doesn't matter if reports land in an inbox nobody checks. A workable intake setup for a lean Indian company looks like this:

Triage and Response SLAs

Once a report lands, the clock matters as much as the content. Researchers judge a VDP's credibility by how fast and transparently a company responds, not by how quickly the bug gets fixed. A reasonable SLA structure for a small-to-mid-size Indian company looks like:

1. Acknowledgment: within 1–3 business days, confirming the report was received.
2. Initial triage decision: within 5–10 business days — valid, duplicate, or out of scope.
3. Severity assignment: via a consistent framework such as CVSS, so critical and high-severity reports get escalated ahead of lower-severity ones.
4. Status updates: at minimum every 2–4 weeks while a report is being worked — silence is what pushes researchers toward public disclosure.

Coordinated Disclosure Timelines

Coordinated disclosure (sometimes still called "responsible disclosure") is the practice of withholding public details of a vulnerability until a fix is available, on an agreed timeline between researcher and vendor. As noted above, the default industry convention is a 90-day window from initial report to public disclosure — long enough to build, test, and ship a fix for most application-layer issues, short enough that vendors can't sit on a known flaw indefinitely.

A working coordinated disclosure clause should specify: the default disclosure window (typically 90 days; actively-exploited critical issues may warrant faster action), conditions for extension (a good-faith request showing active remediation progress, agreed in advance), what happens if the deadline passes without a fix (the researcher retains the right to publish, ideally with advance notice), and credit for the researcher in the eventual advisory, often the primary motivation for reporting through a VDP rather than selling the finding.

The FIRST.org Vulnerability Coordination SIG publishes multi-party coordination guidance for cases involving several affected vendors or shared open-source components — relevant for Indian SaaS companies built on common frameworks where a single flaw can affect many downstream products.

How a VDP Differs From a Bug Bounty Program

VDPs and bug bounty programs are often confused, but they solve different problems and suit different stages of maturity.

Getting Started

Publishing a VDP is a process change, not an engineering project. Start with a dedicated security@ alias and a security.txt file, write safe harbor language that genuinely protects good-faith researchers, commit to realistic SLAs you can actually meet, and default coordinated disclosure to a 90-day window. None of this needs a large security team — just one committed owner and a clear, published process.

A VDP tells you about vulnerabilities researchers find by accident or curiosity; it doesn't systematically look for the ones nobody has stumbled on yet. Bachao.AI, built by Dhisattva AI Pvt Ltd, runs automated VAPT scans that proactively surface exploitable flaws across web applications, APIs, and infrastructure before an external researcher — or an attacker — finds them, with reporting delivered, where relevant, with a CERT-In empanelled partner. For a current picture of your externally-facing systems before publishing a disclosure policy, a free VAPT scan is a fast way to start, and teams building toward India's data protection obligations should review DPDP compliance alongside it. More guides like this are on the Bachao.AI blog.