Contingency Planning Procedures

2. Backup schedule & restore-test SOP (164.308(a)(7)(ii)(A), 164.308(a)(7)(ii)(D))

Backups

1. Configure backups for every Critical asset at a frequency no less than its RPO (at least daily for production ePHI systems); enable built-in snapshots/point-in-time recovery/versioning for [cloud infrastructure provider] and [cloud productivity & storage suite] services.
2. Ensure backups are encrypted in transit and at rest, access-restricted, and that at least one copy resides in a separate region/location.
3. Monitor backup jobs; on failure, the [Security Official] (or delegate) investigates and remediates within [1 business day] and records the outcome.
4. Retain backups per the Data Retention & Disposal Policy; retain backup/restore-test records for 6 years.

Restore test (run at least [quarterly] for Critical systems, and after any major backup change)

1. Select a Critical asset and a recovery point; record the asset, backup date, and tester.
2. Restore to an isolated/non-production target.
3. Validate integrity and completeness (row counts / checksums / spot-checks of representative records) and confirm the restore completed within the asset's RTO.
4. Record result (pass/fail), actual restore time vs. RTO, any data gap vs. RPO, and issues found.
5. Open corrective actions for any failure or missed objective, with an owner and due date; re-test after remediation.

3. Disaster recovery runbook (164.308(a)(7)(ii)(B), 164.308(a)(7)(ii)(C))

Phase A: Notification & activation

1. The first responder notifies the [Security Official] with all known details (what failed, when, suspected cause, systems affected).
2. The [Security Official] assesses impact and decides whether to activate the plan. Activate when, for example, Critical systems or ePHI access are unavailable beyond [24 hours], or sooner if the impact clearly warrants it. If the [Security Official] is unavailable, the documented line of succession assumes this authority.
3. On activation, declare emergency mode (§4), stand up the recovery and assessment teams, and notify affected customers/partners and workforce via the communication plan. If the event involves suspected compromise of ePHI, also trigger the Security Incident Response Policy.

Phase B: Recovery (restore in the priority order from the criticality register, §1)

1. Recovery team restores Critical systems first, from backups (§2) or by failing over to alternate regions/resources with the [cloud infrastructure provider].
2. Re-establish required safeguards on any temporary/replacement platform: authentication, access control, audit logging, and encryption of ePHI.
3. Assessment team validates functionality, data integrity, logging, and security for each restored system before it returns to service; update DNS/endpoints as needed.
4. Track progress against RPO/RTO and communicate status updates to affected parties on a defined cadence.

Phase C: Reconstitution

1. Transition operations back to primary (or permanent replacement) systems and re-validate.
2. Securely decommission temporary resources per the Data Retention & Disposal Policy.
3. Within [5 business days] of recovery, hold a root-cause/lessons-learned review and feed improvements into the plans and the Risk Analysis & Risk Management Policy.

4. Emergency mode operation (164.308(a)(7)(ii)(C))

1. Only an authorized declarer (the [Security Official], [Privacy Officer], or designated leadership member) may declare emergency mode; record who declared it and when.
2. While in emergency mode, run only the critical functions identified in §1; preserve authentication, access control, audit logging, and ePHI encryption on whatever systems are in use.
3. Use the fallback communication channels (e.g., [phone], [SMS], [internal messaging tool], videoconference, or in-person) when primary channels are down; notify workforce, patients/clients, and critical vendors of the disruption and provide periodic updates.
4. For any elevated/emergency access required, follow the break-glass procedure in the Access Control Procedures (pre-authorized roles, logged, reviewed and credentials rotated afterward).
5. The [Security Official] formally stands down emergency mode once normal operations resume and records the time.

5. Plan testing & revision SOP (164.308(a)(7)(ii)(D))

1. Schedule at least one contingency exercise annually, alternating or combining tabletop and technical (restore) tests; the §2 restore tests count as technical tests.
2. For each test, produce a written report containing: test date and type; participants; scenario and scope of systems tested; steps executed with pass/fail outcomes; any failures to meet RPO/RTO; corrective actions with owner and target date.
3. The report is reviewed and signed off by the [Security Official] (and [Privacy Officer] where ePHI is involved) within [15 business days] of the test.
4. Incorporate lessons learned into the relevant plan(s) within [30 days]; bump the plan version and note the change in its change log.
5. Verify the criticality register (§1) and emergency contact list remain accurate as part of each exercise.

Records produced (evidence)

Applications/data criticality register · backup configuration & job-monitoring records · restore-test logs (date, asset, result, time vs. RTO, gap vs. RPO) · disaster-recovery activation and after-action reports · emergency-mode declarations and communication logs · contingency-test reports with sign-off and corrective actions · plan change logs. These are the artifacts an auditor will request to confirm the controls operate.

HIPAA controls addressed

Review & version

Reviewed at least annually by the [Security Official]. v1.0.