Business Continuity and Disaster Recovery
Aventora maintains business continuity and disaster recovery practices to support platform availability and data recovery. This document summarizes capabilities for enterprise reviewers.
For policy requirements, see the Personal Data Privacy & Protection Policy. Related risk governance is described in the Information Security Risk Management Policy.
Scope of continuity program described here: Engagement Hub, Aventora Admin, Domain Assistant, and their supporting cloud infrastructure, data stores, and critical third-party dependencies (telephony/SMS/email and AI providers).
Availability design
| Capability | Description |
|---|---|
| Containerized services | Application services packaged as Docker containers with health checks and automatic restart |
| Database migrations | Schema initialization and migration tooling for controlled upgrades |
| Health endpoints | GET /health probes support liveness monitoring and orchestration |
| Controlled deployments | Versioned container images; production containers replaced rather than modified in place |
| Reverse proxy resilience | Nginx or Caddy TLS termination with forwarding to application containers |
Backup and recovery
| Practice | Description |
|---|---|
| Database backups | Production database backups maintained for recovery purposes |
| Backup protection | Backup access restricted to authorized operations personnel; encryption where supported |
| Backup retention | Retention aligned with recovery objectives and contractual requirements |
| Recovery procedures | Documented restoration procedures for production data stores |
Recovery objectives may vary by deployment tier and contractual agreement. Customers with specific RTO/RPO requirements should discuss these during contracting.
Technical validation note: Formal measurement of RTO/RPO and periodic technical backup-restoration tests are tracked as operational maturity activities. A tabletop exercise exercises decision-making and communications; it does not by itself constitute technical validation of restore, failover, RTO, or RPO.
Third-party dependency continuity
Aventora's platform depends on external providers for telephony, AI inference, and identity services. Operational practices include:
- Error handling and retry behavior for external API calls
- Health monitoring for critical integration paths
- Configurable provider selection per deployment
- Operational alerting for provider failures
Customers requiring specific availability guarantees for telephony or AI features should discuss deployment architecture with their Aventora account team.
Deployment flexibility
Business continuity posture varies by deployment model:
| Model | Considerations |
|---|---|
| Managed cloud | Aventora-operated backup and recovery procedures |
| Self-hosted | Customer-operated backup schedules using published deployment guides |
| Hybrid | Responsibilities defined in services agreement |
Self-hosted deployment guides are available to customers under agreement. Contact security@aventora.ai.
Business Continuity Plan tabletop exercises
Aventora performs a Business Continuity Plan tabletop exercise at least annually, and following significant changes when appropriate.
The 2026 annual exercise (Exercise ID BCP-TT-2026-07) was completed on August 11, 2026 as a discussion-based BCP tabletop. See the Disaster Recovery Tabletop Exercise report for customer-shareable evidence. Earlier public wording that described an August 1, 2026 completion was premature and has been superseded; Aventora conducted one 2026 annual tabletop on August 11, 2026.
Exercise owner
The Information Security Officer owns the annual tabletop exercise program (planning, facilitation or facilitator designation, reporting, and corrective-action tracking).
Required participants
Exercises SHOULD include representation from:
| Role | Participation |
|---|---|
| Information Security Officer / Facilitator | Required |
| Engineering Lead / Incident Commander | Required |
| System Owner(s) for Engagement Hub, Aventora Admin, and Domain Assistant | Required |
| Operations / Cloud | Required |
| Privacy Officer | Required when Customer Data impact is plausible |
| Customer Communications / Account | Required for customer-notification practice |
| Management | Required for escalation and return-to-service authority |
In a small team, participants may cover multiple roles if documented in the attendance record.
Exercise scope
Annual tabletop scope includes, at minimum:
- Engagement Hub, Aventora Admin, and Domain Assistant
- Supporting cloud infrastructure and databases/backups
- Telephony, SMS, and email dependencies
- AI service-provider dependencies
- Administrative access and customer communication procedures
Exercise documentation requirements
Each annual (or event-driven) tabletop MUST retain:
- Exercise plan
- Attendance record
- Facilitator notes or inject log
- Participant worksheets (or equivalent notes)
- Exercise report
- Corrective action register updates
Operational exercise records are maintained in internal / restricted documentation and are not published on the public documentation site.
Corrective-action tracking
Findings from tabletop exercises MUST be recorded with owners, priorities, target dates, and required evidence, and tracked to closure (or formal risk acceptance where appropriate).
Lessons-learned incorporation
Lessons learned MUST be reviewed by the Information Security Officer and Engineering Lead and incorporated into BCP procedures, communication templates, recovery checklists, and related runbooks as applicable.
Event-driven exercise triggers
In addition to the annual cadence, Aventora SHOULD conduct or refresh a tabletop exercise following significant changes, including:
- Material infrastructure changes
- New critical third-party providers
- Major architecture changes
- Significant incidents
- Material changes in customer data processing
- Changes to recovery objectives
- Changes to key personnel or responsibilities
Management review and approval
Exercise reports MUST be submitted for Management review. Material corrective actions and changes to recovery objectives MUST be approved by Management (or designated approvers).
Relationship to technical disaster-recovery testing
| Activity | Purpose |
|---|---|
| BCP tabletop exercise | Discussion-based validation of roles, escalation, communication, prioritization, and decision-making |
| Technical DR / restore testing | Hands-on validation of backups, restore procedures, and measured recovery objectives |
A completed tabletop exercise does not replace technical backup restoration, failover testing, or measured RTO/RPO validation. Those technical tests remain separate evidence items.
Related documentation
- Disaster Recovery Tabletop Exercise
- Data Retention
- Incident Response
- Information Security Risk Management Policy
- Risk Assessment and Treatment Procedure
- Vendor Management Policy
- AI Governance Policy
Changelog
| Date | Change |
|---|---|
| 2026-08-11 | Corrected annual tabletop completion date to August 11, 2026 (BCP-TT-2026-07); superseded premature August 1 wording; reaffirmed tabletop ≠ technical DR / measured RTO/RPO. |
| 2026-08-01 | Linked Disaster Recovery Tabletop Exercise (wording later corrected on 2026-08-11). |
| 2026-07-27 | Platform AWS IaC and operator restore/cutover runbooks added (aventora-infra, internal ops Platform AWS pages). Technical PITR/Multi-AZ drill evidence still required in nonprod before claiming measured RTO/RPO. |
| 2026-07-27 | Added annual BCP tabletop exercise requirements (owner, participants, scope, documentation, corrective actions, lessons learned, event-driven triggers, Management review, and relationship to technical DR testing). Clarified tabletop vs technical validation. Scoped continuity program language to Hub, Admin, and Domain Assistant. |
| 2026-07-27 | Linked Information Security Risk Management Policy and Risk Assessment and Treatment Procedure; removed duplicate related links. |
| 2026-07-06 | Initial publication of business continuity overview. |