# Resilience Tiering and HA/DR Design: [Organisation, portfolio or platform]

> Design document that classifies workloads into business criticality
> tiers, sets recovery and availability objectives per tier (MTD, RTO,
> RPO, availability target), and assigns a high availability (HA) and
> disaster recovery (DR) pattern, a data protection method, a topology
> and a test cadence to each tier. It defines the rules for tier
> inheritance across dependencies, failover and failback design, cost
> per tier and the exception process. The terms and the business impact
> analysis link follow NIST SP 800-34 Rev. 1 (Contingency Planning Guide
> for Federal Information Systems, public domain); the ICT readiness
> view follows the structure of ISO/IEC 27031:2025; the DR pattern names
> are those of the AWS Well-Architected Reliability pillar (backup and
> restore, pilot light, warm standby, multi-site active/active), with
> the equivalent Azure and Google Cloud terms. Replace every
> `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- This is a design standard, written once for a portfolio or platform
  and updated when tiers change. Each system's operational recovery
  procedure lives in the IT Disaster Recovery Plan
  (`ops/disaster-recovery-plan`); backup jobs live in the Backup and
  Restore Procedure (`ops/backup-restore-procedure`); business-level
  continuity lives in the Business Continuity Plan
  (`compliance/business-continuity`).
- Start from the business impact analysis. Tiers and objectives must
  come from business impact, not from what the current platform happens
  to deliver.
- Fill sections 2 to 4 first and get them approved by the business
  before choosing patterns. Patterns (section 6) follow the objectives.
- In-service resilience of a single service (timeouts, retries, circuit
  breakers, load shedding) is covered by the Resilience Design
  (`system-design/resilience-load-shedding-design`); cyber resiliency
  goals and techniques by the Cyber Resiliency Design
  (`security/cyber-resiliency-design`).
- Related documents: Landing Zone Design (`architecture/landing-zone-design`),
  Infrastructure Design (`architecture/infrastructure-design`), Hybrid
  and Multicloud Architecture (`architecture/hybrid-multicloud-architecture`),
  SLO document (`dev/slo-doc`), Chaos Experiment (`ops/chaos-experiment`),
  NFR Catalogue (`requirements/nfr-catalogue`).
-->

## Document control

<!-- Guidance: Identify the scope (whole organisation, one platform or one portfolio), the owner and the business approvers. A change to tier definitions or objectives is a new major version and triggers a review of every workload's assignment. -->

| Field | Value |
|---|---|
| Document ID | [RTD-001] |
| Scope | [Organisation / Platform / Portfolio name] |
| Business impact analysis reference | [BIA ID, version, date] |
| Hosting | [Cloud provider(s), regions, data centres] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@resilience-architect] |
| Approvers/reviewers | [@cio], [@business-continuity-manager], [@ciso], [@platform-lead], [@finance-partner] |
| Last updated | YYYY-MM-DD |
| Next review | YYYY-MM-DD |
| Classification | [Internal / Confidential] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Business continuity manager | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Chief information officer | [@name] | [Decision] | YYYY-MM-DD |
| Chief information security officer | [@name] | [Decision] | YYYY-MM-DD |
| Platform lead | [@name] | [Decision] | YYYY-MM-DD |
| Finance | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft: tier model and objectives |
| 0.2 | YYYY-MM-DD | [@name] | *Example:* Pattern catalogue and cost per tier added |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved; 42 workloads assigned |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Introduction and scope](#1-introduction-and-scope)
2. [Criticality tier model](#2-criticality-tier-model)
3. [Recovery and availability objectives per tier](#3-recovery-and-availability-objectives-per-tier)
4. [Workload tier assignment](#4-workload-tier-assignment)
5. [Failure scenarios and scope of protection](#5-failure-scenarios-and-scope-of-protection)
6. [Pattern catalogue](#6-pattern-catalogue)
7. [Reference design per tier](#7-reference-design-per-tier)
8. [Data protection and replication](#8-data-protection-and-replication)
9. [Zonal and regional topology](#9-zonal-and-regional-topology)
10. [Dependencies and tier inheritance](#10-dependencies-and-tier-inheritance)
11. [Failover and failback design](#11-failover-and-failback-design)
12. [Testing and validation](#12-testing-and-validation)
13. [Cost per tier](#13-cost-per-tier)
14. [Exceptions and waivers](#14-exceptions-and-waivers)
15. [Governance, roles and traceability](#15-governance-roles-and-traceability)
16. [Risks and open decisions](#16-risks-and-open-decisions)
17. [Glossary and references](#17-glossary-and-references)

## 1. Introduction and scope

<!-- Guidance: Say what the design decides and what it leaves to other documents. Questions: which disruptions must the portfolio survive, and which are accepted? Pitfall: treating HA and DR as the same thing, so that a multi-zone deployment is assumed to protect against data corruption or a regional outage. -->

### 1.1 Purpose

This design sets a small number of resilience tiers for [scope], the
recovery and availability objectives each tier must meet, and the
standard architecture patterns that achieve them. Workload teams pick
their tier through the assignment process in section 4 and then build
the pattern for that tier, instead of inventing a recovery approach per
system. A shared set of patterns allows common tooling, common tests
and comparable evidence, which is the practical benefit that public
cloud reliability guidance also stresses.

### 1.2 HA and DR

- **High availability** keeps a service running through frequent,
  local failures (an instance, a disk, a zone) without declaring a
  disaster. It is measured as availability over a period.
- **Disaster recovery** restores a service after a rare, large
  disruption (loss of a region or site, destructive attack, major data
  corruption). It is measured per event, against RTO and RPO.
- A design needs both. Replication improves availability but copies
  corruption and deletion; only point-in-time and isolated copies
  recover from those.

### 1.3 Scope

| In scope | Out of scope |
|---|---|
| *Example:* All production workloads hosted on [cloud provider] and the two company data centres | End-user devices and office networks |
| *Example:* Shared platform services: identity, DNS, network, secrets, CI/CD, observability | Supplier SaaS beyond the contractual DR evidence collected in section 10 |
| [Item] | [Item] |

### 1.4 Design principles

| ID | Principle | Consequence |
|---|---|---|
| RTP-001 *(Example)* | Objectives come from business impact, not from current capability | A workload that cannot meet its tier records an exception (section 14) with a remediation date |
| RTP-002 *(Example)* | Use the cheapest pattern that meets the objectives | Higher tiers are justified by impact, and over-engineering is reviewed like under-engineering |
| RTP-003 *(Example)* | A dependency is at least as resilient as what depends on it | Shared services sit in the highest tier they support (section 10) |
| RTP-004 *(Example)* | Recovery relies on data plane operations | Failover does not depend on creating resources through a control plane that may be impaired |
| RTP-005 *(Example)* | Untested recovery is assumed not to work | Every tier has a mandatory test cadence and evidence (section 12) |
| [RTP-NNN] | [Principle] | [Consequence] |

## 2. Criticality tier model

<!-- Guidance: Define four or five tiers with criteria a business owner can apply. Use impact over time: what happens after 1 hour, 4 hours, 1 day, 1 week. Pitfall: too many tiers, or tier names (gold, silver) that do not say what they mean. -->

### 2.1 Impact categories and scale

Rate impact for each category at each time interval on a 1 to 5 scale
(1 negligible, 2 minor, 3 moderate, 4 major, 5 severe). Define each
level in money, people or regulatory terms for your organisation.

| Category | What to consider | Level 4 means *(Example)* |
|---|---|---|
| Financial | Lost revenue, penalties, extra cost | Loss above USD 500,000 or a contractual penalty |
| Customer and operations | Customers or internal processes unable to act | Most customers unable to pay or order |
| Regulatory and legal | Breach of licence, reporting or statutory duty | Reportable incident to a regulator |
| Safety and wellbeing | Harm to people | Risk of injury or loss of an essential service to vulnerable people |
| Reputation | Public and partner confidence | National media coverage |

### 2.2 Tier definitions

| Tier | Name | Definition | Typical workloads *(Example)* |
|---|---|---|---|
| T0 | Foundation | Shared services without which no other tier can operate or recover | Identity provider, DNS, core network, key management, secrets, backup platform |
| T1 | Mission critical | Impact reaches level 4 or 5 in any category within 4 hours | Payments, customer-facing ordering, trading, clinical systems |
| T2 | Business critical | Impact reaches level 4 within 24 hours | Order fulfilment, customer service, warehouse operations |
| T3 | Business operational | Impact reaches level 4 within 5 days | Reporting, analytics, internal workflow |
| T4 | Deferrable | Impact stays below level 4 for 30 days | Archives, wikis, sandbox and training environments |

The tier is the highest tier triggered by any category at any interval.
T0 is assigned by role (section 10), not by impact scoring.

## 3. Recovery and availability objectives per tier

<!-- Guidance: Give each tier MTD, RTO, RPO and an availability target, and check that they are consistent. ISO/IEC 27031 also uses a minimum business continuity objective (MBCO): the reduced service level that is acceptable during recovery. Pitfall: an RTO equal to the MTD, which leaves no time to detect, decide and verify. -->

| Tier | MTD | RTO | RPO | Availability target (monthly) | Allowed downtime per 30-day month | Yearly equivalent | MBCO during recovery *(Example)* |
|---|---|---|---|---|---|---|---|
| T0 *(Example)* | 2 h | 30 min | Near zero (seconds) | 99.99% | 4.32 min | 52.6 min | Full authentication; read-only admin |
| T1 *(Example)* | 4 h | 1 h | 5 min | 99.95% | 21.6 min | 4.38 h | Core transactions at 50% of peak |
| T2 *(Example)* | 24 h | 8 h | 1 h | 99.9% | 43.2 min | 8.76 h | Critical queues processed; reports deferred |
| T3 *(Example)* | 5 days | 72 h | 24 h | 99.5% | 3.6 h | 43.8 h | Read access to last good copy |
| T4 *(Example)* | 30 days | 14 days | 7 days | 99.0% | 7.2 h | 87.6 h | None |
| [Tier] | [MTD] | [RTO] | [RPO] | [%] | [min or h] | [h] | [MBCO] |

Allowed downtime in a 30-day month at availability $A$ is $(1 - A) \times 43{,}200$ minutes, and the yearly equivalent is $(1 - A) \times 8760$ hours. *Example:* $(1 - 0.9995) \times 43{,}200 = 21.6$ minutes per month and $(1 - 0.9995) \times 8760 = 4.38$ hours per year for T1, and $(1 - 0.9999) \times 525{,}600 = 52.56$ minutes per year for T0. Because the target is monthly, each month must stay within its own allowance; the yearly figure is not a budget that one bad month can spend.

Consistency rules (check each tier):

1. RTO is shorter than MTD, leaving time for detection, the decision to
   invoke and verification. *Example:* T1 leaves 3 hours of margin.
2. RPO is met by the data protection method of the pattern (section 8):
   worst-case data loss is roughly the backup or snapshot interval plus
   replication lag.
3. Compare one DR event at full RTO with the downtime allowance.
   *Example:* a T1 event at the 1-hour RTO uses 1 / 4.38 = 23% of the
   yearly equivalent but is almost three times the T1 monthly allowance
   (21.6 minutes); a T2 event at 8 hours uses 8 / 8.76 = 91% of the
   yearly equivalent and about 11 times the monthly allowance (43.2
   minutes). A monthly target is therefore missed in any month with a
   declared disaster. Decide whether declared DR events count against
   the availability SLO, or are reported separately against RTO, and
   write the rule in the SLO document (`dev/slo-doc`).
4. Objectives apply to the business service, end to end, not to each
   component. Component objectives are derived in section 10.

## 4. Workload tier assignment

<!-- Guidance: Record each workload's tier with the evidence and the owner's agreement. Questions: who scored the impact, when, and did the business owner sign? Pitfall: every owner choosing T1 because it sounds important; tie the tier to the cost in section 13 so the choice is real. -->

| Workload ID | Workload | Business owner | Highest impact (category, interval, level) | Tier | Pattern (section 6) | Meets objectives today | Notes |
|---|---|---|---|---|---|---|---|
| WL-001 *(Example)* | Identity provider | [@iam-lead] | Role: all tiers depend on it | T0 | Active-active across zones plus warm standby region | Yes | Tested quarterly |
| WL-002 *(Example)* | Payments API | [@payments-owner] | Financial, 1 h, level 5 | T1 | Warm standby | No: RPO measured 12 min | Exception EXC-RT-001 |
| WL-003 *(Example)* | Customer web shop | [@ecommerce-owner] | Customer, 4 h, level 4 | T1 | Warm standby | Yes | |
| WL-004 *(Example)* | Order management | [@ops-owner] | Operations, 24 h, level 4 | T2 | Pilot light | Yes | |
| WL-005 *(Example)* | Data warehouse | [@data-owner] | Financial reporting, 5 days, level 4 | T3 | Backup and restore | Yes | Restore measured at 30 h |
| WL-006 *(Example)* | Team wiki | [@it-ops] | Operations, 30 days, level 2 | T4 | Backup and restore | Yes | |
| [WL-NNN] | [Workload] | [@owner] | [Category, interval, level] | [T0 to T4] | [Pattern] | [Yes / No] | [Notes] |

Re-assess every workload when its business use changes and at least
[annually], in line with the BIA review cycle.

## 5. Failure scenarios and scope of protection

<!-- Guidance: List the disruptions the design must handle and say which tier is protected against which. Pitfall: designing only for loss of infrastructure, and not for corruption, deletion, ransomware or a bad deployment, which are more frequent. -->

| Scenario ID | Scenario | Typical cause | HA or DR | T0 | T1 | T2 | T3 | T4 |
|---|---|---|---|---|---|---|---|---|
| FS-001 *(Example)* | Instance or node failure | Hardware, kernel, out-of-memory | HA | Yes | Yes | Yes | Yes | Best effort |
| FS-002 *(Example)* | Zone or data hall failure | Power, cooling, network | HA | Yes | Yes | Yes | Restore | Restore |
| FS-003 *(Example)* | Region or site loss | Large outage, natural event | DR | Yes | Yes | Yes | Yes | Yes, slow |
| FS-004 *(Example)* | Logical corruption or accidental deletion | Bug, operator error | DR from point-in-time copy | Yes | Yes | Yes | Yes | Yes |
| FS-005 *(Example)* | Destructive attack (ransomware, wiper) | Compromised credentials | DR from isolated, immutable copy | Yes | Yes | Yes | Yes | Yes |
| FS-006 *(Example)* | Failed release | Change defect | HA through progressive delivery and rollback | Yes | Yes | Yes | Yes | Yes |
| FS-007 *(Example)* | Critical supplier or SaaS outage | Provider incident | Depends on supplier evidence | Assessed | Assessed | Assessed | Accepted | Accepted |
| FS-008 *(Example)* | Cloud provider control plane impairment | Provider incident | Design rule RTP-004 | Yes | Yes | Partly | Accepted | Accepted |
| [FS-NNN] | [Scenario] | [Cause] | [HA / DR] | [ ] | [ ] | [ ] | [ ] | [ ] |

Accepted scenarios are listed here so that the business has approved
the gap, not discovered it.

## 6. Pattern catalogue

<!-- Guidance: Define each pattern once, with what is running in the recovery location, how data gets there and what must happen at failover. Verify any indicative RTO and RPO ranges against your own tests. Pitfall: calling a design "warm standby" when the recovery site cannot take traffic without a deployment. -->

### 6.1 HA patterns

| Pattern ID | Pattern | Description | Protects against |
|---|---|---|---|
| HA-01 | Redundant instances behind a load balancer | N+1 or more instances with health checks; failed instances replaced automatically | FS-001 |
| HA-02 | Multi-zone deployment | Instances and data replicas spread across at least [two / three] zones in one region, each zone able to carry the load of a lost zone | FS-001, FS-002 |
| HA-03 | Synchronous replicated data store | Writes committed in more than one zone before acknowledgement; automatic promotion of a standby | FS-002 with zero data loss |
| HA-04 | Progressive delivery | Canary or blue-green releases with automatic rollback on health signals | FS-006 |

### 6.2 DR patterns

The four DR strategies below are named and ordered as in the AWS Well-Architected Reliability pillar (best practice REL13-BP02), from lowest cost and complexity with the longest recovery to highest cost with the shortest recovery. Microsoft Azure Well-Architected uses "active-passive cold standby" and "active-passive warm standby" for the middle patterns, and the Google Cloud DR planning guide uses cold, warm and hot. The indicative ranges in the table are the ones the AWS pillar gives; use them only for first selection and replace them with your measured results.

| Pattern ID | Pattern | Closest Azure and Google terms (mapping is approximate) | What runs in the recovery location | Data | Indicative RPO and RTO (AWS pillar) | Action at failover |
|---|---|---|---|---|---|---|
| DR-01 | Backup and restore | Azure: cold standby with no infrastructure running; Google: cold | Nothing; infrastructure defined as code | Backups copied to the recovery location | RPO hours, RTO 24 h or less | Deploy infrastructure and code, restore data |
| DR-02 | Pilot light | Azure: active-passive cold standby with minimal infrastructure; Google: between cold and warm | Core services and data stores only; no application compute | Continuous replication plus backups | RPO minutes, RTO tens of minutes | Create and scale compute, promote replicas, switch traffic |
| DR-03 | Warm standby | Azure: active-passive warm standby; Google: warm | A scaled-down, fully working copy that can take traffic | Continuous replication, live in recovery location | RPO seconds, RTO minutes | Scale up, promote replicas, switch traffic |
| DR-04 | Multi-site active/active | Azure: active-active; Google: hot | Full capacity serving traffic in all locations | Multi-writer or partitioned replication with conflict handling | RPO near zero, RTO potentially zero | Evacuate the failed location; remaining locations absorb load |

A warm standby scaled to full capacity is a hot standby. A point-in-time or immutable backup (section 8) is required with every pattern, because replication alone also replicates corruption and deletion. NIST SP 800-34 Rev. 1 describes the same spectrum for physical alternate sites (cold, warm, hot, mobile and mirrored sites); use those terms for data-centre recovery.

### 6.3 Pattern selection rule

Choose the lowest-cost pattern whose measured RTO and RPO meet the
tier. *Example:* a T2 workload with RTO 8 h and RPO 1 h can use pilot
light; backup and restore fails the RPO unless backups run at least
hourly and the restore of all data stores is proven to finish inside
8 hours.

## 7. Reference design per tier

<!-- Guidance: Turn the tier objectives into a default design that workload teams adopt unchanged. Each row is a standard; deviations are exceptions. Pitfall: reference designs that list products but not the behaviour that must be proven. -->

| Tier | HA patterns | DR pattern | Data protection | Recovery location | Failover decision | Mandatory evidence |
|---|---|---|---|---|---|---|
| T0 *(Example)* | HA-01, HA-02, HA-03 | DR-04 or DR-03 at full scale | Synchronous in region, asynchronous across regions, immutable daily copy | Second region in the same jurisdiction | Pre-approved, automated with human confirmation | Quarterly regional failover test |
| T1 *(Example)* | HA-01, HA-02, HA-03, HA-04 | DR-03 | Synchronous in region; asynchronous cross-region; point-in-time recovery 35 days; immutable copy | Second region | Incident commander invokes with business owner | Semi-annual failover test with RTO and RPO measured |
| T2 *(Example)* | HA-01, HA-02, HA-04 | DR-02 | Asynchronous cross-region replica; daily backups 35 days | Second region | DR manager invokes | Annual failover test |
| T3 *(Example)* | HA-01, HA-02 where cheap | DR-01 | Daily backup copied cross-region; 90 days | Second region or data centre | DR manager invokes | Annual restore test |
| T4 *(Example)* | HA-01 optional | DR-01 | Weekly backup; 90 days | Any | Owner requests | Restore test every two years |

```mermaid
flowchart LR
  subgraph PR[Primary region]
    Z1[Zone A: app and DB primary]
    Z2[Zone B: app and DB sync standby]
  end
  subgraph RR[Recovery region]
    W[Scaled-down app tier]
    R[(Async replica, read-only)]
  end
  U[Users] --> GTM[Global traffic manager]
  GTM -->|normal| PR
  GTM -.->|after failover| RR
  Z1 <-->|synchronous| Z2
  Z1 -->|asynchronous| R
  Z1 --> BK[(Immutable backup vault, separate account)]
  BK -.-> RR
```

*Example:* the diagram shows the T1 reference design: HA-02 and HA-03
in the primary region, DR-03 in the recovery region and an immutable
copy in a separate security boundary.

## 8. Data protection and replication

<!-- Guidance: For each tier, state how data reaches the recovery location, how fresh it is, and how corruption and deletion are recovered. Questions: which stores must stay consistent with each other at recovery? Is the backup vault outside the blast radius of an administrator account compromise? Pitfall: databases recovered to different points in time, so cross-store references break. -->

| Topic | Rule *(Example)* |
|---|---|
| Synchronous versus asynchronous | Synchronous replication within a region (zones are close enough for latency); asynchronous across regions, where distance makes synchronous writes too slow |
| RPO check | Worst-case loss is roughly backup interval plus replication lag; for asynchronous replicas, alert when lag exceeds half the tier RPO |
| Point-in-time recovery | Enabled for every T0 to T2 data store, retention at least [35] days |
| Immutable and isolated copies | Daily copy to a vault in a separate account or subscription, with write-once retention and separate administrators, for T0 to T3 |
| Consistency across stores | Stores that reference each other are recovered to a common point (a consistency group or a recorded timestamp); reconcile messages and events after recovery |
| Encryption keys | Keys are available in the recovery location and not deleted with the primary; key recovery is part of the test |
| Configuration and secrets | Infrastructure code, images, configuration and secrets are replicated with the same RPO as the data |

*Example RPO check:* a T1 database with continuous asynchronous
replication and a p99 lag of 20 seconds meets an RPO of 5 minutes; a
T2 store backed up every 4 hours does not meet an RPO of 1 hour and
needs a replica or hourly snapshots.

Cross-reference: retention periods and restore steps for each data set
are in the Backup and Restore Procedure (`ops/backup-restore-procedure`).

## 9. Zonal and regional topology

<!-- Guidance: Name the regions, zones and data centres, why they were chosen, and the constraints (data residency, capacity, service availability). Pitfall: a recovery region where a required service is not available, or where capacity cannot be obtained during a regional event. -->

| Location ID | Location | Role | Tiers hosted | Constraints |
|---|---|---|---|---|
| LOC-01 *(Example)* | [Provider] [Region A], 3 zones | Primary | T0 to T4 | None |
| LOC-02 *(Example)* | [Provider] [Region B], 3 zones | Recovery for T0 to T3 | T0 standby, T1 warm, T2 pilot light | Same jurisdiction; all required managed services available (checked YYYY-MM-DD) |
| LOC-03 *(Example)* | Company data centre 1 | Primary for legacy systems | T2, T3 | Tape backup offsite |
| [LOC-NN] | [Location] | [Role] | [Tiers] | [Constraints] |

Capacity in the recovery location: reserve or pre-approve capacity for
T0 and T1 so that recovery does not compete with other customers of
the same provider during a regional event. Record quotas and
reservations with dates. Where data residency allows only one region,
state the accepted regional risk explicitly and strengthen zonal
design and isolated backups instead; check residency rules with the
Data Residency and Sovereignty Assessment
(`compliance/data-residency-sovereignty-assessment`).

## 10. Dependencies and tier inheritance

<!-- Guidance: Map each workload's hard dependencies and check that none sits in a lower tier or recovers later than the workload needs it. Shared services usually become T0. Pitfall: a T1 service whose login depends on a T3 directory sync, or whose recovery depends on a CI/CD system that is only in the primary region. -->

### 10.1 Inheritance rules

1. A hard dependency of a tier-N workload must be tier N or higher, or
   the workload must keep working without it (a soft dependency with a
   documented degradation).
2. Recovery order follows dependencies: T0 first, then each workload
   after the services it needs.
3. Shared services used by T1 workloads are T0: identity, DNS,
   certificates and keys, secrets, network, logging needed for
   recovery, the deployment pipeline and the backup platform.
4. External suppliers on a T1 or T2 path provide DR evidence (test
   reports, contractual RTO and RPO); record it in the supplier register,
   for example the ICT Third-Party Register
   (`compliance/dora-ict-third-party-register`) for financial entities.

### 10.2 Dependency check

| Workload | Dependency | Type | Dependency tier | Rule met | Action |
|---|---|---|---|---|---|
| WL-002 Payments API *(Example)* | WL-001 Identity provider | Hard | T0 | Yes | None |
| WL-002 Payments API *(Example)* | Fraud scoring SaaS | Hard | Supplier, RTO 4 h | No: T1 needs 1 h | Add fallback rule-based scoring as soft dependency |
| WL-003 Web shop *(Example)* | Product search cluster | Hard | T2 | No | Raise to T1 or degrade to category browse |
| WL-004 Order management *(Example)* | WL-005 Data warehouse | Soft | T3 | Yes | None |
| [WL-NNN] | [Dependency] | [Hard / Soft] | [Tier] | [Yes / No] | [Action] |

### 10.3 Composite availability

A service that needs all of several components in series has an
availability of roughly the product of theirs, assuming independent
failures:

$$
A_{\text{service}} = \prod_{i=1}^{n} A_i
$$

*Example:* three components at 99.95% each give
$0.9995^3 \approx 0.99850$, that is 99.85%, below the T1 target of
99.95%. Redundancy raises component availability: two independent
copies at 99.9% each give $1 - (0.001)^2 = 0.999999$. Independence is an
assumption; shared zones, shared configuration and shared releases
break it, so treat the result as an upper bound.

## 11. Failover and failback design

<!-- Guidance: Define who decides, what triggers a failover, how traffic and data move, and how the service returns. Questions: is failover automatic or human-initiated? What prevents a split brain? How long does DNS or client caching delay the switch? Pitfall: no failback plan, so the organisation runs for months on the scaled-down recovery site. -->

```mermaid
stateDiagram-v2
  [*] --> Normal
  Normal --> Degraded: HA absorbs component or zone failure
  Degraded --> Normal: Self-healing complete
  Degraded --> Assess: Impact exceeds disaster threshold
  Assess --> Normal: Recovered in place within RTO
  Assess --> Failover: Invoke DR (decision owner per tier)
  Failover --> RunningInRecovery: Data promoted, traffic switched, verified
  RunningInRecovery --> Failback: Primary rebuilt and resynchronised
  Failback --> Normal: Traffic returned and verified
```

| Topic | Design decision *(Example)* |
|---|---|
| Disaster threshold | Declared when the business service is below its MBCO and in-place recovery is not expected within half the RTO |
| Decision | Human-initiated, automated execution: one approved command or runbook step per tier; automatic failover only for HA within a region |
| Split brain prevention | Single writer enforced by a fencing step: the old primary is isolated before the replica is promoted |
| Traffic switch | Global traffic manager or DNS with low time to live for T0 and T1; client caches tested for the actual switch time |
| Data plane reliance | Failover uses pre-provisioned resources and data plane calls; no resource creation in an impaired control plane for T0 and T1 |
| Verification | Synthetic transactions and reconciliation of in-flight messages before declaring recovery |
| Failback | Separate, rehearsed procedure: rebuild the primary, resynchronise from the recovery location, switch in a planned window; or promote the recovery location permanently |

The step-by-step activation, notification and recovery procedure for
each system belongs in the IT Disaster Recovery Plan
(`ops/disaster-recovery-plan`), sections 5 to 7.

## 12. Testing and validation

<!-- Guidance: Set the minimum test per tier, what must be measured and what evidence is kept. Production failover tests are the only proof of RTO for T0 and T1. Pitfall: tests that recover a single database but never the full business service with its dependencies. -->

| Tier | Test type | Minimum frequency *(Example)* | What is measured | Evidence |
|---|---|---|---|---|
| T0 | Regional failover and failback in production | Quarterly | RTO, RPO, dependent workloads recovering | Test report, timings, issues |
| T1 | Failover of the full service to the recovery region | Every 6 months | End-to-end RTO, data loss against RPO, MBCO achieved | Test report signed by business owner |
| T2 | Failover in production or a production-like copy | Annually | RTO, RPO | Test report |
| T3 | Full restore of data and rebuild from code | Annually | Restore duration, data integrity | Restore log, checksums |
| T4 | Sample restore | Every 2 years | Restorability | Restore log |
| All | Tabletop exercise of decision making | Annually | Decision time, communication | Exercise notes |
| T0 to T2 | Fault injection of zone loss and dependency failure | Quarterly | HA behaviour, alerts | Experiment records using the Chaos Experiment (`ops/chaos-experiment`) |

Measured results replace the indicative ranges in section 6. A test
that misses an objective opens a remediation item with an owner and a
date, and the workload is reported as not meeting its tier until a
retest passes. Exercise planning in NIST SP 800-34 Rev. 1 (testing,
training and exercises) is a useful structure for the test programme.

## 13. Cost per tier

<!-- Guidance: Show the cost of each tier so that business owners choose knowingly. Use your own estimates; ratios below are examples, not benchmarks. Pitfall: presenting only infrastructure cost and ignoring the people time for testing and the licence cost of standby capacity. -->

| Tier | Pattern | Additional annual cost per workload as share of primary run cost *(Example)* | Main cost drivers |
|---|---|---|---|
| T0 | DR-04 or full-scale DR-03 | 90% to 110% | Duplicate capacity, cross-region data transfer, quarterly tests |
| T1 | DR-03 | 35% to 60% | Scaled-down standby, replication, reserved capacity, semi-annual tests |
| T2 | DR-02 | 15% to 30% | Replicated data stores, annual tests |
| T3 | DR-01 | 5% to 10% | Backup storage and copies |
| T4 | DR-01 | Under 5% | Backup storage |

*Example:* a T1 workload with a primary run cost of USD 400,000 per
year at a 45% uplift adds USD 180,000 per year for DR; moving it to T2
at a 20% uplift would add USD 80,000 but extend RTO from 1 hour to 8
hours. Put both options in front of the business owner with the impact
scores from section 4.

Charge or show the resilience cost to the owning business unit, for
example through the FinOps Cost Review (`ops/finops-cost-review`).

## 14. Exceptions and waivers

<!-- Guidance: Record every workload that does not meet its tier, with the risk accepted, the compensating measure and an expiry date. Pitfall: permanent exceptions that nobody reviews. -->

| Exception ID | Workload | Gap | Risk accepted by | Compensating measure | Remediation | Expires |
|---|---|---|---|---|---|---|
| EXC-RT-001 *(Example)* | WL-002 Payments API | RPO measured 12 min against 5 min | [@payments-owner], [@cio] | Transaction journal replicated separately allows replay | Move to synchronous journal replication, project [ID] | YYYY-MM-DD |
| EXC-RT-002 *(Example)* | Legacy billing (T2) | No recovery region; data centre only; measured restore 30 h against the T2 RTO of 8 h | [@finance-owner] | Daily offsite backup, tested restore 30 h | Replatform in wave [n] | YYYY-MM-DD |
| [EXC-RT-NNN] | [Workload] | [Gap] | [@owner] | [Measure] | [Plan] | [Date] |

Approval rule: exceptions for T0 and T1 are approved by [the CIO and
the business continuity manager]; T2 and below by [the platform lead].
No exception lasts longer than [12] months without re-approval.

## 15. Governance, roles and traceability

<!-- Guidance: Name who owns tiers, objectives, patterns and tests, and trace from business impact to tested evidence. Pitfall: the architecture team owning the tiers, so the business never really accepts the objectives. -->

### 15.1 RACI

| Activity | Business owner | Business continuity manager | Resilience architect | Platform team | Workload team | Security |
|---|---|---|---|---|---|---|
| BIA and impact scoring | A | R | C | I | C | C |
| Tier model and objectives | C | A | R | C | I | C |
| Tier assignment per workload | A | C | R | I | R | I |
| Pattern catalogue and reference designs | I | C | A | R | C | C |
| Implementation of the pattern | I | I | C | C | A | C |
| Testing and evidence | C | A | C | R | R | C |
| Exceptions | A | R | C | I | R | C |

R: responsible, A: accountable, C: consulted, I: informed.

### 15.2 Traceability

| BIA process | Workload | Tier | Objectives | Pattern | Last test | Result |
|---|---|---|---|---|---|---|
| *Example:* Take customer payments | WL-002 | T1 | RTO 1 h, RPO 5 min | HA-02, HA-03, DR-03 | YYYY-MM-DD | RTO 42 min met; RPO 12 min not met (EXC-RT-001) |
| *Example:* Ship orders | WL-004 | T2 | RTO 8 h, RPO 1 h | HA-02, DR-02 | YYYY-MM-DD | RTO 3.5 h, RPO 10 min, met |
| [Process] | [WL-NNN] | [Tier] | [Objectives] | [Patterns] | [Date] | [Result] |

Map regulatory duties that apply, for example ISO/IEC 27001:2022 Annex
A controls 5.29 and 5.30 on continuity and ICT readiness, or sector
rules on operational resilience, to the rows above.

## 16. Risks and open decisions

<!-- Guidance: Keep design-level risks here and in the programme RAID log (`project/raid-log`). Record open decisions with an owner and a date. -->

| ID | Type | Description | Owner | Due |
|---|---|---|---|---|
| RTR-001 *(Example)* | Risk | Recovery region capacity not guaranteed for T1 during a regional event | [@platform-lead] | Capacity reservations agreed by YYYY-MM-DD |
| RTR-002 *(Example)* | Risk | Shared CI/CD runs only in the primary region, blocking deployments during failover | [@devops-lead] | Pipeline in both regions by YYYY-MM-DD |
| RTD-OD-001 *(Example)* | Decision | Whether DR events count against the availability SLO | [@cio] | YYYY-MM-DD |
| RTD-OD-002 *(Example)* | Decision | Whether to rotate primary and recovery regions on a schedule | [@resilience-architect] | YYYY-MM-DD |
| [ID] | [Risk / Decision] | [Description] | [@owner] | [Date] |

## 17. Glossary and references

<!-- Guidance: Use the same definitions as the BIA and the DR plan. List sources with the date you checked them. -->

### 17.1 Glossary

| Term | Meaning |
|---|---|
| MTD | Maximum tolerable downtime: the longest a business process can be unavailable before the impact is unacceptable |
| RTO | Recovery time objective: the target maximum time to restore the service after a disruption |
| RPO | Recovery point objective: the maximum acceptable age of the data restored, measured back from the disruption |
| MBCO | Minimum business continuity objective: the reduced service level accepted during recovery |
| HA | High availability: continued service through local component or zone failures |
| DR | Disaster recovery: restoration of service after a major disruption, usually in another location |
| Pilot light | Recovery location with data and core services running but no application compute |
| Warm standby | Recovery location with a scaled-down, working copy that can take traffic at once |
| Failback | Returning service to the primary location after a failover |
| Split brain | Two copies both accepting writes after a partition, causing divergent data |

### 17.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems, csrc.nist.gov | May 2010, updated 11 November 2010; checked 2026-10-23 | BIA, MTD, RTO and RPO terms, alternate site types, testing and exercises |
| ISO/IEC 27031:2025, Cybersecurity: Information and communication technology readiness for business continuity, iso.org | Edition 2, May 2025 | ICT readiness structure; MBCO, RPO and RTO as ICT continuity objectives |
| AWS Well-Architected Framework, Reliability pillar, REL13-BP01 and REL13-BP02, docs.aws.amazon.com | Checked 2026-10-23 | DR strategy names and indicative ranges |
| Microsoft Azure Well-Architected Framework, Reliability, RE:09 Architecture strategies for disaster recovery, learn.microsoft.com | Page dated November 2025, checked 2026-10-23 | Criticality tiers, cold and warm standby terms, failback as a separate process |
| Google Cloud Architecture Center, Disaster recovery planning guide, docs.cloud.google.com | Last updated July 2024, checked 2026-10-23 | Cold, warm and hot pattern terms |
| ISO 22301:2019 with Amendment 1:2024, Business continuity management systems, iso.org | 2019, Amd 1 February 2024 | Business continuity management context |
| NIST SP 800-160 Vol. 2 Rev. 1, Developing Cyber-Resilient Systems, csrc.nist.gov | December 2021 | Cyber resiliency perspective for FS-005 |
| [Internal BIA, SLO policy] | [Version] | [Use] |

## Standard and licence note

Based on NIST SP 800-34 Rev. 1 (public domain) for contingency planning
terms and the link to the business impact analysis, and on the disaster
recovery strategies described in the AWS Well-Architected Framework
Reliability pillar, with the equivalent terms from the Microsoft Azure
Well-Architected Framework and the Google Cloud DR planning guide.
Structure aligned with ISO/IEC 27031:2025, which is a copyrighted
standard: only its title, edition and the names of the continuity
objectives it uses are cited, and no text, definitions or tables are
reproduced. AWS, Microsoft Azure and Google Cloud are trademarks of
their owners; this template is not affiliated with or endorsed by them.
This template is original text written for this collection; tier
objectives, cost ratios and results are examples, not normative
values. Check the current official versions before use. Template
licence: MIT.