2026 Annual Disaster Recovery & Business Continuity Tabletop Exercise
| Field | Value |
|---|---|
| Exercise Name | 2026 Annual Disaster Recovery & Business Continuity Tabletop Exercise |
| Exercise ID | BCP-TT-2026-07 |
| Exercise Date | August 11, 2026 |
| Organization | Aventora AI |
| Exercise Type | Tabletop (discussion-based) |
| Owner | Security Management |
| Classification | Internal / Customer Shareable |
| Approval Status | Completed |
| Overall Outcome | PASS |
Documentation history note
Earlier public wording dated August 1, 2026 prematurely described this annual tabletop as completed. That wording was unsupported and has been superseded. Aventora conducted one 2026 annual discussion-based BCP tabletop: BCP-TT-2026-07 on August 11, 2026. This document does not claim that two exercises occurred.
Executive Summary
On August 11, 2026, Aventora AI conducted its annual Disaster Recovery and Business Continuity tabletop exercise (Exercise ID BCP-TT-2026-07). The exercise was a discussion-based evaluation of continuity decision-making against a primary production outage scenario affecting Engagement Hub, Aventora Admin, and Domain Assistant.
The exercise evaluated detection and confirmation, incident declaration, escalation, customer/Gallagher communication discipline, recovery priorities, repair-versus-restore decision criteria, security escalation when compromise is possible but unconfirmed, third-party dependency handling, and return-to-service / return-to-normal / campaign-restart authorization gates.
This exercise did not include live production failover, RDS point-in-time recovery, database restoration, Multi-AZ failover, measured restore timing, or hands-on technical recovery. Technical disaster-recovery validation remains a separate outstanding activity.
Related plans reviewed during the exercise:
- Business Continuity and Disaster Recovery
- Incident Response
- Information Security Risk Management Policy
Participants
| Name / Role | Participation |
|---|---|
| Amir Peivandi (Founder & CTO) | Present — primary operator covering Incident Commander / Engineering Lead, Operations / Cloud, System Owner (Hub / Admin), System Owner (Domain Assistant), Customer Communications, and Management (documented role stacking) |
No additional human participants were invented for this exercise.
Objective
Validate, through structured discussion, the effectiveness of Business Continuity, Disaster Recovery decision paths, and Incident Response escalation for the Aventora AI SaaS platform (Engagement Hub, Aventora Admin, and Domain Assistant), including customer communication and return-to-normal controls.
Recovery objectives (targets only)
| Objective | Target | Status after tabletop |
|---|---|---|
| Recovery Point Objective (RPO) | Less than 1 hour | Documented internal target — not measured by this exercise |
| Recovery Time Objective (RTO) | Less than 4 hours | Documented internal target — not measured by this exercise; not represented as a contractual Gallagher SLA in this exercise |
Achievement of measured RTO/RPO remains subject to future technical restore and failover testing.
Scenario: Primary production outage
Inject theme: Cloud infrastructure or database failure making Engagement Hub, Aventora Admin, and Domain Assistant unavailable; outbound campaigns interrupted; multi-hour recovery possible; latest database state uncertain.
Detection and declaration
- Monitoring/alerting and application health checks used to detect; independent confirmation across Hub, Admin, and Domain Assistant.
- Continuity / major incident declared after confirmed material customer impact without waiting for full root cause.
- Incident Commander: Amir Peivandi.
Escalation and process controls
- After routine restart/redeploy failure, technical recovery moves to controlled diagnosis.
- Management escalation recorded as a formal decision point (role-stacked).
- Non-essential changes frozen; outbound campaigns treated as suspended.
- Customer operational notification required once multi-hour / deeper recovery is credible — facts only; no unsupported ETA.
Recovery priorities and restore decision (discussion)
- Preferred discussion path: preserve state; prefer database point-in-time recovery to a temporary/recovery instance where available; validate before cutover.
- Gallagher-oriented recovery priority discussed: shared dependencies → Engagement Hub → Admin → Domain Assistant → integrations → campaign reconciliation → explicit campaign restart authorization.
- Multi-AZ failover treated as a separate technical test item, not selected for the state-recovery inject.
Security and third-party dependencies
- Possible (unconfirmed) compromise activates Incident Response in parallel; no “breach” communication on hypothesis alone.
- For Hub outbound campaigns, telephony/SMS is the primary critical third-party dependency; AI providers are secondary for AI-assisted features.
- Controlled degraded-mode return may be authorized when integrity gates pass and unavailable functions are disabled.
Return to normal
- Application health alone is insufficient.
- Distinct authorizations: technical validation → cutover → return-to-service → return-to-normal → separate campaign restart.
- Observation after return-to-service is gate- and evidence-based (no fixed minimum clock established by this tabletop).
Validation
- Validated through tabletop discussion and documentation review.
- Not a live restore, failover, or measured RTO/RPO test.
Exercise Results
| Result | Detail |
|---|---|
| Overall outcome | PASS |
| Communications | Workable path demonstrated; customer/Gallagher outage template and contact-record improvements tracked |
| Critical deficiencies | None that blocked a PASS outcome for discussion-based continuity decision-making |
| Documentation / process improvements | Tracked corrective themes: authoritative incident/recovery record; customer outage communications template and contacts; recovery priority / RTO definition / validation checklist and authorization gates; security-preserving recovery, BC/DR–IR conflict handling, and degraded-mode authorization |
This exercise demonstrates that Aventora has exercised its resilience and incident decision-making through a formal annual tabletop. Technical restore, failover, and measured RTO/RPO evidence remain outstanding and are tracked separately.
Relationship to technical disaster-recovery testing
| Activity | Status |
|---|---|
| BCP tabletop (this exercise) | Completed 2026-08-11 |
| Technical DR (Multi-AZ failover, PITR, logical restore, application rollback, E2E recovery, queue/campaign controls, measured RTO/RPO) | Outstanding |
Staging infrastructure rebuild or smoke testing alone is not technical DR evidence.
Related documentation
- Business Continuity
- Incident Response
- Information Security Risk Management Policy
- Customer Security Package
- Security Overview
Changelog
| Date | Change |
|---|---|
| 2026-08-11 | Replaced unsupported August 1 completion claim with factual August 11, 2026 BCP-TT-2026-07 exercise record (PASS; discussion-based; technical DR outstanding). Transparent history note added; no second exercise claimed. |
| 2026-08-01 | Prior premature “Completed” wording published (now superseded). |