Guides

Server Backup Compliance: What SOC 2, HIPAA, and GDPR Actually Require

Published on: Saturday, Mar 21, 2026 By Admin

You’re building something real. You’ve got users, maybe some enterprise interest, and suddenly someone asks for your SOC 2 report. Or your legal team flags a GDPR concern. Or a healthcare client needs proof you handle data correctly before they’ll sign.

Most founders and IT admins don’t think about compliance until they have to. And by then, scrambling to reverse-engineer your backup setup into something audit-ready is not fun. The good news is that the backup requirements across these frameworks aren’t as mysterious as they seem. Once you understand what each one actually demands, you can build a setup that covers all three without doing redundant work.

Why Backup Compliance Is More Specific Than You Think

When people say “we’re compliant,” they often mean they have backups running somewhere. That’s not enough.

SOC 2, HIPAA, and GDPR each care about backups in different ways. They ask different questions. They want different proof. And they have different consequences when you get it wrong.

SOC 2 cares about availability and security controls. HIPAA cares about protecting health data and proving you can recover it. GDPR cares about data residency, the right to erasure, and breach response timelines.

If you’re just running nightly backups to an S3 bucket with no documentation, no encryption verification, no retention policy, and no restore testing, you’re not compliant with any of them. You might not even know it until an auditor asks you to prove otherwise.

Let’s go framework by framework.

SOC 2: What the Availability and Confidentiality Criteria Actually Mean for Backups

SOC 2 is a trust services framework. It’s not a government regulation, it’s an audit standard. You get a report from an independent auditor saying you meet certain criteria. Most enterprise customers ask for it.

There are five trust service criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Backups primarily fall under Availability and Confidentiality, though Security bleeds into everything.

What Availability Requires

The Availability criterion wants to see that your system is available for operation as you’ve committed to. Backups are a core mechanism for that. Specifically, auditors look for:

Documented backup procedures. Not just “we run backups.” A written policy describing what gets backed up, how often, and where it goes.
Evidence that backups actually run. Logs, alerts, monitoring. If a backup fails at 2am and nobody notices for a week, that’s a finding.
Restore testing. This one trips people up. You need to show you’ve actually restored from backups and that it worked. A backup you’ve never tested isn’t proof of availability.
Recovery time commitments. If your service level agreements say you’ll be back up within 4 hours, your backup and restore process needs to actually support that. Auditors check for alignment between your promises and your infrastructure.

What Confidentiality Requires

The Confidentiality criterion focuses on protecting data you’ve identified as confidential. For backups, this means:

Encryption at rest and in transit. Your backup data needs to be encrypted. Not optional. The audit will ask about your encryption standards.
Access controls. Who can access backup files? This needs to be restricted and documented.
Secure disposal. When you delete old backups, they need to be properly wiped, not just soft-deleted where they’re recoverable.

The practical takeaway: for SOC 2, you need written policies, automated monitoring, encrypted storage, and documented restore tests. If you can’t produce logs showing your last 90 days of successful backups and at least one restore test, you’ve got a gap.

HIPAA: The Backup Requirements Nobody Reads Carefully

HIPAA gets misunderstood a lot. People treat it like a vague “be careful with health data” rule. It’s actually quite specific.

The Security Rule under HIPAA has a section called the Contingency Plan standard. It directly addresses backups. Here’s what it requires:

The Five Implementation Specifications

HIPAA breaks its contingency plan requirements into five specifications. Two are required, three are addressable (meaning you can document why they don’t apply, but you really should implement them anyway).

Required:

Data Backup Plan. You must have a documented procedure to create and maintain retrievable exact copies of ePHI (electronic protected health information). This means complete, verifiable copies. Not just “some of it.”
Disaster Recovery Plan. A documented procedure to restore lost data. This is separate from the backup plan. You need both.

Addressable (but practically required):

Emergency Mode Operation Plan. How do you keep critical business processes running while restoring systems?
Testing and Revision Procedures. You need to test your contingency plans and update them when things change. Just like SOC 2, untested backups are a liability.
Applications and Data Criticality Analysis. You need to assess which applications and data are critical to operations and prioritize them accordingly.

What HIPAA Specifically Cares About Beyond SOC 2

A few things HIPAA adds that SOC 2 doesn’t emphasize as much:

Business Associate Agreements (BAAs). If your backup data touches ePHI, every vendor in that chain needs a signed BAA. Your cloud storage provider. Your backup software. Anyone who has access to or processes that data.
Audit logs. HIPAA wants logs of who accessed what and when. This extends to your backup system. Access to backup files should be logged.
Breach notification timelines. If your backup data is compromised, you have 60 days to notify affected individuals and the Department of Health and Human Services. Your incident response plan needs to account for the possibility that backup data gets breached.

The practical takeaway: for HIPAA, you need a written backup plan, a written DR plan, tested restores, BAAs with every vendor, and audit logs on backup access. If you’re using a managed backup tool like Snapbucket, confirm they’ll sign a BAA and that all storage is encrypted.

GDPR is a European Union regulation, but if you have users in the EU or process EU residents’ personal data, it applies to you regardless of where your company is based.

GDPR doesn’t have a section that says “here’s how to do backups.” It’s principles-based. But several of those principles have direct implications for how you manage backup data.

Data Residency

GDPR restricts transferring personal data outside the EU to countries that don’t have adequate data protection. This affects where your backups live.

If you’re backing up servers that contain EU personal data, your backup storage needs to be in an approved location. EU-based S3-compatible storage, or storage with appropriate safeguards in place. Using a US-only storage provider without the right data transfer mechanisms is a problem.

This is why flexibility in choosing your backup storage location matters more than people realize. Being locked into a single region or provider isn’t just a cost issue. It can be a compliance issue.

The Right to Erasure (Right to Be Forgotten)

This one is genuinely tricky for backups. GDPR gives individuals the right to request deletion of their personal data. Your live database? You can delete a user’s record. Your backups from the last 90 days? Harder.

The practical approach most legal teams accept:

Document your backup retention policy. Have a clear, written policy about how long backups are kept and when they’re deleted. If you’re keeping backups for 30 days, document that.
Treat backups as a restoration mechanism, not an archive. Backups are there to recover from failure, not to store data indefinitely. This framing matters when responding to erasure requests.
Delete backups according to your stated policy. If your policy says backups are deleted after 30 days, delete them after 30 days. Don’t keep them longer just because it’s easy to do so.
Consider encryption as a form of erasure. Some legal frameworks accept that destroying the encryption keys effectively erases the data. Talk to your legal counsel about whether this applies in your context.

Breach Notification

GDPR requires notifying your supervisory authority within 72 hours of becoming aware of a personal data breach. If your backup storage is breached, that clock starts immediately. Your incident response plan needs to include backup infrastructure, not just production systems.

Data Minimization

GDPR’s data minimization principle says you shouldn’t collect or retain more data than you need. Applied to backups, this means your retention policy should have a real end date. Keeping backups forever isn’t compliant unless you can justify it. Most teams can’t.

The practical takeaway: for GDPR, you need EU-compliant storage locations, a documented and enforced retention policy, a plan for handling erasure requests, and backup infrastructure in your incident response plan.

Where These Frameworks Overlap (And How to Handle All Three at Once)

There’s more overlap than you might expect. If you build a backup setup that covers all three, you’re not doing triple the work.

Here’s what all three require in some form:

Encrypted backup storage. Non-negotiable across the board.
Documented backup and recovery procedures. Written policies, not just working software.
Regular restore testing. All three want proof that your backups actually work.
Access controls and audit logging. Who can touch backup data, and when did they do it.
Defined retention policies. How long you keep backups, and what happens when they expire.
Incident response that includes backup infrastructure. Breaches aren’t just production database events.

Build these things properly once, and you’ve got a strong foundation for all three frameworks. The differences are mostly in the specifics: HIPAA adds BAAs, GDPR adds residency requirements, SOC 2 adds the formal audit trail.

The Documentation Problem Most Teams Ignore

Here’s something auditors will tell you: it’s not enough to have a good backup system. You need to be able to prove it.

That means documentation. Not a wiki page from 2021. Current, maintained documentation that describes:

What gets backed up and what doesn’t
How frequently backups run
Where backup data is stored and who has access
What encryption is used
How long backups are retained and what the deletion process is
When you last tested a restore and what the results were
What happens when a backup fails

Most teams have half of this scattered across Notion pages and Slack messages. Auditors want it organized, current, and signed off by someone responsible.

If you’re using a centralized backup dashboard, a lot of this documentation becomes easier because the system itself produces logs and reports. But you still need to turn that data into written policy documents.

If an audit is coming up, or you want to get ahead of it, here’s a practical checklist:

Encryption:

Confirm all backup data is encrypted at rest (AES-256 is standard)
Confirm backups transit over encrypted connections (TLS)
Document your encryption standards in your security policy

Access Control:

Identify who has access to backup files and backup management systems
Restrict that access to people who need it
Enable audit logging on all backup access

Testing:

Run a restore from backup right now if you haven’t done one recently
Document it: date, what you restored, whether it succeeded, how long it took
Schedule restore tests on a recurring basis (quarterly at minimum)

Retention:

Write down your retention policy
Make sure your backup system actually enforces it
For GDPR, make sure your policy has an actual end date

Storage Location:

Know where your backup data is physically stored
For GDPR, confirm it’s in an appropriate jurisdiction
For HIPAA, confirm your storage vendor will sign a BAA

Incident Response:

Make sure your IR plan mentions backups explicitly
Know who’s responsible for notifying regulators if backup data is compromised

You don’t need to do all of this manually. A good backup platform should handle the automated parts: running backups on schedule, encrypting data, logging activity, sending failure alerts. What you do need to do is write the policies that wrap around the automation and make sure humans are accountable for the parts that require human judgment.

Conclusion

Backup compliance isn’t about checking boxes. It’s about being able to prove, under pressure, that you actually protect and can recover your data. SOC 2, HIPAA, and GDPR each approach that proof differently, but they’re all asking the same underlying question: can we trust you with this data?

The three things that will get you through any backup-related audit question:

Written policies that match your actual setup. If your policy says daily encrypted backups and you’re running weekly unencrypted ones, that’s a problem.
Tested restores with documented results. A backup you’ve never restored from is just a file sitting somewhere.
A backup system that produces logs and alerts automatically. You can’t manually track compliance. You need infrastructure that does it for you.

Snapbucket was built specifically to handle the automated parts of this. Encrypted storage to any S3-compatible provider (so you can choose your region for GDPR), a centralized dashboard with full backup history logs, automatic failure alerts, and a one-click restore process that’s fast enough to actually meet your RTO commitments. If you want to see how it fits into your compliance setup, start a free trial or reach out directly and we’ll walk through it with you.