IT Disaster Recovery Policy

Purpose

This policy defines the requirements for IT disaster recovery at Carriyo, ensuring that critical technology services and data can be restored within acceptable timeframes following a disruptive event. It complements the Business Continuity Policy (CAR-ISMS-POL-006) by focusing specifically on IT infrastructure, applications, and data recovery.

Scope

This policy covers all Carriyo production systems, databases, infrastructure components, and supporting services hosted on AWS. It applies to the engineering, DevOps, and security teams responsible for maintaining and recovering these systems.

Policy Statements

Recovery Objectives

Carriyo defines the following recovery objectives for its production environment:

Infrastructure Resilience

Carriyo's primary production region is AWS eu-west-1 (Ireland).

• Production services are deployed across multiple AWS Availability Zones (AZs) within the primary region (eu-west-1) to survive single-AZ failures without service interruption.
• Critical databases use synchronous replication across AZs with automated failover.
• Default disaster recovery is in-region, multi-AZ failover within the primary region. This is automatic, requires no manual intervention, and delivers the Tier 1 recovery objectives (RTO 1 hour / RPO 15 minutes). By default, Carriyo does not fail over to another AWS region.
• Multi-region (regional) disaster recovery is offered to customers as an option. No customer is on it today and no secondary region is deployed; the in-region multi-AZ set-up in AWS eu-west-1 is the only deployed set-up and the DR mechanism in use. The option is engineered when a customer subscribes; the chosen region and runbook are documented in CAR-ISMS-PRC-003 at that time.
• Infrastructure is defined as code, enabling re-provisioning of the environment in-region or, on whole-region loss, in another region (CAR-ISMS-PRC-003).

Backup Strategy

• Databases: DynamoDB point-in-time recovery (35-day window) on the core production tables and automated daily snapshots of the OpenSearch domains; backups are held in eu-west-1.
• Object Storage (S3): Versioning enabled to protect against accidental deletion or corruption; no cross-region replication.
• Configuration and Secrets: Infrastructure-as-code repositories are held in source control; secrets are stored in AWS Secrets Manager.
• Application Code: Source code is hosted in Git repositories with remote mirrors. CI/CD pipeline configurations are version-controlled.

Backup Validation

• Backup integrity is validated through automated restoration tests performed at least annually for all system tiers.
• Restoration tests verify that backed-up data can be successfully restored and that applications function correctly with restored data.
• Test results are documented and reviewed by the security team.

Disaster Recovery Procedures

• Detailed disaster recovery runbooks are maintained for each Tier 1 and Tier 2 service, documenting step-by-step recovery procedures.
• Runbooks include: service dependencies, recovery sequence, configuration steps, validation checks, and rollback procedures.
• Runbooks are stored in a location accessible even if the primary infrastructure is unavailable (e.g., offline documentation or an independent location).

DR Testing

• DR exercises are conducted at least annually, validating in-region multi-AZ recovery (CAR-ISMS-REC-015); a cross-region test is deferred until a customer takes the multi-region option.
• Tabletop exercises are conducted annually with key engineering and operations personnel.
• Partial recovery tests (e.g., database failover, single-service recovery) are conducted annually.
• Test results, including actual recovery times and any issues encountered, are documented and reported to the CISO.
• Identified deficiencies are tracked and remediated within agreed timeframes.

Communication During Disasters

• A communication plan defines how customers, employees, and stakeholders are notified during a disaster event.
• Carriyo does not operate a public status page. Customer communication during a disaster is by email (and in-app notice where available) from Customer Success, per the BCP communication plan (PRC-002).
• The CISO or designated deputy authorises external communications regarding service disruptions.
• Post-incident communication includes a root cause analysis and remediation summary.

Roles and Responsibilities

Compliance and Enforcement

Compliance with this policy is verified through DR test results, backup validation reports, and infrastructure configuration audits. Failure to maintain adequate DR capabilities for Tier 1 systems is escalated to the CISO as a critical risk. This policy is reviewed annually or following any significant infrastructure change or disaster event.

Document Control