Business Continuity & Disaster Recovery — Trust Centre — Compass IoT
Resilience

Our commitment

When something goes wrong, our goal is to recover quickly, communicate clearly, and prevent the same disruption from happening twice.

Compass IoT's platform sits at the centre of how our customers make decisions about roads, fleets, and infrastructure. Disruptions to that platform have real consequences. This plan sets out how we design for resilience, how we respond when disruptions occur, and how we recover and communicate during and after an incident.

This plan applies to all employees, contractors, and vendors with a role in maintaining or restoring platform availability. It is reviewed annually and following any significant incident.

Objectives

What this plan covers

Plan in place

This plan covers Compass IoT's response to any event that materially disrupts the availability, integrity, or confidentiality of the platform or its underlying data. This includes but is not limited to infrastructure failure, data loss, cyberattack, third-party outage, and force majeure events.

  • Minimise the duration and impact of any disruption to the Compass IoT platform.
  • Protect the integrity and availability of customer data throughout any incident.
  • Ensure key personnel know their roles and can act without delay when an incident occurs.
  • Communicate proactively and transparently with customers during disruptions.
  • Learn from incidents to prevent recurrence and improve resilience over time.

Prevention

How we design for resilience

The most effective recovery is the one that never needs to happen. Compass IoT's architecture and operational practices are designed to minimise the likelihood and impact of disruption before it occurs.

  • The platform is hosted on Google Cloud Platform with built-in redundancy, autoscaling, and multi-zone availability across all critical services.
  • No single point of failure exists in any critical data path — all core services have redundant instances.
  • Production data is backed up daily to a geographically separate GCP region, with backup integrity verified on a regular schedule.
  • Infrastructure changes are deployed through a controlled change management process, with staging environment testing before production release.
  • Third-party data source dependencies are documented and monitored; upstream disruptions are detected automatically.
  • Access to production systems is restricted and logged, reducing the risk of accidental or malicious disruption.

Disruption scenarios

What we plan for

Our BC/DR plan is designed to cover a range of disruption scenarios, from minor service degradation through to major incidents requiring full platform recovery. The following scenarios are specifically addressed.

Infrastructure failure
GCP zone or region outage, server failure, network disruption, or database unavailability. Mitigated by multi-zone architecture and automatic failover.
Cyberattack or security incident
Ransomware, data breach, DDoS, or unauthorised access. Managed under the Incident Response Plan with containment, recovery, and notification procedures.
Data loss or corruption
Accidental or malicious data deletion, database corruption, or failed migration. Recovered from daily backups stored in a separate GCP region.
Key personnel unavailability
Loss of access to critical personnel due to illness, resignation, or emergency. Mitigated by documented runbooks, cross-training, and defined backup contacts for all critical roles.
Third-party or upstream failure
Outage or failure of an OEM data provider, subprocessor, or critical SaaS dependency. Platform degrades gracefully; cached and historical data remains accessible.
Office or workplace disruption
Loss of access to office facilities due to natural disaster, utility failure, or public health emergency. Compass IoT's remote-first capability means operations continue unaffected in most cases.

Response process

How we respond to a disruption

When a disruption is detected, Compass IoT follows a structured four-phase response process. Each phase has defined responsibilities, actions, and communication requirements.

Phase 01

Detection and assessment
  • Disruption detected via automated monitoring, customer report, or internal alert.
  • On-call personnel assess the nature, scope, and severity of the incident.
  • Incident severity is classified (Minor / Moderate / Major / Critical) to determine the appropriate response level.
  • Relevant personnel are notified based on severity classification.

Phase 02

Containment
  • Immediate steps taken to prevent the incident from escalating or spreading.
  • Affected systems isolated where necessary to protect data integrity.
  • Failover to redundant infrastructure activated where available.
  • Initial customer communication sent if the disruption is visible externally.

Phase 03

Recovery
  • Root cause identified and remediation steps initiated.
  • Platform restored from backup or redundant systems where required.
  • Data integrity verified before services are returned to normal operation.
  • Customer communication updated with resolution timeline and status.
  • Services confirmed stable before incident is closed.

Phase 04

Post-incident review
  • Post-incident review conducted within five business days of resolution.
  • Root cause, contributing factors, and timeline documented.
  • Preventive actions identified and assigned to owners with due dates.
  • Findings used to update runbooks, monitoring, or architecture where relevant.
  • Customers provided with a post-incident summary for Major and Critical incidents.

Recovery targets

Recovery objectives

Compass IoT's recovery objectives define the targets we work to achieve when restoring services following a disruption. These targets apply to critical platform services and are reviewed as part of each post-incident review.

Recovery Time Objective (RTO)

Our target is to restore critical platform services within 4 hours of a confirmed Major or Critical incident. Minor and Moderate incidents are targeted for resolution within 1 business day.

Recovery Point Objective (RPO)

Our target is a maximum data loss of 24 hours in a worst-case scenario, based on our daily backup schedule. In practice, the majority of data loss scenarios are recoverable to within hours given our continuous replication setup.

These objectives represent targets, not guarantees. Actual recovery times will depend on the nature and severity of the incident. Compass IoT will communicate realistic recovery timelines as soon as they can be determined during an active incident.

Communication

How we communicate during disruptions

Compass IoT is committed to proactive, transparent communication with customers during any disruption that affects their use of the platform. We will not wait until an incident is resolved to communicate — we will keep customers informed as the situation develops.

  • An initial notification is sent to affected customers as soon as a Major or Critical disruption is confirmed, typically within 30 minutes of declaration.
  • Updates are provided at regular intervals throughout the incident — at least every two hours for active Major and Critical incidents.
  • A resolution notification is sent when services are fully restored.
  • For Major and Critical incidents, a post-incident summary is provided within five business days of resolution.
  • Where a disruption involves a data breach, affected customers are notified in accordance with our obligations under applicable data protection law — within 72 hours of us becoming aware of a confirmed breach.

Communication channels

Incident communications are sent via the primary contact email address registered on your Compass IoT account. For time-sensitive incidents, we may also attempt to reach designated technical contacts directly. To ensure you receive incident notifications, please keep your account contact details current.

Testing and review

How we test and maintain this plan

A BC/DR plan that has never been tested is a plan that may not work when it matters. Compass IoT tests and reviews this plan on a defined schedule.

  • Backup restoration is tested at least annually to verify that data can be recovered from backups as expected.
  • Failover procedures are tested for critical services to confirm that redundant systems activate correctly.
  • Runbooks are reviewed and updated following any incident and at least annually.
  • This plan is formally reviewed annually by the leadership team, and updated to reflect changes in architecture, personnel, or risk environment.
  • Lessons from post-incident reviews are incorporated into the plan within 30 days of the review being completed.

Plan review

Plan ownership and review

This Business Continuity and Disaster Recovery Plan is owned by the Compass IoT leadership team. The CEO holds ultimate accountability for ensuring the plan remains fit for purpose. Day-to-day operational responsibility for BC/DR readiness sits with the engineering leadership team.

This plan will be reviewed annually, following any Major or Critical incident, and whenever material changes occur to the platform architecture or operational environment.

Questions

Get in touch

Questions about our resilience posture, recovery objectives, or incident communication process.