Most MSPs and IT teams end up supporting more than one compliance framework at once. Each one talks about backups a little differently.
None of these frameworks tell you which backup technology to buy. They ask if you can protect sensitive data, control who touches it, and recover when something goes wrong.
Here’s how each one answers that, side by side.
| Control area | SOC 2 (Type I/II) |
HIPAA | PCI DSS v4.0 | GDPR / UK GDPR |
|---|---|---|---|---|
| Encryption of backup data | Commonly implemented to support Security and Confidentiality criteria, exact standard not prescribed | Currently an addressable implementation specification, meaning it must be implemented if reasonable or an alternative documented; proposed Security Rule updates may introduce stronger requirements | Cardholder data must be rendered unreadable everywhere it’s stored, including any backup copies that contain it | Article 32 names encryption as an example of an “appropriate” measure, risk-based rather than a fixed mandate |
| Access control to backups | Documented access restrictions required, including least privilege and access review | Access controls required as part of the Security Rule | MFA required for access into systems that can impact the cardholder data environment, including backup management systems where applicable | Article 32 requires measures ensuring confidentiality and resilience of processing systems, access control included as part of that |
| Audit logging | Expected, tied to your documented controls | Required as part of audit controls, no fixed retention period set | Logs must be protected from modification, retained at least 12 months, with at least 3 months immediately available for analysis | No specific log requirement, but the accountability principle means you must be able to demonstrate compliance on request |
| Backup retention | Determined by your own organizational policy, contracts, and risk assessment | Not specified by HIPAA itself; organizations typically set retention based on state medical record laws, business needs, and contractual obligations | Not fixed by PCI DSS itself; retention should follow documented business, legal, and compliance need, with secure disposal once data is no longer required | Storage limitation principle requires keeping personal data no longer than necessary for the stated purpose |
| Recovery testing | Evidence of actual restore testing expected, not just a written procedure | Requires an overall contingency plan, including a data backup plan, disaster recovery plan, and emergency mode operations plan, with periodic testing and revision | Tested recovery procedures expected, demonstrating that critical security functions and data protection can actually be restored | Article 32 explicitly requires the ability to restore availability and access to data in a timely manner, plus regular testing of that ability |
| Immutable / ransomware-resistant backups | Supports security objectives by reducing the risk of unauthorized alteration | Supports contingency planning and protection of ePHI, though not named outright | Supports protection against unauthorized modification of stored data | Supports the integrity and resilience requirements under Article 32, though not named outright |
| Backup integrity verification | Evidence of control effectiveness typically expected | Supports the availability and contingency requirements under the Security Rule | Supports demonstrating reliable recovery during testing | Directly supported by Article 32’s requirement to regularly test and evaluate the effectiveness of your safeguards |
| Air-gapped / offline copies | A risk-based control organizations adopt to strengthen their posture | Helps reduce ransomware impact on ePHI availability | Supports broader security architecture expectations | A risk-based measure supporting the same Article 32 resilience requirement |
| Backup provider’s own compliance | Vendor controls and service commitments are typically evaluated as part of your own control environment | Business Associate Agreement requirements apply to vendors handling ePHI | Third-party providers that can affect the cardholder data environment must meet applicable PCI DSS requirements | Article 28 requires a written agreement with any processor, and Article 82 keeps you jointly liable for damage caused by that processor’s failures |
The common ground
All four frameworks are asking the same three things:
- Is your backup data unreadable to anyone who shouldn’t see it
- Can you prove only the right people can touch it
- Can you actually recover from it when it counts
Build toward one framework properly, and you’re most of the way toward the others already.
Where they differ
PCI DSS is the most prescriptive. It names MFA outright and sets a hard 12-month log retention.
HIPAA currently treats encryption as a judgment call, not a fixed mandate. Proposed updates to the Security Rule may change that. Worth watching, not yet settled.
SOC 2 is the most flexible. It checks whether your controls fit your environment, not whether you match a fixed checklist.
GDPR is the most direct about recovery specifically. Article 32 doesn’t just expect you to have backups, it names the ability to restore data in a timely manner and to regularly test that ability as legal requirements. UK GDPR carries the same obligations, just enforced by the ICO instead of an EU data protection authority.
Two things worth flagging for MSPs specifically. Immutable and air-gapped backups aren’t named by any of the four, but they back the intent of all of them and are worth having regardless. And if your backup software or platform is run by an outside provider, that provider’s own controls become part of your compliance story too, not something you can wave off as their problem. Under GDPR this is explicit: Article 28 requires a written agreement with that provider, and Article 82 keeps you jointly liable if their failure causes the damage.
If you’re not sure where you stand
Every one of these frameworks is really asking whether you can recover, reliably, on your own terms, when something goes wrong. If you’re covering more than one framework across your client base, whether that’s SOC 2 and PCI DSS, or GDPR and HIPAA, we can walk through where you’re already solid and where the gaps are. Book a personalized demo with BDRShield experts.
Further reading
Compliance questions rarely stop at one framework or one country. For a look at how these same questions play out for teams navigating international requirements, see What Businesses Are Really Asking About Compliance-Ready Backups.
Follow our Twitter and Facebook feeds for new releases, updates, insightful posts and more.
