Why German law is a good yardstick for data protection and backup quality

By Lucas Flores, IT Systeme Flores UG. Last updated 2026-10-16

Illustration: blocks of different heights in a row, held against a ruler and a glowing green benchmark line; two of them reach the line.

Not legal or tax advice. Rules change; every statement below links its source, read on 16 October 2026. Have your own advisor confirm what applies to you.

Short answer: German law is a good yardstick because its rules on data protection, business records and IT security are specific enough to test, public, current, and enforced by independent authorities that publish their positions. Data protection is a constitutional right. The records rules say not only how long to keep documents but how: unaltered, traceable, machine-readable and described in writing. The federal IT security agency publishes a backup baseline and a catalogue for cloud services. Backup and archive software that meets these rules shows properties you can check wherever you are: where the data lives, who holds the keys, whether tampering shows, whether a restore is proven. It is a benchmark, not a certificate, and this article does not claim that German law is the strictest in the world.

What makes a rule set a good yardstick?

Four tests, applied to the rules below:

Specific. A buyer can turn a requirement into a yes-or-no question about a product.
Public and current. Anyone can read the text, and the issuing body keeps it up to date.
Enforced. Independent bodies supervise it and publish their reasoning.
Technical. It reaches storage, keys, integrity and restore, not only principles.

German rules meet these tests in the areas below. Other countries meet some of them: the GDPR applies in all EU states, so much of German data protection law is shared law, and Switzerland has a records ordinance close in spirit to the GoBD. That is why this is an argument about a useful benchmark, not about national pride.

Where does German data protection law come from?

The Hessian data protection authority describes the Hessian Data Protection Act of 1970 as the first data protection law in Germany and worldwide (HBDI). The act responded to the growing automation of data processing and created the office of the Hessian data protection commissioner. We repeat that as the authority words it.

The second step is the Federal Constitutional Court's census judgment of 15 December 1983 (1 BvR 209/83 and five other cases, BVerfG). The court derived from the general right of personality (Article 2(1) with Article 1(1) of the Basic Law) a right to informational self-determination: in principle, each person decides on the disclosure and use of their personal data. Limits need an overriding public interest, a clear statutory basis and proportionality, and the legislator has to provide organisational and procedural safeguards. That last demand has shaped German rules ever since: they describe processes and organisation, not only principles.

How is data protection enforced in Germany?

GDPR plus BDSG. The GDPR applies directly in every EU state. The Federal Data Protection Act (BDSG) adds national rules where the GDPR leaves room. One concrete example: under § 38 BDSG a company must appoint a data protection officer once at least 20 people are regularly engaged in automated processing of personal data, on top of the cases in Article 37(1) GDPR; Article 37(4) GDPR allows member states to add cases.
Many authorities. Supervision follows the federal structure. The federal commissioner (BfDI) supervises federal public bodies and telecommunications providers (§ 9 BDSG); the state authorities supervise private companies (§ 40 BDSG). The DSK's list names one federal authority and 17 state authorities: 16 states, and Bavaria has two, one for the public sector and one for private companies. Church and broadcasting supervisors are listed separately.
The DSK as their joint conference. The Datenschutzkonferenz (DSK) aims at uniform application of European and national data protection law through resolutions, decisions, guidance (Orientierungshilfen), standardisation and opinions. Of its resolutions the DSK says that they are recommendations agreed among all authorities and not legally binding (DSK). A technical example is the Standard Data Protection Model, version 3.1 of 14 May 2024: a method that turns legal requirements into seven protection goals (data minimisation, availability, integrity, confidentiality, unlinkability, transparency, intervenability) and leans on IT-Grundschutz.

What that means in practice: many authorities that publish guidance and positions put much of the practical reading of "appropriate security" on the record, for example on encryption and backups (see GDPR and backups). It also means that authorities can differ, as the cloud section below shows, and that for large providers from outside Germany the lead authority may sit elsewhere: the DSK's own report on Microsoft notes that the Irish authority leads for Microsoft Ireland while German authorities supervise their German customers (DSK summary).

What do the German rules on business records require?

The GoBD are the finance administration's guidance on keeping books, records and documents electronically (BMF letter of 28 November 2019, amended on 11 March 2024 and 14 July 2025; read in the consolidated text). They apply to businesses that keep books and records for German tax purposes and build on § 147 AO and § 257 HGB. They do not prescribe a technology (Rz. 10, a numbered paragraph of the letter); they describe properties a system and its process must have:

Traceability. An expert third party must be able to follow a record in reasonable time. For every data processing system there has to be a clearly structured procedure documentation (Verfahrensdokumentation) that shows content, structure, flow and results (Rz. 151 to 153); the description of how backups are made is part of it (Rz. 106).
Completeness. Bookings and records have to be made individually, in full, correctly, in time and in order (§ 146 (1) AO).
Immutability. A booking or record must not be changed so that its original content can no longer be determined (§ 146 (4) AO); information that has entered the process must not be suppressed or overwritten without being marked (Rz. 108). It can be ensured by hardware, by software or by organisation, and storing files in a plain file system does not meet it as a rule without further measures (Rz. 110).
Machine readability. During the whole period the data has to be available at any time, be made readable without delay and be evaluable by machine (§ 147 (2) AO), and in a tax audit the authority can ask for read access, an evaluation to its specification or a transfer in a machine-readable format (§ 147 (6) AO).

The retention periods as they stand today:

Class of document	Period	Source
Books and records, inventories, annual accounts, management reports, opening balance sheet, and the instructions needed to understand them	10 years	§ 147 (3) AO, § 257 (4) HGB
Accounting vouchers (Buchungsbelege)	8 years since 1 January 2025 (before: 10)	§ 147 (3) AO, § 257 (4) HGB
Received commercial letters, copies of sent commercial letters, other documents relevant to taxation	6 years	§ 147 (3) AO, § 257 (4) HGB

The period starts at the end of the calendar year in which the last entry was made or the document was received, sent or created (§ 147 (4) AO, § 257 (5) HGB). It does not end while the document still matters for a tax whose assessment period is open (§ 147 (3) AO). The cut for vouchers from ten to eight years came with the Fourth Bureaucracy Relief Act (BGBl. 2024 I Nr. 323) and applies from 1 January 2025 to documents whose old period had not yet run out. Banks, insurers and securities institutions keep vouchers for ten years under sentence 2 of § 257 (4) HGB, which the Federal Ministry of Finance announced on 6 August 2025 (press release).

There is no official GoBD certificate. The GoBD say that the tax authority cannot make general statements on the conformity of hardware and software (Rz. 179), that positive attestations are issued neither in an audit nor in a binding ruling (Rz. 180), and that a third party's certificate can help a company choose software but does not bind the tax authority (Rz. 181). Responsibility stays with the taxpayer. The consequence is concrete: if books or records cannot be produced or are not used as the basis of taxation, the tax authority may estimate the tax base (§ 162 (2) AO).

More on how this applies to mail: email archiving under the GoBD and GoBD and email archiving, explained; the design is described in the documentation page GoBD and evidence.

How other countries compare

The table keeps the comparison of this site's earlier article, "GoBD compared internationally", re-checked on 16 October 2026. If you are outside Germany, the GoBD apply to you only if German tax law does, for example through a German company or permanent establishment.

Jurisdiction	Retention for business records	What it says about electronic records
Germany (GoBD, AO, HGB)	10, 8 and 6 years by class of document, see above.	Detailed: traceability, completeness, immutability, machine evaluation, procedure documentation (GoBD); direct data access for the auditor (§ 147 (6) AO).
Switzerland (OR, GeBüV)	10 years for the books, accounting vouchers, annual report and audit report, from the end of the financial year (Art. 958f OR).	Electronic storage is allowed if it matches the underlying transactions and can be made readable at any time. The ordinance GeBüV adds integrity (no change without detection, Art. 3), documentation of organisation and infrastructure (Art. 4) and availability (Art. 6); see also the KMU portal.
Austria (BAO)	7 years for books, records and vouchers, longer while they matter for pending proceedings (§ 132 (1) BAO).	Storage on data carriers is allowed if a complete, orderly, content-identical and faithful reproduction is guaranteed at any time (§ 132 (2) BAO).
United Kingdom (HMRC, Companies Act 2006)	6 years from the end of the last financial year for a company's records (GOV.UK); VAT records generally at least 6 years (VAT Notice 700/21); under company law 3 years for private and 6 for public companies (s 388).	VAT-registered businesses must keep certain records digitally (Making Tax Digital). No catalogue of technical properties comparable to the GoBD.
United States (IRS)	Generally 3 years; 6 years if more than 25 % of gross income was left out; 7 years for bad-debt or worthless-securities claims; at least 4 years for employment tax; indefinitely if no return was filed or it was fraudulent (IRS).	Rev. Proc. 97-22 sets requirements for electronic storage systems: controls for integrity, accuracy and reliability, controls to prevent and detect unauthorized alteration or deletion, periodic checks, and indexing and retrieval. Shorter and less prescriptive than the GoBD.
United States (SEC Rule 17a-4, broker-dealers only)	6 years for certain core records, 3 years for others, including business communications.	Strict: a system either keeps a complete time-stamped audit trail or preserves records in a non-rewriteable, non-erasable format (17 CFR 240.17a-4(f)).

General retention for business records

Periods from the table above. Germany and Switzerland spell out in most detail how electronic records must be kept; the other rules are shorter or apply to narrower groups.

Germany GoBD: detailed rules on form

6–10 years

Switzerland Art. 958f OR, GeBüV: rules on form

10 years

Austria § 132 BAO

7 years

United Kingdom HMRC, Companies Act; VAT records digital

3–6 years

US, broker-dealers SEC 17a-4: strict on form

3–6 years

United States IRS; Rev. Proc. 97-22 for electronic storage

3–7 years

The bar shows the longest general period named for that jurisdiction, the text the full range; which one applies depends on the record. Not legal advice.

How to read it: every one of these countries sets retention periods, and the periods differ less than the rules on form. Germany (GoBD) and Switzerland (GeBüV) spell out for every business how electronic records must be kept: unaltered, documented, available. The UK requires digital records for VAT, the US has requirements for electronic storage systems and a strict rule for broker-dealers, and Austria sets conditions for storage on data carriers. German rules are not the only detailed ones, and the table is not a ranking.

What does the German security baseline add for backups?

The Federal Office for Information Security (BSI) publishes the IT-Grundschutz Compendium, Edition 2023, which BSI lists as current; BSI says the current IT-Grundschutz stays applicable during a multi-year transition to a new digital rule set (BSI). Its module CON.3 Datensicherungskonzept is a short, testable list for backups. Among the basic requirements, which the module says must be met:

record the conditions per system, including legal requirements and deletion rules (CON.3.A1);
store backups on separate backup media and keep the media apart from the backed-up systems (CON.3.A2, CON.3.A12);
write a backup plan per system: what is backed up, the restore order, how long backups are kept, and how they are protected against unauthorised access and overwriting (CON.3.A4);
protect backups so that they cannot be overwritten, accidentally or on purpose (CON.3.A14);
test regularly whether data can be restored intact and in reasonable time (CON.3.A15).

The standard requirements add, for online storage, a contract that settles the place of storage, service levels, authentication and encryption in storage and in transport (CON.3.A9). For higher protection needs the module suggests encrypting all backups, making sure encrypted data can still be restored after a long time, and protecting the keys with a separate backup (CON.3.A13). The module leaves long-term retention of electronic documents to another module (OPS.1.2.2 Archivierung), the same line this site draws in backup vs. archive.

C5 for cloud services. The BSI's Cloud Computing Compliance Criteria Catalogue (C5) describes minimum requirements for secure cloud services, first published in 2016. Cloud providers have the criteria examined by auditors they commission; BSI is not involved in the audit, and customers should request the report each year and evaluate it. C5:2026 has been final since the end of March 2026; for audit periods ending on or after 1 June 2027 BSI recommends it, until then C5:2020. C5 matters for the cloud storage you choose, not for software you run yourself.

NIS2 in Germany. The act implementing the NIS2 directive (BGBl. 2025 I Nr. 301, signed on 2 December and promulgated on 5 December 2025) has been in force since 6 December 2025 (BSI). BSI estimates that about 29,500 entities now fall under its supervision, against about 4,500 before. Affected entities must take risk-management measures; § 30 (2) BSIG lists among the minimum measures the maintenance of operations, "such as backup management and recovery after an emergency", and concepts for the use of cryptography. Registration takes two steps, "Mein Unternehmenskonto" and then the BSI portal, which opened on 6 January 2026 (BSI). Whether your company is in scope is for you to check; the BSI says companies must do that themselves. This article does not say who is affected, and no backup tool makes anyone NIS2-compliant by itself.

What about cloud services and third countries?

This is the area where the picture is mixed and still moving, so here is the dated sequence without a verdict.

24 November 2022. The DSK decided that controllers could not demonstrate GDPR-compliant use of Microsoft 365 on the basis of Microsoft's data protection addendum of 15 September 2022, as long as transparency about processing for Microsoft's own purposes and proof of its lawfulness were missing (DSK decision). The accompanying summary says the review was limited: it covered contract terms under Article 28 GDPR, not the actual data flows or individual functions (summary). Microsoft considered the findings wrong, as the Hessian report below records.
10 July 2023. The European Commission adopted the adequacy decision for the EU-US Data Privacy Framework (Implementing Decision (EU) 2023/1795). Since then, transfers to US organisations on the Data Privacy Framework List may rely on it without further transfer tools (EDPB information note); the DSK published application notes on 4 September 2023. The same notes recall that a transfer can also be a possibility of access from a third country, for example for administration or support: the question is who can reach the data, not only where the bytes are.
2024 and 2025. The Commission published its first review report on 9 October 2024 and the EDPB reported on 4 November 2024 (EDPB report). On 3 September 2025 the General Court dismissed an action for annulment (T-553/23, Latombe v Commission) and confirmed that the US ensured an adequate level of protection on the date of the decision (press release). An appeal to the Court of Justice (C-703/25 P) was lodged on 31 October 2025; check the court's case page for where it stands.
15 November 2025. After talks with Microsoft, the Hessian commissioner published a 137-page report. Measured against the DSK's seven points, he finds that a GDPR-compliant operation of Microsoft 365 is possible: the contract terms were developed, the adequacy decision now covers transfers to US organisations on the Data Privacy Framework List, and Microsoft moved the greater part of processing into the European Economic Area. He adds that this holds only if the customers meet their own duties. The report gives recommendations for bodies based in Hesse. The DSK's list of decisions shows no later DSK decision on Microsoft (checked on 16 October 2026), so the 2022 finding has not been formally replaced.

The honest summary: no one says cloud services are unlawful as such. The 2022 finding stands formally, one authority has reassessed after contract changes, the Data Privacy Framework is in force but contested, and whether a US cloud service fits your case remains your own assessment with your data protection officer.

What self-hosted backup and archive on storage you choose changes, and what it does not:

It changes who receives your data. With software you run yourself, the software vendor does not receive it, and no backup vendor's cloud sits in the path.
It lets you choose the location and the provider, for example a German or Finnish location of an object storage provider or your own disk, and so decide which jurisdiction applies to the stored bytes.
It lets you encrypt before upload with keys you hold, so the storage provider holds ciphertext only.
It does not remove duties. You still need a processing agreement with the storage provider if you use one (Article 28 GDPR), a look at who owns that provider (an EU region of a US-owned company is a different question from an EU-owned provider), and an assessment of the source system: backing up Microsoft 365 means reading data out of the very service discussed above. The copy can live elsewhere, the source does not move.

What this means when you choose backup software

A short checklist a buyer anywhere can use, taken from the rules above. It is plain text on this page: nothing to download and no form to fill in.

Where does the data live? You should be able to name the country, the provider and who can reach it, and to choose them. CON.3 asks to settle the place of storage in the contract when backups go online (CON.3.A9), and the transfer rules of the GDPR turn on the same question.
Who holds the keys? Data should be encrypted before it leaves your systems, with keys that the storage provider does not hold and that are protected by a separate backup (CON.3.A13). Ask what a provider that operates the software for you can decrypt.
Can tampering be detected or prevented? Immutable storage, a hash chain or both. The GoBD accept hardware, software or organisational measures for unalterability, but not a plain file share on its own (Rz. 110). CON.3.A14 asks that backups cannot be overwritten, by accident or on purpose.
Can you prove retention? Periods you can set from your own law (6, 8 and 10 years in Germany, 7 in Austria), deletion that waits until the period ends, and a way to suspend deletion for legal reasons.
Can you prove a restore? Regular restore tests with written results (CON.3.A15, Article 32(1)(c) and (d) GDPR, and the periodic checks that IRS Rev. Proc. 97-22 asks for). A green job status shows only that data was written.
Is there documentation you can build on? German auditors expect a procedure documentation (Verfahrensdokumentation) that is yours. A vendor cannot write it for you, but should state the facts that belong in it: storage location, encryption, access, retention, deletion.
Can you leave? An open, documented format and a way to restore without the vendor's servers. Records have to stay available and machine-evaluable until the period ends, whatever happens to a vendor (§ 147 (2) AO).
Does the vendor say what it does not do? Be wary of certificates that cannot exist (the GoBD say none binds the tax authority) and of claims that a tool "makes you compliant". Good vendors name their measures and their limits.

How Restow handles this

Restow is developed by IT Systeme Flores UG in Bergisch Gladbach, Germany, and designed with the German rules above in mind. This is what the released version does and does not do, checked against the product source and docs at tag v0.4.1 (paths are in the public repository). Restow is a beta: run it next to your existing backup until you have checked restores against your own data.

What it does

Self-hosted. You run it on your own infrastructure. There is no Restow-run cloud, no telemetry, and it connects only to what you configure (encryption and key handling, your data).
Storage you choose. Backups go to a local path, S3-compatible object storage or NFS (storage). For S3 there is a Hetzner Object Storage preset with a location choice: Falkenstein and Nuremberg in Germany, Helsinki in Finland (apps/web/src/features/storage/forms.ts; locations per Hetzner). The preset has not been tested against a real Hetzner bucket yet. Copy repositories can hold a second copy elsewhere. An S3 endpoint must use HTTPS: a new or changed endpoint over plain http:// is refused, except to localhost (docs/STORAGE.md).
Immutable backups, per repository. Off until an administrator turns them on for a repository. On S3 with Object Lock (compliance or governance mode, 1 to 3650 days; a bucket without Object Lock is refused) the packs, manifests and keys of the chunk store and the backups of servers and clients, file shares and Proxmox VE containers are locked until the period plus 7 days has passed, and a daily renewal keeps data that new restore points reuse locked (docs/STORAGE.md). A restore point shows "Immutable until <date>" in green only for a compliance retention that the storage itself reported. That is the kind of measure CON.3.A14 asks for; whether it is enough for your systems is yours to judge. The archive's item records keep their own retention, as before (immutable backups).
Ransomware detection, a tripwire. Every new restore point is judged for signs of ransomware from data the backup already has: how much changed against the object's own history, mass deletions, renamed extensions, known ransomware extensions and ransom notes, and the entropy and compressibility of new data. A finding marks the restore point "Suspicious", raises a notification and, while it is unresolved and the hold is switched on (the default), stops retention from deleting any restore point of that object, so clean older ones are not pruned (ransomware detection, docs/RANSOMWARE.md). It is not a virus scanner, a restore point without findings proves nothing, and it was tested with simulated attacks, not with live ransomware.
Encryption with your own keys. Every chunk is encrypted with AES-256-GCM, with a key per tenant that is wrapped by the installation's master key (docs/ARCHITECTURE.md). On a self-hosted installation nobody outside your organisation holds the master key; if a service provider operates the installation for you, the provider does, and your data processing agreement should say so.
An archive with a hash chain and anchors. The archive is append-only: each item is chained with SHA-256 to the one before (packages/core/src/archive/chain.ts), and daily anchors catch items cut off the end of the chain. The chain check recomputes every link. The chain and the anchors live inside Restow, so someone with write access to the database could recompute them; the documentation says so. Search and export (EML in a ZIP, MBOX) are in every edition (mail import, export and the archive).
Designed for GoBD-compliant use, with edition limits. Capture from the mailboxes (Microsoft Graph, IMAP sync, near-time and not complete), journal receipt of Exchange Online reports and copies a mail provider forwards, enforced retention and legal hold are in Business and Service Provider, the archive itself in every edition (what is covered and what stays yours, editions). No certificate, because none exists.
Restore evidence. A weekly restore check reads a random sample of every backup back, and every read and restore goes into a hash-chained audit log. File shares are checked after every new restore point, Proxmox VE (preview) guests within minutes of every new restore point, and Proxmox VE can also boot-test restore points (how restorability is proven, how to prove a restore).

How the archive period relates to the legal periods

The archive keeps each item for a fixed 8 years, ending on 31 December of the year of receipt plus 8 (apps/api/src/features/archive/retention-policy.ts); no screen or API sets another period yet (docs/ARCHIVE.md, in German). Set against the German periods, that covers the 6 years for commercial letters and the 8 years for accounting vouchers. It does not cover the 10-year class (books, records, annual accounts), it does not account for the rule that a period does not end while the assessment period is open, and banks, insurers and securities institutions keep vouchers for 10 years. The code already knows the choices 6, 8 and 10 years or unlimited (packages/core/src/archive/retention.ts), but nothing lets you pick one yet. Until then a legal hold, in Business and Service Provider, suspends deletion for the items it covers; it is meant for documented reasons, not as a retention setting. Which of your mail falls into which class is a question for your tax advisor; see backup vs. archive.

What it does not do

It carries no GoBD certificate, because none exists, and it gives no legal or tax advice.
It does not write your procedure documentation. It supplies facts that belong in it (storage location, encryption, retention, access); the document stays yours.
Immutability is opt-in and has limits. It is off until an administrator turns it on per repository, and the installation's default repository cannot be made immutable (give the tenant a repository of its own). Only S3 with Object Lock can lock data. A directory (the Docker volume, an NFS share) gets a deletion delay that Restow's own code keeps: it protects against misuse of Restow, not against anyone with access to the server or the share, and the interface says it is not immutability. Not locked: checkpoints, staging, exports, downloads and restic's lock and index files. Someone who controls Restow can stop new locks and the renewal, and a governance lock is lifted by any account with the bypass permission on the bucket, so use compliance mode or an access key without that permission. The lock was tested against a simulated S3 service only, not a real one, and behaviour with a bucket-wide default retention is untested (docs/STORAGE.md, Learn: immutable backups).
What reaches the archive is decided per mail job by the capture ways you choose (Graph or Exchange journaling for Microsoft 365, IMAP sync or forwarded copies for IMAP and Google Workspace) and by what you import. The near-time ways can miss a mail that is moved or deleted right after delivery, and they were tested against simulated services only. An auditor export and a signed evidence report are planned; neither is built.
It makes no statement about the rules of other countries, such as SEC 17a-4 or HMRC rules. C5 is a catalogue for cloud providers: a C5 report applies to the cloud storage you choose, not to software you run yourself.

Frequently asked

Is German law the strictest in the world?

We do not claim that, and we know of no source that ranks countries. The claim is narrower: German rules on data protection, business records and IT security are specific, public and enforced, so they make a useful benchmark. Switzerland's records ordinance is similar in spirit, and the GDPR applies in the whole EU.

Do I have to follow German law if my company is outside Germany?

Only if it applies to you. The German tax record rules (§ 147 AO, GoBD) apply if German tax law applies to you, for example through a German company or permanent establishment. The GDPR can apply to a company outside the EU if it offers goods or services to people in the EU or monitors their behaviour there (Article 3 GDPR). Your own counsel decides what applies.

Is there an official GoBD certificate for software?

No. The GoBD state that the tax authorities issue no positive attestations on the conformity of a bookkeeping system, neither in an audit nor in a binding ruling, and that a third party's certificate does not bind them (Rz. 179 to 181). A certificate can help when choosing software, but responsibility stays with the taxpayer.

How long must I keep accounting vouchers in Germany?

Eight years since 1 January 2025 (before: ten), counted from the end of the calendar year in which the voucher arose (§ 147 (3) and (4) AO, § 257 (4) and (5) HGB, changed by the Fourth Bureaucracy Relief Act). Books and annual accounts: ten years. Commercial letters and other tax-relevant documents: six. Banks, insurers and securities institutions keep vouchers for ten years under the HGB. The period does not end while the document matters for a tax whose assessment period is still open.

May I use Microsoft 365 under German data protection law?

There is no ban. In November 2022 the DSK found that controllers could not demonstrate compliant use on the basis of Microsoft's September 2022 addendum. In November 2025 the Hessian commissioner reported, after talks with Microsoft, that compliant operation is possible for bodies in Hesse if Microsoft and the customer both meet their duties. The DSK's list of decisions shows no later DSK decision on this. Your data protection officer and counsel decide for your situation.

Does a self-hosted backup make me GDPR compliant?

No. It helps with where the data lives, who holds the keys and which processors you rely on. You still need your own record of processing activities, a deletion concept, processing agreements with any storage provider and a way to answer requests from data subjects.

Sources (read 16 October 2026)

More: Learn: backup vs. archive · Learn: GDPR and backups · Learn: immutable backups · Encryption and key handling · Storage · Ransomware detection · Verification · Docs: GoBD and evidence · Docs: backup vs. archive