What a responsible disclosure policy actually says
A responsible-disclosure policy tells external security researchers four things: (1) what they're allowed to test (in-scope assets — domains, subdomains, app endpoints, API endpoints); (2) what they're not allowed to test (out-of-scope — third-party processors, social engineering against staff, physical access); (3) how to report a finding (channel — typically a dedicated email like security@yourdomain.com, optionally a form); (4) what happens after — your triage timeline, your safe-harbour commitment (you won't sue good-faith researchers), and your acknowledgement policy (hall of fame, optional payout).
Copy this template to your /security page
## Responsible Disclosure Policy
[Your Company] welcomes security research that helps us protect our users. This policy describes how to report vulnerabilities and what to expect in return.
### Scope
- [your domain] and its subdomains
- Application endpoints (web + mobile)
- Public APIs
### Out of scope
- Third-party processors (vendor systems we depend on)
- Social engineering of our staff or customers
- Physical security testing
- DDoS / volumetric attacks
### How to report
Email security@[your domain] with: (a) a clear description, (b) reproduction steps, (c) suspected severity, (d) any supporting screenshots or video. Encrypt sensitive payloads with our PGP key (linked).
### Our response timeline
- Initial acknowledgement: within 2 business days
- Triage decision (in-scope, severity, accepted/duplicate/out-of-scope): within 5 business days
- Remediation timeline shared with reporter: within 10 business days
- Public hall-of-fame listing (with reporter consent): within 30 days of remediation
### Safe harbour
We will not pursue legal action against good-faith researchers who comply with this policy. Specifically, you may not access user data beyond your own test accounts, must not disrupt service, and must not publicly disclose the finding until we have remediated.
### Recognition
We list researchers in our hall of fame at [/security/hall-of-fame] with consent. For qualifying findings we may pay a discretionary bounty; the per-finding rate is communicated case-by-case.
### Updates
This policy was last updated on [DATE].
Aligning with CERT-In Directions and DPDP Act
CERT-In's April 2022 Directions require Indian organisations to maintain an incident response posture. DPDP Act 2023 requires Data Fiduciaries to take reasonable security safeguards (Schedule I). A published responsible-disclosure policy is documentary evidence of both — auditors accept it as proof you have a vulnerability-handling process. The safe-harbour clause is what makes researchers actually report instead of weaponise findings, which is the operational benefit.
Common mistakes Indian startups make
Mistake 1: copy-pasting a US/EU template without aligning the language to CERT-In + DPDP terminology — your auditor recognises the mismatch. Mistake 2: omitting the safe-harbour clause — researchers default to silent or hostile if not legally protected. Mistake 3: not publishing the page at /security (Google and researchers both look for that path). Mistake 4: never updating the policy — set a reminder for an annual review.
How Bachao.AI helps
If you want help going from template to live policy + a managed bug bounty layer on top, talk to us. We draft the /security page, host the PGP key, run triage on incoming reports, and handle payout administration in INR. See the Bug Bounty Program for Indian Startups page for the full engagement details.