Incident & Breach Notification Procedure

1.1 This Incident & Breach Notification Procedure (“Procedure”) establishes the framework under which StampMitra identifies, assesses, contains, investigates, manages and communicates security incidents, privacy incidents, Personal Data breaches and other material operational incidents.

1.2 The purpose of this Procedure is to:

• (a) establish a structured incident-response process;
• (b) protect Developer Data and End User information;
• (c) reduce the impact of security incidents;
• (d) establish notification principles;
• (e) support legal and regulatory compliance;
• (f) coordinate with Developers and service providers;
• (g) preserve appropriate evidence;
• (h) support service restoration; and
• (i) provide a consistent framework for post-incident remediation.

2.1 This Procedure forms part of the StampMitra Developer policy framework.

2.2 Where incorporated into an applicable agreement, Order Form, DPA or other contractual instrument, this Procedure shall have contractual effect to the extent provided in that instrument.

2.3 This Procedure does not create a universal contractual notification deadline unless expressly stated in an executed agreement or required by Applicable Law.

3.1 This Procedure applies to incidents affecting or potentially affecting:

• (a) StampMitra Developer Platform;
• (b) StampMitra APIs;
• (c) Developer accounts;
• (d) API credentials;
• (e) Developer Data;
• (f) Personal Data;
• (g) e-Stamp transactions;
• (h) e-Sign transactions;
• (i) verification services;
• (j) payment-related integrations;
• (k) infrastructure;
• (l) databases;
• (m) storage;
• (n) communications;
• (o) security systems;
• (p) third-party integrations;
• (q) Underlying Service Providers;
• (r) internal systems; and
• (s) other systems supporting StampMitra services.

4.1 StampMitra shall seek to manage incidents according to the following principles:

• (a) prompt identification;
• (b) risk-based assessment;
• (c) containment;
• (d) preservation of relevant evidence;
• (e) protection of affected information;
• (f) accurate communications;
• (g) regulatory compliance;
• (h) service restoration; and
• (i) corrective action.

5.1 “Incident” means an event that has affected, or may affect, the confidentiality, integrity, availability or lawful operation of StampMitra systems, information or services.

5.2 “Security Incident” means an event involving actual or suspected unauthorized access, disclosure, alteration, destruction, loss, compromise or disruption of information or systems.

5.3 “Personal Data Breach” means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to Personal Data, to the extent such concept applies under Applicable Data Protection Law.

5.4 “Privacy Incident” means an event involving an actual or suspected violation of applicable privacy or data-protection requirements.

5.5 “Service Incident” means an event affecting availability, performance, reliability or functionality without necessarily constituting a security or privacy incident.

5.6 “Developer Data” means information submitted by or on behalf of a Developer through the StampMitra services.

5.7 “End User” means an individual or entity whose information is submitted or processed through a Developer's use of StampMitra.

5.8 “Applicable Law” means laws, regulations, directions and binding requirements applicable to the relevant incident.

5.9 “Incident Response Team” means the internal personnel or authorized persons responsible for managing an incident.

5.10 “Affected Developer” means a Developer reasonably determined to be materially affected by an incident.

5.11 “Containment” means measures taken to prevent an incident from continuing or increasing in scope.

5.12 “Remediation” means measures taken to eliminate the cause of an incident or reduce the likelihood of recurrence.

6.1 StampMitra may classify incidents into one or more categories:

• (a) security incident;
• (b) Personal Data breach;
• (c) privacy incident;
• (d) account compromise;
• (e) credential compromise;
• (f) API abuse;
• (g) fraud incident;
• (h) document-related incident;
• (i) e-Stamp incident;
• (j) e-Sign incident;
• (k) payment-related incident;
• (l) infrastructure incident;
• (m) service availability incident;
• (n) third-party provider incident;
• (o) regulatory incident;
• (p) communications incident; or
• (q) other material operational incident.

7.1 StampMitra may classify incidents according to severity.

7.2 Indicative classifications include:

• CRITICAL: An incident presenting a potentially severe impact on security, Personal Data, critical infrastructure, financial transactions or material service operation.
• HIGH: An incident presenting substantial risk or significant service or data impact.
• MEDIUM: An incident presenting limited or contained impact.
• LOW: An incident with limited operational or security significance.

7.3 Severity may be changed as investigation progresses.

8.1 Incident severity may consider:

• (a) number of affected persons;
• (b) categories of information;
• (c) sensitivity;
• (d) duration;
• (e) likelihood of misuse;
• (f) actual misuse;
• (g) geographic scope;
• (h) financial impact;
• (i) regulatory impact;
• (j) service impact;
• (k) availability impact;
• (l) integrity impact;
• (m) confidentiality impact; and
• (n) ability to contain the incident.

9.1 Incidents may be identified through:

• (a) automated monitoring;
• (b) security alerts;
• (c) fraud systems;
• (d) API monitoring;
• (e) access logs;
• (f) Developer reports;
• (g) End User reports;
• (h) service-provider notifications;
• (i) vulnerability reports;
• (j) employee reports;
• (k) regulatory notifications;
• (l) law-enforcement communications; or
• (m) other sources.

10.1 Developers should promptly report suspected incidents affecting StampMitra services, including:

• (a) compromised API keys;
• (b) unauthorized account access;
• (c) exposed credentials;
• (d) suspicious API traffic;
• (e) unauthorized transactions;
• (f) Personal Data exposure;
• (g) webhook compromise;
• (h) document compromise;
• (i) fraudulent use; or
• (j) other material security concerns.

11.1 Security and legal incident notifications may be directed to:

Legal Team

BANI GLOBAL INDUSTRIES LLP

Email: [email protected]

11.2 Where StampMitra publishes a dedicated security contact in future, such contact may supersede this address for security reports.

12.1 A Developer reporting an incident should provide, where reasonably available:

• (a) account or project identifier;
• (b) date and approximate time;
• (c) affected API or service;
• (d) affected transaction identifiers;
• (e) nature of suspected incident;
• (f) affected information;
• (g) relevant logs;
• (h) screenshots where appropriate;
• (i) indicators of compromise;
• (j) steps already taken; and
• (k) contact details for follow-up.

13.1 Developers shall not send:

• (a) API secret keys;
• (b) passwords;
• (c) OTPs;
• (d) private keys;
• (e) webhook secrets;
• (f) authentication tokens; or
• (g) other credentials

through ordinary support or incident communications unless specifically requested through a secure and authorized channel.

14.1 Upon receiving a credible incident report, StampMitra may perform initial triage.

14.2 Initial triage may determine:

• (a) whether an incident exists;
• (b) affected systems;
• (c) preliminary severity;
• (d) immediate containment requirements;
• (e) potential Personal Data involvement;
• (f) potential regulatory implications; and
• (g) whether additional teams or providers must be involved.

15.1 StampMitra may create an incident record containing:

• (a) incident identifier;
• (b) detection source;
• (c) detection date;
• (d) affected systems;
• (e) severity;
• (f) investigation notes;
• (g) containment actions;
• (h) communications;
• (i) remediation;
• (j) closure status; and
• (k) post-incident actions.

16.1 Depending on the nature of an incident, the response may involve:

• (a) technology personnel;
• (b) security personnel;
• (c) legal personnel;
• (d) privacy personnel;
• (e) operations;
• (f) finance;
• (g) customer support;
• (h) management;
• (i) communications personnel; and
• (j) external advisers.

17.1 Incident information may be shared internally according to need-to-know principles.

17.2 Sensitive incident information may be restricted to authorized personnel.

18.1 StampMitra may designate an incident lead for material incidents.

18.2 The incident lead may coordinate:

• (a) investigation;
• (b) containment;
• (c) technical remediation;
• (d) legal assessment;
• (e) communications;
• (f) provider coordination; and
• (g) closure.

19.1 StampMitra may take immediate action to contain an incident.

19.2 Such actions may include:

• (a) disabling credentials;
• (b) rotating secrets;
• (c) blocking IP addresses;
• (d) restricting API traffic;
• (e) suspending an account;
• (f) disabling an endpoint;
• (g) isolating infrastructure;
• (h) blocking suspicious transactions;
• (i) changing routing;
• (j) disabling an integration; or
• (k) other reasonable security measures.

20.1 StampMitra may take emergency action without prior notice where necessary to protect:

• (a) Personal Data;
• (b) Developer accounts;
• (c) End Users;
• (d) financial transactions;
• (e) API infrastructure;
• (f) legal documents;
• (g) e-Stamp transactions;
• (h) e-Sign transactions; or
• (i) service integrity.

21.1 Where an API key or other credential is suspected to be compromised, StampMitra may:

• (a) revoke it;
• (b) disable it;
• (c) require rotation;
• (d) restrict associated traffic;
• (e) suspend associated functionality; or
• (f) require additional verification.

22.1 Suspected account takeover may result in temporary restriction of account access.

22.2 StampMitra may require additional verification before restoring access.

23.1 StampMitra may investigate unusual API activity including:

• (a) credential attacks;
• (b) excessive requests;
• (c) enumeration;
• (d) automated abuse;
• (e) fraud;
• (f) unauthorized access;
• (g) data harvesting; or
• (h) suspicious transaction activity.

24.1 Fraud incidents may require coordination among security, operations, payment, verification and other relevant functions.

24.2 StampMitra may restrict affected transactions while an investigation is conducted.

25.1 For each potentially privacy-related incident, StampMitra may assess:

• (a) whether Personal Data was involved;
• (b) categories of Personal Data;
• (c) number of affected persons;
• (d) whether data was accessed;
• (e) whether data was actually exfiltrated;
• (f) likelihood of misuse;
• (g) potential harm;
• (h) containment status; and
• (i) legal notification obligations.

26.1 Where StampMitra acts as a Data Processor or equivalent role, incident obligations shall be determined under the applicable DPA, Developer Terms and Applicable Law.

26.2 StampMitra may notify the relevant Developer where required by the applicable contractual arrangement.

27.1 Where StampMitra acts as a Data Fiduciary or equivalent role, StampMitra shall independently assess its applicable legal obligations.

27.2 StampMitra may make notifications directly to affected persons, authorities or other relevant entities where required.

28.1 Incident obligations shall depend on the actual role of the parties in the relevant Processing activity.

28.2 The same incident may involve different legal roles for different datasets or processing activities.

29.1 Developers remain responsible for incidents originating within their own systems, applications, personnel, infrastructure or client environments.

29.2 A Developer shall independently assess whether it is required to notify its own customers, Data Principals, authorities or other parties.

30.1 If a Developer's system is compromised while using StampMitra, the Developer shall take reasonable steps to:

• (a) contain the incident;
• (b) secure credentials;
• (c) prevent further unauthorized requests;
• (d) preserve evidence;
• (e) investigate;
• (f) cooperate with StampMitra where relevant; and
• (g) comply with applicable law.

31.1 StampMitra shall investigate incidents affecting its own systems according to the nature and severity of the incident.

31.2 StampMitra may implement technical and organizational measures to contain and remediate the incident.

32.1 Where an incident originates from or involves an external service provider, StampMitra may coordinate with that provider.

32.2 Provider identity and technical information may remain confidential.

33.1 An incident involving an Underlying Service Provider does not automatically constitute a StampMitra security breach.

33.2 StampMitra shall assess whether:

• (a) StampMitra systems were affected;
• (b) Developer Data was affected;
• (c) Personal Data was affected;
• (d) service availability was affected; and
• (e) notification is legally or contractually required.

34.1 StampMitra may rely on information supplied by external providers when investigating an incident involving their systems.

34.2 StampMitra may not be able to independently verify every technical detail immediately.

35.1 Where contractually available, StampMitra may request from an external provider:

• (a) incident timelines;
• (b) affected systems;
• (c) affected data;
• (d) containment measures;
• (e) remediation;
• (f) forensic information; and
• (g) other relevant information.

36.1 StampMitra shall make notifications where required by:

• (a) Applicable Law;
• (b) the applicable DPA;
• (c) an executed agreement;
• (d) regulatory direction; or
• (e) other binding legal requirement.

37.1 Not every service interruption, failed transaction, security alert or technical error constitutes a notifiable Personal Data breach.

37.2 Notification shall be based on the facts, applicable legal requirements and contractual obligations.

38.1 Before issuing a notification, StampMitra may assess:

• (a) incident credibility;
• (b) scope;
• (c) impact;
• (d) affected data;
• (e) affected Developers;
• (f) affected End Users;
• (g) legal requirements;
• (h) contractual requirements;
• (i) containment status; and
• (j) available verified information.

39.1 Where notification is required, StampMitra may include, to the extent reasonably available and appropriate:

• (a) nature of the incident;
• (b) affected service;
• (c) affected data categories;
• (d) known or reasonably suspected impact;
• (e) measures taken;
• (f) recommended Developer actions;
• (g) contact information;
• (h) relevant remediation steps; and
• (i) other information required by law.

40.1 StampMitra may issue a preliminary notification before the investigation is complete where timely communication is required.

40.2 Preliminary information may subsequently be updated.

41.1 StampMitra may issue supplementary communications when material new information becomes available.

41.2 Updates may address:

• (a) scope;
• (b) affected data;
• (c) containment;
• (d) remediation;
• (e) user actions;
• (f) regulatory requirements; or
• (g) closure.

42.1 StampMitra shall not intentionally delay required notification merely because every technical detail is unavailable.

42.2 Where appropriate, initial communications may identify information as preliminary or under investigation.

43.1 Incident communications shall be based on information reasonably believed to be accurate at the time of communication.

43.2 StampMitra may correct or update information if subsequent investigation identifies an error.

44.1 Notifications may be communicated through:

• (a) email;
• (b) Developer Portal;
• (c) service notifications;
• (d) status page;
• (e) account notifications;
• (f) direct contractual notice;
• (g) legally required channels; or
• (h) other appropriate channels.

45.1 Service incidents may be communicated through an authorized StampMitra status page where appropriate.

45.2 A status-page notice may provide operational information without disclosing confidential security details.

46.1 StampMitra may communicate service availability incidents without publicly describing confidential security mechanisms.

46.2 Security-related details may be withheld where disclosure could increase risk.

47.1 StampMitra may publish a public incident notice where:

• (a) service availability is materially affected;
• (b) public communication is legally required;
• (c) a broad Developer population is affected; or
• (d) public communication is otherwise appropriate.

48.1 StampMitra shall not be required to disclose:

• (a) exploit details;
• (b) private credentials;
• (c) security architecture;
• (d) detection rules;
• (e) defensive configurations;
• (f) provider confidential information; or
• (g) other information whose disclosure could increase security risk.

49.1 A Developer may be required to:

• (a) rotate API keys;
• (b) reset credentials;
• (c) review logs;
• (d) inspect its own systems;
• (e) notify End Users;
• (f) stop affected integrations;
• (g) validate transactions;
• (h) reconcile records; or
• (i) implement other remediation.

50.1 Where an incident may have exposed credentials, StampMitra may require immediate credential rotation.

50.2 Developers shall not continue using credentials that StampMitra has revoked or identified as compromised.

51.1 Where webhook secrets or endpoints are compromised, StampMitra may require:

• (a) secret rotation;
• (b) endpoint validation;
• (c) signature verification;
• (d) replay protection;
• (e) temporary suspension; or
• (f) endpoint replacement.

52.1 Payment-related incidents may require coordination with applicable payment infrastructure providers.

52.2 StampMitra may investigate:

• (a) payment status;
• (b) duplicate transactions;
• (c) unauthorized payment;
• (d) settlement;
• (e) refunds;
• (f) chargebacks; and
• (g) payment security.

53.1 Incidents involving e-Stamp transactions may require reconciliation with applicable external systems.

53.2 StampMitra may place affected transactions into pending, review or restricted status where appropriate.

54.1 Incidents involving e-Sign transactions may require investigation of:

• (a) signer identity;
• (b) authentication;
• (c) signing status;
• (d) document integrity;
• (e) certificate status;
• (f) audit trail; and
• (g) external service status.

55.1 Incidents involving verification services may require assessment of:

• (a) request integrity;
• (b) returned information;
• (c) source accuracy;
• (d) unauthorized access;
• (e) data exposure; and
• (f) external source status.

56.1 Where documents may have been exposed or altered, StampMitra may assess:

• (a) document identity;
• (b) access history;
• (c) integrity;
• (d) affected users;
• (e) storage;
• (f) downloads;
• (g) sharing; and
• (h) remediation requirements.

57.1 Incidents affecting data integrity may require:

• (a) reconciliation;
• (b) backup restoration;
• (c) transaction verification;
• (d) duplicate detection;
• (e) record correction; and
• (f) customer communication.

58.1 Temporary inability to access information does not necessarily constitute a Personal Data breach.

58.2 StampMitra may assess availability incidents separately from confidentiality incidents.

59.1 Suspected data loss shall be investigated to determine:

• (a) what information was lost;
• (b) whether backup copies exist;
• (c) whether unauthorized access occurred;
• (d) whether restoration is possible; and
• (e) whether notification is required.

60.1 Unauthorized disclosure may include:

• (a) incorrect recipient;
• (b) exposed document;
• (c) public URL exposure;
• (d) accidental email disclosure;
• (e) unauthorized API response; or
• (f) other unintended disclosure.

61.1 Unauthorized access includes access to systems or information without appropriate authorization.

61.2 StampMitra may assess whether information was actually accessed or merely exposed to potential access.

62.1 Physical or electronic loss of information may be assessed for breach implications based on the nature of the information and applicable legal requirements.

63.1 Malware, ransomware or destructive attacks may require immediate isolation, credential rotation, infrastructure protection and forensic investigation.

64.1 Denial-of-service or distributed denial-of-service activity may be managed as a service-security incident.

64.2 StampMitra may implement traffic restrictions, rate limiting, filtering or other protective controls.

65.1 Accounts suspected of being used for abuse may be restricted or suspended while an investigation occurs.

66.1 StampMitra may preserve:

• (a) access logs;
• (b) API logs;
• (c) security alerts;
• (d) transaction records;
• (e) system logs;
• (f) configuration records;
• (g) communications;
• (h) forensic images where appropriate; and
• (i) other relevant evidence.

67.1 Where reasonably practicable, incident evidence shall be preserved in a manner designed to maintain its integrity and traceability.

68.1 StampMitra may preserve information beyond ordinary retention periods where necessary for:

• (a) litigation;
• (b) regulatory proceedings;
• (c) investigation;
• (d) fraud prevention;
• (e) law enforcement; or
• (f) other lawful purposes.

69.1 Legal advice and privileged communications may be handled separately from ordinary incident records where applicable.

70.1 StampMitra may engage internal or external specialists to conduct forensic investigations.

70.2 Such specialists may include security professionals, legal advisers or other qualified experts.

71.1 StampMitra may rely upon forensic findings provided by authorized external providers where appropriate.

72.1 Containment may seek to:

• (a) stop unauthorized access;
• (b) prevent further disclosure;
• (c) protect remaining systems;
• (d) preserve evidence;
• (e) maintain critical services; and
• (f) prevent recurrence during remediation.

73.1 Remediation may include:

• (a) software patches;
• (b) configuration changes;
• (c) credential rotation;
• (d) access restrictions;
• (e) infrastructure changes;
• (f) provider replacement;
• (g) data correction;
• (h) additional monitoring; and
• (i) policy changes.

74.1 For material incidents, StampMitra may conduct a root cause analysis.

74.2 Root cause analysis may identify:

• (a) technical cause;
• (b) process cause;
• (c) human factors;
• (d) third-party dependency;
• (e) control failure; or
• (f) other contributing factors.

75.1 A corrective action plan may contain:

• (a) remediation;
• (b) security improvements;
• (c) process changes;
• (d) training;
• (e) monitoring enhancements;
• (f) architectural changes; and
• (g) provider actions.

76.1 Material incidents may be reviewed after containment.

76.2 The review may assess:

• (a) detection;
• (b) response;
• (c) communication;
• (d) containment;
• (e) remediation;
• (f) lessons learned; and
• (g) future risk.

77.1 StampMitra may update:

• (a) security controls;
• (b) policies;
• (c) technical architecture;
• (d) training;
• (e) documentation;
• (f) incident procedures; and
• (g) provider requirements

based on lessons learned.

78.1 Developers shall reasonably cooperate with StampMitra when necessary to investigate an incident affecting shared services.

78.2 Cooperation may include:

• (a) providing relevant logs;
• (b) securing credentials;
• (c) confirming affected transactions;
• (d) identifying affected users;
• (e) implementing remediation; and
• (f) preserving relevant evidence.

79.1 Developers should maintain sufficient logs to support investigation of their use of StampMitra APIs.

79.2 Logs should include appropriate request identifiers, timestamps and transaction references without unnecessarily retaining sensitive information.

80.1 Financial, e-Stamp, e-Sign and verification incidents may require reconciliation of:

• (a) requests;
• (b) responses;
• (c) transaction identifiers;
• (d) payment status;
• (e) service status;
• (f) document status; and
• (g) completion status.

81.1 A transaction that remains pending during an incident shall not automatically be treated as failed.

81.2 Developers may be required to wait for reconciliation or final status.

82.1 Developers shall use idempotency and appropriate transaction controls where supported.

82.2 Developers should not automatically resubmit transactions merely because an incident causes a timeout.

83.1 StampMitra may temporarily:

• (a) reduce rate limits;
• (b) disable endpoints;
• (c) restrict high-risk operations;
• (d) suspend webhooks;
• (e) require additional authentication; or
• (f) otherwise restrict service access

where necessary to manage an incident.

84.1 Emergency security maintenance may be performed without ordinary maintenance notice where necessary to protect the platform.

85.1 StampMitra may provide updates based on the significance and development of the incident.

85.2 StampMitra does not guarantee a fixed communication frequency unless expressly provided under an applicable SLA or agreement.

86.1 This Procedure does not establish a universal incident response, investigation or resolution time.

86.2 Applicable contractual or statutory deadlines shall prevail.

87.1 StampMitra shall assess whether notification to an authority is required.

87.2 Such assessment may consider:

• (a) applicable law;
• (b) nature of data;
• (c) affected persons;
• (d) severity;
• (e) legal role;
• (f) jurisdiction; and
• (g) applicable regulatory directions.

88.1 Where Applicable Data Protection Law requires notification of a Personal Data breach, StampMitra shall take appropriate steps consistent with the applicable legal framework.

88.2 The Digital Personal Data Protection Act, 2023 and rules made thereunder shall be considered to the extent applicable and in force at the relevant time.

89.1 Where legislation or rules have phased commencement, obligations shall be applied according to the provisions that are legally effective at the relevant time.

89.2 References to legal obligations in this Procedure shall not be interpreted as asserting that every provision of a statute or rule is simultaneously in force.

90.1 StampMitra may cooperate with lawful law-enforcement requests.

90.2 Disclosure shall be handled according to Applicable Law and appropriate legal process.

91.1 Government or regulatory authorities may receive incident information where legally required.

91.2 StampMitra may restrict public disclosure where required by law or necessary to avoid compromising an investigation.

92.1 Incident communications may contain confidential, security-sensitive or legally privileged information.

92.2 Developers shall not publicly disclose confidential incident information provided under a confidentiality obligation.

93.1 Developers shall not misrepresent or prematurely publish unverified claims concerning a StampMitra security incident.

93.2 Nothing in this provision restricts a Developer from exercising rights required by Applicable Law.

94.1 Public media communications concerning StampMitra incidents may be handled through authorized StampMitra representatives.

95.1 StampMitra may issue security advisories concerning:

• (a) vulnerabilities;
• (b) compromised credentials;
• (c) required developer actions;
• (d) affected versions;
• (e) service restrictions; or
• (f) remediation.

96.1 Security vulnerabilities shall be handled according to the StampMitra Security Vulnerability Disclosure Policy where applicable.

96.2 A vulnerability does not necessarily constitute a Personal Data breach.

97.1 A vulnerability is a weakness that may permit compromise.

97.2 An incident involves an actual or suspected event affecting security, privacy, availability or integrity.

97.3 A vulnerability may exist without evidence of exploitation.

98.1 A service outage does not necessarily constitute a security incident.

98.2 A security incident may also cause a service outage.

99.1 Deliberately false or malicious incident reports may result in account action.

99.2 Good-faith reports shall not be penalized merely because the reported issue is ultimately determined not to be a security incident.

100.1 StampMitra encourages prompt good-faith reporting of credible security and privacy concerns.

101.1 StampMitra shall not intentionally retaliate against a Developer for making a good-faith incident report.

101.2 This protection does not extend to malicious, fraudulent or unauthorized activity.

102.1 Where an incident materially affects a Developer and notification is appropriate or required, StampMitra may provide notice to that Developer.

102.2 Notification may be limited to information relevant to the Developer.

103.1 Where appropriate or legally required, StampMitra or the relevant Developer may notify affected End Users.

103.2 Responsibility shall depend on the applicable legal role, contractual arrangement and nature of the incident.

104.1 Where the Developer is the relevant Data Fiduciary, controller or responsible entity, StampMitra may provide information reasonably necessary for the Developer to fulfil its own notification obligations.

105.1 Where required under an applicable DPA, StampMitra may provide reasonable information and cooperation necessary to support a Developer's incident response.

106.1 Data Principal requests following an incident shall be handled according to the applicable legal role and privacy framework.

107.1 StampMitra may require reasonable verification before disclosing incident information relating to an account or individual.

108.1 StampMitra shall not disclose confidential incident information to persons who cannot reasonably demonstrate authorization.

109.1 Developers should independently verify that communications claiming to originate from StampMitra are authentic.

109.2 StampMitra shall not request secret credentials through ordinary incident notifications.

110.1 Developers should treat unexpected incident-related messages requesting passwords, OTPs, private keys or API secrets as potentially fraudulent.

111.1 Where a notification directs Developers to a portal or website, Developers should use official StampMitra domains or authorized contractual communication channels.

112.1 StampMitra shall not require a Developer to disclose an OTP through an ordinary incident response communication.

113.1 Incident communications shall seek to minimize unnecessary disclosure of Personal Data.

114.1 Incident records may be redacted to protect:

• (a) Personal Data;
• (b) credentials;
• (c) security architecture;
• (d) third-party confidential information;
• (e) privileged information; or
• (f) legally protected information.

115.1 Incident records may be retained for periods appropriate to:

• (a) legal requirements;
• (b) security needs;
• (c) audit;
• (d) litigation;
• (e) regulatory requirements;
• (f) lessons learned; and
• (g) contractual obligations.

116.1 Incident-related data shall be deleted or anonymized when retention is no longer reasonably required, subject to lawful retention requirements.

117.1 Incident information may remain temporarily in backups after primary records are deleted.

118.1 Material incidents may maintain an audit trail of:

• (a) detection;
• (b) decisions;
• (c) actions;
• (d) communications;
• (e) approvals;
• (f) remediation; and
• (g) closure.

119.1 Material incidents may be escalated to appropriate management personnel.

119.2 Critical incidents may receive senior-management oversight.

120.1 Incidents involving potential legal, regulatory, contractual or privacy consequences may be escalated to legal personnel.

121.1 Incidents involving Personal Data may be escalated for privacy and data-protection assessment.

122.1 Incidents involving compromise, vulnerability, unauthorized access or malicious activity may be escalated to security and technical personnel.

123.1 Incidents involving payment, financial transactions, refunds, settlement or fraud may be escalated to appropriate financial and operational personnel.

124.1 Where an external provider is involved, StampMitra may escalate through applicable provider support or incident channels.

125.1 StampMitra may coordinate:

• (a) containment;
• (b) service restoration;
• (c) investigation;
• (d) evidence;
• (e) customer communications; and
• (f) remediation

with relevant providers.

126.1 Provider names, technical details and incident information may remain confidential where required by contract, law or security considerations.

127.1 StampMitra may receive incident information concerning third-party systems.

127.2 Such information may be subject to third-party confidentiality restrictions.

128.1 Incidents involving international Processing may require additional legal or regulatory analysis.

128.2 StampMitra may consider the laws applicable to the affected Processing activity and affected persons.

129.1 Where an incident affects multiple jurisdictions, StampMitra may assess notification requirements separately for each applicable jurisdiction.

130.1 Notifications may be issued in English or another language where reasonably appropriate to the affected audience.

131.1 StampMitra may provide incident communications through accessible channels appropriate to the relevant Developer.

132.1 Critical service incidents may require immediate operational communications.

132.2 Such communications may initially focus on:

• (a) service impact;
• (b) affected functionality;
• (c) recommended action; and
• (d) current status.

133.1 Public communications may intentionally omit technical details that could facilitate exploitation.

134.1 An incident may be closed when:

• (a) containment is achieved;
• (b) immediate risk is addressed;
• (c) service is restored where applicable;
• (d) required notifications are completed;
• (e) remediation is implemented or tracked; and
• (f) the incident record is appropriately documented.

135.1 A closed incident may be reopened if new evidence indicates continuing or related risk.

136.1 StampMitra may prepare a post-incident report for material incidents.

136.2 Such report may include:

• (a) incident summary;
• (b) root cause;
• (c) impact;
• (d) response;
• (e) remediation;
• (f) lessons learned; and
• (g) preventive measures.

137.1 A post-incident report may be shared with an affected Developer where appropriate or contractually required.

137.2 Confidential, privileged or security-sensitive information may be omitted.

138.1 Following an incident, StampMitra may implement:

• (a) additional monitoring;
• (b) stronger authentication;
• (c) architecture changes;
• (d) provider changes;
• (e) additional access controls;
• (f) data minimization;
• (g) additional testing; and
• (h) other safeguards.

139.1 StampMitra may use incident findings to improve security, privacy and incident-response training.

140.1 StampMitra may conduct exercises, simulations or tabletop activities to assess incident-response readiness.

141.1 Incident management shall be coordinated with applicable business continuity and disaster recovery arrangements.

142.1 Where applicable, StampMitra may restore services using backup, redundancy or recovery infrastructure.

143.1 Recovery of data shall be subject to:

• (a) backup availability;
• (b) data integrity;
• (c) transaction reconciliation;
• (d) security validation; and
• (e) applicable legal requirements.

144.1 StampMitra does not guarantee that every incident will be resolved without data loss, service interruption or other impact.

145.1 Incidents arising from events beyond reasonable control may be subject to applicable force majeure provisions.

146.1 This Procedure may be updated when incident notification requirements change under Applicable Law.

147.1 Enterprise customers may have additional incident notification requirements under an executed agreement or Order Form.

147.2 Such requirements shall apply according to the relevant contract.

148.1 Where the DPA contains incident or breach notification requirements, those requirements shall govern the applicable Processing relationship.

149.1 Service availability communications shall also be governed by the applicable API SLA & Service Availability Policy.

150.1 Vulnerability reports shall be handled according to the Security Vulnerability Disclosure Policy.

150.2 If a vulnerability is exploited, it may additionally become a Security Incident.

151.1 Where an incident is caused by Developer misuse or prohibited activity, the Developer may be subject to the Acceptable Use Policy and applicable enforcement measures.

152.1 StampMitra may suspend an account where necessary to contain or investigate an incident.

153.1 Account access may be restored after:

• (a) containment;
• (b) credential security;
• (c) verification;
• (d) remediation; and
• (e) other reasonable security requirements.

154.1 Security restrictions may remain in place while risk continues.

155.1 StampMitra may provide reasonable support regarding incident-related Developer actions.

155.2 Support does not replace the Developer's own security, privacy or legal obligations.

156.1 Each Developer remains responsible for its own compliance with Applicable Law, including obligations relating to its End Users and customer data.

157.1 Each party shall generally bear its own incident-response costs unless otherwise provided by an applicable agreement or law.

158.1 Indemnification arising from an incident shall be governed by the applicable Developer Terms, DPA, Order Form or other executed agreement.

159.1 Liability arising from incidents shall be governed by the applicable contractual framework.

159.2 This Procedure does not independently create a separate liability cap or liability obligation.

160.1 An incident notification, investigation, remediation or customer communication shall not automatically constitute an admission of liability, wrongdoing or contractual breach.

161.1 StampMitra may cooperate with lawful regulatory, governmental, judicial and law-enforcement investigations.

162.1 Nothing in this Procedure limits rights or remedies that cannot lawfully be excluded or restricted.

163.1 Failure to immediately notify, investigate or communicate concerning an event shall not constitute a waiver of any contractual or legal right unless expressly agreed.

164.1 Incident records and communications may constitute Confidential Information under the applicable Developer agreement.

165.1 StampMitra may disclose incident information to legal, security, audit, insurance, forensic or other professional advisers where reasonably necessary.

166.1 Where applicable, StampMitra may coordinate incident information with relevant insurers or professional advisers.

167.1 Material incidents shall be documented to the extent reasonably appropriate for security, legal, operational and compliance purposes.

168.1 Incident records may be reviewed through internal or external audits where appropriate.

169.1 Enterprise customers may receive additional incident information subject to:

• (a) confidentiality;
• (b) security;
• (c) applicable law;
• (d) contractual rights; and
• (e) availability of verified information.

170.1 StampMitra shall seek to balance transparency with:

• (a) security;
• (b) privacy;
• (c) legal privilege;
• (d) provider confidentiality;
• (e) investigation integrity; and
• (f) regulatory requirements.

171.1 Material external incident communications may be reviewed by appropriate legal, security or management personnel before publication where circumstances permit.

172.1 In urgent circumstances, immediate communications may be issued before ordinary internal review is completed.

173.1 If an incident communication contains material inaccurate information, StampMitra may issue a correction.

174.1 StampMitra may request feedback from affected Developers following material incidents to improve incident response.

175.1 StampMitra may periodically review and update this Procedure.

176.1 This Procedure may be maintained by StampMitra's legal, security, technology or designated governance functions.

177.1 Changes to this Procedure shall be reflected through version control and an updated effective or last-updated date.

178.1 This Procedure may be made available through the StampMitra Developer Portal or another authorized channel.

179.1 Electronic versions of this Procedure may constitute the official policy record where maintained by StampMitra.

180.1 If any provision is held invalid or unenforceable, the remaining provisions shall continue to the extent permitted by law.

181.1 A waiver must be expressly made and shall not be inferred from delay or omission.

182.1 This Procedure shall be read 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;
• (k) Developer Grievance Redressal Policy;
• (l) Security Vulnerability Disclosure Policy;
• (m) Cookie & Tracking Policy;
• (n) Developer Data Retention & Deletion Schedule;
• (o) API Documentation & Developer License Terms;
• (p) Enterprise API Agreement / Order Form; and
• (q) Subprocessor / Service Provider Disclosure Framework.

183.1 In the event of conflict:

• (a) mandatory Applicable Law shall prevail;
• (b) executed enterprise agreements shall prevail where expressly inconsistent;
• (c) the DPA shall govern applicable Personal Data Processing;
• (d) the Developer Terms shall govern general contractual matters;
• (e) the applicable SLA shall govern service availability;
• (f) this Procedure shall govern incident and breach response matters.

184.1 This Procedure shall be governed by the laws of India, subject to applicable mandatory statutory requirements.

184.2 Dispute resolution shall be governed by the applicable Developer Terms, DPA, Order Form or other executed agreement.

185.1 Incident, privacy and legal notifications may be directed to:

Legal Team

BANI GLOBAL INDUSTRIES LLP

Email: [email protected]

186.1 By using StampMitra services, the Developer acknowledges that security, privacy, service and operational incidents may occur despite reasonable safeguards.

186.2 The Developer acknowledges that:

• (a) incidents are assessed according to risk;
• (b) not every outage is a Personal Data breach;
• (c) notification depends on Applicable Law and contract;
• (d) external providers may be involved;
• (e) confidential security information may be withheld;
• (f) Developers have independent incident-response obligations;
• (g) credential security remains a shared responsibility; and
• (h) incident communications may be updated as facts become available.

• Policy Name: StampMitra Incident & Breach Notification Procedure
• Policy Number: 18 of 19
• Version: 1.0
• Effective Date: 05 October 2026
• Last Updated: 05 October 2026
• Operator: BANI GLOBAL INDUSTRIES LLP
• LLPIN: ACI6373
• Legal Contact: [email protected]
• Prepared By: Legal Team, BANI GLOBAL INDUSTRIES LLP
• Status: FINAL — PUBLISHED POLICY