Backup requirements for SOC 2, GDPR and HIPAA

This is not legal advice. Frameworks are interpreted by your auditor, your regulator and your counsel, and requirements vary by jurisdiction, sector and the data you hold. Treat this as a map of what is commonly asked for, then confirm specifics with whoever owns compliance.

With that said: the single most common finding is not missing backups. It is missing evidence that a restore was ever tested. Nearly every framework asks for the test, and nearly every team has the backups and no record of the test.

What the frameworks actually ask

SOC 2 — under the Availability criterion, the expectation is that you back up data, that recovery procedures exist and are documented, and that they are tested periodically with the results recorded. Auditors typically ask for: your backup policy, evidence backups ran across the audit period, and dated records of restore tests.

GDPR — Article 32 requires "the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident," and regular testing of that ability. Note the wording: restoring in a timely manner is the obligation, which makes your measured RTO a compliance artefact, not just an ops metric. Article 17 covers erasure — see below, it is the genuinely hard part.

HIPAA — the Security Rule's contingency plan standard calls for a data backup plan, a disaster recovery plan, an emergency mode operation plan, and testing and revision procedures. Retrievable exact copies of electronic protected health information, and evidence you have exercised the plan.

The common shape across all three:

The erasure problem

This is the question that comes up in every GDPR conversation and has a more workable answer than people expect.

The tension: Article 17 gives individuals a right to erasure. Backups are immutable by design — rewriting them would destroy their integrity and defeat their purpose. You cannot both preserve backup integrity and surgically delete records from historical snapshots.

The commonly accepted resolution, reflected in guidance from several supervisory authorities: personal data may remain in backups until those backups rotate out on their normal schedule, provided you can demonstrate that:

1. The backup data is frozen — not used for any processing, only for disaster recovery.
2. The retention period is defined and documented, so "until it rotates out" is a bounded, stated period rather than indefinite.
3. Erasure is re-applied on restore — if you restore a snapshot containing data that was erased, you delete it again as part of the restore procedure.
4. The individual is informed that their data persists in backups and when it will expire.

What this means operationally is mostly documentation plus one runbook step:

• Write down your retention period and stick to it. An indefinite period is much harder to defend than a stated 30 or 90 days.
• Keep a log of erasure requests with dates.
• Add a step to your restore runbook: re-apply pending erasures after any production restore. This is the part teams miss, and it converts a defensible position into a breach the moment you actually restore.

Again — confirm the specifics with counsel. The shape above is common practice, not a guarantee about your situation.

Building the evidence

The controls themselves are ordinary engineering, and most of them you would want regardless.

Encryption with keys you hold:

import { generateKeyfile } from "@lighthouse-web3/baas-js-sdk";

generateKeyfile("/secure/lh.keyfile", process.env.LH_KEYFILE_PASSPHRASE);

await client.backup(["./db-dumps"], {
  description: "nightly",
  encryption: {
    keyfilePath: "/secure/lh.keyfile",
    passphrase: process.env.LH_KEYFILE_PASSPHRASE,
  },
});

Data is AES-256-GCM encrypted client-side; the storage operator holds only ciphertext. For questionnaires asking whether your provider can read the data, the answer is structurally no. Note the flip side, which auditors also ask about: you hold the keys, and losing them means losing the data. Key custody needs its own documented procedure.

Enforced, documented retention:

const policy = {
  sourceId: snapshot.sourceId,
  keepLatest: 30,
  before: new Date(Date.now() - 90 * 86400_000).toISOString(),
};
await client.pruneSnapshots({ ...policy, dryRun: false });

A policy in a document that nothing enforces is a finding. A policy the system applies is evidence. See retention policy.

Scoped access. Mint API keys with write and read scopes for the backup job, and keep deletion out of them. That separation is both a ransomware control and an access-control answer.

Restore test records. The one that actually gets flagged. Automate the drill and keep the output:

2026-08-21  postgres/orders  snapshot 4f2a…  restored 84m  412,338 rows  PASS
2026-07-21  postgres/orders  snapshot 9c1b…  restored 79m  398,102 rows  PASS

A dated log like that, produced automatically, answers the testing requirement in every framework above. How to test your backups has a CI drill you can lift directly — and its measured wall-clock time is the "timely manner" evidence GDPR asks for.

Data residency

Frameworks rarely mandate a specific region, but contracts and sector rules sometimes do, and customer questionnaires almost always ask.

If you have a hard residency requirement, confirm where snapshots are stored before committing, and be aware that client-side encryption changes the analysis: ciphertext whose keys never leave your infrastructure is treated differently from plaintext in many assessments — though whether your auditor accepts that argument is theirs to decide, not yours to assume.

A minimum viable policy

Most of a compliance backup programme is one page that says what you do and matches what you actually do:

• ✅ What is backed up, and what is deliberately excluded and why
• ✅ Frequency, and the resulting RPO
• ✅ Retention per tier, with the reason for each
• ✅ Where backups are stored and under whose control
• ✅ Encryption method and key custody, including what happens if a key is lost
• ✅ Who can restore, and who authorises it
• ✅ Drill cadence, and where results are recorded
• ✅ Measured RTO, with the date it was last measured
• ✅ How erasure requests are handled against backups

The mismatch is what gets flagged. A policy claiming quarterly restore tests with no records is worse than a policy claiming annual tests you actually performed — auditors are far more forgiving of modest commitments met than ambitious ones missed.

Start with the free tier: backupdata.io has 5 GB free, no card, and the 10-minute quickstart gets you to a first verified snapshot today.