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.

Document control

Approvals

Revision history

Contents

1. Introduction and scope
2. Criticality tier model
3. Recovery and availability objectives per tier
4. Workload tier assignment
5. Failure scenarios and scope of protection
6. Pattern catalogue
7. Reference design per tier
8. Data protection and replication
9. Zonal and regional topology
10. Dependencies and tier inheritance
11. Failover and failback design
12. Testing and validation
13. Cost per tier
14. Exceptions and waivers
15. Governance, roles and traceability
16. Risks and open decisions
17. Glossary and references

1. Introduction and scope

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

1.4 Design principles

2. Criticality tier model

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.

2.2 Tier definitions

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

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

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

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

6. Pattern catalogue

6.1 HA patterns

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.

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

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

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

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

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

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:

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

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

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

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

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

15.1 RACI

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

15.2 Traceability

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

17. Glossary and references

17.1 Glossary

17.2 References

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.