JIL Sovereign Technologies, Inc.
A Delaware Corporation · jilsovereign.com
Business Continuity and Disaster Recovery Plan
1. Recovery Objectives
| Service Tier | RTO | RPO | Note |
|---|---|---|---|
| Customer-facing portals (admin, retail, marketing) | 4 hours | 1 hour | Multi-AZ in primary region; cross-region warm standby. |
| AVA™ Pro / AVA™ Pro+ analytical pipeline | 8 hours | 1 hour | SQS-buffered; pipeline can recover from queue without data loss. |
| Audit log integrity | 0 (durability target) | 0 | S3 Object Lock Compliance mode + cross-region replication. Loss is not a designed-for failure mode. |
| Court Ready Evidence Bundle access | 4 hours | 0 | Sealed and immutable; replication preserves integrity. |
RTO ("recovery time objective") is the maximum tolerable time for a service to be unavailable. RPO ("recovery point objective") is the maximum tolerable amount of data loss measured in time.
2. Architecture
The Company's commercial production environment runs in AWS with the following resilience architecture:
- Primary region: us-east-1 (N. Virginia). Active.
- Warm standby region: us-east-2 (Ohio). Cross-region replication of S3 audit and CREB™ buckets; cross-region read replica of RDS. Failover via Route 53 health checks with manual approval gate to prevent thrashing on transient blips.
- Cold disaster-recovery region: us-west-2 (Oregon). Periodic snapshot copy. Recovery time measured in hours; expected only in catastrophic loss of two regions, an event scenario considered low-probability.
- Federal track (when in use): us-gov-west-1 (GovCloud). Independent control plane.
3. Backup
The Company employs the following backup posture:
- RDS automated daily snapshots retained 35 days; weekly snapshots retained 1 year; monthly snapshots retained 7 years where required by customer contract.
- S3 versioning enabled on all production buckets; lifecycle rules transition non-current versions to lower-cost tiers.
- S3 audit and CREB™ buckets use Object Lock Compliance mode preventing deletion within the 15-year retention period, including by AWS root user.
- Cross-region replication on audit and CREB™ buckets within 15 minutes objective.
4. Plan Activation
The plan is activated by the on-call Incident Commander upon any of:
- regional outage of the primary AWS region exceeding 30 minutes;
- partial outage projected to exceed the SEV-1 RTO threshold;
- destructive event affecting data integrity (ransomware, malicious deletion);
- contractually triggered customer demand for failover demonstration.
5. Communication During an Event
- Customer notifications via Customer Liaisons; cadence per the Incident Response Plan severity matrix.
- Public status page reflecting current operational state.
- Internal coordination via dedicated incident channel; no out-of-band side conversations.
6. Testing
- Quarterly tabletop exercises rotating across loss scenarios.
- Annual live failover from primary to warm-standby region with measured RTO and RPO.
- Semi-annual restore-from-backup verification against a representative dataset.
- Annual business-impact analysis updated to reflect changes in service mix and customer concentration.
7. Plan Maintenance
The plan is reviewed at least annually and after each tabletop, live-failover, or actual SEV-1 event. Material changes require approval by the CISO and the Head of Operations. Inventory of customer-facing commitments is maintained in the contracts register and reconciled to the plan annually.