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.
Document control
| 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
1. Purpose, scope and system of interest
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
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] |
3. Adversary and threat assumptions
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
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
| 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
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
| 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
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.
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
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
| 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
| 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
| 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
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
| 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
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.