1. Purpose

1.1 This Security Vulnerability Disclosure Policy (“Policy”) establishes the framework under which security researchers, Developers, customers, users, and other authorised persons may report suspected security vulnerabilities affecting StampMitra Services.

1.2 The purpose of this Policy is to encourage responsible security reporting while protecting StampMitra, its Developers, End Users, infrastructure, third-party systems, confidential information, and Underlying Service Providers from unauthorised access or disruption.

1.3 This Policy establishes permitted and prohibited security research activities, reporting expectations, handling procedures, confidentiality requirements, and safe-harbour principles.

1.4 This Policy does not grant permission to access systems, data, accounts, or infrastructure beyond the scope expressly permitted by this Policy.

2. Scope

2.1 This Policy applies to publicly accessible StampMitra security-relevant assets that are operated or controlled by BANI GLOBAL INDUSTRIES LLP and are expressly within the scope of authorised security research.

2.2 Potentially affected assets may include, where applicable:

(a) StampMitra Developer Platform;
(b) publicly documented APIs;
(c) Sandbox interfaces;
(d) authentication interfaces;
(e) Developer Portal functionality;
(f) publicly accessible web applications;
(g) webhook security mechanisms; and
(h) other assets expressly designated by StampMitra.

2.3 Internal systems, confidential infrastructure, third-party systems, government systems, and Underlying Service Provider systems are not automatically within scope.

2.4 The absence of an asset from an expressly stated scope list must not be interpreted as permission to test it.

3. Legal Status

3.1 This Policy establishes limited permission for responsible security research only within the boundaries stated herein.

3.2 Nothing in this Policy creates:

(a) employment;
(b) agency;
(c) partnership;
(d) contractor status;
(e) ownership rights;
(f) access rights beyond the stated scope; or
(g) a general licence to conduct security testing.

4. Definitions

4.1 “Security Researcher” means an individual or organisation conducting security research within the scope of this Policy.

4.2 “Vulnerability” means a weakness that may affect confidentiality, integrity, availability, authentication, authorisation, privacy, or security of an applicable StampMitra system.

4.3 “Security Report” means a communication describing a suspected Vulnerability.

4.4 “Affected System” means a StampMitra system reasonably believed to contain the reported Vulnerability.

4.5 “Proof of Concept” means limited technical evidence demonstrating a suspected Vulnerability.

4.6 “Sensitive Data” means personal, confidential, authentication, financial, security, proprietary, or otherwise protected information.

4.7 “Third-Party System” means a system not operated or controlled by BANI GLOBAL INDUSTRIES LLP.

4.8 “Safe Harbour” means the limited protection described in this Policy for good-faith research conducted within its requirements.

5. Responsible Disclosure

5.1 StampMitra encourages responsible disclosure of genuine security vulnerabilities.

5.2 Researchers should report vulnerabilities privately rather than publicly disclosing exploitable details before StampMitra has had a reasonable opportunity to investigate.

5.3 Researchers should provide sufficient information to reproduce or assess the issue without causing unnecessary harm.

6. Authorised Research

6.1 Security research is authorised only when:

(a) performed against an in-scope StampMitra asset;
(b) conducted in good faith;
(c) conducted without unnecessary disruption;
(d) limited to the minimum activity reasonably required;
(e) no prohibited activity is performed; and
(f) the Researcher complies with this Policy.

7. No General Penetration Testing Permission

7.1 This Policy does not constitute blanket permission to conduct penetration testing against Production infrastructure.

7.2 Load testing, stress testing, denial-of-service testing, destructive testing, or other intrusive testing requires separate written authorisation unless expressly included within an applicable published scope.

8. Sandbox Preference

8.1 Researchers should use Sandbox environments whenever the Vulnerability can reasonably be demonstrated there.

8.2 Production testing should be avoided where a Sandbox demonstration is sufficient.

9. Production Testing

9.1 Limited Production testing may be permitted only where reasonably necessary to establish a security issue and where such testing can be performed without material risk.

9.2 Researchers must stop testing immediately if continued activity could:

(a) access another person's data;
(b) affect service availability;
(c) modify or delete data;
(d) affect Transactions;
(e) affect third-party systems;
(f) create financial consequences; or
(g) create material security risk.

10. Minimum Necessary Testing

10.1 Researchers must use the least intrusive method reasonably capable of demonstrating the Vulnerability.

10.2 Researchers must not continue testing after sufficient evidence has been obtained.

11. No Destructive Testing

11.1 Researchers must not intentionally:

(a) delete production data;
(b) corrupt data;
(c) alter Documents;
(d) alter e-Stamp information;
(e) create unauthorised signatures;
(f) modify financial records;
(g) disrupt services;
(h) destroy logs; or
(i) otherwise cause destructive effects.

12. No Denial-of-Service Testing

12.1 The following are prohibited without explicit written authorisation:

(a) denial-of-service testing;
(b) distributed denial-of-service testing;
(c) traffic flooding;
(d) resource exhaustion;
(e) connection exhaustion;
(f) deliberate rate-limit exhaustion; or
(g) sustained load generation.

13. No Excessive Automation

13.1 Automated scanning must be configured conservatively.

13.2 Researchers must avoid high-volume scanning that could materially affect service availability or infrastructure.

14. Rate Limits

14.1 Researchers must respect published rate limits and security controls.

14.2 Attempts to bypass rate limits are prohibited unless expressly authorised for a specific test.

15. No Credential Attacks

15.1 Researchers must not conduct:

(a) credential stuffing;
(b) password spraying;
(c) brute-force attacks;
(d) OTP brute forcing;
(e) authentication flooding; or
(f) credential harvesting.

16. Test Accounts

16.1 Researchers should use accounts they own or are expressly authorised to test.

16.2 Researchers must not use another person's account without explicit authorisation.

17. Account Takeover

17.1 Demonstrating account-takeover risk must be performed using the Researcher's own account or an expressly authorised test account wherever reasonably possible.

17.2 Researchers must not take control of another person's account.

18. No Access to Third-Party Data

18.1 Researchers must not intentionally access, copy, download, disclose, modify, or retain personal or confidential information belonging to another person.

18.2 If unintended access occurs, the Researcher must immediately stop and report the issue.

19. Minimum Data Access

19.1 If a Vulnerability unexpectedly exposes data, the Researcher must:

(a) stop further access;
(b) avoid copying unnecessary information;
(c) avoid downloading bulk data;
(d) avoid disclosure; and
(e) report the exposure promptly.

20. Data Minimisation

20.1 Researchers should collect only the minimum evidence required to demonstrate the Vulnerability.

21. Personal Data

21.1 Researchers must not intentionally access or retain personal data unless strictly necessary to establish the Vulnerability.

21.2 Personal data obtained accidentally must be treated as confidential and securely deleted when no longer necessary for reporting.

22. Sensitive Data

22.1 Researchers must not intentionally access:

(a) identity documents;
(b) authentication secrets;
(c) financial credentials;
(d) private Documents;
(e) e-Sign credentials;
(f) e-Stamp information;
(g) private API keys;
(h) private customer records; or
(i) other Sensitive Data.

23. API Keys

23.1 Researchers must not obtain, disclose, sell, publish, or misuse API credentials belonging to other users.

23.2 Accidentally discovered credentials must be reported privately and must not be used beyond the minimum necessary to establish the issue.

24. Webhook Secrets

24.1 Researchers must not attempt to obtain webhook secrets belonging to other Developers.

24.2 Any accidental exposure must be reported immediately.

25. Authentication Bypass

25.1 Researchers may report authentication-bypass vulnerabilities.

25.2 Demonstration must be limited to the minimum evidence necessary.

25.3 Researchers must not use an authentication bypass to access unrelated accounts or data.

26. Authorisation Bypass

26.1 Researchers may report access-control vulnerabilities.

26.2 Testing must use only controlled test resources wherever reasonably possible.

27. IDOR / Access Control Testing

27.1 Where testing access-control issues requires changing an identifier, Researchers should use resources belonging to their own test accounts.

27.2 Researchers must not enumerate or access real customer resources.

28. Session Security

28.1 Researchers may report session-management vulnerabilities.

28.2 Researchers must not hijack another user's active session.

29. OTP Security

29.1 Researchers must not perform OTP flooding, OTP interception, OTP guessing, or abuse of telecommunications systems.

29.2 OTP vulnerabilities should be demonstrated through controlled test accounts wherever possible.

30. Password Reset Testing

30.1 Password-reset vulnerabilities may be reported.

30.2 Researchers must not reset credentials belonging to another user.

31. Account Recovery

31.1 Account-recovery vulnerabilities may be reported using controlled accounts.

31.2 Researchers must not use recovery mechanisms to obtain unauthorised access to another person's account.

32. Web Application Testing

32.1 Researchers may test common web application security weaknesses within scope.

32.2 Testing must remain non-destructive and proportionate.

33. API Security Testing

33.1 Researchers may test documented APIs for security weaknesses where the API is expressly in scope.

33.2 Researchers must comply with rate limits, authentication requirements, and this Policy.

34. Input Validation

34.1 Researchers may test input validation using controlled payloads.

34.2 Payloads must not intentionally cause destructive system behaviour.

35. Injection Testing

35.1 Injection vulnerabilities may be reported.

35.2 Researchers must stop after sufficient evidence is obtained and must not extract unrelated data.

36. File Upload Testing

36.1 Researchers may test file-upload security using harmless test files.

36.2 Malware, destructive payloads, or files intended to damage systems are prohibited.

37. SSRF Testing

37.1 Server-side request forgery vulnerabilities may be reported.

37.2 Researchers must not use SSRF to access internal services, credentials, metadata, or systems beyond the minimum necessary proof.

38. Command Execution

38.1 Remote-code or command-execution vulnerabilities may be reported.

38.2 Researchers must not execute destructive commands or access unrelated data.

39. Code Execution Limit

39.1 Where a Vulnerability permits code execution, the Researcher should use a harmless command demonstrating controlled execution.

39.2 The Researcher must not establish persistence.

40. Persistence

40.1 Researchers must not establish backdoors, persistence mechanisms, scheduled tasks, hidden accounts, or unauthorised access paths.

41. Privilege Escalation

41.1 Privilege-escalation vulnerabilities may be reported.

41.2 Researchers must not use escalated privileges to access unrelated data or systems.

42. Cloud Infrastructure

42.1 Cloud infrastructure may contain security boundaries that must not be crossed.

42.2 Researchers must not attempt to access cloud accounts, storage, databases, credentials, service accounts, or infrastructure that is not expressly within scope.

43. Internal Networks

43.1 Internal network scanning is prohibited unless expressly authorised.

43.2 Researchers must not pivot from a vulnerable application into unrelated internal systems.

44. Administrative Interfaces

44.1 Administrative interfaces are not automatically in scope.

44.2 Researchers must not attempt unauthorised access to administrative systems.

45. Database Access

45.1 Database vulnerabilities may be reported.

45.2 Researchers must not dump, copy, alter, or delete production databases.

46. Log Access

46.1 Researchers must not intentionally access internal logs containing personal, credential, or confidential information unless specifically authorised.

47. Source Code

47.1 Source-code repositories that are not intentionally public are confidential.

47.2 Researchers must not attempt to obtain private source code through unauthorised means.

48. Repository Security

48.1 Public repository issues may be reported where they expose credentials, security-sensitive information, or vulnerabilities.

48.2 Researchers must not clone or publish private repositories obtained through unauthorised access.

49. Secret Disclosure

49.1 Accidentally exposed secrets should be reported privately.

49.2 Researchers must not publicly publish discovered secrets.

50. DNS and Domain Security

50.1 Domain-related vulnerabilities may be reported where the affected domain is within scope.

50.2 Researchers must not attempt unauthorised domain takeover or destructive DNS changes.

51. Certificate Security

51.1 Certificate and TLS vulnerabilities may be reported.

51.2 Researchers must not impersonate StampMitra or create fraudulent certificates.

52. Email Security

52.1 Email security issues may be reported.

52.2 Researchers must not conduct phishing campaigns against StampMitra personnel or customers.

53. Social Engineering

53.1 Social engineering of StampMitra employees, contractors, Developers, customers, or support personnel is prohibited unless separately authorised in writing.

54. Phishing

54.1 Researchers must not conduct phishing, credential harvesting, impersonation, or fraudulent communications as part of ordinary vulnerability research.

55. Telecommunication Systems

55.1 Researchers must not test OTP, SMS, WhatsApp, voice, or other telecommunications infrastructure using abusive or high-volume techniques.

56. Payment Systems

56.1 Payment security vulnerabilities may be reported.

56.2 Researchers must not conduct unauthorised financial transactions, chargebacks, payment manipulation, or financial fraud.

57. e-Stamp Systems

57.1 Researchers must not attempt to create fraudulent e-Stamp instruments, alter issued instruments, manipulate statutory amounts, or interfere with external authority systems.

58. e-Sign Systems

58.1 Researchers must not create unauthorised signatures, impersonate Signers, manipulate signature records, or interfere with external signing systems.

59. Verification Systems

59.1 Researchers must not conduct bulk identity enumeration, identity harvesting, or unauthorised verification of third parties.

60. Government Systems

60.1 Government systems, regulatory systems, statutory databases, and public authority infrastructure are not automatically within scope.

60.2 Researchers must not test or attack such systems through StampMitra without explicit written authorisation.

61. Third-Party Systems

61.1 Third-party systems are outside scope unless expressly included.

61.2 A vulnerability in a third-party system should be reported to the relevant party where appropriate.

62. Underlying Service Providers

62.1 Underlying Service Providers and their infrastructure are not automatically within scope.

62.2 Researchers must not attempt to identify, access, test, attack, or interfere with confidential upstream systems.

63. Provider Discovery

63.1 Researchers must not attempt to reverse engineer StampMitra routing to identify confidential commercial service providers.

64. External API Testing

64.1 Developers and Researchers must not use StampMitra access as a means to conduct unauthorised security testing of an external service.

65. No Cross-System Pivoting

65.1 A vulnerability in one system must not be used to access unrelated systems.

66. No Data Exfiltration

66.1 Researchers must not intentionally exfiltrate data.

66.2 A minimal proof demonstrating access is generally sufficient.

67. No Data Deletion

67.1 Researchers must not delete, corrupt, modify, encrypt, or otherwise damage data.

68. No Ransomware

68.1 Ransomware, extortionware, destructive encryption, or similar activity is strictly prohibited.

69. No Mining

69.1 Researchers must not deploy cryptocurrency mining, resource-intensive workloads, or other unauthorised persistent computation.

70. No Malware

70.1 Researchers must not deploy malware, trojans, worms, ransomware, destructive scripts, or malicious persistence mechanisms.

71. No Backdoors

71.1 Researchers must not create or retain backdoors.

72. No Data Harvesting

72.1 Researchers must not harvest personal information, Documents, verification data, API credentials, or other user information.

73. No Customer Enumeration

73.1 Researchers must not enumerate customer identifiers, accounts, phone numbers, email addresses, Documents, or other personal information.

74. No Account Enumeration

74.1 Bulk enumeration of user accounts or identifiers is prohibited.

75. No Spam

75.1 Researchers must not generate unsolicited email, SMS, WhatsApp, webhook, or other communications through StampMitra Services.

76. No Abuse of Notifications

76.1 Researchers must not intentionally trigger excessive notifications to users or administrators.

77. Rate-Limit Bypass

77.1 Circumventing rate limits through multiple accounts, IP addresses, credentials, proxies, distributed clients, or other mechanisms is prohibited unless expressly authorised.

78. WAF or Security-Control Bypass

78.1 Researchers must not intentionally bypass security controls beyond the minimum evidence necessary to demonstrate a vulnerability.

79. Security Control Testing

79.1 Where bypassing a control is necessary to establish a vulnerability, testing must stop immediately after sufficient proof is obtained.

80. No Persistence

80.1 Researchers must not retain access after demonstrating the vulnerability.

81. Cleanup

81.1 Researchers must remove test accounts, files, payloads, tokens, or other artefacts created during authorised testing where reasonably possible.

82. Test Data

82.1 Researchers should use synthetic or personally controlled test data wherever possible.

83. Test Accounts

83.1 Researchers should clearly distinguish security test accounts from ordinary customer accounts.

84. Proof of Concept

84.1 Proofs of concept should be:

(a) minimal;
(b) reproducible;
(c) non-destructive;
(d) relevant; and
(e) sufficient to demonstrate impact.

85. Proof of Concept Limits

85.1 A Proof of Concept must not become a full exploitation campaign.

86. Automated Scanners

86.1 Automated vulnerability scanners may be used cautiously where permitted.

86.2 Scanners must be configured to avoid excessive traffic and destructive tests.

87. Scanning Windows

87.1 Researchers should avoid periods where testing may create material operational risk.

87.2 StampMitra may request that testing cease temporarily.

88. Stop-Test Request

88.1 If StampMitra requests that a Researcher stop testing, the Researcher should promptly cease activity.

88.2 Continued testing after a legitimate stop request may fall outside the Safe Harbour of this Policy.

89. Emergency Contact

89.1 Researchers who discover an actively exploited or materially dangerous vulnerability should identify the issue as urgent in the Security Report.

90. Reporting Channel

90.1 Security vulnerability reports may be submitted to:

[email protected]

90.2 StampMitra may establish a dedicated security reporting address or portal in the future.

90.3 Where a dedicated security channel is officially published, Researchers should use that channel.

91. Report Subject

91.1 Researchers should clearly identify reports as:

“SECURITY VULNERABILITY REPORT”

where practicable.

92. Report Content

92.1 A useful report should include:

(a) vulnerability title;
(b) affected asset;
(c) affected endpoint or component;
(d) severity assessment;
(e) description;
(f) reproduction steps;
(g) Proof of Concept;
(h) security impact;
(i) prerequisites;
(j) remediation suggestions, if available; and
(k) contact information.

93. Reproduction Steps

93.1 Reproduction instructions should be sufficiently detailed to allow technical investigation.

93.2 Researchers should avoid providing unnecessary exploit automation.

94. Evidence

94.1 Researchers may provide screenshots, logs, request samples, response samples, or other evidence.

94.2 Evidence should be redacted to remove unnecessary personal or confidential information.

95. API Requests

95.1 Request and response examples should have credentials and sensitive values removed.

96. Credential Redaction

96.1 API keys, tokens, cookies, passwords, OTPs, signing credentials, webhook secrets, and similar information must be redacted before submission.

97. Personal Data Redaction

97.1 Personal information that is not necessary to demonstrate the vulnerability should be redacted.

98. Duplicate Reports

98.1 Multiple Researchers may report the same Vulnerability.

98.2 StampMitra may consolidate duplicate reports.

99. Report Prioritisation

99.1 StampMitra may prioritise reports based on:

(a) severity;
(b) exploitability;
(c) affected users;
(d) data exposure;
(e) service impact;
(f) active exploitation;
(g) regulatory significance; and
(h) other relevant factors.

100. Severity

100.1 StampMitra may classify Vulnerabilities as:

(a) Critical;
(b) High;
(c) Medium;
(d) Low; or
(e) Informational.

100.2 Severity classification is determined by StampMitra and does not necessarily correspond to the Researcher's assessment.

101. Impact Assessment

101.1 StampMitra may assess:

(a) confidentiality;
(b) integrity;
(c) availability;
(d) authentication;
(e) authorisation;
(f) privacy;
(g) financial impact; and
(h) regulatory impact.

102. Report Acknowledgement

102.1 StampMitra may acknowledge receipt of a Security Report.

102.2 An acknowledgement does not confirm validity or severity.

103. Investigation

103.1 StampMitra may investigate reported vulnerabilities using internal technical, security, operational, legal, and compliance resources.

104. Reproduction

104.1 StampMitra may reproduce the reported issue in a controlled environment.

104.2 StampMitra may contact the Researcher for clarification.

105. Reporter Cooperation

105.1 Researchers should reasonably cooperate with clarification requests.

105.2 Researchers are not required to provide confidential information unrelated to the Vulnerability.

106. Remediation

106.1 StampMitra may remediate vulnerabilities through:

(a) code changes;
(b) configuration changes;
(c) access-control changes;
(d) credential rotation;
(e) infrastructure changes;
(f) monitoring;
(g) rate controls;
(h) service restriction; or
(i) other appropriate measures.

107. Emergency Remediation

107.1 StampMitra may implement immediate protective controls before a permanent fix is available.

108. Service Restriction

108.1 StampMitra may temporarily restrict affected functionality where necessary to protect users or systems.

109. Disclosure Timing

109.1 Researchers should not publicly disclose a vulnerability while StampMitra is actively investigating or remediating it unless disclosure is legally required or otherwise independently authorised.

110. Coordinated Disclosure

110.1 StampMitra may coordinate disclosure timing with the Researcher where appropriate.

111. Public Disclosure

111.1 Public disclosure should avoid:

(a) active exploit instructions;
(b) credentials;
(c) personal data;
(d) confidential architecture;
(e) provider identities;
(f) sensitive infrastructure details; and
(g) information that materially increases exploitation risk.

112. Confidentiality

112.1 Researchers must keep non-public vulnerability information confidential until disclosure is appropriate.

113. Provider Confidentiality

113.1 Researchers must not disclose confidential information identifying Underlying Service Providers or their internal systems.

114. Customer Confidentiality

114.1 Researchers must not disclose information relating to StampMitra customers or End Users discovered during testing.

115. Security Advisories

115.1 StampMitra may publish a security advisory when appropriate.

115.2 Publication is at StampMitra's discretion, subject to applicable law and security considerations.

116. Researcher Credit

116.1 StampMitra may credit a Researcher for a responsibly disclosed vulnerability where appropriate.

116.2 Credit is not guaranteed.

117. Anonymous Credit

117.1 A Researcher may request that their identity not be publicly disclosed.

118. No Payment Guarantee

118.1 Submission of a vulnerability does not create an automatic entitlement to payment, bounty, compensation, service credits, employment, or other consideration.

119. Bug Bounty

119.1 Unless StampMitra separately publishes a written bug-bounty programme, this Policy does not create a bug-bounty entitlement.

120. Expenses

120.1 StampMitra is not responsible for Researcher expenses unless expressly agreed in writing.

121. Safe Harbour

121.1 To the extent permitted by applicable law, StampMitra will seek not to pursue civil action solely because a Researcher conducted good-faith security research that:

(a) complied with this Policy;
(b) remained within authorised scope;
(c) avoided unnecessary harm;
(d) did not access unnecessary data;
(e) did not conduct prohibited activity; and
(f) was responsibly disclosed.

122. Limitation of Safe Harbour

122.1 Safe Harbour does not apply to:

(a) fraud;
(b) extortion;
(c) threats;
(d) harassment;
(e) intentional destruction;
(f) data theft;
(g) credential theft;
(h) unauthorised financial transactions;
(i) deliberate service disruption;
(j) unlawful access to third-party systems;
(k) malicious persistence;
(l) public disclosure of sensitive information contrary to this Policy; or
(m) other unlawful conduct.

123. Safe Harbour Not Legal Immunity

123.1 This Policy cannot provide immunity from laws, regulations, court orders, or actions by third parties or authorities.

124. Third-Party Rights

124.1 Safe Harbour applies only to actions within StampMitra's authority to permit.

124.2 It does not authorise conduct against third parties, government systems, payment systems, telecommunications systems, or other external infrastructure.

125. No Authority Over Government Systems

125.1 StampMitra cannot authorise security research against systems that StampMitra does not own or control.

126. No Authority Over Underlying Providers

126.1 StampMitra does not grant permission to test confidential Underlying Service Provider infrastructure unless the provider has separately authorised such testing.

127. Third-Party Vulnerabilities

127.1 Where a reported issue appears to originate exclusively from a third-party system, StampMitra may redirect or coordinate the report as appropriate.

128. Responsible Third-Party Reporting

128.1 Researchers should consider reporting third-party vulnerabilities directly to the affected third party when appropriate.

129. No Extortion

129.1 Researchers must not condition disclosure on payment, service restoration, preferential treatment, or another demand.

130. No Threats

130.1 Threats to publish, damage, disrupt, expose, or exploit systems are prohibited.

131. No Data Sale

131.1 Researchers must not sell or offer for sale data discovered during security research.

132. No Public Credential Disclosure

132.1 Credentials must never be published in a vulnerability report, repository, social media post, forum, or other public channel.

133. No Public Exploitation

133.1 Researchers must not publish a functioning exploit against an actively vulnerable StampMitra system before coordinated remediation where doing so would create material risk.

134. Responsible Social Media Use

134.1 Researchers should avoid posting technical details that could facilitate exploitation while a vulnerability remains unresolved.

135. Automated Security Agents

135.1 AI agents, automated scanners, security bots, and other autonomous systems must comply with this Policy.

135.2 The person or organisation operating the system remains responsible for its actions.

136. AI-Generated Testing

136.1 Use of AI-generated payloads, scripts, or testing techniques does not expand the authorised scope.

137. Agentic Systems

137.1 Autonomous systems must not be permitted to continue testing beyond the scope authorised by this Policy.

138. Third-Party Tools

138.1 Researchers are responsible for ensuring that third-party security tools do not generate prohibited traffic or disclose sensitive information.

139. Open-Source Tools

139.1 Use of open-source security tools is permitted only where their operation remains within the authorised scope.

140. Tool Safety

140.1 Researchers should configure security tools to:

(a) limit concurrency;
(b) respect rate limits;
(c) avoid destructive modules;
(d) avoid credential attacks;
(e) avoid data harvesting; and
(f) stop upon unexpected impact.

141. Source-IP Controls

141.1 Researchers should identify themselves appropriately where requested during coordinated testing.

142. Contact Information

142.1 Researchers should provide a valid contact method when submitting a report, unless they choose to report anonymously.

143. Report Confidentiality

143.1 StampMitra may treat submitted reports as confidential security information.

144. Report Data

144.1 Information supplied in a Security Report may be processed for:

(a) investigation;
(b) remediation;
(c) security monitoring;
(d) legal compliance;
(e) incident response; and
(f) service improvement.

145. Privacy

145.1 Personal information submitted through the vulnerability reporting process will be handled subject to applicable privacy and data-protection requirements.

146. Security Incidents

146.1 A Vulnerability that results in actual unauthorised access, data exposure, compromise, or service disruption may be treated as a Security Incident.

147. Incident Response

147.1 StampMitra may activate its applicable incident-response procedures where a Vulnerability results in an actual or suspected Security Incident.

148. Incident Notification

148.1 Notification concerning an incident will be handled according to applicable law, contractual obligations, and StampMitra's Incident & Breach Notification Procedure.

149. Legal Review

149.1 StampMitra may involve legal, compliance, security, privacy, or other specialists in evaluating a report.

150. Law Enforcement

150.1 StampMitra may notify or cooperate with competent authorities where required by law or reasonably necessary in relation to unlawful activity.

151. Evidence Preservation

151.1 StampMitra may preserve relevant technical evidence following a security report.

152. Researcher Evidence Preservation

152.1 Researchers should preserve sufficient evidence to support their report without retaining unnecessary Sensitive Data.

153. Log Deletion

153.1 Researchers must not intentionally delete, alter, or conceal StampMitra security logs.

154. Forensics

154.1 StampMitra may conduct forensic analysis where appropriate.

155. Post-Remediation Validation

155.1 StampMitra may request validation or confirmation that a reported Vulnerability has been remediated.

156. Re-Testing

156.1 Researchers should obtain confirmation before conducting substantial re-testing after remediation.

156.2 Re-testing must remain within the original scope.

157. Regression Testing

157.1 A previously reported Vulnerability may be re-tested only within reasonable limits and without disruptive activity.

158. Security Testing Requests

158.1 StampMitra may separately authorise structured penetration tests or security assessments.

158.2 Such authorisation should be documented in writing.

159. Authorised Security Assessments

159.1 A separately authorised security assessment may have different scope, timing, traffic, and testing permissions.

160. Policy Override by Written Authorisation

160.1 Specific written authorisation from an authorised StampMitra representative may permit testing outside ordinary restrictions.

160.2 The authorisation must clearly identify the permitted scope.

161. No Implied Authorisation

161.1 The existence of a public API, website, or security mechanism does not create implied permission to test it.

162. No Implied Consent

162.1 Technical accessibility does not constitute consent to access data, systems, or functionality beyond the authorised scope.

163. Researcher Responsibility

163.1 Researchers remain responsible for their own actions and for ensuring that their tools, employees, contractors, agents, and automated systems comply with this Policy.

164. Employee or Contractor Research

164.1 A Researcher organisation is responsible for ensuring that its personnel comply with this Policy.

165. Report Ownership

165.1 Submission of a Security Report does not transfer ownership of the Researcher's intellectual property unless separately agreed.

166. StampMitra Rights

166.1 StampMitra may independently investigate, reproduce, remediate, document, and disclose a Vulnerability where legally permitted.

167. No Exclusivity

167.1 Submission of a Vulnerability does not prevent StampMitra from discovering the same issue through another source.

168. No Admission

168.1 Receipt, investigation, or acknowledgement of a Security Report does not constitute an admission that a Vulnerability exists or that StampMitra was negligent.

169. Researcher Warranties

169.1 The Researcher represents that:

(a) the report is submitted in good faith;
(b) the Researcher has authority to submit the report;
(c) the evidence has not been unlawfully obtained;
(d) the Researcher will comply with this Policy; and
(e) the Researcher will not intentionally cause unnecessary harm.

170. Prohibited Disclosure

170.1 Researchers must not disclose:

(a) private credentials;
(b) personal data;
(c) confidential provider identities;
(d) private customer data;
(e) exploitable secrets;
(f) internal architecture;
(g) security keys; or
(h) other confidential information.

171. Disclosure to Third Parties

171.1 Researchers should not disclose confidential vulnerability information to third parties except where legally required or necessary to obtain professional assistance under appropriate confidentiality.

172. Professional Assistance

172.1 Researchers may obtain legal, technical, or professional advice concerning a vulnerability, provided confidential information remains appropriately protected.

173. Public Security Research

173.1 General discussion of security concepts is permitted provided it does not disclose confidential StampMitra information or actionable details of an unresolved vulnerability.

174. Security Conferences

174.1 Researchers intending to present StampMitra-specific vulnerability information should coordinate disclosure where the material concerns a non-public or unresolved issue.

175. Media Requests

175.1 Researchers should direct media requests concerning StampMitra-specific vulnerabilities through appropriate public channels and must not disclose confidential information.

176. Policy Interpretation

176.1 StampMitra may interpret this Policy reasonably in light of security, legal, operational, and technical circumstances.

177. Good-Faith Exceptions

177.1 Minor inadvertent deviations from this Policy may be considered in determining whether Safe Harbour applies, provided the Researcher acted in good faith, caused no material harm, and promptly stopped or corrected the activity.

178. Material Violation

178.1 Material violations may result in loss of Safe Harbour and may be handled under applicable legal and contractual rights.

179. Immediate Threats

179.1 Where activity creates an immediate threat to security or availability, StampMitra may take immediate defensive action.

180. Blocking

180.1 StampMitra may block IP addresses, accounts, credentials, tokens, sessions, or other access mechanisms where necessary to protect its systems.

181. Contact

181.1 Security and legal correspondence may be directed to:

[email protected]

181.2 Official Developer Platform:

https://developer.stampmitra.in/

182. Policy Updates

182.1 StampMitra may update this Policy to reflect changes in security practices, technology, law, infrastructure, or operational requirements.

183. Effective Date

183.1 Updated versions become effective on the date stated in the updated Policy unless otherwise specified.

184. Severability

184.1 If any provision is found invalid or unenforceable, the remaining provisions remain effective to the extent permitted by law.

185. Waiver

185.1 Failure to enforce a provision does not constitute a waiver of future enforcement.

186. Relationship with Other Policies

186.1 This Policy must be read together with:

(a) Developer Terms of Service;
(b) Developer Privacy Policy;
(c) Data Processing Addendum;
(d) API Acceptable Use Policy;
(e) Third-Party & Underlying Services Policy;
(f) API Security Policy;
(g) API SLA & Service Availability Policy;
(h) Billing, API Credits & Refund Policy;
(i) Verification, e-Stamp & e-Sign Service Terms;
(j) API Versioning, Suspension & Deprecation Policy; and
(k) Developer Grievance Redressal Policy.

187. Order of Precedence

187.1 In the event of conflict, the order of precedence specified in the Developer Terms of Service shall apply.

188. Governing Law

188.1 This Policy is governed by the governing law provisions of the StampMitra Developer Terms of Service, subject to applicable Indian law.

189. Dispute Resolution

189.1 Disputes relating to this Policy shall be handled in accordance with the dispute-resolution provisions of the StampMitra Developer Terms of Service.

190. Final Acknowledgement

190.1 By conducting security research under this Policy, the Researcher acknowledges that:

(a) scope is limited;
(b) good-faith research is expected;
(c) unnecessary data access is prohibited;
(d) destructive testing is prohibited;
(e) third-party systems are not automatically authorised;
(f) confidential information must be protected;
(g) vulnerabilities should be responsibly disclosed;
(h) Safe Harbour is limited and subject to applicable law;
(i) this Policy does not create a bug-bounty entitlement; and
(j) StampMitra may take protective action where necessary.

191. Policy Record

Policy Name: Security Vulnerability Disclosure Policy
Policy Number: 12 of 19
Version: 1.0
Status: FINAL — PUBLISHED POLICY
Effective Date: 05 October 2026
Last Updated: 05 October 2026
Legal Entity: BANI GLOBAL INDUSTRIES LLP
Prepared By: Legal Team
Legal Contact: [email protected]