Data backup

Backup differs from replication and archive

Replication keeps another system copy current, which can spread deletion or corruption. An archive retains records for a defined purpose and period. A backup supports recovery to a usable earlier state. One design may serve several purposes, but each purpose needs its own rules and evidence.

List clinical records, attachments, schedules, authorizations, claims, payments, payroll, identity, configuration, audit logs, integration queues, and infrastructure needed for restoration. Include vendor-held and local data.

Set recovery points from business and safety needs

The recovery point objective describes the tolerated data-loss point before disruption. Backup frequency should support that target for the actual system. A nightly copy may leave nearly a day of work to reconstruct.

Document source, method, frequency, successful-copy evidence, retention, location, encryption, key custody, immutability or offline separation, dependencies, and owner. Map which records can be recreated and which carry clinical, legal, or financial consequences if lost.

HIPAA has a specific contingency requirement

For covered entities and business associates, current 45 CFR 164.308(a)(7) includes required data-backup, disaster-recovery, and emergency-mode-operation specifications. It calls for procedures to create and maintain retrievable exact copies of ePHI. Testing and revision procedures and applications-and-data criticality analysis are addressable specifications.

This federal requirement applies to ePHI within regulated scope. Other records and entities may have different legal, contractual, professional, and operational duties.

Protect backups from the primary failure

CISA’s ransomware guide recommends offline, encrypted backups and regular tests of availability and integrity in a disaster-recovery scenario. Separation matters because attackers and erroneous credentials can reach connected backup systems.

Limit administrative access, require strong authentication, log changes, protect keys separately, and alert on deletion or retention-policy changes. NIST SP 1800-25 describes practices for identifying and protecting assets against ransomware and other destructive events, including secure storage, integrity checking, and audit logs.

A fictional restore test

Omar locks a cohort of 100 records: 40 clinical notes, 20 attachments, 20 authorization records, and 20 scheduling records. The restore process returns 96 records with matching identifiers, content, timestamps, and access rules: 96 of 100, or 96%.

Four older attachments are missing. A dashboard still reports the backup job as successful, so job completion and restore acceptance clearly differ. The four failures remain in the denominator with owners, root-cause work, and a retest date.

The practice also measures recovery duration from approved start to acceptance, reconciled records divided by expected records, and corrective actions closed by due date. One successful sample does not prove every record, point in time, or disaster path will work.

Test restoration, dependencies, and return to service

A restore test should define the selected recovery point, clean environment, records expected, permissions, applications, interfaces, and acceptance criteria. Verify content, relationships, audit history, identity, access, and downstream reconciliation. Scan for corruption or reinfection before reconnecting systems.

Technical restoration is one milestone. Qualified operations, security, privacy, and clinical roles decide whether their release conditions are met. Account for work created during downtime before normal integrations and billing resume.

Vendors do not remove owner responsibility

Ask who performs backups, where copies reside, how restores are requested, which time commitments apply, how testing works, and how data is returned or deleted. HHS cloud guidance explains that a cloud provider maintaining ePHI on behalf of a covered entity or business associate can itself be a business associate, even without the decryption key.

The NIST Cybersecurity Framework 2.0 is voluntary general guidance for managing cybersecurity risk. A framework alignment, BAA, or encrypted copy does not substitute for a proven recovery path.

Maintain a backup evidence register

For each protected system, keep the data owner, technical owner, records covered, backup method, schedule, recovery point, retention, storage separation, encryption and key arrangement, last successful job, last accepted restore, and next test. Link vendor reports to the exact service and tenant rather than storing an undated screenshot.

Review the register after new applications, integrations, record types, locations, vendors, and retention rules. A green job indicator can hide an excluded attachment bucket, failed database relationship, or inaccessible encryption key. Compare expected scope with restored evidence.

Give restore exceptions a severity and business owner. Missing safety information or current clinical records can require a service hold, while a delayed historical report may have another response. Qualified roles decide the operational and clinical consequences.

Retirement also needs backup decisions. Document how long old copies remain, which holds apply, who can retrieve them, and when keys and media are destroyed. Vendor deletion of a live tenant may leave scheduled backup copies under a separate cycle, so request the applicable timeline and evidence.