Direct answer
A backup threat model must include more than encryption of stored data. Attackers may delete recovery points, shorten retention, corrupt catalogs, steal encryption keys, poison restored images or disable the people and documentation needed to recover. Model these objectives against each control plane and operator role.
How to frame the decision
Architecture decisions should be evaluated against shared failure domains. Geographic distance alone does not create independence when identities, management tools or deletion privileges are shared.
For this decision, document the protected service, assumed compromise, required recovery point and the maximum acceptable time to a trusted business state. Keep product capability, configured capability and tested capability as three separate fields: they are rarely identical.
Decision table
The following factors convert the decision into requirements that can be reviewed, tested and retained as evidence.
| Factor | Practical guidance | Evidence to retain |
|---|---|---|
| Attacker objectives | List deletion, corruption, exfiltration, retention tampering and recovery delay as distinct outcomes. | A threat register mapped to preventive and detective controls. |
| Entry paths | Cover compromised workload agents, administrative sessions, APIs, supply chain and support access. | Data-flow diagrams with trust boundaries and authentication methods. |
| Recovery abuse | Consider poisoned images, vulnerable templates and stolen keys reintroduced during restoration. | A validation gate for images, credentials and restored application behavior. |
Validation procedure
Run this procedure in a non-production or isolated recovery environment. Define a named owner and time limit before the test begins.
- Draw the actual trust and data flows before changing controls.
- Translate the requirement into a pass/fail test for a threat model for backup and recovery systems.
- Capture timestamps, logs, restored-object counts and operator actions for each decision factor.
- Repeat the test with one dependency unavailable so the result reflects a hostile recovery, not a clean demo.
A pass means the recovery outcome and supporting evidence meet the pre-declared requirement. A partial restore, undocumented manual workaround or result that depends on an unavailable production service should be recorded as an exception—not rounded up to a success.
Common failure modes
These conditions can make a compliant-looking design unusable during an actual recovery.
- The threat model stops at repository encryption.
- Vendor support and integration accounts are omitted from privileged-path analysis.
- The recovery environment reuses compromised secrets and golden images.
Failure modes should become tabletop injects and technical tests. If the team has never performed the recovery while one normal dependency is unavailable, the runbook describes a best-case restore rather than a ransomware recovery.
Evidence checklist
Keep this evidence with the recovery plan so that a reviewer can distinguish a documented capability from a reproduced result.
- Record the design decision, owner, exception and next test date.
- A tested requirement exists for: Attacker objectives.
- A tested requirement exists for: Entry paths.
- A tested requirement exists for: Recovery abuse.
- Evidence includes a date, environment, operator and reproducible procedure.
- The exception path identifies who can accept residual risk.
Frequently asked questions
These answers state the decision in plain language and preserve the conditions that can change it.
How do you threat-model a backup system?
A backup threat model must include more than encryption of stored data. Attackers may delete recovery points, shorten retention, corrupt catalogs, steal encryption keys, poison restored images or disable the people and documentation needed to recover. Model these objectives against each control plane and operator role. The deciding factors in this guide are attacker objectives, entry paths, recovery abuse.
Can ransomware corrupt backup catalogs?
Treat the answer as conditional on the actual environment and plan. Cover compromised workload agents, administrative sessions, APIs, supply chain and support access. Retain data-flow diagrams with trust boundaries and authentication methods.
What recovery assets are security critical?
Do not rely on the product label or a successful backup job alone. Test the requirement directly: consider poisoned images, vulnerable templates and stolen keys reintroduced during restoration. Record the result with a date, operator and named exception owner.