<!-- Copyright (c) 2026 defconxt. All rights reserved. -->
<!-- Licensed under AGPL-3.0 — see LICENSE file for details. -->
---
name: implementing-disaster-recovery-architecture
description: >-
  Implement disaster recovery architectures with RTO/RPO-driven designs, multi-region
  failover, backup encryption, recovery testing procedures, and resilience patterns
  that maintain security controls during and after recovery.
domain: cybersecurity
subdomain: security-architecture
tags:
  - disaster-recovery
  - business-continuity
  - rto-rpo
  - backup-security
  - failover
  - resilience
version: "1.0"
author: defconxt
license: AGPL-3.0
metadata:
  mitre-attack: ["T1490"]
---

# Implementing Disaster Recovery Architecture

## Overview

Disaster recovery architecture ensures business continuity while maintaining security
controls during and after recovery events. This skill covers RTO/RPO classification,
multi-region failover design, backup encryption and integrity verification, recovery
testing, and ensuring security controls survive DR events.

Mode: `[MODE: ARCHITECT]` — DR design with security control continuity.

## Prerequisites

- Business impact analysis (BIA) with RTO/RPO requirements
- Multi-region cloud infrastructure or secondary data center
- Backup infrastructure with encryption capability
- Python 3.10+

## Key Concepts

### DR Tier Classification

| Tier | RTO | RPO | Strategy | Cost |
|------|-----|-----|----------|------|
| **Tier 1** | < 15 min | 0 (zero data loss) | Active-active multi-region | $$$$$ |
| **Tier 2** | < 1 hour | < 15 min | Hot standby with replication | $$$$ |
| **Tier 3** | < 4 hours | < 1 hour | Warm standby with snapshots | $$$ |
| **Tier 4** | < 24 hours | < 24 hours | Cold standby from backups | $$ |
| **Tier 5** | > 24 hours | > 24 hours | Backup restore only | $ |

### Multi-Region Failover Architecture

```
┌──────────────┐     Replication     ┌──────────────┐
│  Primary     │ ──────────────────▶ │  Secondary   │
│  Region      │                     │  Region      │
│              │     Health Probe    │              │
│  ┌────────┐  │ ◀────────────────── │  ┌────────┐  │
│  │ App    │  │                     │  │ App    │  │
│  │ Stack  │  │                     │  │ Stack  │  │
│  └────────┘  │                     │  └────────┘  │
│  ┌────────┐  │    Async/Sync       │  ┌────────┐  │
│  │ DB     │  │ ──────────────────▶ │  │ DB     │  │
│  │ Primary│  │                     │  │ Replica│  │
│  └────────┘  │                     │  └────────┘  │
└──────────────┘                     └──────────────┘
       │                                    │
       └──────────── Global LB ─────────────┘
             (DNS failover / traffic manager)
```

### Backup Security Requirements

```json
{
  "backup_policy": {
    "encryption": {
      "algorithm": "AES-256-GCM",
      "key_management": "separate-kms-region",
      "key_rotation_days": 90
    },
    "integrity": {
      "checksum": "SHA-256",
      "verification_frequency": "daily",
      "immutable_storage": true,
      "retention_lock_days": 30
    },
    "access_control": {
      "break_glass_only": true,
      "mfa_required": true,
      "separate_credentials": true,
      "audit_all_access": true
    },
    "anti_ransomware": {
      "air_gapped_copy": true,
      "write_once_storage": true,
      "offline_copy_frequency": "weekly"
    }
  }
}
```

### Security Controls Continuity Checklist

```yaml
dr_security_controls:
  identity:
    - IdP reachable from DR region
    - MFA operational during failover
    - Break-glass accounts tested
  network:
    - Firewall rules replicated to DR
    - WAF policies synced
    - VPN tunnels pre-established
  monitoring:
    - SIEM ingesting DR region logs
    - Alerting configured for DR resources
    - Incident response runbooks updated
  encryption:
    - KMS keys accessible from DR region
    - TLS certificates valid in DR
    - Backup decryption keys available
```

## Workflow

### Step 1: Classify Systems by DR Tier

```bash
node scripts/agent.js --action classify --systems systems.json
```

### Step 2: Design DR Architecture

```bash
node scripts/agent.js --action design --systems classified.json --output dr-arch.json
```

### Step 3: Validate Backup Security

```bash
node scripts/agent.js --action validate-backups --backups backup-config.json
```

### Step 4: Generate DR Test Plan

```bash
node scripts/agent.js --action test-plan --architecture dr-arch.json --output test-plan.json
```

## Detection

```yaml
title: Disaster Recovery Architecture Detection
id: c51d3ffd-f079-4072-a71b-62cb18d2da2e
status: experimental
description: Detects suspicious activity related to implementing disaster recovery architecture techniques in security architecture context
logsource:
  category: network_connection
  product: firewall
detection:
  selection:
    DestinationPort: 443
    Initiated: "true"
  condition: selection
level: medium
tags:
  - attack.t1490
  - attack.lateral_movement
falsepositives:
  - Network segmentation testing by authorized infrastructure teams
```

## Verification

- [ ] All systems classified with RTO/RPO requirements
- [ ] DR architecture matches tier requirements
- [ ] Backups encrypted with separate KMS keys
- [ ] Immutable backup copies protect against ransomware
- [ ] Security controls verified operational during failover test
- [ ] DR test executed and documented quarterly
- [ ] Recovery time meets RTO within 10% margin
- [ ] Break-glass procedures tested and documented

## References

- [NIST SP 800-34 Contingency Planning Guide](https://csrc.nist.gov/publications/detail/sp/800-34/rev-1/final)
- [ISO 22301 Business Continuity Management](https://www.iso.org/standard/75106.html)
- [AWS Disaster Recovery Whitepaper](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
