Disaster recovery and compliance: what HIPAA, PCI-DSS, SOC 2, and GDPR want to see

If your business must comply with HIPAA, PCI-DSS, SOC 2, or GDPR regulations then, disaster recovery is already one of your obligations. This obligation is not always obvious since none of the four frameworks has a section with that name on it. HIPAA puts it in a contingency planning standard, PCI-DSS in a requirement about testing your incident response, SOC 2 in a criterion about availability, and GDPR in an article about restoring access to personal data.

Which of the four you’re under changes what you actually have to do. PCI-DSS gives you a hard deadline of once every 12 months, SOC 2 wants tests spread across a period you agree with your auditor in advance, HIPAA sets no frequency at all, and GDPR gives no number and expects you to set one and then defend it.

What satisfies one of them can leave you short on another, and the evidence each wants back is different too. Below is what each asks of your recovery plan, and what you hand over when somebody asks to see it.

HIPAA: if you handle patient records

HIPAA applies if you handle patient records, and it treats backup and recovery as two separate obligations. Its contingency plan standard has five parts (45 CFR 164.308). Three are required:

• A data backup plan
• A disaster recovery plan
• An emergency mode operation plan, which keeps critical processes running while you recover

The two remaining obligations are addressable, meaning you either implement them or document why the alternative you chose is reasonable for your business:

• Testing and revision procedures
• An analysis of which applications and data are most critical

Do the systems criticality analysis first. Rank your systems by which ones stop patient care and which ones can wait a day. This gives you the order you’ll follow to get them back online. Your contingency plan is written around that order. Keep the ranked list with the plan and hand over both, since the list is what shows you decided the order before anything happened.

PCI-DSS: if you take card payments

PCI-DSS applies if you take card payments, and it puts a clock on your testing (PCI DSS v4.0.1).

• Requirement 12.10.2. Your incident response plan has to be reviewed and tested at least once every 12 months. A tabletop exercise satisfies it, meaning a run-through in a room instead of an actual restore, as long as you keep the attendance list, the scenario you ran, and what you recorded afterwards
• Requirement 9.4.1.1. Offline media backups holding cardholder data have to be stored in a secure location.
• Requirement 9.4.1.2. The security of that location has to be reviewed at least once every 12 months.

During an audit, you supply the dated result of that test and the record of the location review.  This documentation as well as your media backups should be stored on a system separate from the live systems it covers. Ransomware follows the credentials and network paths it finds, so a backup sitting on the same network behind the same logins gets encrypted alongside the systems it was there to protect.

SOC 2: if you handle data on behalf of your customers

SOC 2 applies if you handle data on behalf of your customers. It requires that you prove you have internal security controls that operate effectively over a sustained period of time, usually 3 to 12 months.

• The reporting period. A Type 2 report covers a window you agree with your auditor in advance and says whether your security controls operated effectively across the entire window of time. The report requires a detailed write up of your company’s infrastructure, software, data, security and disaster recovery procedures. It must provide the evidence of direct testing via access logs that your onboarding steps, backup/recovery and firewalls are all working as intended.  It includes a formal statement, where senior leadership confirms the system’s controls are accurately presented and effective.
• Criterion A1.3. The AICPA Trust Services Criteria asks you to test your recovery procedures. You will not pass the audit if you have the written plan, but don’t have a copy of your recovery test. 
• The record. Each test needs a dated record, and those records have to fall across the window instead of clustering at the end of it.

It’s also the report your customers ask for by name, because their auditor will treat your SOC 2 as the evidence covering the part of their operation you run. A gap in your report becomes a gap in theirs.

Testing against an isolated copy of your environment is how businesses keep to that schedule without disrupting anyone. An isolated test boots your systems somewhere separate, confirms they come up and the data is usable, and leaves the systems your customers are on untouched. You hand over the dated record from each test across the window.

GDPR: if you hold data on people in the EU

GDPR applies if you hold data on people in the EU, and it sets three obligations that touch recovery.

• Article 32(1)(c). You need the ability to restore availability and access to personal data in a timely manner after an incident (Article 32).
• Article 32(1)(d). You need a process for regularly testing, assessing, and evaluating whether your measures work.
• Article 33(1). You have 72 hours from becoming aware of a breach to notify a supervisory authority, and a notification made later has to carry the reasons for the delay (Article 33).

Timely manner is left to you, so you set the number and then have to defend it. Decide an acceptable recovery window for each system holding personal data, write it down with the reasoning behind it, and use your tests to show you meet it. The 72-hour clock starts when you become aware of a breach and not when you finish recovering, so your plan needs to name which systems hold personal data before you’re working that out mid-incident. You hand over your written recovery windows and the test results against them.

What all four have in common

All four want the same three things underneath their own wording:

• A recovery plan that exists as a document
• A dated record showing somebody tested it
• Clarity on which parts of recovery are yours and which belong to whoever hosts your systems

The document itself is covered in what your recovery plan has to contain. For the ownership split, ask your host for their half in writing. They typically own the storage, the replication, and the facility.  You are typically responsible for an incident, setting your recovery order, and keeping the documentation current. Every regulatory framework requires that the division of responsibilities between you and any service provider you engage is written down somewhere.

Requirements for your hosting provider

If you host your servers with a third party provider, you will need to include them in your backup and disaster recovery plan.  How much you do and how much they do will be determined during your purchase of services. Auditors will require that this division of labor is not only documented, but potentially tested during a recovery simulation.