Business Continuity Plan (BCP)

1.     Introduction

The Business Continuity Plan (“BCP”) of HashMove Inc. (“HashMove”) establishes the framework and procedures designed to ensure the resilience, continuity, and timely recovery of its critical business operations and SaaS platform in the event of a disruption.

This BCP is intended to:

• safeguard the availability and integrity of HashMove’s services;
• minimize operational and service impact during unforeseen incidents;
• enable rapid restoration of critical systems and business functions; and
• ensure continued service delivery to customers in accordance with applicable service commitments.

‍

The scope of this BCP includes all systems, infrastructure, personnel, and processes that support HashMove’s SaaS-based logistics platform and associated services.

In the event of a disruption—whether due to system failures, cyber incidents, natural disasters, or other unforeseen events—this BCP provides structured guidance for incident response, escalation, communication, and recovery. It defines the roles and responsibilities of designated personnel and outlines the procedures required to restore normal operations within defined recovery objectives.

This document is aligned with industry best practices for SaaS and cloud-based service providers and is periodically reviewed, tested, and updated to ensure ongoing effectiveness and compliance with evolving operational and regulatory requirements.
‍

2. Business Continuity Management Framework

HashMove is committed to maintaining the resilience and continuous availability of its critical business operations and SaaS platform for its customers and stakeholders.

HashMove’s Business Continuity Management System (“BCMS”) is designed in alignment with internationally recognized standards, including ISO 22301, and incorporates industry best practices applicable to cloud-based SaaS platforms. The BCMS establishes a structured approach to identifying, managing, and mitigating risks that may impact service availability.

To ensure ongoing effectiveness and operational readiness, HashMove:

• conducts periodic Business Continuity and Disaster Recovery (“BCP/DR”) drills with documented and auditable outcomes;
• performs post-incident reviews and integrates lessons learned into continuous improvement initiatives;
• regularly reviews and updates continuity strategies, recovery procedures, and control frameworks.

This BCP operates in conjunction with HashMove’s broader corporate policies and is intended to:

• minimize disruption to services and operations;
• protect customer data and system integrity;
• ensure timely recovery of critical services within defined recovery objectives; and
• maintain transparent communication with internal and external stakeholders during incidents.
  ‍

3. Business Continuity Strategy

HashMove’s continuity strategy is designed to ensure the sustained delivery of its SaaS services in the event of technical failures, infrastructure outages, cyber incidents, or other disruptions.

Given the cloud-native architecture of HashMove’s platform, the strategy emphasizes:

• high availability through distributed infrastructure;
• automated failover and redundancy mechanisms;
• rapid recovery and restoration of services with minimal manual intervention.

The continuity approach is supported by proactive monitoring, automated recovery workflows, and predefined escalation procedures to ensure timely incident response and resolution.
‍

4. Preventive Controls and High Availability Architecture

HashMove implements a multi-layered architecture to ensure service resilience, scalability, and fault tolerance.

a. Cloud Infrastructure

HashMove’s applications are deployed on leading cloud platforms (e.g., AWS and/or Microsoft Azure), leveraging:

• multi-region and multi-availability zone deployments;
• geographically distributed infrastructure to mitigate localized failures;
• built-in cloud redundancy and failover capabilities.

b. Traffic Management and Load Balancing

HashMove utilizes highly available load balancing mechanisms to:

• distribute incoming traffic across multiple application instances;
• prevent single points of failure;
• ensure optimal system performance and scalability under varying load conditions.

c. Application Layer Resilience

Application services are deployed using clustered and horizontally scalable architectures, enabling:

• automatic failover in case of node-level failures;
• load distribution across multiple instances;
• seamless scaling during peak usage periods.

Capacity buffers and auto-scaling configurations are maintained to ensure consistent performance and availability.

d. Data Layer and Database Resilience

The data layer is designed with high availability and durability in mind, including:

• clustered and replicated database configurations;
• automated backup and recovery mechanisms;
• performance optimization to support high transaction volumes.

Data integrity and availability are continuously monitored to ensure reliability during both normal operations and disruption scenarios
‍

5. Recovery Prioritization and Execution

HashMove adopts a risk-based approach to recovery prioritization, focusing on restoring services that are critical to business operations and customer impact.

Recovery execution is managed by designated Technology and DevOps teams in accordance with predefined procedures and escalation protocols.

Key principles include:

• prioritization of mission-critical services and high-impact customer environments;
• restoration of core platform functionality before non-critical components;
• adherence to defined recovery objectives and service commitments.

HashMove maintains and periodically updates:

• an inventory of critical services and system dependencies;
• customer impact assessments to guide prioritization decisions;
• internal runbooks and recovery playbooks to ensure consistent and efficient execution.
  ‍

6. Scope – Critical Systems and Processes

• Application systems and services
• Database systems
• Network infrastructure
• Server and compute infrastructure
• Data storage and backup systems
• Integration platforms and APIs
• Cloud infrastructure (e.g., AWS, Microsoft Azure)

Exclusions:

This document does not cover business continuity procedures for operational teams, administrative functions, or non-technology processes. Such areas are addressed in separate, process-specific BCP documents.
‍

7. BCP / Disaster Recovery (DR) Testing and Assurance

HashMove maintains a structured testing program to validate the effectiveness of its Business Continuity and Disaster Recovery capabilities.

a. Drill Frequency

• BCP/DR drills are conducted on a semi-annual basis at a minimum.
• Additional scenario-based tests may be performed as required.

b. Types of Drills

• Simulation (Soft) Drills:

Periodic restoration of recent database backups and file systems in a controlled environment to validate recoverability and data integrity.

• Scenario-Based Testing:

Validation of recovery procedures against predefined disruption scenarios (e.g., application failure, database outage, infrastructure disruption).

c. Reporting and Continuous Improvement

• All drills are documented with auditable reports, including outcomes, gaps identified, and corrective actions.
• Summary reports may be shared with customers upon request.
• Lessons learned are incorporated into ongoing improvements of the BCP/DR framework.
  ‍

8. Recovery Objectives

HashMove defines recovery targets to ensure timely restoration of services:

• Recovery Time Objective (RTO): Up to 4 hours for critical systems
• Recovery Point Objective (RPO): Up to 24 hours data loss tolerance

These objectives apply to major disruption scenarios unless otherwise specified in customer agreements or SLAs.

9. Recovery Procedures for Critical Scenarios

HashMove maintains documented recovery playbooks for key disruption scenarios.

a. Complete System Failure

While highly unlikely due to distributed, multi-availability zone architecture, a complete system failure scenario is addressed through:

• restoration from latest available backups and transaction logs;
• • failover to alternate infrastructure environments;
• • activation of incident management and recovery teams.

Recovery Targets:

• RTO: 4 hours
• RPO: 24 hours

During such events, applicable service levels may be temporarily impacted until restoration is completed.

b. Application-Level Failure

Scenario: Failure or malfunction of application services.

Response Actions:

• restore application configurations from recent backups;
• redeploy services across healthy nodes;
• validate system functionality and performance.

Recovery Targets:

• BCP Activation Time: ~15 minutes
• RTO: 4 hours
• RPO: 24 hours

c. Database Failure

Scenario: Partial or complete database disruption.

Partial Failure (e.g., corruption, data loss):

• targeted restoration from backup and logs;
• validation of data integrity.

Complete Failure:

• full database restoration and failover procedures.

Recovery Targets:

• RTO: 4 hours
• RPO: 24 hours

d. Recovery Locations and Infrastructure

• Primary Infrastructure: Cloud platforms (AWS / Microsoft Azure)
• Recovery Execution Teams:
  • DevOps / Cloud Operations
  • Database Administration (DBA)
  • Application Support Teams
    ‍

10. Incident Management and Escalation

HashMove follows a structured incident management framework to ensure timely detection, escalation, and resolution.

a. Incident Reporting

• All incidents are logged through designated support channels (e.g., ticketing systems such as Zendesk).
• Critical incidents are escalated immediately to relevant technical and leadership teams.

b. Incident Command and Governance

• Incident severity is assessed by Technology, DevOps, and Service Delivery teams.
• The Information Security (CISO) function oversees cybersecurity-related incidents.
• A centralized command structure ensures coordinated response and decision-making.

c. Activation of BCP

• BCP/DR procedures are activated based on severity, impact, and recovery requirements.
• Stakeholders are notified in accordance with the communication plan.
  ‍

10A. Activation Criteria

The BCP shall be activated where:

• A Severity 1 (Critical) incident occurs;
• There is a material disruption to core platform services; or
• Standard incident response procedures are insufficient to restore service within defined recovery objectives
  ‍

11. Communication Management

Clear and timely communication is a critical component of HashMove’s continuity framework.

a. Client Communication

Clients are informed of:

• service impact and affected functionalities;
• expected recovery timelines;
• any potential data or security implications.

b. Communication Channels (in order of preference):

1. Corporate email systems
2. Alternate email channels
3. Telephone (mobile and landline)

c. Partner Communication

• Critical partners are notified promptly and engaged for support where required.
• Vendor continuity plans may be activated where dependencies exist.

d. Internal and Stakeholder Communication

• Internal stakeholders are updated regularly on incident status and recovery progress.
• Executive-level reporting is conducted for major incidents.
  ‍

12. Post-Incident and Recovery Activities

Following restoration of services, HashMove conducts structured post-incident activities, including:

• confirmation of full service restoration and return to normal operations;
• root cause analysis (RCA) and incident reporting;
• assessment of SLA impact and customer communication;
• identification and implementation of corrective actions;
• updates to BCP documentation and controls, where required.
  ‍

13. Documentation and Governance

The following supporting documents are maintained as part of the BCMS framework:

• Business Impact Analysis (BIA)
• Risk Assessments and Recovery Plans
• Standard Operating Procedures (SOPs) for critical processes
• Incident Response Procedures
• BCP/DR Drill Reports and Evidence
• Incident Reports and Root Cause Analyses
• Critical Contact Lists and Escalation Matrices
  ‍

14. Acronyms and Definitions

• BCP: Business Continuity Plan
• BCM: Business Continuity Management
• DR: Disaster Recovery
• RTO: Recovery Time Objective
• RPO: Recovery Point Objective
• BIA: Business Impact Analysis
• CISO: Chief Information Security Officer
• DBA: Database Administrator
• ERT / CMT: Emergency / Crisis Management Teams
  ‍

15. Version Control and Review

This BCP is reviewed and updated at least annually or upon significant changes to infrastructure, operations, or risk environment.

16. Nature of Commitments

HashMove shall implement and maintain the measures described in this Business Continuity Plan using commercially reasonable efforts and in alignment with applicable service commitments.

Nothing in this BCP shall be construed as creating service level commitments beyond those expressly defined in the applicable Service Level Agreement (SLA).
‍

17. Other Agreements

This BCP shall operate in conjunction with:

• The Service Level Agreement (SLA)
• The Information Security Policy
• Applicable Subscription Agreements

In the event of any conflict:

• The SLA shall prevail in relation to service performance and availability
• The Information Security Policy shall prevail in relation to security controls
  ‍

18. Third-Party Dependencies

HashMove’s continuity capabilities rely on third-party service providers, including cloud infrastructure providers.

HashMove shall:

• Select reputable providers
• Monitor their performance

However, HashMove shall not be liable for failures caused by third-party providers beyond its reasonable control, subject to applicable contractual obligations.
‍

19. Force Majeure

Events triggering BCP activation may constitute Force Majeure events under applicable agreements.

Performance obligations during such events shall be governed by the relevant contractual provisions.