Design a Backup Strategy Around What Must Be Restored

Backups are useful only when they can support something the business actually needs to restore. A folder copy, provider feature, or successful job report may be relevant evidence, but none of those facts alone shows that a team can recover a working capability with its dependencies, ownership, and authority intact.

This guide helps a 1–50-person team create a bounded recoverability map before selecting tools or planning a restore test. It stays at category level: do not copy system names, storage locations, schedules, configuration, credentials, recovery material, evidence content, or operational objective values into the map.

Start with recoverability, not tools

The NCSC incident-preparation guidance asks small organisations to identify essential electronic information, where it is stored or accessed, and the critical processes and systems they rely on. Its current backup guidance says to copy the data the business needs to operate and to know how that data can be restored and checked.

Those documented statements support the business-first questions in this guide. The ten concepts, eight stages, objective prompts, state vocabulary, evidence threshold, 18 fields, completion rule, and review triggers are PlainFort editorial judgment. They are not NCSC requirements, technical recovery architecture, certification, compliance, a regulated recovery level, a universal backup strategy, or a guarantee.

A business-defined objective is a planning boundary, not observed capability. A named objective does not prove the current method can meet it. This guide supplies no universal duration, frequency, copy count, retention period, storage model, technology, or restoration sequence.

Keep ten recoverability concepts separate

1. Business capability: the operation or outcome the team needs to continue or recover.
2. Recoverable scope category: the related data, service, configuration, software, or business knowledge.
3. Bounded inventory reference: an inert reference to the relevant SF-02 scope, not a second inventory.
4. Dependency chain: the people, identity, administrator, device, provider, configuration, knowledge, and sequence dependencies that could block recovery.
5. Ownership and authority: the accountable owner, responsible operator, genuine backup, and escalation authority.
6. Business impact: what stops or degrades when the capability is unavailable, without creating a second risk score.
7. Tolerated data-loss objective: the loss boundary the business authorizes for planning, not a promise that a method can meet it.
8. Tolerated downtime objective: the interruption boundary the business authorizes for planning, not proof of achievable restoration time.
9. Restore order and current method category: dependency-aware sequencing plus a reported or evidenced method category, not a live design or test.
10. Evidence, handoff, exception, residual risk, escalation, and review: the truthful state and next decision without false completion.

Do not collapse these concepts into one backed up, recoverable, covered, resilient, ready, compliant, or secure checkbox. A strong state in one concept cannot silently compensate for an unknown, reported — evidence not inspected, blocked, deferred, exception, BR-25 decision required, or BR-22 test required state elsewhere.

The eight-stage PlainFort process

The sequence below is an editorial method for building one bounded map. It does not authorize any backup, restore, export, configuration, purchase, provider, account, evidence, or recovery action.

1. Set the business boundary and internal owner

Choose one capability with a clear beginning and end. Record the internally accountable owner, the responsible maintainer or operator, a genuine backup who can act under a defined handover, and the escalation authority.

Repeated roles may be unavoidable in a very small team. Make the resulting lack of independent challenge, capacity, availability, or continuity visible. Naming a role does not prove competence, access, authority, independence, or availability.

2. Consume the inventory without rebuilding it

Use the relevant SF-02 inventory reference to identify only category-level data, services, configuration, software, knowledge, and ownership gaps. Record Bounded inventory reference held in approved system — details not copied; do not reproduce identifiers, discovery steps, or lifecycle fields.

3. Map dependencies before objectives

List dependency categories that could prevent useful recovery: people, identity, an administrator, a usable device, provider behavior, configuration, business knowledge, and the order in which components would need to become available. A data copy is not a working capability if a required identity, configuration, authority, or sequence is missing.

4. Describe business impact without rescoring security work

State, in business language, what work stops or degrades when the capability is unavailable. Do not create a parallel risk score or reorder the security backlog; route changed priority decisions to the SF-03 priority process.

5. Write bounded loss and downtime objectives

Ask the authorized business owner what loss and interruption the team can tolerate for this capability. Record the deciding authority, assumptions, conflicts, and an inert reference such as Business-defined objective held in approved record — value not copied.

Objectives may differ between capabilities. Never copy a duration or target from this guide, a generic template, a product default, a source, or another organisation. If authority is missing, dependencies conflict, or a system cannot support the desired boundary, keep the gap visible and escalate it.

6. Set restore order and hand off provider questions

Record the dependency-aware restore order and the reason for it. This is a business sequence, not a technical restoration procedure or timing guarantee.

Questions about provider availability, retention, export, native recovery, identity or configuration recovery, and customer-versus-provider responsibility belong in the BR-25 SaaS responsibility decision. A provider, contractor, managed service, or software feature may execute authorized work or supply evidence, but it does not silently acquire internal accountability, business authority, or proof of recoverability.

7. Calibrate current method and evidence, then hand off testing

Record only a category-level current backup or recovery method. Separate Reported — evidence not inspected from Documented — evidence referenced, and use an inert location such as Evidence held in approved system — content not copied.

Do not open, export, test, or change a backup, account, tenant, device, storage location, provider plan, configuration, log, key, credential, or recovery record. Actual restore verification belongs in the separately authorized BR-22 restore-test guide. The state BR-22 test required records a handoff; it does not authorize a test.

8. Close only with visible gaps, escalation, and review

Close the mapping pass only when every field has a truthful state, unresolved exceptions and residual risks remain visible, the completion evidence is referenced, and the next review trigger is named. Do not mark the map complete by hiding an unknown, blocked, deferred, exception, provider decision, or test handoff.

Review after a material change to the capability, inventory, owner, provider, dependency, recovery method, business objective, or evidence. A completed map is still a planning record: it does not prove that a backup exists, a restore will work, or recovery will succeed.

Use workflow states, not a score

• Documented — evidence referenced
• Reported — evidence not inspected
• Unknown — follow up
• Blocked — qualified help required
• Deferred — owner and review date required
• Exception — scope, reason, owner, expiry, and residual risk required
• BR-25 decision required
• BR-22 test required
• Not applicable — rationale and reviewer required

These are workflow positions, not a security score, maturity level, resilience rating, compliance status, or prediction that recovery will succeed. Documented is not validated, and Not applicable requires a bounded rationale rather than omission.

Build the 18-field vertical recoverability map

Complete one vertical record per bounded business capability:

1. Business capability: the bounded operation or outcome.
2. Data, service, configuration, software, or knowledge category: category only.
3. Bounded SF-02 scope reference: inert reference; details not copied.
4. Internally accountable owner: role, not a personal identity.
5. Responsible maintainer or operator: role and bounded responsibility.
6. Genuine backup and escalation authority: handover coverage plus decision authority.
7. Dependencies: category-level people, identity, administrator, device, provider, configuration, knowledge, and sequence needs.
8. Impact if unavailable: work that stops or degrades, without a security score.
9. Business-defined tolerated data-loss objective: approved-record reference; value not copied.
10. Business-defined tolerated downtime objective: approved-record reference; value not copied.
11. Restore order and dependency rationale: sequence category and reason, not a procedure or guarantee.
12. Current backup or recovery-method category: reported or evidenced category only.
13. BR-25 SaaS-responsibility handoff: state and next owner.
14. Evidence state and inert location reference: content not copied.
15. BR-22 restore-test handoff: state and separately authorized next step.
16. Exception and residual risk: scope, reason, owner, expiry, and visible consequence.
17. Qualified escalation: trigger, authority, and safe route.
18. Completion evidence and review trigger: inert reference plus the event or date that reopens the map.

Do not convert this record into a table, architecture, timeline guarantee, dashboard, heat map, maturity model, compliance checklist, product comparison, scorecard, or live configuration worksheet.

Fictional example — do not copy as a completed backup or recovery record

The example below is intentionally generic and incomplete. It contains no real or plausibly operational values.

1. Business capability: Example Co. customer-work continuity category.
2. Data, service, configuration, software, or knowledge category: work-record and operating-knowledge categories.
3. Bounded SF-02 scope reference: Bounded inventory reference held in approved system — details not copied.
4. Internally accountable owner: operations-owner role.
5. Responsible maintainer or operator: service-maintainer role.
6. Genuine backup and escalation authority: continuity-backup role named; independent capacity not yet evidenced.
7. Dependencies: identity, administrator, device, provider, configuration, knowledge, and ordering categories.
8. Impact if unavailable: a bounded work category would pause; details not copied.
9. Business-defined tolerated data-loss objective: Business-defined objective held in approved record — value not copied.
10. Business-defined tolerated downtime objective: Business-defined objective held in approved record — value not copied.
11. Restore order and dependency rationale: dependency order held in approved record; sequence not copied.
12. Current backup or recovery-method category: Reported — evidence not inspected.
13. BR-25 SaaS-responsibility handoff: BR-25 decision required for unresolved provider/customer responsibility.
14. Evidence state and inert location reference: Documented — evidence referenced; Evidence held in approved system — content not copied.
15. BR-22 restore-test handoff: BR-22 test required; no test authorized by this record.
16. Exception and residual risk: Exception — scope, reason, owner, expiry, and residual risk required because independent continuity capacity is not evidenced.
17. Qualified escalation: Blocked — qualified help required before any design, purchase, export, restore, configuration, or provider decision.
18. Completion evidence and review trigger: completion is blocked; reopen after authority and evidence gaps are resolved through an approved route.

The example does not prove that Example Co. has a backup, meets an objective, can restore a capability, or is secure. A fabricated backup, recovery objective, restore result, provider record, or failure plausible enough to be mistaken for live evidence is prohibited even when labelled fictional.

Keep the dedicated guides separate

• SF-02 owns inventory construction and review; this guide consumes bounded references without recreating the inventory.
• SF-03 owns security-work prioritization; this guide records business impact and restore order without creating a parallel risk score.
• SF-04 owns the general responsibility model; this guide applies its vocabulary without redefining the six functions.
• DN-16 records device backup and recovery prerequisites; BR-21 owns backup design and business recovery objectives.
• BR-25 owns provider/customer SaaS responsibility and unresolved provider evidence.
• BR-22 owns one separately authorized bounded restore test and its result.
• BR-24 owns general incident roles and communications, not the recoverability strategy.
• BR-23 owns the later ransomware-readiness synthesis and consumes this evidence without reproducing the map.

Stop before live or specialist work

This guide creates a planning record; it does not validate a backup, prove recoverability, select a product, inspect evidence, or authorize live backup, restore, export, import, configuration, deletion, overwrite, retention, provider, account, tenant, device, recovery, or incident work.

Stop and obtain qualified help when authority is unclear; critical, regulated, private, or high-impact data is involved; dependencies, administrators, recovery prerequisites, or evidence are unknown; a sole copy or only recovery path may be affected; a system is unsupported; or a legal, records, privacy, contractual, insurance, procurement, or compliance question appears. Keep the gap visible rather than turning uncertainty into completion.