Writing a Backup Policy: Structure, Content, and Example

TL;DR

ISO 27001 Control A.8.13 and NIS2 Article 21 No. 3 require documented data backup procedures. Without a backup policy, you lack the evidence.
The policy must define backup types (full, incremental, differential), intervals, retention periods, and storage locations as binding requirements.
Restore tests are not optional — they are mandatory. Only a regularly tested backup is a backup. Untested backups are hope at best.
The 3-2-1 rule (three copies, two media types, one offsite location) forms the foundation of every solid backup strategy.
Responsibilities must be assigned by name: who backs up, who monitors, who tests, and who authorizes a restore in an emergency.

Why a backup policy is not an optional document

Backups are taken for granted, like electricity from the outlet. Someone in IT set up a backup script at some point, it runs every night, and as long as no error message appears, everyone assumes everything is fine. Until it isn't.

Ransomware encrypts production data along with the backup shares. A faulty update destroys the database, and during the restore it turns out the backup has been failing for three weeks because the storage ran full. Or the CEO asks for a deleted contract from eight months ago, and nobody knows whether the backup retention period even covers that.

All of this happens regularly, and all of it could be prevented — or at least made manageable — with a properly documented backup policy. A backup policy is the document that defines binding rules for which data is backed up at what interval, to which medium, at which location, how long the backups are retained, who is responsible, and how the restore process works in an emergency.

For an ISMS according to ISO 27001, this document is non-negotiable. Control A.8.13 (Information backup) explicitly requires that backup copies of information, software, and system configurations are created, regularly tested, and documented. NIS2 goes a step further: Article 21 Paragraph 2 No. 3 demands measures to maintain operations, and a functioning data backup is an elementary foundation for this.

What distinguishes the backup policy from a backup concept

Before you start writing, a brief clarification is worthwhile, because the terms backup policy and backup concept are frequently confused.

The backup policy is the overarching document. It defines principles, responsibilities, minimum requirements, and framework conditions. It addresses all relevant stakeholders in the organization and is approved by management.

The backup concept is the technical implementation document. It describes the specific backup jobs, schedules, storage systems, network paths, and configuration details. It is directed at the IT department and is managed by the IT lead or administrator.

In practice, you can combine both into a single document if your company is not too large. A cleaner approach is to separate them: the policy sets the framework, the concept describes the technical implementation. For your ISMS, you need at least the policy. An auditor will ask about the principles, not about the details of individual backup jobs.

Scope and classification

Every backup policy begins with the question of what needs to be backed up. The answer is not a blanket "everything" but rather is based on the classification and protection requirements of the data.

Your organization has conducted a protection needs assessment as part of the ISMS. The results feed directly into the backup policy. Data with high protection requirements regarding availability needs shorter backup intervals and shorter recovery times than data with standard protection requirements.

Typically, the policy defines three to four backup classes:

Class A (Business-critical): ERP system, financial accounting, customer database, email server. Backup multiple times daily, Recovery Time Objective (RTO) under four hours, Recovery Point Objective (RPO) under one hour. How you properly define RPO and RTO depends on the business impact analysis.

Class B (Important): File server, project data, intranet, document management. Daily backup, RTO under 24 hours, RPO under 24 hours.

Class C (Standard): Development environments, test data, archive material. Weekly backup, RTO under 72 hours, RPO under one week.

Class D (Not backup-relevant): Temporary files, local caches, publicly available information. No backup required.

The assignment of systems to classes is done jointly by IT and the business departments. The policy must require that this assignment is documented and reviewed at least annually. New systems must be assigned to a backup class before going into production.

Backup types and their use cases

The policy should define the permitted backup types and specify when each is used.

Full backup

A full backup copies all data completely. It forms the basis for every backup strategy but is time- and storage-intensive. Typically, a full backup is performed weekly or monthly, depending on data volume and backup window.

Advantage: Restoration is simple and fast because only a single backup set is needed. Disadvantage: High storage requirements and long runtime.

Incremental backup

An incremental backup saves only the data that has changed since the last backup (regardless of whether it was full or incremental). This is the most efficient method in terms of storage space and runtime.

Advantage: Fast and storage-efficient. Disadvantage: For restoration, the last full backup plus all subsequent incremental backups are needed. If one link in the chain fails, the restore is at risk.

Differential backup

A differential backup saves all data that has changed since the last full backup. It grows with each day but is simpler to restore than a chain of incremental backups.

Advantage: For restoration, only the last full backup and the last differential backup are needed. Disadvantage: Growing storage requirements over the course of the week.

Recommended combination

For most SMEs, the following combination has proven effective: weekly full backup on the weekend, daily incremental or differential backup on workdays. For business-critical Class A systems, an additional intraday incremental backup or real-time replication is added.

The policy defines the minimum requirements per backup class. The detailed technical planning is done in the backup concept.

The 3-2-1 rule as foundation

The 3-2-1 rule is the gold standard of data backup and should be established as a core principle in every backup policy:

3 copies: In addition to the original data, at least two more copies exist. This allows your organization to survive the simultaneous failure of a storage medium.

2 different media: The copies reside on at least two different storage technologies. Hard drive and tape, local storage and cloud, SAN and NAS. This protects against technology-specific failures.

1 offsite location: At least one copy is at a geographically separate location. This protects against local disasters such as fire, flood, or break-in.

In practice, the rule is increasingly supplemented with an extension: 3-2-1-1-0. The additional 1 stands for an offline copy (air-gapped), which is protected from ransomware because it is physically unreachable. The 0 stands for zero errors during verification — meaning regular restore tests without any issues.

Your backup policy should formulate the 3-2-1 rule (or the extended variant) as a binding principle and only allow exceptions with documented risk acceptance.

Retention periods

The question of how long backups are retained is not purely technical — it has legal and business dimensions.

Legal retention obligations: Commercial documents must be retained for ten years under the German Commercial Code (HGB), and tax-relevant documents for six to ten years under the German Fiscal Code (AO). If these data exist only in backups (which should not be the standard but does happen), the backup must be available for at least that long.

Data protection deletion obligations: The DSGVO (GDPR) requires that personal data be deleted when the processing purpose no longer applies. Backups containing personal data must be included in the deletion concept. This does not mean you must delete every single person from the backup, but you must document how you handle personal data in backups and when the backups are regularly deleted.

Business requirements: Business departments often have their own ideas about how far back in time they need to go. One month may be sufficient for IT; the legal department may want three years.

Typical retention periods in the policy:

Backup type	Retention
Daily backup	30 days
Weekly backup	12 weeks
Monthly backup	12 months
Annual backup	7–10 years (depending on legal requirements)

These periods are guideline values. Your policy must adapt them to the specific requirements of your organization.

Storage locations and access protection

The policy must define where backups are stored and how access is protected.

Local backup

Backups to local storage systems (NAS, SAN, dedicated backup servers) provide fast backup and fast restore. They are the first point of contact for daily operations. The policy should require that local backup storage resides in a separate network segment and is not accessible through the same user accounts as the production data. Ransomware attacks regularly exploit the fact that backup shares are reachable with the same credentials as the original data.

Offsite backup

The external backup is made to a geographically separate location. This can be a second company location, a service provider's data center, or a cloud storage service. The policy must define the requirements for the offsite storage location: location in the EU (GDPR), encryption of data before transfer and at rest, contractual agreements with the service provider (DPA, SLA).

Offline backup (air-gapped)

At least for business-critical Class A data, the policy should require an offline copy — so-called immutable backups offer particular protection here. These can be tape media that are physically removed from the drive after backup, or a dedicated storage system that is only connected to the network during backup. This copy is the last line of defense against ransomware.

Encryption

All backups that leave the corporate network (offsite, cloud, tape transport) must be encrypted. The policy should mandate AES-256 as the minimum standard and define how encryption keys are managed. A backup whose decryption key is lost is worthless. Key management for backup encryption must be documented separately and securely.

Access protection

Access to backup systems and data must be governed by the least-privilege principle. The policy should require that only named administrators have access to backup systems, that all access is logged, and that a four-eyes principle applies for restoring critical data.

Restore tests: The heart of the policy

A backup that has never been tested is not a backup — it is a hypothesis. Restore tests are the part of the policy most frequently neglected and simultaneously the most important.

Why restore tests are indispensable

The reasons why backups fail in an emergency are varied: corrupt backup files, incompatible backup software versions, missing drivers or licenses for the restore environment, restoration that is too slow, incomplete data, or faulty backup job configuration. All of this only becomes apparent when you actually test the restore.

How the policy should govern restore tests

The policy should define the following points:

Frequency: At least quarterly for business-critical systems (Class A), semi-annually for important systems (Class B). Annually for Class C systems.

Scope: Not only restoring individual files but also regularly testing complete system restorations. Can the database server be fully restored from the backup? Does the ERP system work after the restore?

Documentation: Every restore test is documented: date, tested system, backup date of the restored data, time required, result (successful/failed), identified problems, and actions taken.

Responsibility: Who performs the tests, who reviews the results, who escalates when problems occur?

RTO validation: The measured restoration time is compared with the defined RTO. If the restore takes four hours but the RTO is two hours, the backup strategy must be adjusted.

An auditor will almost always ask about the most recent restore tests. Those who can present logs demonstrating regular, successful tests have won on this point. Those who cannot have a finding.

Clearly assigning responsibilities

A policy without clear responsibilities remains ineffective. The following roles should be defined:

Management: Approves the policy, provides resources, bears overall responsibility.

Information Security Officer (ISO): Creates and maintains the policy, monitors compliance, reports to management.

IT Management: Responsible for technical implementation, creates the backup concept based on the policy, monitors the operation of the backup infrastructure.

Backup Administrator: Performs daily monitoring, responds to error messages, conducts restore tests, documents results.

Business departments: Define the business requirements for availability and retention, report new systems and data assets, participate in restore tests (validation of restored data).

The policy must require that proper handover of backup responsibilities is conducted and documented when there is a personnel change in any of these roles.

Monitoring and escalation

Backup jobs can fail for many reasons: storage full, network connection interrupted, source system unreachable, time window exceeded. The policy must define how errors are handled.

Automated monitoring: All backup jobs are monitored automatically. Successful and failed jobs generate notifications to the responsible team.

Daily check: The backup administrator checks the results of the nightly backup every workday and confirms the check.

Escalation procedure: Failed backups are escalated immediately (not the next day). The policy defines escalation levels: a one-time failure is resolved and made up, repeated failures are escalated to IT management, ongoing outages are reported to the ISO and management.

Reporting: Monthly or quarterly reports on the backup status feed into the ISMS management review. The report includes success rates, problems encountered, restore tests performed, and the current state of compliance with the policy.

Special cases and common pitfalls

Cloud services and SaaS

Many organizations assume that cloud providers like Microsoft 365, Google Workspace, or Salesforce handle data backup. This is a dangerous misconception. Most SaaS providers protect their infrastructure, not your data. Deleted emails, SharePoint documents, or CRM records are irretrievably lost after a short retention period (often 30 to 93 days).

The policy must require that SaaS data is included in the backup strategy. A separate article explains why a dedicated cloud backup for Microsoft 365 is indispensable. Specialized backup solutions exist for this purpose (e.g., Veeam Backup for Microsoft 365, Acronis, Spanning).

Databases

Database backups require special care. A file-based backup of a running database may produce inconsistent data. The policy must require that databases are backed up using database-specific methods (dump, snapshot, log shipping) and that backup consistency is part of the restore test.

Encrypted systems

If production data is encrypted (disk encryption, database encryption), it must be ensured that the backup data is also encrypted and that the decryption keys are available for the restore. The policy should explicitly state that key material is stored separately and securely.

Virtual machines and containers

Modern infrastructures rely on virtualization and containerization. The policy must clarify whether VM-level backups (snapshot of the entire VM) or application-level backups (backing up the data within the VM) are required. In practice, a combination is often practical: VM snapshots for fast recovery and application-specific backups for granular restores.

Example outline for a backup policy

If you want to create a backup policy for your organization, you can use the following outline as a guide:

Purpose and scope — Why does the policy exist, who does it apply to?
Terms and definitions — RTO, RPO, full backup, incremental, differential
Normative references — ISO 27001 A.8.13, NIS2 Art. 21 No. 3, BSI IT-Grundschutz
Principles — 3-2-1 rule, encryption requirement, restore test requirement
Classification and backup requirements — Backup classes A through D with RTO, RPO, interval
Backup methods — Permitted backup types and combinations
Storage locations and media — Local, offsite, offline/air-gapped
Retention periods — Table with periods per backup type
Encryption and key management — Algorithms, key management
Access protection — Permissions, logging, four-eyes principle
Monitoring and escalation — Monitoring, error handling, escalation levels
Restore tests — Frequency, scope, documentation
Responsibilities — Roles and tasks
Special cases — SaaS, databases, encryption, VMs
Exceptions and risk acceptance — Process for justified deviations
Review and update — Annual review cycle
Effective date and approval — Date, management signature

This outline is not a rigid framework. Adapt it to your organization. Small companies can consolidate sections; larger organizations will elaborate individual chapters in more detail.

From policy to living process

The best backup policy is useless if it is written once and then forgotten. For it to be effective, it must be embedded in everyday business operations.

Communication: The policy is made known to all relevant employees (IT, business departments with responsibility for data). Ideally, every participant confirms acknowledgment in writing.

Training: Backup administrators are trained on the policy and know their obligations. Business departments understand which data is backed up in which class and what the retention periods mean.

Review: The policy is reviewed at least annually, and on an ad-hoc basis when significant changes occur to the IT infrastructure. New systems, new cloud services, changed legal requirements, or a security incident can trigger an unscheduled review.

Versioning: Every change is documented, the old version is archived, the new version is approved and communicated.

ISMS Lite maps exactly this lifecycle: you create the policy (with AI support if needed), version changes automatically, obtain digital acknowledgment from employees, and have management approve it with a signature. This way, the backup policy does not become a paper tiger but a living document that actually protects your organization.