Haripay INDIA PRIVATE LIMITED

This Policy establishes the framework for maintaining critical business operations and recovering technology, transaction, customer-support and other essential services following disruption, disaster, cyber incident, partner outage or other business interruption.

• Protect customers and critical business processes.
• Reduce downtime and operational impact.
• Define continuity and recovery responsibilities.
• Maintain critical data and systems through appropriate backup arrangements.
• Coordinate with key partners and vendors.
• Test recovery capability and improve resilience.

This Policy applies to critical business processes, technology systems, applications, APIs, transaction processing, customer support, settlement/reconciliation, key vendors, PPI/bank/payment partners, facilities, personnel and information required for Haripay operations.

• Cybersecurity incident
• System/application failure
• Cloud or hosting outage
• Network/telecommunication failure
• Power or facility disruption
• Payment/PPI/bank partner outage
• Critical vendor failure
• Data corruption/loss
• Natural or other physical disaster
• Key-personnel unavailability

• Customer support and grievance handling
• Transaction/order processing
• Gift-card/voucher issuance and status management
• Partner/API connectivity
• Payment and settlement operations
• Reconciliation and financial controls
• Fraud/risk monitoring
• Information security and incident response

Critical processes shall be assessed for customer impact, financial impact, regulatory/contractual impact, operational dependency, data loss and recovery requirements.

Recovery priority shall be based on business criticality, customer impact, transaction dependency, security risk, contractual obligations and management assessment.

Appropriate Recovery Time Objectives (RTO) and Recovery Point Objectives (RPO) shall be defined for critical systems where practicable. Objectives shall be proportionate to business and technology risk.

• Critical data shall be backed up according to risk and system requirements.
• Backups shall be protected from unauthorised access.
• Backup restoration shall be tested periodically where appropriate.
• Critical backup failures shall be investigated.

1. Identify affected systems.
2. Contain security risks.
3. Restore infrastructure/application components.
4. Restore trusted data.
5. Validate system integrity.
6. Test critical functions.
7. Reconnect partners/APIs.
8. Approve return to normal operations.

Where technology services are unavailable, approved manual or alternate procedures may be used for critical activities where feasible, with appropriate controls and later reconciliation.

Critical PPI issuers, banks, payment processors, cloud providers and vendors shall be assessed for continuity arrangements where their failure could materially affect Haripay.

A disruption communication process shall identify internal escalation, partner coordination, customer communication and management reporting responsibilities. External communications shall be issued only by authorised personnel.

• Material customer impact
• Critical system outage
• Significant transaction disruption
• Settlement/reconciliation interruption
• Cybersecurity incident
• Extended partner outage
• Potential regulatory/contractual impact

Management may activate a crisis-management structure for material disruptions and designate an incident/continuity coordinator responsible for coordinating response and recovery.

• Management – strategic decisions and crisis oversight
• Operations – business process continuity
• Technology – system recovery
• Information Security – cyber containment and secure recovery
• Finance – settlement/reconciliation continuity
• Compliance – regulatory/contractual coordination
• Customer Support – customer communications
• Partner Management – external partner coordination

Where required, approved remote or alternate working arrangements may be used, subject to information-security, access-control and data-protection requirements.

Emergency access shall be limited, authorised, logged and reviewed after normal operations resume. Privileged emergency credentials shall be protected.

Recovered systems and data shall be validated before being returned to production. Suspected corrupted or compromised data shall not be treated as trusted until appropriately reviewed.

1. Confirm recovery criteria.
2. Validate systems and data.
3. Confirm partner connectivity.
4. Reconcile transactions and financial records.
5. Remove temporary emergency controls.
6. Document outstanding issues.
7. Obtain management closure approval.

Transactions, payments, refunds, redemptions, settlements and other relevant records processed during or immediately before the disruption shall be reconciled after recovery.

• Tabletop exercises
• Backup restoration tests
• System recovery tests
• Partner communication drills
• Cyber incident simulations
• Manual process tests

Testing results shall be documented and material weaknesses shall have corrective actions.

Continuity plans, contact lists, system dependencies and recovery procedures shall be updated following material changes, incidents and testing outcomes.

Material dependencies on single vendors, payment processors, PPI issuers, banks or technology platforms shall be documented and appropriate contingency measures considered.

• Business impact assessments
• Continuity plans
• Recovery procedures
• Backup/testing records
• Exercise reports
• Incident logs
• Partner communications
• Recovery approvals
• Post-event reviews

Material disruptions shall be reviewed after recovery to identify root causes, control gaps, recovery performance, lessons learned and improvement actions.

Personnel with continuity or recovery responsibilities shall understand their roles and participate in relevant exercises or training.

Business continuity and disaster recovery controls may be reviewed through internal audits, testing, partner assessments and management reviews.

Exceptions shall be documented, risk-assessed and approved by authorised management. Mandatory legal, regulatory or contractual requirements shall not be bypassed.

This Policy shall be reviewed at least annually and whenever there is a material change in systems, business processes, partner dependencies, critical vendors or applicable requirements, and after material disruptions.