Free HIPAA policy template · v1.0 · Applies to covered entities & business associates · Companion: Procedures →
Adopting this document means committing to these HIPAA controls, the 45 CFR §164 requirements it helps satisfy, by area:
Common threats (NIST SP 800-30 classes) that the controls behind this document defend against:
Exploits: Unpatched systems; no tested backups · 164.308(a)(7) Contingency; 164.308(a)(5)(ii)(B) Malware
Exploits: No line of succession; key-person risk · 164.308(a)(7) Contingency Plan
Exploits: No tested backups; single copy · 164.308(a)(7)(ii)(A) Backup
Template. Replace every
[bracketed]item with your organization's specifics. A name in[Title Case]is your organization, a role, or a person; a phrase in[lower case]is a category of tool. Substitute the actual product you use (e.g.,[cloud infrastructure provider]→ your chosen platform). Have this reviewed by counsel or your compliance advisor before adoption.
This Policy establishes how [Organization] prepares for, responds to, and recovers from emergencies and other events (fire, system failure, cyberattack, vendor outage, natural disaster) that could damage systems containing electronic protected health information (ePHI) or interrupt critical operations. It ensures that ePHI can be backed up and restored, that critical systems and business functions can continue or be re-established within defined time and data-loss tolerances, and that the plans are tested and kept current. It satisfies the contingency-planning requirements of the HIPAA Security Rule at 45 CFR § 164.308(a)(7).
This Policy applies to all workforce members (employees, contractors, interns, and volunteers), business associates, and any other party with a role in maintaining or recovering operations, and to all system components (applications, endpoints, cloud services, and infrastructure) that create, receive, maintain, or transmit ePHI, together with the data backups that protect them. The plans required by this Policy cover both internal disruptions (affecting only 's own ability to operate) and external disruptions (affecting critical systems, vendors, or third parties).
See where your organization stands on the controls this template cites.
Join Us[Organization][Organization] maintains a documented Contingency Plan (a coordinated set of a Data Backup Plan, a Disaster Recovery Plan, and an Emergency Mode Operation Plan) for responding to events that damage or disrupt systems containing ePHI. The Plan identifies essential business functions and the system assets that support them, assigns contingency roles and responsibilities to named individuals with current contact information, defines recovery objectives and restoration priorities, and is coordinated with the Security Incident Response Policy. The [Security Official] owns the Plan, which is reviewed and approved by leadership, kept available to plan participants in more than one location (including at least one copy reachable when primary systems are down), and protected from unauthorized disclosure or modification.
[Organization] assesses the relative criticality of its applications and data components so that contingency effort is focused where it matters most. Each in-scope application and data store is classified (for example, Critical: required for core operations and ePHI access, restored first; versus Non-critical: supports operations but its loss does not halt critical functions, restored afterward) and assigned a recovery priority, a Recovery Point Objective (RPO) (maximum tolerable data loss), and a Recovery Time Objective (RTO) (target time to restore). The analysis is recorded in a criticality register (see the companion Contingency Planning Procedures), drives backup frequency and restoration sequence, and is reviewed at least annually and on significant changes to the environment.
[Organization] creates and maintains retrievable exact copies of ePHI so that data remains available after a loss. At minimum:
[cloud infrastructure provider] or a [cloud productivity & storage suite], built-in mechanisms (automated snapshots, point-in-time recovery, object versioning) are enabled and treated as backups; source code and analysis tooling that handle ePHI are kept under version control;[Security Official] is responsible for backup configuration, monitoring, and management, and backup success/failure is monitored so failures are detected and corrected.Backups are verified by restore testing under §6; an untested backup is not considered reliable.
[Organization] maintains a Disaster Recovery Plan to restore any loss of data and re-establish systems following a disaster, executed through three phases: notification/activation, recovery, and reconstitution. Critical system components are designed for resilience (for example, replicated across multiple availability zones or regions) so that critical operations can resume after loss of a facility, region, or service. Recovery restores systems in the priority order set by the criticality analysis (§2), validates functionality, logging, and security before return to service, and aims to meet the documented RPO/RTO targets. The step-by-step runbook lives in the companion Contingency Planning Procedures.
[Organization] maintains an Emergency Mode Operation Plan to enable continuation of critical business processes and protection of ePHI security while operating in emergency mode (i.e., while primary systems are unavailable). The Plan:
[Security Official], [Privacy Officer], or designated leadership member, with a defined line of succession if the primary is unavailable;[Organization] tests its contingency plans at least annually and revises them based on the results and on significant changes to the environment. Testing includes tabletop exercises (walkthrough of the plan against a simulated disruption) and technical tests (restore from backup, validation of system access and integrity), and validates that RPO/RTO targets are achievable. Each test produces a written report; identified gaps become corrective actions with assigned owners and due dates; and lessons learned are incorporated into the plans within a defined window. Cadence, report contents, and revision timeframes are specified in the companion Contingency Planning Procedures.
The Contingency Plan and its component plans are reviewed and updated at least annually and after any significant change (new critical system, major architecture change, organizational change, or a real activation). Current copies are kept accessible in more than one location, including a form reachable when primary systems are down, and an emergency contact list with at least two contact methods for key personnel and critical vendors is maintained and reviewed at least annually. Ongoing contingency efforts incorporate lessons learned from prior tests, training, and actual events.
[Security Official]: owns this Policy and the Contingency Plan; owns backup configuration and monitoring; declares emergency mode/activation; ensures testing occurs and revisions are made.[Privacy Officer]: supports activation decisions affecting ePHI and patient/client communications.Contingency Planning Procedures · Security Incident Response Policy · Access Control Policy · Data Retention & Disposal Policy · Risk Analysis & Risk Management Policy.
| Citation | Requirement | Addressed in |
|---|---|---|
| 164.308(a)(7)(i) | Contingency Plan | §1, §7 |
| 164.308(a)(7)(ii)(E) | Applications and Data Criticality Analysis | §2 |
| 164.308(a)(7)(ii)(A) | Data Backup Plan | §3 |
| 164.308(a)(7)(ii)(B) | Disaster Recovery Plan | §4 |
| 164.308(a)(7)(ii)(C) | Emergency Mode Operation Plan | §5 |
| 164.308(a)(7)(ii)(D) | Testing and Revision Procedures | §6 |
Reviewed at least annually by the [Security Official] and after any significant change to the ePHI environment. v1.0.