64 lines
4.1 KiB
Markdown
64 lines
4.1 KiB
Markdown
# Business Continuity & Disaster Recovery Policy
|
|
|
|
**Document owner:** [Owner/Role]
|
|
**Approved by:** [Steering Committee / CISO]
|
|
**Effective date:** [YYYY-MM-DD]
|
|
**Review cadence:** [Annually]
|
|
|
|
---
|
|
|
|
## 1. Purpose & Scope
|
|
This policy establishes mandatory requirements for [Organization]'s ability to recover from disruption — outages, ransomware, natural disaster, or vendor failure. It applies to all systems, with the tightest requirements applied to kill-chain systems defined in [Authentication Policy §2.1](authentication_policy.md).
|
|
|
|
---
|
|
|
|
## 2. Policy Statements
|
|
|
|
### 2.1 Business Impact Analysis (BIA)
|
|
- A BIA **must** be conducted at least annually, identifying critical processes, dependencies, and acceptable downtime.
|
|
|
|
### 2.2 Recovery Objectives by Tier
|
|
| Tier | RTO (Recovery Time) | RPO (Recovery Point / max data loss) |
|
|
|---|---|---|
|
|
| Kill-chain (IdP, PKI, backup infra, break-glass vault) | ≤ 4 hours | ≤ 15 minutes |
|
|
| Critical business systems | ≤ 24 hours | ≤ 4 hours |
|
|
| Standard systems | ≤ 72 hours | ≤ 24 hours |
|
|
| Low-priority systems | Best effort | Best effort |
|
|
|
|
### 2.3 Backup Requirements
|
|
- Backups **must** be encrypted (per [Secrets & Key Management Policy §2.3](secrets_management_policy.md)) and include at least one copy that is offline or immutable (air-gapped or WORM), unreachable by a compromised production credential.
|
|
- Backup restoration **must** be tested at least quarterly for kill-chain systems, annually for others.
|
|
|
|
### 2.4 DR Testing
|
|
- A full failover test **must** be conducted at least **annually** for kill-chain and critical systems.
|
|
- Tests **must** follow the calibrated-dose principle: bounded blast radius, non-production first where feasible, pre-agreed abort condition — consistent with [Authentication Policy §2.13](authentication_policy.md) and [Incident Response Policy §3.6](incident_response_policy.md).
|
|
|
|
### 2.5 Break-Glass & Emergency Access During DR
|
|
- DR procedures **must** account for break-glass account availability when the primary IdP is part of the outage — see [Authentication Policy §3](authentication_policy.md) and [§2.6](authentication_policy.md) (graceful degradation).
|
|
|
|
### 2.6 Greenfield Rebuild Capability
|
|
- [Organization] **must** maintain the documented, version-controlled capability to rebuild its environment from scratch — not merely restore from backup — at least once every **five years**, or on demand after a compromise where restoring from backup risks reintroducing the compromised state.
|
|
- This capability **must** be exercised, not just claimed on paper; an untested greenfield rebuild plan is treated the same as untested break-glass access.
|
|
|
|
### 2.7 Enforcement
|
|
- Systems without a current BIA, tested backup, or documented RTO/RPO **must** be remediated or formally excepted with CISO approval.
|
|
|
|
---
|
|
|
|
## 3. Antifragility Alignment
|
|
This policy is built to the five pillars of the organization's internal **Antifragile Enterprise Manifest**.
|
|
|
|
| Pillar | Applied In | How |
|
|
|---|---|---|
|
|
| **1. Structural Decoupling** | §2.6 | Greenfield rebuild capability is the ultimate expression of decoupling — the org can leave its own compromised/legacy state behind entirely |
|
|
| **2. Optionality Preservation** | §2.3 | Offline/immutable backup copy preserves the option to recover even if the primary environment (and its credentials) is fully compromised |
|
|
| **3. Stress-to-Signal Conversion** | §2.4 | DR tests are dosed exercises, not annual theater — findings feed structural fixes per [Authentication Policy §2.12](authentication_policy.md) |
|
|
| **4. Sovereign Intelligence** | §2.6 | Rebuild capability requires documented, owned architecture knowledge — the antidote to "only Dave knows how this works" |
|
|
| **5. Asymmetric Payoff Design (Barbell)** | §2.2 | 4-hour RTO concentrated on kill-chain systems; low-priority systems get best-effort — no moderate RTO spread evenly across everything |
|
|
|
|
---
|
|
|
|
## 4. References
|
|
- **[NIST SP 800-34 Rev. 1, Contingency Planning Guide](https://csrc.nist.gov/pubs/sp/800/34/r1/upd1/final)**
|
|
- **[ISO 22301:2019, Business Continuity Management Systems](https://www.iso.org/standard/75106.html)**
|