Compliance frameworks have a way of sounding like they were written for organisations with a legal department and a dedicated security team. GDPR and NIS2 both mention backups, but neither hands you a checklist. This post translates what the two regulations actually ask of backup practice into a set of documents a small IT team, or an MSP acting on a client's behalf, can realistically maintain.

One caveat up front: this is practical guidance, not legal advice. Where your obligations are unclear, confirm with counsel or your national authority.

What each regulation says about backups

GDPR

GDPR doesn't use the word "backup" much, but three articles reach it directly:

• Article 5(1)(f) and Article 32 require appropriate security for personal data, and Article 32 specifically names the ability to restore availability and access to personal data in a timely manner after an incident. A backup that can't be restored, or has never been tested, is hard to defend as "appropriate."

• Article 30 requires a record of processing activities, including where data is stored and what security measures apply. Backup locations, retention periods, and encryption belong in that record.

• Article 33 requires notifying the supervisory authority of a personal-data breach within 72 hours. Ransomware that encrypts personal data counts as a breach of availability, and your backup logs are part of the evidence for what was affected and when.

There's also a well-known tension with Article 17, the right to erasure. Regulators have generally accepted that immediate deletion from backup archives isn't feasible, provided you have a documented retention policy, don't restore erased data back into production without re-applying the deletion, and can explain the process.

NIS2

NIS2 (Directive 2022/2555) has applied across the EU since October 2024, though national transposition timelines vary. It covers "essential" and "important" entities in sectors such as energy, health, digital infrastructure, manufacturing of critical products, and, notably, managed service providers. Medium-sized companies in those sectors are in scope, and many smaller suppliers get pulled in through their customers' supply-chain obligations.

Article 21 lists the minimum risk-management measures, and backups appear explicitly under business continuity: backup management, disaster recovery, and crisis management. The same article requires policies on cryptography and encryption, incident handling, and supply-chain security. Article 23 sets reporting deadlines: an early warning within 24 hours of becoming aware of a significant incident, a fuller notification within 72 hours, and a final report within a month.

Article 20 is the part that changes conversations with leadership: management bodies must approve the risk-management measures and can be held personally liable for non-compliance.

The documents that actually matter

Auditors and authorities don't want to see that you have backups. They want to see that you can demonstrate control over them. In practice that comes down to six documents, most of which can be short.

1. Backup policy

One or two pages stating what gets backed up, how often, where the copies go, how long they're kept, and who is responsible. Include the retention schedule explicitly, since it answers both GDPR's storage-limitation principle and the right-to-erasure question. If you follow a 3-2-1 approach, say so and name the three locations.

2. Data inventory with backup mapping

Your Article 30 record already lists what personal data you process. Extend it with a column for where each dataset is backed up and which encryption applies. This is usually the piece small teams are missing, and it's the one that turns a generic policy into evidence.

3. Encryption statement

A short description of how backups are encrypted, which algorithm and key length, where keys or passphrases are held, and who can access them. With Duplicati, this is straightforward: backups are encrypted client-side with AES-256 before leaving the source machine, so the storage provider never holds readable data. Document the passphrase custody arrangement carefully; a lost passphrase is a compliance failure of a different kind.

4. Restore test records

Article 32's "ability to restore" is only credible with evidence. Keep a log of restore tests: date, what was restored, how long it took, whether it succeeded, and who performed it. Quarterly is a defensible cadence for most organizations; monthly for anything NIS2 would consider essential. Duplicati's built-in verification can run automatically and provides a lightweight record between full test restores.

5. Backup monitoring and job logs

Both regulations, in different words, expect you to know when protection has failed. A folder of per-machine log files rarely satisfies that. Centralized reporting, such as the Duplicati Console, gives you a single view of job status and failures across every endpoint and a history you can export when an auditor asks "were backups running the week before the incident?"

6. Incident and recovery procedure

A one-page runbook covering: how you detect a backup or data-availability incident, who decides whether it's reportable, the 24/72-hour reporting steps, and the restore sequence. Tie it to the monitoring in document 5, because the clock in both GDPR and NIS2 starts when you become aware, and detection time is something you control.

Processors, MSPs, and the supply chain

If you're an MSP handling backups for clients, two things apply on top of the above. Under GDPR you're a processor, and Article 28 requires a contract specifying the security measures you provide and your obligations on breach notification; your backup policy is the natural attachment. Under NIS2, managed service providers are in scope in their own right, and your clients will increasingly ask for evidence of your own compliance as part of their supply-chain due diligence. Having these six documents ready is a sales advantage as much as a legal one.

Where to start

If you have none of this, start with the data inventory mapping (document 2) and a single restore test with a written record (document 4). Those two produce the most evidence for the least effort and surface the gaps in everything else. Add centralized monitoring next; it makes documents 5 and 6 mostly self-maintaining.

The goal isn't a binder. It's being able to answer, in an afternoon, the three questions any authority will ask after an incident: what did you have, was it protected, and can you get it back.

Need a single view of backup status across every endpoint for your compliance records? The Duplicati Console centralizes job monitoring, alerts, and history. Start a free trial or talk to us about MSP and enterprise plans.