Enterprise SLA Policy

1. Introduction

The HashMove Enterprise Service Level Agreement (“SLA”) outlines the service standards, support framework, and operational commitments provided to customers utilizing HashMove’s cloud-based enterprise solutions. This SLA is designed to ensure reliable performance, availability, security, and continuous optimization of the HashMove platform and associated applications.

HashMove provides a comprehensive support and operations framework combining technical expertise, operational oversight, and proactive monitoring to ensure reliable system performance, timely issue resolution, and minimal disruption to business operations. This enables customers to focus on their core business activities while leveraging a scalable and dependable digital infrastructure.

This SLA forms part of the governing Customer Agreement. In the event of conflict, the Customer Agreement shall prevail unless otherwise agreed in writing.
‍

2. Scope and Applicability

This SLA applies to all Customers with an active subscription to HashMove products and services. It governs:

• Incident management and support services
• Service requests and operational assistance
• Platform availability and uptime commitments
• Escalation procedures and service credits

Unless explicitly agreed in writing, this SLA does not cover product customization, new feature development, or professional services.
‍

3. Definitions

• Incident: An unplanned interruption to a service, degradation in service quality, or failure of a component impacting normal operations.
• Service Request: A request for information, assistance, or standard administrative action (e.g., user access, configuration guidance).
• Change Request: A formally documented request to add, modify, or remove functionality or configuration.
• Support Ticket: A record created to track Incidents, Service Requests, or Change Requests.
• Response Time: Time between ticket submission and initial acknowledgment.
• Resolution Time: Time required to restore service or provide a reasonable workaround.
• Software Release Cycle (SRC): Process and timeframe for deploying fixes, patches, or enhancements.
  ‍

4. Support Coverage and Channels

4.1 Coverage

• Severity 1 (Critical): 24×7×365 support coverage
• Severity 2–4: Support during Business Hours (unless otherwise agreed in writing)

4.2 Business Hours Definition

Business Hours are defined as 9:00 AM to 6:00 PM, Monday to Friday, Customer local time, excluding public holidays, unless otherwise agreed in writing.

4.3 Support Channels

• Support Portal: https://support.hashmove.com
• Email: support@hashmove.com

All requests are logged in the support system and assigned a unique ticket ID for tracking and communication.

4.4 Support Scope

HashMove provides support for:

• Platform incidents and operational issues
• Service requests and administrative actions
• Investigation and resolution of system-related issues

The following are out of scope of standard SLA support unless otherwise agreed:

• Product enhancements and feature development
• Custom integrations and project-based work

4.5 Support Ticket Submission and Management

Customers may submit Incidents, Service Requests, or Change Requests through the HashMove Support Portal at: https://support.hashmove.com

To submit a request via the Support Portal, the Customer must:

• Activate their support account and log in
• Select “New Support Ticket”
• Provide the subject, description, and any relevant supporting information or attachments

Upon submission, a support ticket will be created and assigned a unique reference number for tracking and communication.

Through the Support Portal, Customers may:

• Track the status of requests
• Add comments or additional information
• Upload attachments
• Communicate with HashMove support personnel

Customers will receive notifications upon updates and resolution of the support ticket.

If the Customer is not satisfied with the resolution, the ticket may be reopened within forty-eight (48) hours of closure via the Support Portal or by referencing the ticket ID in a new support request.
‍

5. Incident Severity and Service Targets

5.1 Priority Levels and Incident Severity Definitions

HashMove classifies support tickets based on priority levels that reflect the severity of the issue and its impact on business operations.

P1 – Critical

A Critical incident represents a complete system outage or failure of core functionality preventing normal system operation, with no available workaround. The issue affects all or a majority of users.

Typical examples include:

• Full platform unavailability
• Failure of critical transaction processing
• Major system disruption preventing business operations

P2 – High

A High priority incident indicates that a major function of the system is significantly impaired, resulting in substantial business impact. The system remains operational but with limited functionality.

Examples include:

• Failure of a major module or workflow
• Significant degradation in performance
• Issues impacting a large group of users

P3 – Medium

A Medium priority incident refers to issues affecting non-critical functionality where the system remains operational and a temporary workaround is available.

Examples include:

• Functional issues with limited operational impact
• Errors affecting a small group of users
• Performance degradation with available alternatives

P4 – Low

A Low priority case includes general service requests, informational inquiries, cosmetic issues, or enhancement requests that do not affect system functionality.

Examples include:

• General questions or guidance requests
• Minor user interface issues
• Requests for enhancements or improvements

Ticket Classification

HashMove Support will perform initial triage and assign the appropriate priority level based on the validated business impact of the issue, in consultation with the Customer.

Priority levels may be reclassified during the resolution process as additional information becomes available.
‍

5.2 Response and Resolution Targets

Note: Resolution targets may be satisfied through restoration of service to a usable state (via fix or workaround). Permanent fixes may be delivered through the Software Release Cycle.
‍

6. Incident Management

HashMove shall use commercially reasonable efforts to meet the service levels set forth in this SLA.

6.1 Ticket Classification

HashMove Support will perform initial triage and assign severity based on business impact, in collaboration with the Customer.

6.2 SLA Measurement

SLA timelines apply only to HashMove-controlled activities and exclude delays caused by:

• Awaiting customer input, validation, or approvals
• Customer-side infrastructure or configuration issues
• Third-party systems or integrations

SLA measurement will pause during such periods and resume once dependencies are resolved.

Severity levels may be reclassified by HashMove based on validated business impact, in consultation with the Customer.
‍

7. Root Cause Analysis (RCA)

For applicable incidents, HashMove will conduct a Root Cause Analysis (RCA) to identify underlying causes and prevent recurrence.

RCA may be delivered:

• At the time of resolution; or
• Separately if extended investigation is required

A reference ID (e.g., ticket or tracking ID) will be provided for ongoing tracking where applicable.
‍

8. Escalation Matrix and Process

Escalation Process

1. Submit request via support channel
2. Escalate if response/resolution targets are not met
3. Higher levels coordinate with technical teams for resolution
   ‍

9. Platform Availability and Downtime

9.1 Uptime Commitment

HashMove commits to 99.5% monthly uptime for production environments. SLA commitments apply to production environments and core platform functionality.

9.2 Uptime Measurement

Uptime is measured based on HashMove monitoring systems and may be corroborated by Customer-reported incidents.

9.3 Downtime Definition

Downtime is any period during which the production environment is not accessible or materially fails to perform, including significant degradation of core functionality.

Downtime:

• Measured in minutes
• Starts at monitoring detection or customer notification
• Excludes scheduled maintenance and SLA exclusions
  ‍

10. Scheduled Maintenance

Scheduled maintenance refers to planned service updates, upgrades, or maintenance activities that may impact availability.

• Maintenance will be scheduled during off-peak hours where reasonably possible
• Customers will be provided at least 48 hours prior notice, unless urgent maintenance is required
• Scheduled maintenance is excluded from uptime calculations
  ‍

11. SLA Exclusions

The SLA commitments set forth in this Agreement shall not apply to any service interruptions, performance degradation, or availability issues resulting from the following circumstances:

• Scheduled Maintenance
  Periods of planned maintenance or scheduled downtime that have been communicated to Customers in advance.
  ‍
• Third-Party Applications or Integrations
  Performance or availability issues related to third-party applications, integrations, infrastructure providers, or add-on services, including cloud infrastructure providers and telecommunications networks.
  ‍
• Customer Infrastructure or Environment
  Issues arising from the Customer’s hardware, network infrastructure, software systems, internet connectivity, or other third-party services not controlled by HashMove.
  ‍
• Customer Actions or Misuse
  Issues resulting from actions or omissions by the Customer, including the activities of its employees, agents, contractors, vendors, or any individuals accessing the service using Customer credentials.
  ‍
• Failure to Follow Recommended Practices
  Issues resulting from the Customer’s use of the service in a manner inconsistent with HashMove’s documented recommendations, configurations, or operational guidance.
  ‍
• Non-Production Environments
  Downtime or performance issues associated with beta services, trial environments, early access programs, proof-of-concept deployments, or demonstration environments.
  ‍
• Force Majeure Events
  Events beyond HashMove’s reasonable control, including but not limited to natural disasters, acts of government, labor disputes, or widespread internet or infrastructure outages.
  ‍

12. Service Credits - Resolution SLA Violations

Service credits may be issued if HashMove fails to meet the resolution service levels defined in this SLA.

Service credits shall apply only where the overall monthly resolution SLA compliance falls below ninety percent (90%) for the applicable calendar month.

Conditions

To qualify for service credits:

• The Customer must be in good standing and not in material breach of the applicable agreement.
• The Customer must submit a service credit request within thirty (30) days following the end of the applicable month.
• The Customer must provide reasonable supporting details to enable validation of the claim.

HashMove will review all reasonably available information to determine whether the reported incident qualifies as an SLA breach.

If validated, the applicable service credit will be applied to the Customer’s subsequent invoice, up to a maximum amount equivalent to the monthly subscription fee for the affected service.

Service credits constitute the sole and exclusive remedy for any failure by HashMove to meet the service levels set forth in this SLA.
‍

13. Service Credits - Uptime SLA Violations

If the monthly uptime of the HashMove SaaS platform falls below the committed service availability, the Customer may be eligible to receive service credits as set forth below. Service credits shall be applied to the Customer’s subsequent billing cycle.

13.1 Uptime-Based Service Credits

13.2 Conditions and Limitations

• Uptime is calculated on a monthly basis and excludes scheduled maintenance windows that are communicated in advance.
• Service credits represent the sole and exclusive remedy for any failure by HashMove to meet the uptime commitment under this SLA.
• Customers must submit a service credit request within thirty (30) days following the end of the applicable month in which the uptime violation occurred.
• Service credits shall be applied only after validation of the claim by HashMove and will be reflected in the Customer’s subsequent invoice.
• Service credits shall not exceed one hundred percent (100%) of the monthly subscription fee for the affected service.
  ‍

14. Support Request Requirements

Customers should provide:

• Clear description of the issue
• Steps to reproduce (if applicable)
• Logs, screenshots, or supporting documentation

Providing complete information enables efficient investigation and resolution.
‍

15. Resolution Criteria

A request is considered resolved when:

• Service is restored to a usable state (via fix or workaround)
• Issue is identified as external with guidance provided
• Customer confirms resolution
• Customer is unresponsive after three (3) reasonable follow-up attempts over a defined period

Each issue must be logged as a separate ticket.
‍

16. Remote Access

Where required, HashMove may request secure remote access to Customer systems solely for troubleshooting and resolution purposes, subject to applicable security and confidentiality requirements.
‍

17. Business Continuity and Disaster Recovery

Business continuity and disaster recovery are governed under a separate HashMove BCP policy which is available online or upon customer request.
‍

18. Changes to SLA and Support Services

HashMove may periodically update or modify support processes and operational procedures to improve service delivery and platform performance.

Any material changes that impact support services or SLA commitments will be communicated to Customers in writing at least five (5) days in advance.

Non-material changes that do not adversely affect service levels may be implemented without prior notice.

Notwithstanding the foregoing, HashMove may implement immediate changes where required for operational integrity, security, or compliance purposes.
‍

19. Changes to Response Time Commitments

HashMove reserves the right to review and optimize response time targets from time to time in order to improve overall service delivery.

Any material changes to response time commitments will be communicated to the Customer at least thirty (30) days in advance and shall become effective only upon mutual written agreement between the parties.
‍

20. Regional Compliance and Deployment

20.1 Data Residency (KSA)

Where required by the Customer or applicable regulations, HashMove supports deployment within the Kingdom of Saudi Arabia, including hosting in KSA-based cloud regions or on-premise environments. Customer data shall be processed and stored in accordance with agreed deployment architecture and applicable regulatory requirements.

20.2 Regulatory Alignment (KSA)

HashMove security practices are designed to align with internationally recognized standards and relevant regional frameworks, including alignment principles with the Saudi National Cybersecurity Authority (NCA) Essential Cybersecurity Controls (ECC), where applicable.

20.3 Data Protection

HashMove processes Customer data in accordance with applicable data protection laws and industry best practices. Where applicable, HashMove will align with local data protection regulations in jurisdictions where services are delivered.

20.4 Deployment Flexibility

HashMove supports flexible deployment models including public cloud, private cloud, and on-premise environments, subject to customer requirements and agreed architecture.

20.5 Connectivity and Infrastructure Limitations

Service performance may be impacted by regional internet infrastructure, connectivity, or third-party telecommunications providers outside HashMove’s control.

20.6 Regional Support and Language

HashMove may provide regional support resources where applicable. Support services are primarily provided in English and may be provided in additional languages, including Arabic, where agreed.
‍

21. Governing Terms

This SLA is governed by and incorporated into the Customer Agreement. All undefined terms shall have the meaning assigned in the Customer Agreement.