# Cyber Resiliency Design: [System or mission name]

> Engineering design record for making a system able to anticipate,
> withstand, recover from and adapt to attacks and other adversity that
> exploit or arrive through cyber resources. It follows the cyber
> resiliency engineering framework in NIST SP 800-160 Volume 2
> Revision 1, *Developing Cyber-Resilient Systems: A Systems Security
> Engineering Approach* (December 2021): goals, objectives, techniques,
> implementation approaches, strategic and structural design principles,
> and the effects vocabulary used for adversary-oriented analysis. It
> maps selected measures to NIST SP 800-53 Revision 5 controls and
> models adversary behaviour with MITRE ATT&CK. Replace every
> `[bracketed]` value and every row marked *Example*.

<!--
Guidance: How to use this template
- Write one design per system of interest (a system, a service or a
  mission thread that crosses several systems). The Security
  architecture (`security/security-architecture`) describes the
  protection baseline; this document adds what happens when that
  baseline has already been breached.
- Start from the mission, not from the techniques. Sections 2 and 3
  (critical functions and adversary assumptions) decide everything that
  follows. A technique chosen without a mission reason is decoration.
- The framework assumes a capable adversary who is already inside some
  part of the system. Keep that assumption explicit in every section.
- Do not try to apply all 14 techniques. Select a small, coherent set,
  record the ones rejected and why, and analyse conflicts between them.
- Keep the NIST construct names exactly as published so reviewers can
  trace them. Write everything else in your own words.
- Related documents: Threat model (`security/threat-model`), Attack
  tree (`security/attack-tree`), Zero trust architecture plan
  (`security/zero-trust-architecture`), Resilience tiering and HA/DR
  design (`architecture/resilience-tiering-ha-dr-design`), Disaster
  recovery plan (`ops/disaster-recovery-plan`), Business continuity
  (`compliance/business-continuity`), Incident response plan
  (`compliance/incident-response-plan`), NIST CSF profile
  (`compliance/nist-csf`).
-->

## Document control

<!-- Guidance: Identify the system of interest, its mission owner and the risk executive who accepts residual risk. A change to the adversary assumptions or to the critical function list is a new major version. -->

| Field | Value |
|---|---|
| Document ID | [CRD-001] |
| System of interest | [Name, version, boundary reference] |
| Mission or business function supported | [Function name and owner] |
| Life cycle stage | [Concept / Development / Production / Utilisation and support / Retirement] |
| Framework basis | NIST SP 800-160 Vol. 2 Rev. 1 (December 2021); NIST SP 800-53 Rev. 5 (release in use: [5.2.0]); MITRE ATT&CK (version in use: [v20]) |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@resiliency-engineer] |
| Approvers/reviewers | [@mission-owner], [@security-architect], [@sre-lead], [@risk-executive] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |
| Related documents | [Security architecture], [Threat model], [DR plan], [Business impact analysis] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Mission or business owner | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Security architect | [@name] | [Decision] | YYYY-MM-DD |
| Operations and SRE lead | [@name] | [Decision] | YYYY-MM-DD |
| Risk executive (residual risk acceptance) | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved; four techniques selected for the settlement thread |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Adversary assumptions updated for the new ATT&CK release; immutable backup approach added |

## Contents

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

1. [Purpose, scope and system of interest](#1-purpose-scope-and-system-of-interest)
2. [Mission, critical functions and assets](#2-mission-critical-functions-and-assets)
3. [Adversary and threat assumptions](#3-adversary-and-threat-assumptions)
4. [Cyber resiliency goals and objectives](#4-cyber-resiliency-goals-and-objectives)
5. [Strategic design principles](#5-strategic-design-principles)
6. [Techniques and implementation approaches](#6-techniques-and-implementation-approaches)
7. [Structural design principles](#7-structural-design-principles)
8. [Architecture changes and alternatives](#8-architecture-changes-and-alternatives)
9. [Effects on adversary behaviour](#9-effects-on-adversary-behaviour)
10. [Control mapping to SP 800-53 Rev. 5](#10-control-mapping-to-sp-800-53-rev-5)
11. [Effectiveness measures](#11-effectiveness-measures)
12. [Verification and exercises](#12-verification-and-exercises)
13. [Residual risk and recommendations](#13-residual-risk-and-recommendations)
14. [Traceability matrix](#14-traceability-matrix)
15. [Glossary and references](#15-glossary-and-references)

## 1. Purpose, scope and system of interest

<!-- Guidance: Say why resiliency analysis is being done now and what it must decide. Questions: is this a new design, a retrofit of a system in production, or a review before a major change? Which decisions will the recommendations feed? Pitfall: a boundary drawn around the application only, which leaves out the identity provider, the CI/CD pipeline and the backup system that an adversary will use. -->

### 1.1 Purpose

This document records the cyber resiliency analysis and design for
[system of interest]. It answers four questions: which mission functions
must keep working or be restored when an adversary has a foothold, what
the system must do to make that possible, which changes to the
architecture deliver it, and how well those changes are expected to work
against the assumed adversary.

SP 800-160 Volume 2 Revision 1 describes a tailorable analysis process
in section 3.2: understand the context, develop the cyber resiliency
baseline, analyse the system, define and analyse specific alternatives,
and develop recommendations. Sections 2 to 13 of this document follow
that order.

### 1.2 Scope

| In scope | Out of scope |
|---|---|
| *Example:* Payment initiation, settlement batch, ledger database, message broker | Marketing website (no mission dependency) |
| *Example:* Identity provider tenant, privileged access path, CI/CD pipeline that deploys the system | Corporate e-mail (covered by enterprise programme) |
| *Example:* Backup platform, key management service, monitoring and logging pipeline | Physical site security (covered by facilities) |
| [Item] | [Item] |

### 1.3 Analysis triggers and decisions to support

| Trigger | Decision this document supports |
|---|---|
| *Example:* Ransomware incident at a peer institution | Whether to fund an isolated recovery environment |
| *Example:* Migration of the ledger to a managed database | Which resiliency properties must be preserved in the target design |
| [Trigger] | [Decision] |

### 1.4 Assumptions and constraints

| ID | Assumption or constraint | Consequence for the design |
|---|---|---|
| ASM-001 *(Example)* | Some system elements will be compromised without detection for weeks | Recovery must not rely on the integrity of production backups alone |
| ASM-002 *(Example)* | The hosting provider's control plane is trusted, the tenant administration plane is not | Privilege restriction effort focuses on tenant roles and automation identities |
| ASM-003 *(Example)* | Budget allows one new platform service this financial year | Alternatives in section 8 are ranked by cost and effect |
| [ASM-NNN] | [Assumption] | [Consequence] |

## 2. Mission, critical functions and assets

<!-- Guidance: Identify what must survive. Use the business impact analysis where one exists and translate it into technical dependencies. Questions: which functions are mission essential? What is the tolerable degraded mode? Which shared services do all of them depend on? Pitfall: listing every server as critical, which removes the ability to prioritise. -->

### 2.1 Mission essential functions

| ID | Function | Owner | Maximum tolerable downtime | Minimum acceptable degraded mode | Recovery priority |
|---|---|---|---|---|---|
| MEF-001 *(Example)* | Accept and authorise card payments | @payments-lead | 30 minutes | Authorise up to a stand-in limit without real-time balance check | 1 |
| MEF-002 *(Example)* | Settle the daily batch with the scheme | @settlement-lead | 8 hours | Manual file submission from the recovery environment | 2 |
| MEF-003 *(Example)* | Customer statement generation | @servicing-lead | 5 days | Deferred, regenerated from the ledger | 4 |
| [MEF-NNN] | [Function] | [@owner] | [Duration] | [Degraded mode] | [1 to 5] |

### 2.2 Critical assets and dependencies

Record the system elements, data and services whose loss or corruption
would stop a mission essential function. Include shared services that
many functions depend on: SP 800-160 Volume 2 calls these common critical
assets, and they are where resiliency investment usually returns most.
Critical resiliency assets use the prefix `CRA-` so that they cannot be
confused with SP 800-53 Assessment, Authorization and Monitoring (CA)
control identifiers in section 10.

| ID | Asset | Type | Supports | Common critical asset | Integrity source of truth |
|---|---|---|---|---|---|
| CRA-001 *(Example)* | Ledger database | Data store | MEF-001, MEF-002, MEF-003 | Yes | Ledger plus signed daily snapshot |
| CRA-002 *(Example)* | Identity provider tenant | Service | All | Yes | Configuration exported to code repository |
| CRA-003 *(Example)* | CI/CD pipeline and artefact registry | Service | All changes | Yes | Signed artefacts with provenance |
| CRA-004 *(Example)* | Key management service | Service | MEF-001, MEF-002 | Yes | Provider-held, key backup in separate tenant |
| CRA-005 *(Example)* | Authorisation service | Application | MEF-001 | No | Release artefact and configuration repository |
| [CRA-NNN] | [Asset] | [Type] | [MEF IDs] | [Yes / No] | [Source] |

```mermaid
flowchart LR
  MEF1[MEF-001 Authorise payments] --> CA5[CRA-005 Authorisation service]
  MEF2[MEF-002 Settle batch] --> CA1[CRA-001 Ledger]
  CA5 --> CA1
  CA5 --> CA4[CRA-004 Key management]
  CA1 --> CA4
  CA5 --> CA2[CRA-002 Identity provider]
  CA1 --> CA2
  CA3[CRA-003 CI/CD pipeline] -. deploys .-> CA5
  CA3 -. deploys .-> CA1
```

## 3. Adversary and threat assumptions

<!-- Guidance: State who you are designing against, in enough detail to analyse effects. Questions: what are the adversary's goals, capabilities and persistence? Which entry points and techniques are most likely? Which non-adversarial events (failure, error, disaster) must the same design also handle? Pitfall: designing against a generic "hacker" so that no technique can be shown to be necessary or sufficient. -->

### 3.1 Adversary profiles

| ID | Adversary | Goal | Capability | Time horizon | Stealth |
|---|---|---|---|---|---|
| ADV-001 *(Example)* | Financially motivated ransomware affiliate | Extortion through encryption and data theft | Buys initial access, uses commodity and custom tooling | Days to weeks | Moderate, tries to avoid detection until impact |
| ADV-002 *(Example)* | Fraud group with insider help | Divert settlement funds | Legitimate credentials for one operations role | Months | High |
| ADV-003 *(Example)* | Supply chain attacker | Persistent access to many customers | Compromise of a build dependency | Months to years | Very high |
| [ADV-NNN] | [Adversary] | [Goal] | [Capability] | [Horizon] | [Stealth] |

### 3.2 Adversary behaviour model (MITRE ATT&CK)

Describe the expected attack path with ATT&CK tactics and the techniques
you consider most relevant. ATT&CK Enterprise v20 (October 2026) lists
15 tactics: Reconnaissance, Resource Development, Initial Access,
Execution, Persistence, Privilege Escalation, Stealth, Defense
Impairment, Credential Access, Discovery, Lateral Movement, Collection,
Command and Control, Exfiltration and Impact. ATT&CK v19 (April 2026)
split the former Defense Evasion tactic into Stealth, which keeps ID
TA0005, and Defense Impairment (TA0112); v20 keeps that split. Releases
up to v18, and the mapping tables in Appendix F of SP 800-160 Volume 2
Revision 1, use the single Defense Evasion tactic, so map older
analyses to the tactic that matches the behaviour (hiding activity is
Stealth, disabling or degrading defences is Defense Impairment). Record
the version you used and check the current matrix at attack.mitre.org
before each review.

| Scenario | Adversary | Tactic | Technique (ATT&CK ID and name) | Target asset | Notes |
|---|---|---|---|---|---|
| SCN-001 *(Example)* | ADV-001 | Initial Access | [T1566 Phishing] | Operations workstation | Leads to credential theft |
| SCN-001 *(Example)* | ADV-001 | Credential Access | [Technique ID and name] | CRA-002 | Session token theft |
| SCN-001 *(Example)* | ADV-001 | Impact | [T1486 Data Encrypted for Impact] | CRA-001, backups | Backups are a primary target |
| SCN-002 *(Example)* | ADV-002 | Impact | [Technique ID and name] | CRA-001 | Small, repeated ledger manipulation |
| SCN-003 *(Example)* | ADV-003 | Initial Access | [T1195 Supply Chain Compromise] | CRA-003 | Malicious package version |
| [SCN-NNN] | [ADV-NNN] | [Tactic] | [ID and name] | [CRA-NNN] | [Notes] |

Use the Threat model (`security/threat-model`) and Attack tree
(`security/attack-tree`) for the detailed analysis; summarise here only
what the resiliency design must answer.

### 3.3 Non-adversarial adversity

| ID | Event | Why it matters for this design |
|---|---|---|
| NAD-001 *(Example)* | Region-wide provider outage | Same recovery path as a destructive attack, but without integrity doubt |
| NAD-002 *(Example)* | Operator deletes a production table | Tests the protected backup and restore approach |
| [NAD-NNN] | [Event] | [Relevance] |

## 4. Cyber resiliency goals and objectives

<!-- Guidance: Interpret the four goals and eight objectives for this system and set priorities. Questions: which objective matters most for each mission function? How would you know an objective is met? Pitfall: giving every objective "high" priority, which tells engineers nothing about trade-offs. -->

### 4.1 Goals

SP 800-160 Volume 2 defines four goals. Write what each means for this
system in one or two sentences.

| Goal | Meaning for [system of interest] |
|---|---|
| Anticipate | *Example:* Know the current threat picture for payments, keep tested recovery plans and recognise early signs of ledger tampering |
| Withstand | *Example:* Keep authorising card payments, in stand-in mode if needed, while part of the estate is compromised |
| Recover | *Example:* Restore settlement within 8 hours from a known-good state, and verify that the restored state is trustworthy |
| Adapt | *Example:* Change the architecture after each incident or major threat shift so the same path cannot be reused |

### 4.2 Objectives

| Objective | Interpretation for this system | Priority | Related MEF | Indicative measure (section 11) |
|---|---|---|---|---|
| Prevent or Avoid | *Example:* Make the ledger write path unreachable from user networks | Medium | MEF-001, MEF-002 | MOE-001 |
| Prepare | *Example:* Hold clean, tested recovery images and runbooks for every critical asset | High | All | MOE-002 |
| Continue | *Example:* Keep payment authorisation running in degraded mode for at least 24 hours | High | MEF-001 | MOE-003 |
| Constrain | *Example:* Limit a compromised workload to its own segment and its own data | High | MEF-001, MEF-002 | MOE-004 |
| Reconstitute | *Example:* Rebuild the settlement service in the isolated recovery environment | High | MEF-002 | MOE-005 |
| Understand | *Example:* Know which assets are affected and how far the adversary has progressed | Medium | All | MOE-006 |
| Transform | *Example:* Change operational procedures, such as moving manual approvals out of e-mail | Low | MEF-002 | [MOE-NNN] |
| Re-Architect | *Example:* Replace the shared batch server with per-function services | Medium | MEF-002, MEF-003 | [MOE-NNN] |

Appendix D of SP 800-160 Volume 2 lists representative sub-objectives
and capabilities for each objective. Use them as a prompt list and write
tailored sub-objectives for this system, numbered under the objective
(for example `OBJ-CON-01`).

| ID | Objective | Tailored sub-objective | Owner |
|---|---|---|---|
| OBJ-CON-01 *(Example)* | Continue | Authorisation keeps working when the ledger is read-only | @payments-lead |
| OBJ-CST-01 *(Example)* | Constrain | No single automation identity can modify both production data and its backups | @platform-lead |
| OBJ-REC-01 *(Example)* | Reconstitute | Settlement can be rebuilt without using any production credential | @settlement-lead |
| [OBJ-XXX-NN] | [Objective] | [Sub-objective] | [@owner] |

## 5. Strategic design principles

<!-- Guidance: Strategic principles express the organisation's risk management strategy and steer the whole analysis. Questions: does each principle apply to this system, and what does it change in the design? Pitfall: copying the list without a consequence for each row. -->

| Strategic design principle | Applies | Consequence for this design |
|---|---|---|
| Focus on common critical assets | Yes | *Example:* Identity provider, pipeline, key management and backups receive the strongest measures (CRA-001 to CRA-004) |
| Support agility and architect for adaptability | Yes | *Example:* Settlement logic packaged so it can run in the recovery environment without code changes |
| Reduce attack surfaces | Yes | *Example:* Remove standing administrative access and unused integration endpoints |
| Assume compromised resources | Yes | *Example:* Every recovery step validates integrity before trusting restored data |
| Expect adversaries to evolve | Yes | *Example:* Adversary assumptions reviewed at each ATT&CK release and after each sector incident |

## 6. Techniques and implementation approaches

<!-- Guidance: Select techniques and the specific approaches that implement them. Record why each technique is selected or not, which objectives it supports and where it conflicts with another choice. Questions: is the approach mature enough to adopt? Can the team operate it? Pitfall: Deception or Unpredictability selected because they sound advanced, without an operating model to run them. -->

### 6.1 Technique selection

The table lists all 14 techniques and their implementation approaches as
named in SP 800-160 Volume 2 Revision 1 (Tables D-2 and D-4). Mark which
approaches you adopt and give the reason in your own words.

| Technique | Implementation approaches (NIST names) | Selected approach | Objectives supported | Decision and reason |
|---|---|---|---|---|
| Adaptive Response | Dynamic Reconfiguration; Dynamic Resource Allocation; Adaptive Management | *Example:* Dynamic Reconfiguration | Continue, Constrain | *Example:* Selected: switch authorisation to stand-in mode automatically on ledger integrity alarm |
| Analytic Monitoring | Monitoring and Damage Assessment; Sensor Fusion and Analysis; Forensic and Behavioral Analysis | *Example:* Monitoring and Damage Assessment; Sensor Fusion and Analysis | Understand, Prepare | *Example:* Selected: correlate ledger, identity and pipeline events |
| Contextual Awareness | Dynamic Resource Awareness; Dynamic Threat Awareness; Mission Dependency and Status Visualization | *Example:* Mission Dependency and Status Visualization | Understand, Continue | *Example:* Selected: dashboard of MEF status for the incident commander |
| Coordinated Protection | Calibrated Defense-in-Depth; Consistency Analysis; Orchestration; Self-Challenge | *Example:* Orchestration; Self-Challenge | Prepare, Withstand | *Example:* Selected: recovery orchestration and quarterly purple-team exercises |
| Deception | Obfuscation; Disinformation; Misdirection; Tainting | *Example:* Tainting | Understand | *Example:* Selected (limited): canary records in the ledger detect exfiltration and tampering |
| Diversity | Architectural Diversity; Design Diversity; Synthetic Diversity; Information Diversity; Path Diversity; Supply Chain Diversity | *Example:* Path Diversity | Continue | *Example:* Selected: second network path to the scheme |
| Dynamic Positioning | Functional Relocation of Sensors; Functional Relocation of Cyber Resources; Asset Mobility; Fragmentation; Distributed Functionality | *Example:* Functional Relocation of Cyber Resources | Continue, Reconstitute | *Example:* Selected: settlement can move to the recovery environment |
| Non-Persistence | Non-Persistent Information; Non-Persistent Services; Non-Persistent Connectivity | *Example:* Non-Persistent Services; Non-Persistent Connectivity | Constrain, Prevent or Avoid | *Example:* Selected: immutable, frequently rebuilt workloads; administrative sessions created on demand |
| Privilege Restriction | Trust-Based Privilege Management; Attribute-Based Usage Restriction; Dynamic Privileges | *Example:* Dynamic Privileges | Constrain, Prevent or Avoid | *Example:* Selected: just-in-time elevation with approval |
| Realignment | Purposing; Offloading; Restriction; Replacement; Specialization; Evolvability | *Example:* Restriction; Offloading | Prevent or Avoid, Re-Architect | *Example:* Selected: remove file-share access from the settlement server; offload statements to a separate service |
| Redundancy | Protected Backup and Restore; Surplus Capacity; Replication | *Example:* Protected Backup and Restore | Reconstitute, Prepare | *Example:* Selected: immutable, logically isolated backups with separate credentials |
| Segmentation | Predefined Segmentation; Dynamic Segmentation and Isolation | *Example:* Predefined Segmentation; Dynamic Segmentation and Isolation | Constrain | *Example:* Selected: per-function segments, automated quarantine of a compromised workload |
| Substantiated Integrity | Integrity Checks; Provenance Tracking; Behavior Validation | *Example:* Integrity Checks; Provenance Tracking | Understand, Reconstitute | *Example:* Selected: signed ledger snapshots, signed build artefacts with provenance |
| Unpredictability | Temporal Unpredictability; Contextual Unpredictability | None | n/a | *Example:* Not selected in this version: no team to operate it; revisit at next review |

### 6.2 Conflicts and synergies

SP 800-160 Volume 2 (Table D-3) notes that some techniques support each
other and others interfere. Record the interactions that matter here.

| ID | Technique pair | Interaction | Handling |
|---|---|---|---|
| INT-001 *(Example)* | Non-Persistence and Analytic Monitoring | Conflict: rebuilt workloads destroy forensic evidence | Stream logs and memory snapshots off-host before rebuild |
| INT-002 *(Example)* | Segmentation and Adaptive Response | Synergy: predefined segments make automated quarantine safe | Quarantine playbook uses segment boundaries |
| INT-003 *(Example)* | Redundancy and Substantiated Integrity | Synergy: redundant copies are only useful if their integrity can be proven | Each backup set carries a signed manifest |
| INT-004 *(Example)* | Diversity and operating cost | Conflict: two network providers double the operational procedures | Accepted for MEF-001 only |
| [INT-NNN] | [Pair] | [Conflict / Synergy] | [Handling] |

### 6.3 Selection criteria

Use these criteria, which reflect the factors discussed in section 3.1
of SP 800-160 Volume 2, to justify each decision in 6.1:

- Contribution to the high-priority objectives in section 4.2.
- Fit with the risk management strategy and the strategic principles in
  section 5.
- Suitability for the system type (enterprise IT, cloud service,
  operational technology, embedded).
- Reuse of existing investments in security, continuity and
  reliability engineering.
- The architectural location where the approach can be applied.
- The expected effect on the adversary behaviours in section 3.2.
- Maturity of the technology and the team's ability to operate it.

## 7. Structural design principles

<!-- Guidance: Structural principles guide where and how techniques are applied in the architecture. Questions: which principle drives each architecture change in section 8? Which principles are knowingly not followed, and why? Pitfall: principles applied in the design but lost in implementation because no requirement carries them. -->

| ID | Structural design principle | Applied | Where it shows in the design | Requirement |
|---|---|---|---|---|
| SDP-01 | Limit the need for trust | Yes | *Example:* Recovery environment does not trust production identities | REQ-CR-001 |
| SDP-02 | Control visibility and use | Yes | *Example:* Ledger schema and endpoints hidden from non-payment segments | REQ-CR-002 |
| SDP-03 | Contain and exclude behaviors | Yes | *Example:* Workload sandboxing and egress allow-lists | REQ-CR-003 |
| SDP-04 | Layer defenses and partition resources | Yes | *Example:* Separate segments per mission function | REQ-CR-004 |
| SDP-05 | Plan and manage diversity | Partly | *Example:* Network path diversity only | REQ-CR-005 |
| SDP-06 | Maintain redundancy | Yes | *Example:* Isolated backups and warm standby for MEF-001 | REQ-CR-006 |
| SDP-07 | Make resources location-versatile | Yes | *Example:* Settlement runs in production or recovery environment | REQ-CR-007 |
| SDP-08 | Leverage health and status data | Yes | *Example:* Health signals drive stand-in mode | REQ-CR-008 |
| SDP-09 | Maintain situational awareness | Yes | *Example:* Mission status dashboard | REQ-CR-009 |
| SDP-10 | Manage resources (risk-) adaptively | Yes | *Example:* Privileges raised only with approval and time limit | REQ-CR-010 |
| SDP-11 | Maximize transience | Yes | *Example:* Workloads rebuilt at least every [7] days | REQ-CR-011 |
| SDP-12 | Determine ongoing trustworthiness | Yes | *Example:* Periodic integrity attestation of ledger snapshots | REQ-CR-012 |
| SDP-13 | Change or disrupt the attack surface | No | *Example:* Deferred with Unpredictability | n/a |
| SDP-14 | Make the effects of deception and unpredictability user-transparent | Partly | *Example:* Canary records excluded from customer views and reports | REQ-CR-013 |

## 8. Architecture changes and alternatives

<!-- Guidance: Describe the cyber resiliency baseline (what the system already does), then the alternatives considered, and the chosen changes. Questions: what does each alternative cost, what does it change in operations, and which objectives does it improve? Pitfall: one alternative presented as a foregone conclusion with no comparison. -->

### 8.1 Cyber resiliency baseline

Record what the current design already provides, by technique, before
proposing changes. Existing backup, high availability and monitoring
capabilities often deliver part of an approach already.

| Technique | Existing capability | Gap against objectives |
|---|---|---|
| Redundancy *(Example)* | Nightly backups in the same tenant, replicated to a second region | Backups deletable with production administrator rights |
| Analytic Monitoring *(Example)* | Application and infrastructure logs to the SIEM | No ledger integrity monitoring, pipeline events not collected |
| Segmentation *(Example)* | One network segment for all payment services | Compromise of any service exposes the ledger |
| [Technique] | [Capability] | [Gap] |

### 8.2 Alternatives

| ID | Alternative | Techniques | Objectives improved | Cost (one-off / yearly) | Operational impact | Assessment |
|---|---|---|---|---|---|---|
| ALT-001 *(Example)* | Immutable backups in a separate tenant with separate identities | Redundancy, Privilege Restriction | Reconstitute, Constrain | [USD 40,000 / USD 15,000] | Restore drills move to the new tenant | Preferred |
| ALT-002 *(Example)* | Isolated recovery environment with pre-staged settlement images | Dynamic Positioning, Redundancy, Coordinated Protection | Reconstitute, Continue | [USD 180,000 / USD 60,000] | Quarterly rebuild exercise | Preferred for MEF-002 |
| ALT-003 *(Example)* | Per-function segmentation with automated quarantine | Segmentation, Adaptive Response | Constrain, Continue | [USD 70,000 / USD 10,000] | Firewall policy maintained as code | Preferred |
| ALT-004 *(Example)* | Second, independent payment authorisation stack on a different technology | Diversity | Continue | [USD 600,000 / USD 200,000] | Two codebases to maintain | Rejected: cost exceeds benefit at current threat level |
| [ALT-NNN] | [Alternative] | [Techniques] | [Objectives] | [Cost] | [Impact] | [Assessment] |

### 8.3 Target architecture

Show the target state with the chosen alternatives, the trust
boundaries between tenants and the one-way data paths. The example
below combines ALT-001, ALT-002 and the stand-in mode of MEF-001.

```mermaid
flowchart TB
  subgraph PROD[Production tenant]
    AUTH[Authorisation service<br/>stand-in mode]
    LEDGER[(Ledger)]
    SETTLE[Settlement batch]
    MON[Integrity monitor]
  end
  subgraph BKP[Backup tenant, separate identities]
    IMM[(Immutable backups<br/>signed manifests)]
  end
  subgraph IRE[Isolated recovery environment]
    IMG[Clean images]
    RSET[Settlement rebuild]
  end
  LEDGER -- one-way copy --> IMM
  MON -- alarm --> AUTH
  IMM -- verified restore --> RSET
  IMG --> RSET
  RSET -- manual file --> SCHEME[Card scheme]
  SETTLE --> SCHEME
```

### 8.4 Architectural locations

SP 800-160 Volume 2 (Table D-5) relates approaches to the architectural
layers where they can be applied. Record where each chosen change sits,
so that each one has an owning team.

| Change | Layer | Owning team |
|---|---|---|
| ALT-001 immutable backups *(Example)* | Information storage management | Platform |
| ALT-002 recovery environment *(Example)* | Technical system as a whole; operations | Platform and settlement |
| ALT-003 segmentation and quarantine *(Example)* | Networking and communications; cloud and virtualisation | Network and security operations |
| [Change] | [Hardware and firmware / Networking and communications / Cloud, virtualisation, middleware and infrastructure / Operating system / Other software / Application / Information storage management / Technical system as a whole / Operations / Support / Environment of operation] | [Team] |

## 9. Effects on adversary behaviour

<!-- Guidance: Use the effects vocabulary from SP 800-160 Volume 2 Appendix F to state what each change does to the adversary. Questions: does the change stop the activity, slow it, limit its damage or make it visible? Pitfall: claiming "prevents" for a measure that only detects. -->

SP 800-160 Volume 2 groups intended effects on threat events into five
high-level effects: Redirect (deter, divert, deceive), Preclude
(expunge, preempt, negate), Impede (contain, degrade, delay, exert),
Limit (shorten, reduce) and Expose (detect, scrutinize, reveal). Rate
each change against the scenarios from section 3.2.

| Scenario | Tactic | Change | Intended effect | Expected result | Confidence |
|---|---|---|---|---|---|
| SCN-001 *(Example)* | Impact | ALT-001 | Limit (reduce) | Encrypted production data restored from untouched backups | High |
| SCN-001 *(Example)* | Lateral Movement | ALT-003 | Impede (contain) | Spread stops at the segment boundary | Medium |
| SCN-002 *(Example)* | Impact | Canary records, integrity monitor | Expose (detect) | Tampering visible within one reconciliation cycle | Medium |
| SCN-003 *(Example)* | Initial Access | Provenance tracking | Preclude (negate) | Unsigned or unproven artefacts are refused at deploy | Medium |
| [SCN-NNN] | [Tactic] | [Change] | [Effect] | [Result] | [Low / Medium / High] |

## 10. Control mapping to SP 800-53 Rev. 5

<!-- Guidance: Link each selected approach to the controls that implement it, so the design enters the system security plan and the assessment process. Appendix E of SP 800-160 Volume 2 identifies the SP 800-53 controls that directly support each technique; use it as the starting point and check control identifiers in the current release. Pitfall: mapping a technique to a broad base control that the system already claims, which adds nothing. -->

| Approach | SP 800-53 Rev. 5 control | Control name (short) | Implementation in this design | Status |
|---|---|---|---|---|
| Protected Backup and Restore *(Example)* | CP-9, CP-9(8) | System backup; cryptographic protection | Immutable, encrypted backups in the backup tenant | Planned |
| Functional Relocation of Cyber Resources *(Example)* | CP-2(8) | Contingency plan: identify critical assets | Recovery environment sized for MEF-002 | Planned |
| Dynamic Segmentation and Isolation *(Example)* | SC-7(20), SC-7(21) | Boundary protection: dynamic isolation; isolation of components | Automated quarantine playbook | In design |
| Non-Persistent Services *(Example)* | SI-14 | Non-persistence | Rebuild cycle for workloads | Implemented |
| Dynamic Privileges *(Example)* | AC-6, AC-2(6) | Least privilege; dynamic privilege management | Just-in-time elevation | Implemented |
| Integrity Checks *(Example)* | SI-7 and enhancements | Software, firmware and information integrity | Signed ledger snapshots, deploy-time signature checks | Planned |
| Monitoring and Damage Assessment *(Example)* | SI-4 and enhancements, IR-4 | System monitoring; incident handling | Integrity monitor and damage assessment runbook | In design |
| Tainting *(Example)* | SI-20 | Tainting | Canary ledger records | Planned |
| Self-Challenge *(Example)* | CA-8 | Penetration testing | Purple-team exercises in section 12 | Planned |
| [Approach] | [Control ID] | [Name] | [Implementation] | [Status] |

Record the SP 800-53 release used for the mapping in Document control.
Release 5.2.0 (August 2025) added and revised controls on software
update and integrity topics; check the Cybersecurity and Privacy
Reference Tool at csrc.nist.gov for later releases.

## 11. Effectiveness measures

<!-- Guidance: Define how you will know the design works. Distinguish measures of effectiveness (does the mission outcome improve?) from measures of performance (does the mechanism work as specified?). Pitfall: counting deployed tools instead of measuring recovery or containment. -->

| ID | Objective | Measure | Type | Target | Method | Frequency |
|---|---|---|---|---|---|---|
| MOE-001 *(Example)* | Prevent or Avoid | Number of network paths from user segments to the ledger write interface | Performance | 0 | Automated reachability analysis | Weekly |
| MOE-002 *(Example)* | Prepare | Share of critical assets with a restore test passed in the last 90 days | Effectiveness | 100 % | Restore drill records | Monthly |
| MOE-003 *(Example)* | Continue | Duration authorisation stays available in stand-in mode during an exercise | Effectiveness | 24 hours or more | Game day | Twice a year |
| MOE-004 *(Example)* | Constrain | Time from detection to quarantine of a compromised workload | Performance | 15 minutes or less | Exercise and incident records | Quarterly |
| MOE-005 *(Example)* | Reconstitute | Time to rebuild settlement in the recovery environment from verified backups | Effectiveness | 8 hours or less | Recovery exercise | Quarterly |
| MOE-006 *(Example)* | Understand | Share of exercise adversary actions detected and correctly attributed to an asset | Effectiveness | 80 % or more | Purple-team scoring | Quarterly |
| [MOE-NNN] | [Objective] | [Measure] | [Effectiveness / Performance] | [Target] | [Method] | [Frequency] |

All targets above are illustrative. Set targets from the business
impact analysis and the maximum tolerable downtime in section 2.1.

## 12. Verification and exercises

<!-- Guidance: Plan how each measure is tested before go-live and repeatedly afterwards. Questions: who plays the adversary, who scores, and what counts as a pass? Pitfall: tabletop exercises only, which never prove that a restore actually works. -->

| ID | Activity | Objectives tested | Scenario | Pass criteria | Owner | Cadence |
|---|---|---|---|---|---|---|
| VER-001 *(Example)* | Restore drill from the backup tenant | Prepare, Reconstitute | NAD-002 | MOE-002 and MOE-005 met | @platform-lead | Quarterly |
| VER-002 *(Example)* | Ransomware game day | Continue, Constrain, Reconstitute | SCN-001 | MOE-003, MOE-004, MOE-005 met | @sre-lead | Twice a year |
| VER-003 *(Example)* | Purple-team exercise against ledger tampering | Understand | SCN-002 | MOE-006 met | @security-operations | Quarterly |
| VER-004 *(Example)* | Pipeline compromise simulation | Prevent or Avoid, Understand | SCN-003 | Unsigned artefact blocked, alert raised | @devsecops-lead | Twice a year |
| [VER-NNN] | [Activity] | [Objectives] | [Scenario] | [Criteria] | [@owner] | [Cadence] |

Plan the game days with the Game day plan (`ops/game-day-plan`) and
fault injection with the Chaos experiment template
(`ops/chaos-experiment`). Record each result and feed failures into
section 13.

## 13. Residual risk and recommendations

<!-- Guidance: State what remains after the selected changes and what the organisation decides to do about it. Questions: which scenarios still reach a mission essential function? Who accepts the risk, and until when? Pitfall: residual risk written as a single sentence with no owner or review date. -->

### 13.1 Residual risk

| ID | Scenario | Residual risk | Likelihood | Impact | Decision | Owner | Review by |
|---|---|---|---|---|---|---|---|
| RR-001 *(Example)* | SCN-002 | Small manipulation below reconciliation thresholds may persist for one cycle | Medium | Medium | Accept, with monthly forensic sampling | @risk-executive | YYYY-MM-DD |
| RR-002 *(Example)* | SCN-003 | Compromised dependency signed by a legitimate maintainer | Low | High | Reduce: add dependency review for critical packages | @devsecops-lead | YYYY-MM-DD |
| RR-003 *(Example)* | ALT-004 rejected | Common-mode software flaw in authorisation stack | Low | High | Accept until next review | @payments-lead | YYYY-MM-DD |
| [RR-NNN] | [Scenario] | [Risk] | [L / M / H] | [L / M / H] | [Accept / Reduce / Transfer / Avoid] | [@owner] | YYYY-MM-DD |

Record accepted risks in the Risk register (`compliance/risk-register`).

### 13.2 Recommendations and roadmap

| ID | Recommendation | Alternative | Priority | Target date | Dependency |
|---|---|---|---|---|---|
| REC-001 *(Example)* | Implement immutable backups in a separate tenant | ALT-001 | 1 | YYYY-MM-DD | Backup tenant approval |
| REC-002 *(Example)* | Build and exercise the isolated recovery environment | ALT-002 | 2 | YYYY-MM-DD | REC-001 |
| REC-003 *(Example)* | Per-function segmentation with automated quarantine | ALT-003 | 2 | YYYY-MM-DD | Network policy as code |
| [REC-NNN] | [Recommendation] | [ALT-NNN] | [1 to 5] | YYYY-MM-DD | [Dependency] |

### 13.3 Adapt: triggers for re-analysis

Re-run sections 3 to 13 when any of these occur: a new ATT&CK release
that changes relevant techniques, a significant incident in the sector,
a change to a common critical asset, a failed exercise in section 12, or
a new mission essential function.

## 14. Traceability matrix

<!-- Guidance: Show the chain from mission function to measure so a reviewer can follow any thread in both directions. Pitfall: rows that stop at the technique and never reach a control or a test. -->

| MEF | Critical asset | Scenario | Objective | Technique and approach | Structural principle | Change | Control | Measure | Verification |
|---|---|---|---|---|---|---|---|---|---|
| MEF-002 *(Example)* | CRA-001 | SCN-001 | Reconstitute | Redundancy: Protected Backup and Restore | SDP-06 | ALT-001 | CP-9(8) | MOE-005 | VER-001 |
| MEF-001 *(Example)* | CRA-005 | SCN-001 | Constrain | Segmentation: Dynamic Segmentation and Isolation | SDP-04 | ALT-003 | SC-7(20) | MOE-004 | VER-002 |
| MEF-001 *(Example)* | CRA-001 | SCN-002 | Understand | Deception: Tainting | SDP-14 | Canary records | SI-20 | MOE-006 | VER-003 |
| [MEF-NNN] | [CRA-NNN] | [SCN-NNN] | [Objective] | [Technique: approach] | [SDP-NN] | [ALT-NNN] | [Control] | [MOE-NNN] | [VER-NNN] |

## 15. Glossary and references

<!-- Guidance: Define terms in your own words and list the exact versions consulted, with the date you checked them. -->

### 15.1 Glossary

| Term | Meaning in this document |
|---|---|
| Cyber resiliency | The ability of a system that depends on cyber resources to keep delivering its mission through and after attacks, failures and other adversity |
| System of interest | The system whose resiliency is being analysed, including the services it depends on |
| Mission essential function | A function whose interruption beyond a set time causes unacceptable harm |
| Common critical asset | A resource that many mission functions depend on, such as identity, key management or backups |
| Technique | A broad category of capability that contributes to resiliency, for example Segmentation |
| Implementation approach | A more specific way of realising a technique, for example Dynamic Segmentation and Isolation |
| Measure of effectiveness | A measure of how well a mission outcome is achieved under adversity |
| Measure of performance | A measure of whether a mechanism works as specified |
| Isolated recovery environment | A separate, minimal environment with its own identities, used to rebuild critical services from verified sources |

### 15.2 References

| Reference | Version or date checked | Use |
|---|---|---|
| NIST SP 800-160 Vol. 2 Rev. 1, *Developing Cyber-Resilient Systems: A Systems Security Engineering Approach*, csrc.nist.gov | December 2021 (final, supersedes the 2019 edition), checked YYYY-MM-DD | Constructs, process, effects vocabulary |
| NIST SP 800-160 Vol. 1 Rev. 1, *Engineering Trustworthy Secure Systems* | November 2022 | Systems security engineering context |
| NIST SP 800-53 Rev. 5, *Security and Privacy Controls for Information Systems and Organizations* | Release [5.2.0, August 2025] | Control mapping in section 10 |
| MITRE ATT&CK Enterprise, attack.mitre.org | [v20, October 2026] | Adversary behaviour model |
| MITRE, *Cyber Resiliency Metrics, Measures of Effectiveness, and Scoring* (2018) | Report PR 18-2579 | Background for section 11 |
| [Business impact analysis] | [Version] | Section 2 |

## Standard and licence note

Based on NIST Special Publication 800-160 Volume 2 Revision 1,
*Developing Cyber-Resilient Systems: A Systems Security Engineering
Approach* (December 2021), NIST SP 800-53 Revision 5 and MITRE ATT&CK.
NIST publications are works of the United States Government and are not
subject to copyright in the United States; the names of goals,
objectives, techniques, implementation approaches, design principles and
effects are used as published so that the design can be traced to the
framework. All explanations, examples and guidance are original text
written for this collection and do not reproduce NIST tables or
definitions. MITRE ATT&CK is a registered trademark of The MITRE
Corporation; tactic and technique names and IDs are used for reference
under its terms of use. Check the current official versions of each
source before use. Template licence: MIT.