Is a backup plan mandatory?

For most companies there is no law that prescribes a document with this name. The GDPR does, however, require appropriate technical and organisational measures and their regular testing, and NIS2 requires backup management from the entities concerned. A written plan is the simplest way to demonstrate both.

How extensive does the plan have to be?

For a small business a few pages are often enough: the list of systems with RPO and RTO, the storage locations, retention, responsibilities and the test plan. More important than its length is that it is up to date and that someone other than its author can act on it in an emergency.

Module CON.3 “Backup Concept” in the BSI's IT-Grundschutz Compendium describes what a plan should contain and works well as an outline. The nine building blocks and the checklist in this article cover the most important points.

Backup plan: a guide with checklist

Why a backup plan?

Without a plan, backup grows along with the IT: a job here for the new server, a USB disk there for accounting. Whether everything is covered and whether a restore succeeds in the time needed, nobody then knows for sure. The plan forces you to answer these questions completely once and records the answers so that they do not depend on a single person.

It is also expected from outside. The GDPR requires in Art. 32 the ability to restore personal data promptly after an incident and regular testing of the measures (Backup under the GDPR). NIS2 explicitly lists backup management among the obligations of the entities concerned (NIS2 and backup). In the IT-Grundschutz of Germany's Federal Office for Information Security (BSI), the topic has a module of its own, CON.3 “Backup Concept”. And cyber insurers usually ask how backups are made before the policy is even signed.

The nine building blocks

A complete plan answers nine questions. For a small business, a few pages are often enough.

Building block	Key question	Result
Inventory	Which systems, data and cloud services exist, and where are they?	List of all systems with data volume and owner
Recovery objectives	How much data loss and how much downtime is acceptable for each system?	RPO and RTO per class of system
Method	Whole drives, individual files or the virtual machine as a whole? How do databases stay consistent?	Backup type and schedule per system
Storage locations	How many copies, on which media, which off-site, which immutable?	Destinations following the 3-2-1 rule
Retention	How long are daily, weekly and monthly versions kept?	Generation scheme and deletion rules
Protection	Who may read, change and delete backups? Where is the key?	Permissions, encryption, safekeeping of the key
Responsibilities	Who reads the alerts, who stands in, who decides in an emergency?	Roles, deputies, order of recovery
Tests	How often and how thoroughly is the restore rehearsed?	Test plan with documented results
Evidence and upkeep	How is it proven what happened, and when is the plan reviewed?	Logs, reports, a fixed review date

RPO and RTO: the two most important figures

The recovery point objective (RPO) states how much work may be lost at most – with a daily backup at 3 a.m. it is up to one day. The recovery time objective (RTO) states how long a system may be down at most before it is working again. Neither figure is set by IT alone, but by management together with the departments: what does a day without the ERP system cost, what does a lost morning in accounting cost?

Class of system	Examples	RPO	RTO
Critical	Merchandise management, ERP, databases	a few hours	less than a day
Important	File server, mail	one day	one to two days
Supporting	Laptops, test systems	one day to one week	several days

The values are examples. What matters is that they are set deliberately and confirmed by tests: an RTO of four hours is worthless if restoring the database server takes six hours in the test.

Storage locations and retention

For storage locations, the 3-2-1 rule has proven itself and is also recommended by the BSI: three copies on two different media, one of them off-site. Against ransomware, an immutable or disconnected copy is added, plus regular tests – the 3-2-1-1-0 rule.

Retention usually follows a generation scheme: daily versions for a few weeks, weekly ones for a few months, monthly ones for a year or longer. Many older versions help when an attack or an error is only noticed late. The GDPR sets an upper limit: backups containing personal data should not be kept longer than necessary and should then expire automatically.

A backup is not an archive: statutory retention obligations under tax and commercial law – in Germany usually eight years for accounting vouchers and ten years for books and annual financial statements – are met by an audit-proof archive, not by the backup. Backups serve the restore and expire at the end of their period.

Keys, permissions and responsibilities

An encrypted backup is only as good as the safekeeping of its key. If the key exists only on the server that fails, the backup is lost along with it. The plan specifies where the key is kept – for example in a sealed emergency envelope in the safe and as a copy at a second location – and who has access to it.

Permissions are just as important: the systems being backed up should not be able to delete their own backups, otherwise an attacker with their rights can do so too. And it must be clear who reads error alerts, who stands in during holidays and who decides in an emergency. The order of recovery – first the network and directory service, then databases, then the business applications – belongs in the emergency manual together with the contacts.

Tests and evidence

A plan that has never been rehearsed is an assumption. Regular restore tests confirm RPO and RTO and reveal gaps, such as a new drive that was never added to the backup. Every backup, every test and every deletion should be logged in a traceable way – that is the evidence for auditors, insurers and your own management.

Review the plan at least once a year and after every major change: a new site, a new business application, moving services to the cloud or a change in the IT team.

Checklist

All systems, data sets and cloud services such as Microsoft 365 are recorded, each with an owner.
RPO and RTO are set for each system together with management.
Backup type and schedule are set for each system, databases are backed up consistently.
There are at least three copies on two media, one off-site and one immutable or disconnected.
Retention is set by generations, expired backups are deleted automatically.
The backups are encrypted, the key is kept separately and is accessible in an emergency.
The systems being backed up cannot delete their backups.
Responsibility and deputies for alerts and emergencies are settled.
The order of recovery is in the emergency manual.
The restore is tested regularly, the results are documented.
The next review date for the plan is in the calendar.

How AegisGrid puts the plan into practice

With AegisGrid, the plan becomes configuration. One run writes to up to eight destinations – local disk, NAS, your own backup server, a second site or the cloud storage. Schedules take the public holidays of each German federal state into account and catch up on missed runs, and retention applies per destination, also by generations. The data is encrypted on the system being backed up, and the key stays with you. On WORM storage of the backup server, every backup is locked against changes and deletion until its lock expires, even for the computers being backed up.

The backup server reports missing backups, regularly restores backups as a test and keeps a signed evidence log, from which an evidence report is produced as a PDF every month – proof that the plan is actually lived. If you would rather not run it yourself, leave the operation to our Managed Backup.

Writing a backup plan: what belongs in it