How Often Should You Back Up? ISO 27001 Evidence-Based Frequency

“Back up every night” is a schedule, not a risk decision. It may be excessive for a static archive and dangerously inadequate for a transactional service that cannot tolerate a day of lost changes. Backup frequency should come from approved recovery needs, data behaviour, threat scenarios and the capability of the recovery design.

ISO/IEC 27001 does not prescribe hourly, daily or weekly backups. Annex A includes controls relating to information backup and ICT readiness, but the organisation selects and implements controls through risk treatment. Frequency is therefore an organisation-specific parameter that must be justified, operated, monitored and tested.

Direct answer: Set the maximum interval between recoverable copies no longer than the approved recovery point objective, then account for job duration, replication lag, corruption detection, retention and credible failure modes. A schedule is adequate only when restore evidence proves the required data point can be recovered.

Separate the key recovery measures

Three concepts are often mixed together:

• Recovery point objective (RPO): the maximum acceptable amount of data loss expressed as time before disruption.
• Recovery time objective (RTO): the target time to restore a service or capability after disruption.
• Backup interval: how often a copy or recoverable point is created.

A four-hour RPO does not automatically mean one backup every four hours. If a job takes 45 minutes, uploads later, and recovery cataloguing takes more time, the age of the newest usable copy could exceed the objective. Conversely, continuous replication may create a very recent copy but reproduce corruption immediately and therefore fail the recovery need.

The RTO and RPO evidence guide explains how to approve, measure and test both objectives.

Derive frequency from business impact

Start with the business activity and its information, not the backup product. For each data set or service, determine:

1. what transactions, evidence or work would be lost;
2. the operational, legal, safety, financial and customer impact of that loss;
3. the point at which loss becomes unacceptable;
4. whether lost data can be reconstructed and at what cost;
5. dependencies that must be recovered to the same consistent point; and
6. who has authority to approve the objective and residual risk.

An order database, identity directory, source repository and monthly reference archive can all require different objectives. Classifying solely by server creates weak results because one platform may host data with very different business value.

The business impact analysis guide provides a method for connecting disruption effects to recovery requirements.

Account for how data changes

Frequency should reflect change rate and change pattern. Consider transaction volume, batch windows, end-of-period processing, configuration changes and the creation of cryptographic or identity material.

Examples:

• A low-change policy library may need a copy after approved changes plus periodic protection.
• A transaction platform may require log shipping, snapshots or another mechanism that supports a short RPO.
• Infrastructure configuration may be recoverable from version-controlled code, but secrets, state and provider settings need separate treatment.
• A data warehouse may be reproducible from authoritative inputs, yet rebuilding it could exceed the RTO.

Document the reasoning. “Daily because that is the default” is not evidence that risk was evaluated.

Design for failure and corruption

One backup mechanism should not be expected to solve every failure mode. Evaluate accidental deletion, hardware loss, malicious encryption, privileged account compromise, application corruption, regional outage and supplier failure.

Use separation and retention to preserve recovery choices. Depending on risk, this can include different credentials, immutable storage, offline or logically isolated copies, geographic separation, independent administration and protected catalogues. Confirm that a compromise of production cannot easily delete or alter every recovery point.

Replication and high availability support service continuity, but they are not automatically backups. They may replicate unwanted changes, depend on the same identity plane or lack historical versions. Likewise, a retained copy is not useful until the organisation can locate, decrypt, restore and validate it.

NIST’s contingency planning guidance connects backup and recovery measures to business impact and testing. NIST control examples also express backup frequency as organisation-defined and consistent with recovery objectives, reinforcing the need for explicit risk-based parameters rather than a universal cadence.

Convert the RPO into operating rules

For each protected data set, record:

Field	Decision to capture
Owner	Person accountable for the business recovery need
RPO	Maximum acceptable data loss and approval date
Method	Full, incremental, snapshot, journal, export or other recoverable mechanism
Frequency	Schedule or trigger and allowed completion window
Retention	Number and age of recovery points needed for scenarios
Separation	Failure domains, accounts, regions and administrative boundaries
Monitoring	Success, age, lag, capacity and integrity conditions
Test	Restore scope, frequency, acceptance criteria and owner
Exception	Escalation threshold and temporary risk treatment

Set monitoring against recoverability, not merely job completion. A “successful” job that copied zero objects, used an expired key or uploaded to an inaccessible account is operational evidence of failure.

The free Annex A Control Lookup can help identify related control purposes. Selection and implementation still need the organisation’s own risk assessment and Statement of Applicability.

Test the recoverable point

Restore testing should answer four questions:

1. Did the organisation recover the intended data set?

2. Was the recovered point within the approved RPO?

3. Was the data complete, consistent and usable by the service?

4. Could authorised people perform the recovery within the required conditions?

Use representative samples across technologies, criticalities and suppliers. Include application-consistent recovery, not only file extraction. Measure the age of the recovered data, restoration time, validation result, exceptions and manual workarounds.

Test scenarios in which normal administrators, networks or primary credentials are unavailable. The ICT recovery readiness guide shows how to include dependencies and failure assumptions in exercise design.

Investigate missed or stale backups

Define thresholds for a missed job, excessive lag, failed integrity check, capacity limit and overdue restore test. The response should state who investigates, when service and risk owners are informed, which compensating measures are used and when formal risk acceptance is required.

Track repeated failures as systemic issues. Restarting a job can recover today’s copy while leaving a capacity, access or architecture weakness unresolved. Feed material trends into management review and improvement.

Audit implementation and operation separately

For implementation evidence, examine approved objectives, architecture, schedules, retention, access controls, monitoring rules and test design.

For operating evidence, select recent periods and trace:

• completed and failed jobs;
• oldest and newest usable recovery points;
• alerts and response records;
• restore tests with measured data age;
• exceptions and risk acceptance;
• changes to protected systems and backup configuration; and
• corrective actions from failed restores.

Sample a high-change service, a critical but low-change data set, a cloud service and one system with an unusual recovery method. Then reconcile the backup inventory with the current service and asset inventory to find omissions.

Sample audit questions

• Which approved impact statement produced this RPO?
• Does the schedule include job duration and replication lag?
• How would the organisation recover from corruption discovered after several days?
• Can production administrators alter every retained copy?
• What was the actual data point in the most recent restore?
• Which systems have missed their RPO in the last quarter?
• How are new services added to protection before launch?

Judge pass, partial and fail conditions

Pass: Frequencies trace to approved recovery needs, monitoring detects stale or failed protection, copies survive credible failure modes, and restore tests demonstrate usable data within the RPO.

Partial: Jobs run and success is monitored, but objectives are generic, restoration covers only files, or retention and separation do not address delayed corruption or privileged compromise.

Fail: Frequency is an undocumented default, critical data is absent from scope, failures go unnoticed, or the organisation cannot recover a usable point within its stated objective.

Backup frequency is defensible when it is the output of business analysis and the input to a tested operating process. The proof is not how often a job starts; it is whether a trustworthy recovery point exists when the organisation needs it.