Backup and Recovery Standard

A backup and recovery standard specifies the technical requirements that data protection mechanisms must satisfy to ensure organisational data remains recoverable following loss, corruption, or disaster. This standard establishes minimum requirements for backup frequency, retention duration, recovery speed, geographic distribution, and security controls. Individual systems may impose stricter requirements based on data criticality or regulatory obligations, but no system storing organisational data may operate below these baselines.

The standard applies to all data under organisational control, including data stored in cloud services, on-premises infrastructure, endpoint devices, and third-party platforms where the organisation maintains data ownership. Data managed entirely by third parties under their retention policies falls outside this standard’s direct scope, though vendor assessments must verify adequate backup capabilities exist and recovery testing occurs.

Backup

A copy of data created at a specific point in time, stored separately from the primary data, and usable to restore the original data state.

Recovery Point Objective (RPO)

The maximum acceptable age of data that can be recovered. An RPO of 4 hours means the organisation accepts losing up to 4 hours of data changes in a recovery scenario.

Recovery Time Objective (RTO)

The maximum acceptable duration between failure and restoration of service. An RTO of 2 hours means systems must be operational within 2 hours of a recovery decision.

Immutable backup

A backup that cannot be modified, encrypted, or deleted for a defined retention period, even by administrators with full system access.

Air-gapped backup

A backup stored on media physically or logically disconnected from production networks, inaccessible to attackers who compromise primary systems.

System tiering

Backup requirements scale with system criticality. Each system must be assigned to a tier based on its role in organisational operations and the impact of its unavailability.

Tier assignment must be documented for each system and reviewed annually or when system function changes materially. Systems processing personal data of vulnerable populations or protection-sensitive information default to Tier 1 regardless of other factors.

Recovery objectives by tier

Recovery objectives establish the maximum acceptable data loss and downtime for each system tier. These objectives drive backup frequency, retention, and recovery infrastructure requirements.

The RPO directly determines minimum backup frequency. A system with a 4-hour RPO requires backups at least every 4 hours. Transaction log shipping, continuous data protection, or synchronous replication may supplement periodic backups for systems requiring sub-hour RPOs.

The RTO determines recovery infrastructure investment. A 4-hour RTO for a complex system requires pre-provisioned recovery infrastructure, tested runbooks, and on-call personnel. A 72-hour RTO permits cold recovery from stored media with infrastructure provisioned during recovery.

Calculating recovery objectives

Recovery objectives derive from business impact analysis rather than technical convenience. For each system, determine:

1. The financial cost per hour of system unavailability (staff idle time, lost transactions, contractual penalties)
2. The operational impact of unavailability (beneficiaries unable to receive services, partner coordination disrupted, reporting deadlines missed)
3. The data sensitivity and regulatory requirements (personal data, donor requirements, legal holds)
4. The reputational impact of extended outage or data loss

A finance system processing £50,000 daily with month-end close deadlines and donor reporting requirements warrants Tier 1 classification with 1-hour RPO and 4-hour RTO. A staff training platform with pre-recorded content and flexible completion deadlines warrants Tier 3 classification with 24-hour RPO and 72-hour RTO.

Backup frequency requirements

Backup frequency must satisfy RPO requirements while accounting for backup duration, system load impact, and storage costs.

Full backups capture complete system state but require substantial time and storage. A 500GB database full backup taking 2 hours cannot run hourly. Incremental backups capture only changes since the last backup, completing quickly but requiring the full backup plus all subsequent incrementals for recovery. Transaction log backups for databases enable point-in-time recovery to any moment between backups.

Backup windows

Backups must complete within defined windows to avoid impacting production operations:

Backups exceeding their window threshold indicate undersized infrastructure, inefficient backup methods, or excessive data growth requiring architectural review.

Retention requirements

Retention periods determine how long backups remain available for recovery. Retention balances recovery flexibility against storage costs and data protection obligations.

Standard retention applies to all Tier 1, 2, and 3 systems unless regulatory or contractual requirements mandate extended retention. Extended retention applies to financial records, HR data, and systems subject to donor audit requirements. Minimal retention applies only to Tier 4 systems with no regulatory obligations.

Retention worked example

A Tier 2 email system with standard retention maintains:

• 7 daily backups (one per day for the past week)
• 4 weekly backups (Sundays from the past month)
• 12 monthly backups (first Sunday of each month for the past year)
• 3 yearly backups (January 1 for the past 3 years)

Total backup count: 7 + 4 + 12 + 3 = 26 distinct recovery points spanning 3 years. Storage requirement equals approximately 3x the system’s data size, assuming 60% deduplication efficiency across backup generations.

For a 200GB email system:

• Raw backup data without deduplication: 200GB × 26 = 5,200GB
• With 60% deduplication: 5,200GB × 0.4 = 2,080GB
• With compression (typical 2:1 for email): 2,080GB × 0.5 = 1,040GB

Storage planning must account for data growth. A system growing 20% annually requires storage capacity for projected size at the end of the longest retention period.

Geographic and offsite requirements

Backups must be stored in locations that survive events affecting primary data. A backup stored on the same physical server as production data provides no protection against hardware failure, fire, or ransomware.

The 3-2-1 rule provides a baseline: maintain 3 copies of data, on 2 different media types, with 1 copy offsite. For Tier 1 systems, extend this to 3-2-1-1: add 1 immutable or air-gapped copy.

Cloud backup geography

Cloud backups must consider data residency requirements and provider failure scenarios. Backups stored in the same cloud provider region as production data do not survive region-wide outages. Cross-region replication addresses single-region failure but not provider-wide incidents or account compromise.

Tier 1 systems require backups in at least two of: primary cloud provider cross-region, separate cloud provider, or offline/air-gapped media. This ensures recoverability even if the primary cloud provider experiences complete failure or the organisation’s account is compromised.

Backup security requirements

Backups contain the same sensitive data as production systems and require equivalent security controls. A backup lacking encryption or access controls provides attackers an unprotected copy of organisational data.

Encryption requirements

Encryption keys stored alongside backup data provide no protection. An attacker obtaining backup files from cloud storage also obtains the means to decrypt them if keys reside in the same location. Store encryption keys in dedicated key management systems, hardware security modules, or physically separate secure storage.

Access control requirements

Immutability requirements

Immutable backups cannot be modified or deleted before their retention period expires, even by administrators with full system access. Immutability protects against ransomware that targets backups, insider threats, and accidental deletion.

Immutability mechanisms include:

• Object lock with compliance mode (cloud storage)
• WORM (Write Once Read Many) storage media
• Air-gapped storage disconnected after backup completion
• Separate administrative domain requiring distinct credentials for deletion

Governance mode immutability, which permits deletion by users with special permissions, provides reduced protection compared to compliance mode, which prevents deletion by anyone including cloud provider support. Tier 1 systems require compliance mode or equivalent.

Testing requirements

Untested backups provide false confidence. A backup that cannot be restored is not a backup. Regular testing verifies that backup data is complete, uncorrupted, and recoverable within RTO targets.

Recovery test requirements

System recovery tests must validate actual recoverability, not merely that restoration completes without errors.

Recovery tests must use production backup data restored to isolated environments. Tests using specially prepared test data do not validate production backup recoverability.

Test documentation

Each recovery test must produce documentation including:

• Test date and participants
• System(s) tested
• Backup date and type used
• Recovery procedure followed
• Actual recovery time versus RTO
• Issues encountered and resolution
• Data validation results
• Pass/fail determination
• Remediation actions for any failures

Failed recovery tests require root cause analysis and remediation within 14 days for Tier 1 systems, 30 days for Tier 2, and 60 days for Tier 3-4. Remediation must be followed by successful retest.

Backup monitoring and alerting

Backup failures must be detected and addressed promptly. A failed backup discovered only when recovery is needed provides no value.

Alert response must be assigned to specific roles with documented escalation paths. Unacknowledged critical alerts must escalate automatically.

Backup reporting

Regular reporting maintains visibility into backup health and compliance:

Backup data lifecycle

Backup data follows a defined lifecycle from creation through eventual destruction.

+-------------------------------------------------------------------+
|                    BACKUP DATA LIFECYCLE                          |
+-------------------------------------------------------------------+
|                                                                   |
|  +----------+     +----------+     +----------+     +----------+  |
|  |          |     |          |     |          |     |          |  |
|  |  Create  +---->+  Verify  +---->+  Store   +---->+ Replicate|  |
|  |          |     |          |     |          |     |          |  |
|  +----------+     +----------+     +----------+     +----+-----+  |
|                                                          |        |
|       +--------------------------------------------------+        |
|       |                                                           |
|       v                                                           |
|  +----+-----+     +----------+     +----------+     +----------+  |
|  |          |     |          |     |          |     |          |  |
|  |  Monitor +---->+  Age     +---->+  Expire  +---->+ Destroy  |  |
|  |          |     |          |     |          |     |          |  |
|  +----------+     +----------+     +----------+     +----------+  |
|                                                                   |
|  Retention clock starts at creation                               |
|  Immutability prevents early transition to Expire                 |
|  Destruction requires verification of newer valid backups         |
|                                                                   |
+-------------------------------------------------------------------+

Figure 1: Backup data lifecycle from creation through destruction

Backup destruction must verify that newer backups covering the same data exist and are recoverable before removing older backups. Automated retention policies must include this verification to prevent accidental deletion of the only valid backup copy.

Special considerations

Database backup requirements

Databases require application-consistent backups that capture a transactionally coherent state. File-level backups of database files while the database is running produce corrupted, unrecoverable backups.

Tier 1 and Tier 2 databases require point-in-time recovery capability through transaction log backups. A 15-minute transaction log backup interval permits recovery to any point with maximum 15 minutes data loss, satisfying 1-hour RPO with margin.

Cloud service backup requirements

Cloud SaaS applications may not provide native backup capabilities or may retain deleted data for limited periods. The organisation must verify backup coverage for each cloud service.

Cloud provider backup that the organisation cannot independently restore (requiring provider support intervention) does not fully satisfy backup requirements. The organisation must maintain the ability to recover without depending on provider cooperation.

Endpoint backup requirements

Endpoints (laptops, mobile devices) present backup challenges due to intermittent connectivity, diverse locations, and user-controlled data storage.

Endpoint backups must encrypt data before transmission and at rest. Backup of endpoints to personal cloud storage (user’s personal iCloud, Google Drive, or Dropbox) is prohibited for organisational data.

Field office and low-connectivity backup

Offices with limited or intermittent connectivity require adapted backup approaches that function despite bandwidth constraints.

Field offices with local backup must maintain at least two local copies on separate devices. A single local backup drive provides no protection against device failure, theft, or office-level disaster.

Exceptions

Exceptions to this standard require documented approval from the information security function and the system owner’s management chain. Exception requests must include:

• Specific requirement(s) to be excepted
• Business or technical justification demonstrating why compliance is not feasible
• Compensating controls implemented to reduce residual risk
• Risk assessment with explicit residual risk acceptance by accountable business owner
• Review date (maximum 12 months)
• Accountable individual for ongoing exception management

Systems operating under exception must be reviewed at each exception renewal to determine whether changed circumstances permit standard compliance. Exceptions for Tier 1 systems require senior management approval and quarterly review.

See also

• Backup Systems
• High Availability and Disaster Recovery
• Data Backup and Recovery
• Backup Verification
• DR Testing
• Backup Recovery Playbook
• Data Classification
• Cryptography Standard