Cybersecurity and Cyber Law Policy

1Purpose, ownership and scope

1.1GABBAR Exchange is a brand and platform owned and operated by Pipscapital Pvt Ltd. Our technology is powered by Pips Forex Technology. Pipscapital Pvt Ltd remains responsible for the customer-facing commitments and controls described in this policy.

1.2This policy explains how we govern cybersecurity, protect systems and information, respond to cyber incidents and support compliance with applicable Indian cyber law. It applies to GABBAR websites, applications, APIs, administrative systems, wallets, internal networks, cloud environments, data stores, customer-support systems and material third-party services.

1.3This policy applies to directors, employees, contractors, temporary personnel, service providers and other persons who access GABBAR information or systems. Contractual and internal procedures may impose more detailed or stricter requirements than this public policy.

1.4Cybersecurity is a shared responsibility. We implement controls proportionate to risk, but no internet-connected system, blockchain network or security control can eliminate every possibility of compromise, interruption, fraud or loss. Customers must follow the security duties in Section 13 and the Terms and Conditions.

1.5Product-specific security rules, the Privacy Policy, AML/KYC Policy, Risk Disclosure, incident procedures and contractual requirements operate together with this policy. If mandatory law imposes a higher or different standard, the mandatory requirement prevails.

2Applicable cyber-law framework

2.1We design and operate our cyber controls with regard to laws, rules, directions and binding orders that apply to our activities, including the Information Technology Act, 2000 and amendments made from time to time.

2.2We maintain processes intended to support applicable directions issued by the Indian Computer Emergency Response Team under section 70B of the Information Technology Act, including requirements concerning time synchronisation, preservation of ICT logs, cyber-incident reporting and cooperation with CERT-In.

2.3Where applicable to our processing, we address personal-data security and breach obligations under the Digital Personal Data Protection Act, 2023 and rules or commencement notifications brought into force from time to time. The Privacy Policy explains our broader processing practices and customer rights.

2.4We also consider applicable obligations concerning electronic records, unauthorised access, identity theft, impersonation, fraud, harmful code, confidentiality, intermediary responsibilities, law-enforcement cooperation and preservation of evidence.

2.5A reference to legislation includes its amendments, replacements, subordinate rules and binding directions. This policy does not represent that every cited provision applies to every service, nor does it limit a duty arising under another applicable law or authority order.

2.6Compliance with a reporting or registration requirement is not a representation that any authority guarantees GABBAR, customer assets, digital assets, transactions or investment outcomes.

3Governance and accountability

3.1Management oversees cyber risk and assigns accountable owners for security, technology, privacy, compliance, incident response and business continuity. Material cyber risks, incidents and unresolved control weaknesses are escalated according to severity.

3.2Security responsibilities are separated where practicable. A person who develops or requests a sensitive change should not be the only person able to approve, deploy and conceal that change. Privileged financial, wallet and administrative actions require additional safeguards proportionate to their impact.

3.3We maintain documented standards and procedures for access control, secure development, vulnerability management, backups, incident response, evidence preservation, third-party risk and recovery. Confidential technical procedures are not published where disclosure could weaken security.

3.4Material systems and data are assigned owners. Owners classify criticality, approve authorised use, review access, address identified risks and ensure that recovery and retention requirements are defined.

3.5Employees and contractors must promptly report suspected security events, policy violations, lost devices, exposed credentials, suspicious communications and control failures through approved channels. Good-faith reporting must not be suppressed or retaliated against.

4Cyber-risk management

4.1We identify and assess threats to confidentiality, integrity, availability, authenticity and accountability. Assessments consider customer harm, financial loss, market integrity, legal impact, service interruption, fraud, asset theft, data compromise and dependency failure.

4.2Risk assessment covers internet-facing applications, APIs, mobile or web clients, authentication, administrator access, databases, order and ledger services, wallets and signing systems, payment connections, support tools, cloud infrastructure and critical vendors.

4.3Controls are selected according to risk and may include prevention, detection, response, recovery, transfer or acceptance. Material residual risks require approval at an appropriate level and are reviewed when systems, threats, products or law change.

4.4We maintain asset and service inventories proportionate to the environment. Unsupported or unapproved assets, services and software may be blocked, isolated, upgraded or retired.

4.5Threat intelligence, advisories, incidents, penetration tests, vulnerability reports and observed fraud patterns inform risk decisions. We prioritise remediation based on exploitability, exposure, affected assets and potential customer impact rather than severity labels alone.

5Identity, authentication and access control

5.1Access is granted for a legitimate business purpose, limited to what the role requires and removed when no longer needed. Joiner, role-change and departure processes address account creation, modification, revocation and recovery of company assets.

5.2Privileged, production, wallet, database and security-tool access receives stronger controls. Measures may include multi-factor authentication, managed devices, network restrictions, just-in-time access, approval workflows, session recording, command or activity logging and periodic recertification.

5.3Shared accounts are avoided where individual accountability is reasonably possible. Service accounts and machine credentials must have defined owners, limited permissions, protected secrets and monitored use.

5.4Passwords, API secrets, private keys, seed phrases, recovery codes and authentication tokens must not be stored in source code, public repositories, ordinary chat, unsecured notes or other unapproved locations. Secrets are rotated when exposure is suspected and according to risk-based schedules.

5.5Customer authentication controls may include password requirements, one-time codes, authenticator applications, device or session checks, withdrawal verification and risk-based challenges. We may delay or restrict sensitive activity when compromise is suspected.

5.6Account recovery requires verification proportionate to the requested change and associated risk. Support personnel must not request a customer’s password, private key, seed phrase or complete one-time authentication code.

6Secure engineering and change management

6.1Security requirements are considered during design, development, testing, deployment and retirement. Sensitive functions must enforce authorisation on trusted server-side components and must not rely solely on hidden buttons or client-side validation.

6.2Code and configuration changes follow documented review, testing and approval processes proportionate to risk. Emergency changes are recorded, reviewed after deployment and reversed or corrected if they produce unacceptable risk.

6.3Development, test and production environments are separated where practicable. Production data is not copied into lower environments unless necessary, authorised and protected with equivalent or compensating controls.

6.4We use vulnerability detection methods appropriate to the system, which may include dependency scanning, static or dynamic testing, infrastructure review, code review, penetration testing and independent security assessment.

6.5Vulnerabilities are triaged and remediated according to severity, exposure and credible exploitation. Internet-facing critical weaknesses and actively exploited issues receive expedited containment or correction. When immediate correction is not possible, we apply documented compensating controls and monitor the risk.

6.6APIs must use authentication, authorisation, input validation, rate controls, secure error handling and monitoring proportionate to their sensitivity. Unique transaction and operation references support traceability and safe handling of repeated requests.

6.7Releases affecting balances, order matching, withdrawals, authentication, permissions or audit records require additional validation. A user-interface success message must not substitute for authoritative server and ledger confirmation.

7Infrastructure, wallet and cryptographic security

7.1Systems are configured to reduce unnecessary exposure. We apply secure configuration, patch management, network controls, endpoint protection, encryption and hardening appropriate to system purpose and risk.

7.2Sensitive information is protected in transit and at rest where appropriate. Cryptographic algorithms, key sizes and protocols are selected according to accepted security practice and are reviewed as standards and threats change.

7.3Wallet and signing controls are designed according to transaction risk. Controls may include separation of hot and restricted storage, withdrawal limits, address controls, multi-person approval, hardware-backed key protection, transaction screening, reconciliation and emergency suspension.

7.4Private keys and seed material require tightly restricted access, secure generation, protected backup and documented recovery. No single control or person should create an avoidable single point of compromise for material customer assets.

7.5Administrative balance adjustments and other privileged financial mutations must be authenticated, authorised, uniquely referenced and recorded in tamper-resistant audit records. The financial operation and required audit evidence should succeed or fail consistently so that a reported error does not conceal a completed change.

7.6Network, blockchain, bridge, node, custodian or third-party wallet failures may create risks outside our direct control. We may pause deposits, withdrawals or another affected function while validating network safety and reconciling records.

8Monitoring, logs and threat detection

8.1We monitor systems and activity proportionate to risk for indicators such as unauthorised access, credential abuse, malware, unusual privilege use, anomalous transactions, data extraction, denial of service and control bypass.

8.2Relevant logs may include authentication, administrator activity, API access, wallet events, security alerts, system changes, application events, database actions and network records. Logs are protected against unauthorised alteration and access is restricted.

8.3ICT system clocks are synchronised to approved time sources as required by applicable CERT-In directions. Accurate time supports investigation, transaction reconstruction and coordination with authorities and service providers.

8.4We retain ICT logs securely for at least the period and in the jurisdiction required by applicable law or direction. Where the CERT-In Cyber Security Directions apply, relevant logs are maintained for a rolling period of at least 180 days within India, without limiting longer AML, transaction, tax, dispute or legal retention duties.

8.5Alerts are assessed according to documented criteria. High-risk events are escalated promptly, while repeated low-level events may be correlated to identify a wider attack.

8.6Monitoring is conducted for security, fraud prevention, compliance and service integrity. It is subject to access controls, retention rules and the Privacy Policy and is not used to justify indiscriminate access to personal information.

9Cyber-incident response and regulatory reporting

9.1We maintain an incident-response process covering preparation, identification, triage, containment, preservation, eradication, recovery, communication, reporting and post-incident improvement.

9.2Incidents are classified according to actual and potential impact on customers, assets, personal data, market integrity, critical services, legal obligations and public trust. Classification may change as new facts emerge.

9.3Response teams may isolate systems, revoke credentials, rotate secrets, suspend withdrawals or trading, block malicious traffic, preserve logs, engage specialists and take other proportionate actions needed to contain harm.

9.4We report applicable cyber incidents to CERT-In within the period prescribed by binding directions. Under the CERT-In Cyber Security Directions of 28 April 2022, specified incidents must be reported within six hours of noticing the incident or being informed of it. An initial report may be supplemented as reliable information becomes available.

9.5Reports and cooperation may include available indicators, affected systems, timing, impact, containment, logs and other information lawfully requested. We preserve evidence and maintain confidentiality so far as compatible with reporting, investigation and customer-protection duties.

9.6We coordinate with law enforcement, data-protection bodies, FIU-IND, payment or infrastructure providers and other competent authorities when the incident falls within their lawful remit. Reporting to one authority does not remove a separate duty to report elsewhere.

9.7After a material incident, we document the cause or contributing factors, decisions, impact, recovery, lessons and corrective actions. Actions are assigned owners and tracked according to risk.

10Personal-data and customer notification

10.1A personal-data breach includes unauthorised processing or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access that compromises confidentiality, integrity or availability, as defined by applicable data-protection law.

10.2We assess suspected breaches promptly, including the data and persons affected, likely consequences, continuing risks, containment, recovery and legal notification requirements.

10.3We notify affected persons and competent authorities when required by applicable law. Notices are based on available verified facts and may be updated. They may describe the incident, affected information, likely consequences, actions taken and practical steps customers should follow.

10.4Notification may be delayed, limited or coordinated where immediate disclosure would create additional security risk, prejudice a lawful investigation or conflict with an authority direction, but only to the extent permitted by law.

10.5We do not ask customers to disclose passwords, private keys, seed phrases or full authentication codes in response to an incident. Customers should verify communications through gabbarex.com and report suspicious messages to security@gabbarex.com.

11Third parties, cloud and supply-chain security

11.1Before relying on a material technology, cloud, wallet, payment, identity, communication or security provider, we assess risks relevant to the service. Review may cover security posture, access, data location, incident handling, resilience, subcontracting, audit rights and exit arrangements.

11.2Contracts allocate security, confidentiality, notification, cooperation, deletion or return of data and continuity responsibilities where appropriate. Contract language does not replace technical verification or ongoing oversight.

11.3Third-party access is limited to approved purposes and is removed when no longer required. Material provider incidents are assessed under our incident process even when the affected infrastructure is not directly operated by us.

11.4We manage software and infrastructure dependencies proportionate to risk, including component inventory, version monitoring, vulnerability response and controls for build and deployment systems.

11.5Concentration and exit risks are considered for critical providers. Where reasonable, we maintain backups, alternatives, recovery arrangements or controlled shutdown procedures.

12Business continuity and recovery

12.1We identify critical services and define recovery priorities for customer authentication, asset records, ledgers, wallets, trading, withdrawals, support and security monitoring.

12.2Backups are protected according to the sensitivity of the data and are tested periodically for recoverability. Backup access and deletion rights are restricted to reduce the risk of ransomware or insider misuse.

12.3Recovery plans address technology failure, cyberattack, provider outage, loss of personnel, corrupted data and loss of normal operating premises or connectivity. Plans include internal and external communication responsibilities.

12.4Recovery does not mean restoring a service before it is safe. We reconcile authoritative balances, transactions, orders, permissions and audit records before resuming an affected financial function where the incident may have compromised integrity.

12.5Exercises and actual incidents are used to improve recovery procedures. Material gaps are assigned remediation owners and reviewed by management.

13Acceptable use and prohibited cyber conduct

13.1Customers must protect account credentials, enable available security controls, maintain secure devices, review transaction details and promptly report suspected compromise. A customer must not allow another person to use the account in violation of the Terms or applicable law.

13.2You must not attempt to gain unauthorised access, bypass authentication or limits, probe private systems, interfere with service availability, introduce malicious code, scrape contrary to published rules, manipulate APIs, conceal attack traffic or access another person’s data or assets.

13.3You must not use GABBAR for phishing, impersonation, credential theft, ransomware, malware distribution, unlawful surveillance, stolen data, fraud, laundering cybercrime proceeds or financing prohibited activity.

13.4Creating multiple accounts, automating requests or using VPNs, proxies, emulators or altered devices to evade security, eligibility, sanctions, rate or fraud controls is prohibited. Legitimate privacy or accessibility use does not authorise evasion of applicable controls.

13.5Security testing is permitted only under an expressly published vulnerability-disclosure programme or written authorisation and within its scope. Discovery of a vulnerability does not authorise access to customer data, movement of assets, persistence, service disruption, extortion or public disclosure that creates avoidable harm.

13.6We may restrict accounts, sessions, API credentials, withdrawals or other functions when necessary to investigate or contain a suspected cyber threat, subject to the Terms and applicable law.

14Evidence, lawful requests and cooperation

14.1We preserve relevant records when an incident, dispute, investigation, legal hold or authority request requires it. Evidence handling aims to protect integrity, chronology, access history and lawful admissibility.

14.2We assess requests from law-enforcement and competent authorities for legal validity, scope and authenticity. We may seek clarification, narrow an overbroad request or challenge it where appropriate and lawful.

14.3We disclose information only to the extent required or permitted and use secure channels where reasonably available. We may be prohibited from notifying an affected customer about a request or investigation.

14.4We may share indicators of compromise, malicious addresses, attack infrastructure or relevant incident information with authorities, providers or security partners when lawful and reasonably necessary to protect systems, customers or the public.

14.5Nothing in this policy requires us to disclose confidential security architecture, detection rules, private keys, protected reports or information that could facilitate an attack.

15Vulnerability disclosure and security research

15.1Security researchers should report suspected vulnerabilities privately to security@gabbarex.com with a clear description, affected location, reproduction steps and non-sensitive evidence.

15.2Do not include passwords, private keys, seed phrases, unnecessary personal data or customer funds in a report. If you encounter personal information, stop testing, do not retain or share it and explain the limited access in the report.

15.3We acknowledge and triage reports according to severity and available information. We may request clarification, coordinate remediation and communicate when a verified issue has been addressed, but we do not promise a reward unless a written programme expressly provides one.

15.4Public disclosure should be coordinated so that we have a reasonable opportunity to validate and remediate the issue and protect customers. This request does not prevent legally protected reporting to an authority.

15.5A vulnerability report does not excuse unlawful access, data extraction, threats, extortion, asset movement, denial of service, social engineering or violation of another person’s rights.

16Training, assurance and policy review

16.1Personnel receive security and privacy training appropriate to their responsibilities. Higher-risk roles receive additional instruction on privileged access, secure development, fraud, incident handling, evidence, wallets or customer support.

16.2We conduct security assessments proportionate to risk. These may include internal control review, penetration testing, vulnerability assessment, recovery exercises, access review and independent audit by appropriately qualified or empanelled assessors where required.

16.3Findings are documented, risk-ranked, assigned and tracked. Closure requires evidence proportionate to the finding, and material corrections may be re-tested.

16.4We review this policy after material legal, threat, business or technology change and periodically even when no major change occurs. Earlier versions and relevant acceptance records are retained as needed to establish which policy applied.

16.5Metrics may include vulnerabilities, patching, access reviews, security events, incident response, recovery testing, phishing resistance, vendor findings and overdue remediation. Metrics support improvement and must not be manipulated to conceal risk.

17Enforcement, exceptions and contact

17.1Violations may result in removal of access, disciplinary action, contract remedies, account restriction, transaction review, reporting to competent authorities or legal action, depending on the facts and applicable law.

17.2A security exception must identify the requirement, business reason, risk, compensating controls, owner and expiry or review date. An exception cannot waive a mandatory legal obligation.

17.3Report suspected account compromise, phishing, fraud, data exposure, security incidents and vulnerabilities to security@gabbarex.com. General platform support is available at support@gabbarex.com, privacy questions at privacy@gabbarex.com and complaints at complaints@gabbarex.com.

17.4Do not send passwords, private keys, seed phrases, full one-time codes or unnecessary personal information by email. Preserve relevant transaction IDs, timestamps, addresses, messages and screenshots where safe to do so.

17.5We may update this policy to address changes in law, threats, technology, products or controls. Material changes will be published or communicated as required by applicable law.

17.6Official legal references include the Information Technology Act, 2000 and applicable rules and amendments; CERT-In directions issued under section 70B; and the Digital Personal Data Protection Act, 2023 and applicable rules or commencement notifications. Readers should consult the current official publications because these instruments may change.