164.308(a)(7)(ii)(B) Disaster recovery plan: requirements and evidence

What the disaster recovery plan requirement asks your organization to prove

Compliance leads often find that 164.308(a)(7)(ii)(B) is easy to write and hard to prove. The requirement is to establish, and implement as needed, procedures to restore any loss of electronic protected health information. It is a required implementation specification, not an addressable one, so you cannot document a reason to skip it. It sits under the contingency plan standard in 164.308(a)(7), alongside the data backup plan and emergency mode operation plan. The current rule does not set a recovery time, so the assessor will look for a restoration process your organization has defined, can explain and can show working.

The loss scenarios are familiar: ransomware that encrypts production and backup volumes, hardware failure, a cloud region outage, a deleted or corrupted database, and lost encryption keys or credentials that make backups unreadable. Each one exposes a different weakness. Teams commonly discover during an incident that the backup catalog is itself stored on the failed server, that a restore depends on a license server, certificate authority or DNS record nobody documented, or that the restore procedure was written for a configuration that has since changed. None of these problems appear in a plan that has never been exercised.

To prove the requirement, collect evidence that connects the plan to the systems. Ask for a current inventory of ePHI systems mapped to their backup jobs, a documented restore runbook with named owners, and restore test records showing what was restored, when, by whom and how long it took. For self-hosted tooling such as Bareos, confirm that the Director's SQL catalog is backed up separately and can be rebuilt, and for restic, schedule restic check with --read-data-subset so that pack file integrity is checked rather than assumed. Confirm with your assessor which recovery time you will set internally, because the proposed rule's 72-hour figure is not yet in force. The HHS Security Rule text(7)(ii)(B)) is the natural starting point for confirming the wording your plan must satisfy.

Which systems, data, teams and third parties fall under the restore procedures

The disaster recovery plan under 164.308(a)(7)(ii)(B) reaches every place ePHI lives, every backup copy of it, and every person or vendor who can bring it back. The criticality analysis under 164.308(a)(7)(ii)(E) and the proposed 72-hour rule for critical systems decide how far down that list the restore work must go and in what order.

Systems that hold or process ePHI

Start with an inventory of every system that creates, stores, transmits or processes ePHI: the EHR, file shares, databases, email, scheduling and billing applications, and SaaS and cloud workloads. Each system needs a named owner and a restore path. Ask whether any system is missing from the inventory because a department bought it outside IT. Unlisted systems are the most common gap in restore scope.

Backup repositories and catalogs

Scope includes the backup servers, storage targets, and the catalog or index that records what was backed up and when. A restore is only possible if the catalog survives the event that destroyed the data. Confirm where catalogs are stored, whether they are backed up separately, and how long each backup set is kept. Backup software such as Bareos keeps its catalog in a SQL database that needs the same protection as the data it describes.

Criticality ranking for restore order

The applications and data criticality analysis under 164.308(a)(7)(ii)(E) sets which systems are restored first and which can wait. Under the current rule this ranking is an addressable specification, so the reasoning must be documented. The January 2025 proposed rule would require restoring critical relevant systems within 72 hours of loss, so the criticality ranking would become the basis for a hard deadline. Ask who signs off on the ranking and when it was last reviewed.

Teams that run restores

Restore work crosses infrastructure, application, database and security teams, and each needs written authority to start a restore and to declare recovery complete. Scope should name the people who hold backup administrator rights, who can approve a restore to production, and who covers nights and weekends. An illustrative check: if the only person who knows the backup console is on leave, the plan has a single point of failure.

Physical access for contingency operations

The addressable contingency operations specification in 164.310(a)(2)(i) allows facility access so that lost data can be restored under the disaster recovery plan. Scope should cover data centers, server rooms, and any site where restore hardware sits, including access for vendor engineers after hours. Confirm that badge and key procedures let authorized restore staff in during an outage, and that access is still logged.

Cloud hosts and managed backup providers

Third parties that host systems or run backups fall inside the restore scope even though the organization does not operate their hardware. Review each contract for restore commitments, the location of backup copies, notice of outages, and the business associate terms that apply to them. Ask each provider to show a recent restore test result for your data, not only a statement that backups run. Business associate duties are covered in the vendor section.

How an assessor tests the disaster recovery procedures

An assessor testing 164.308(a)(7)(ii)(B) starts with four questions: does a written disaster recovery procedure exist, does it cover the loss of any ePHI rather than only the systems the organization thinks matter most, has it actually been implemented, and is it tied to the applications and data criticality analysis and the data backup plan. The tester then looks for the links between these documents. A recovery procedure that names a system the criticality analysis ranked as low priority, or that restores from a backup source the backup plan never mentions, will draw a finding even if the document itself looks complete. Because the current rule sets no recovery time, the assessor will ask the organization to state its own recovery objectives and check that the procedure reflects them.

OCR audit and investigation staff usually ask for the same small set of items: the current disaster recovery plan with its revision history, the criticality analysis it depends on, the most recent restore test with its results and any corrective actions, and a list of the people who run recovery and their roles. Confirm with your counsel and your own audit scope which items you would produce first, and assemble them before a request arrives. The people question matters more than many teams expect. If the only person who knows how to restore the database has left, or the named recovery owner cannot describe the steps, the procedure will not be treated as implemented.

No HIPAA certification exists, and a third party's review of your recovery procedure cannot replace OCR's findings. HHS states that it does not endorse or recognize private certifications and that such reviews do not prevent it from later finding a violation. An outside assessor can test your restore process, document gaps and help you prepare evidence, which is useful work, but the conclusion of an OCR review belongs to OCR alone. Treat any external report as internal evidence of diligence, and plan your restore tests so they can be repeated and shown to a regulator at any time.

What assessors request and where disaster recovery plans fail

This table lists what an assessor typically asks for under 164.308(a)(7)(ii)(B), how each request is tested, and the findings that appear most often. Use it to check your evidence before an OCR review, a customer assessment or an independent audit, since each row shows a gap that is easy to miss until someone asks for proof.

Area	What assessors request	Common findings
Written plan	A documented disaster recovery plan with defined procedures to restore any loss of ePHI, approved by the security official and available to staff who would run it	Plan describes backup storage but not the sequence for rebuilding systems, or it sits in a document no one on call can reach during an outage
Restore test records	Dated records of restore tests showing which systems were recovered, who ran the test, the result and the corrective actions taken	Plans never tested, or tests that only confirm backup jobs succeeded without restoring usable ePHI
Scope against the asset inventory	Evidence that the plan covers every system holding ePHI, reconciled with the applications and data criticality analysis	New SaaS tools, endpoints or databases holding ePHI missing from the plan because the inventory was not updated
Linkage to backup and emergency mode plans	Cross-references showing that restore points come from the data backup plan and that critical processes continue under the emergency mode operation plan	Disaster recovery steps assume backups that the backup plan does not produce, or emergency procedures that have no restore dependency mapped
Access during restoration	Documented break-glass accounts, privileged access approval during recovery, and logs showing who accessed systems while they were rebuilt	Restore steps that depend on a departed administrator's credentials, or recovery environments that bypass normal audit logging
Revision after change	Records showing the plan was updated after tests, incidents, system changes or staff changes	Plan last revised before a platform migration, with no record of review after the change

How to build a disaster recovery plan that restores ePHI

This sequence moves from knowing where ePHI lives to proving that it can be restored. Each step produces a document or test record that an assessor can read, so the plan is both workable and evidenced.

Inventory every system that holds ePHI
Start by listing each application, database, file share, backup target, endpoint and cloud service that creates, stores, transmits or processes ePHI. Pull the list from the risk analysis and check it against asset records, network diagrams and business associate contracts, since shadow systems often hide here. Assign each asset an owner and a location. The output is the scope register, a dated document that defines what the disaster recovery plan must cover. The step is done when the system owners have signed off that nothing material is missing.
Set restore priorities from the criticality analysis
Use the applications and data criticality analysis to rank each system by its effect on patient care and operations. Record the order in which systems must return, the data each one needs, and the dependencies between them, such as identity services or DNS that must come back first. The current rule does not set a recovery time, so ask leadership and clinical owners to state tolerable downtime in their own terms and document the basis. The output is a restore priority table. The step is complete when each in-scope system has a rank and a named approver.
Document recovery procedures and dependencies
Write the restore runbook for each priority tier. Each procedure should name the backup source, the restore target, the credentials and keys needed, the order of steps, the people who act and the points where a decision is required. Map infrastructure dependencies, including cloud accounts, hypervisors, network segments and vendor support contacts, and note which of them the organization itself controls. The output is a set of runbooks stored where staff can reach them during an outage, not only on the affected network. The step is done when a person outside the team can follow a runbook from start to finish.
Implement and configure recovery tooling
Deploy the backup and monitoring tools that the runbooks depend on. Open-source options include Bareos, whose Director schedules backup, restore and verify jobs and keeps a catalog of backed-up files, and restic, whose check command can read pack files back to confirm stored data is unmodified. Monitoring with Prometheus and Grafana Alerting can surface failed backup jobs and stale copies. Confirm each tool's current capabilities and supported platforms against its documentation before you commit to a design. The output is a configuration record with job schedules, retention settings, access controls and alert rules. The step is done when backup failures trigger a notification to a named owner.
Run a restore test against the runbooks
Restore representative data from the most recent backups to an isolated environment, following the runbooks as written. Include at least one high-priority system and one that depends on another, so the test exposes sequencing gaps. Time each stage, record missing credentials or unclear steps, and verify that restored data matches expected integrity checks. This is the contingency plan testing that the addressable testing and revision specification describes. The output is a test report listing scope, participants, results, failures and the fixes assigned. The step is done when the report is signed by the security official and the system owners.
Record results and revise the plan
Feed every finding from the test back into the scope register, priority table and runbooks. Update the version history, change the dates, and confirm that the revised procedures are the ones staff were given. Track open remediation items to closure and keep the prior versions for the documentation retention period that applies under the Policies, procedures and documentation requirements. Repeat the test after significant system changes and on the schedule the organization sets. If the proposed rule is finalized with a 72-hour restoration target for critical systems, the priority table and tooling settings would need to be re-ranked against that target. The output is a revised plan, a remediation log and a dated approval record. The step closes when the next test cycle is on the calendar.

How self-hosted open-source tools produce restore evidence

An assessor testing 164.308(a)(7)(ii)(B) will ask for proof that data can actually be restored, not only that a backup policy exists. Self-hosted tools can generate that proof as a by-product of normal operations if they are configured to keep it. With Bareos, the Director schedules and supervises backup, restore, verify and archive jobs and keeps a SQL catalog of backed-up files. Exporting job logs, catalog records and the output of a test restore selected from a specific backup date and time gives the assessor a dated record of a restore performed against the plan. Confirm in your own environment that the catalog retention and job history you need are kept long enough to cover the review period your evaluation cycle requires.

restic provides a different kind of evidence. Running restic check verifies the structural consistency of snapshots, trees and pack files, and adding --read-data or --read-data-subset reads pack files back to confirm the stored backup data has not been modified. Saving the command, its date, the repository identifier and the exit output in the contingency plan's test record shows that integrity was checked, not assumed. Because a full read of large repositories can take considerable time and bandwidth, decide with the risk analysis how often a full read is needed and when a subset read is acceptable, and document that choice.

Monitoring closes the loop between backups and the plan. Prometheus collects metrics from instrumented jobs over HTTP and stores them as time series, and Grafana Alerting can build rules from those metrics and send alerts when a backup job fails or stops reporting. Retaining alert rule definitions, notification history and the response record gives evidence that failures were detected and handled. Confirm that each tool's job-failure metrics and alert delivery paths work with your backup software before relying on them. Licensing also matters for the evidence file: Bareos and Grafana are licensed under AGPL-3.0-only, restic under BSD-2-Clause and Prometheus under Apache-2.0, so have counsel review how each license affects any modifications and distribution you plan.

Evidence that passes a disaster recovery review

A disaster recovery review tests whether the plan on paper matches what the systems actually do. The cards below cover the documents, test records and system outputs that connect the written procedure to restores that have really happened, and how to keep each one current between audits.

Written disaster recovery procedure

The dated, approved procedure sets out the systems in scope, who declares a disaster, the order of restoration, the backup sources used and the people responsible for each step. It should name the criticality ranking from the applications and data criticality analysis, since that ranking drives recovery priority. Check that the procedure states what it does not yet cover and that every system holding ePHI appears in it. Review it at least once a year and after any change to the backup platform or hosting location.

Restore test records

Each restore test record should show the date, the systems tested, the data sets restored, the person who ran the test and whether the restored data matched the source. A test that restores only a single file proves less than one that rebuilds a full system. Record failures and the corrective actions taken, not only passes. Schedule restore tests on a fixed cadence so the most recent one is never far from the review date, and keep the records with the procedure they test.

Backup job logs and catalog exports

Bareos keeps a SQL catalog of backed-up files and the Director records the outcome of each backup, restore, verify and archive job. Export the catalog and job history on a schedule so an assessor can see which backups ran, when, and against which clients. Confirm that exports cover the retention period your procedure claims. Gaps in the job history for critical systems are the first thing a reviewer will question.

Verification and integrity check outputs

Integrity checks show that stored backups can still be read and are unmodified. For restic, restic check verifies the structural consistency of snapshots, trees and pack files, and the --read-data or --read-data-subset options read pack files back to confirm the stored data is intact. Keep the command output with its date and repository name. Running the deeper read-back check on a rotating subset on a schedule is a practical way to show integrity without reading every pack file each time.

Alert history for failed jobs

Alerts show that failures are noticed and acted on, not only logged. Grafana Alerting can build rules from queries across multiple data sources, so a failed backup job metric or a stale last-success timestamp can raise an alert. Keep the alert rule definitions, the notification history and the acknowledgement or resolution notes. Ask whether alerts reach a named on-call role, because an alert that goes to an unmonitored mailbox will not satisfy a reviewer.

Change log of post-test revisions

The change log links each test to the revision it caused. When a restore test exposes a missing system, a wrong recovery order or an expired credential, the procedure should be revised, dated and approved, and the change log should cite the test that prompted it. Assessors look for this loop because it shows the plan is tested and improved, not just stored. Keep the log under version control or in a document system with an audit trail so earlier versions remain available.

What meeting the disaster recovery requirement costs

This table breaks the cost of meeting the 164.308(a)(7)(ii)(B) disaster recovery plan requirement into its components, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. Use it to build a quote request, not as a price estimate, because no HHS or vendor figures for these costs are supplied. The main takeaway is that the rule's cost sits mostly in people time, storage and repeated restore testing, while self-hosted open-source tooling mainly removes license spend.

Cost component	One-time or recurring	What drives it up or down
Backup and recovery tooling	One-time setup, recurring operation	Self-hosted Bareos or restic removes per-seat license fees, but the organization still pays for hosting, configuration and patching. Ask whether the quote includes vendor support.
Engineering time for disaster recovery runbooks	One-time build, periodic revision	Number of critical systems and their dependencies. Fewer systems in the applications and data criticality analysis means shorter runbooks.
Restore testing effort	Recurring	Test frequency set by the risk analysis, number of systems tested and whether restores are scripted. Ask how many restore tests the quote covers.
Storage for backup copies	Recurring, grows with data	Volume of ePHI, retention periods, number of copies and offsite replication. Ask for storage sizing assumptions and retention settings in writing.
Monitoring and alerting for backup jobs	One-time setup, recurring operation	Self-hosted Prometheus and Grafana remove license spend, but alert tuning and on-call staffing remain. Confirm who receives and acts on alerts.
Evidence upkeep	Recurring	Frequency of documented test results, change records and retention of restore logs. Ask what artifacts the quote delivers and in what format.
External testing or review	Periodic, optional	Whether an independent party reviews the plan or observes a restore. The organization owns the plan; a reviewer offers an opinion, not a certification.
Assessor sampling during audit	Periodic, set by the assessor	Scope of the assessment and which restore records the assessor selects. Keep restore evidence organized by system so sampling does not require rework.

Who owns the restore procedures, who helps, and what the auditor checks

Your organization owns the disaster recovery plan. The Security Rule places the obligation on the covered entity or business associate, so the people who decide what is restored, in what order and to what standard must work for you. The security official and the teams that run the ePHI systems should agree on the recovery priorities from the applications and data criticality analysis, then approve the written procedures and the restore test results.

Plan ownership: Named staff write or approve the procedures, record decisions and keep the plan current after system changes.
Restore test execution: Your operators run restores of ePHI from backups, record what was restored, how long it took and what failed.
Sign-off: An accountable leader reviews results, accepts or rejects residual gaps and assigns remediation owners.
Vendor oversight: You keep the contracts, access and escalation paths for any cloud or hosting provider that holds copies of ePHI.

Before engaging anyone else, confirm that your own staff can explain each restore step without the consultant in the room.

Common gaps in disaster recovery plans and how to close them

Most disaster recovery plans under 164.308(a)(7)(ii)(B) exist on paper but fail when systems are actually lost. The gaps below cluster around untested restores, unclear priorities and single points of dependence, and each one has a closing action an assessor can verify.

Plans that never describe a restore

Many plans list backup schedules and contacts but never state the steps to bring an ePHI system back to a usable state. The required specification asks for procedures to restore any loss of data, so a plan that stops at copying data does not show how restoration happens. Check that each critical system has a written restore runbook with the tool, the source of the copy, the order of steps and the person who signs off that the data is complete and usable.

Backups never test-restored

A backup job reporting success does not prove the data can be read back. Plans often assume backups work because the job log is green. Schedule restore tests from the backup catalog to an isolated environment, record what was restored, how long it took and which data failed to come back, and feed those results into the plan.

No criticality analysis behind priorities

When the plan does not rank applications and data by criticality, restore order becomes a guess made during the incident. The applications and data criticality analysis is an addressable specification, but it drives what the contingency plan restores first. Document each system's clinical and operational impact, its data owner and the order in which it must return, and reconcile that list with the risk analysis.

No recovery path for SaaS data

Plans written around on-premises servers often ignore EHR add-ons, email, collaboration tools and other cloud services that hold ePHI. The provider may restore the platform without restoring a customer's deleted records or configuration. Confirm in each vendor agreement what the provider backs up, how long it keeps copies, how customers request restores and whether an export to your own storage is possible, then document a fallback for each service.

Restores that depend on one person

If one administrator holds the backup credentials, encryption keys and restore knowledge, a single absence can stop recovery. Name at least two trained people per critical restore, store credentials and key material in a controlled location with documented access, and rehearse the restore with a different person from the one who wrote the runbook.

Disaster recovery detached from emergency mode

The disaster recovery plan restores systems after an emergency, while the emergency mode operation plan keeps critical processes running during it. When the two are written separately, teams may restore a system before clinicians know whether it is safe to use or before ePHI protections are reapplied. Cross-reference both plans, define the handoff point from emergency mode to restoration and confirm that the same people own both documents.

Questions buyers ask about the disaster recovery plan requirement

What does the disaster recovery plan requirement in 164.308(a)(7)(ii)(B) actually require?

It requires a covered entity or business associate to establish, and implement as needed, written procedures to restore any loss of data that affects electronic protected health information. It is a required implementation specification, so it applies to every organization covered by the Security Rule, not only to those that choose it. The rule does not prescribe a particular product, architecture or document layout. What an assessor looks for is a plan that names the systems holding ePHI, states how data would be recovered after an emergency, assigns owners, and shows that the procedures were actually exercised. Pair the plan with the data backup plan in 164.308(a)(7)(ii)(A) and the criticality analysis in 164.308(a)(7)(ii)(E), since those two sets of records decide what is restored first.

Does HIPAA require a specific recovery time today?

No. The current Security Rule sets no recovery time objective, so the organization decides what is reasonable and appropriate based on its risk analysis and its own operational needs. That flexibility is also why assessors ask hard questions: they expect the recovery target to follow from the criticality analysis and the risk analysis, and they expect the organization to be able to explain how it chose that target. Document the target, the reasoning behind it, and the evidence that the environment can meet it. Do not treat any figure found in a vendor brochure or a third-party guide as a HIPAA requirement unless it appears in the rule itself or in a finalized regulation.

How often should restores be tested under the contingency plan?

The rule does not set a test interval. The related addressable specification in 164.308(a)(7)(ii)(D) calls for periodic testing and revision of contingency plans, so the frequency should follow your risk analysis, the rate at which systems and data change, and any material change to the environment. In practice, many organizations run restore tests of representative systems on a schedule and perform tabletop exercises for disaster scenarios, then feed the results back into the plan. Keep dated records of what was restored, how long it took, what failed, and what was corrected. Ask any consultant or partner to show you that a restore was tested, not only that a backup job reported success.

What would the January 2025 proposed rule change for disaster recovery?

HHS proposed on January 6, 2025 (90 FR 898) that covered entities and business associates restore critical relevant electronic information systems and data within 72 hours of loss, and restore other systems according to the criticality analysis. The proposal is not law. Comments closed on March 7, 2025, and as of October 2026 no final rule has been published. The latest Unified Agenda lists the rulemaking under Long-Term Actions with final action projected for July 2027. Plan against the current rule, but design your recovery architecture so that a 72-hour target for critical systems would be achievable if the rule is finalized in that form. Confirm the status on the Federal Register and reginfo.gov before making commitments to a customer or regulator.

Can our own team write the disaster recovery plan without outside help?

Yes, in most organizations the plan is written by the people who run the systems, and HIPAA does not require an outside firm. The security official, system owners and the team that operates backups should own it, because the organization owns its controls. Outside help is useful when the team lacks time, when the environment is complex, or when an independent reviewer should challenge the plan before an assessment. An implementation partner can prepare the systems, backup and restore tooling and evidence, and draft documentation for your review. Only an independent assessor can report on compliance, and no third party can certify HIPAA compliance, so the plan must reflect your actual environment and your decisions.

What drives the cost and effort of a disaster recovery program?

The main cost drivers are the number and size of systems holding ePHI, how much data must be retained and restored, how quickly the business needs each system back, and whether recovery runs on your own infrastructure or in a cloud account. One-time costs include the criticality analysis, plan drafting, backup design, configuration and first restore tests. Recurring costs include storage, backup monitoring, periodic restore testing, plan revision after changes, and staff time. A fixed-scope quote should list the systems in scope, the backup and restore tools, the number of test exercises, the documentation delivered, and what your staff must provide. Ask for each item to be priced or estimated separately so you can see which decisions move the total.

What does an implementation partner need from us before starting?

A partner needs accurate inputs before it can build or test anything. Provide the current risk analysis and the list of systems and data stores that hold ePHI, the existing backup and retention settings, the criticality ranking of applications and data, and the business owners who can set recovery priorities. Give the partner access to the environment through an agreed change process, along with a maintenance window for restore tests. Confirm who approves the recovery targets and who signs off on the final plan. The partner will prepare systems, tooling and evidence, but your organization remains responsible for the decisions and for the controls themselves.

Which open-source tools can produce evidence for backup and restore?

Several open-source tools can support this requirement, but none of them makes an environment compliant on its own. Bareos schedules backup, restore, verify and archive jobs, keeps a SQL catalog of backed-up files, and can restore files from the current backup or one taken before a given date and time, which gives you job logs and restore records. restic's check command verifies the structural consistency of snapshots, trees and pack files, and with the read-data option it reads pack files back to confirm stored data is unmodified, which is useful integrity evidence. Prometheus collects metrics and Grafana Alerting can notify staff when backup jobs fail or stale. Confirm each tool's licensing terms and capabilities against its current documentation before relying on it in your environment.

How DeployOpen prepares restore procedures and evidence

DeployOpen plans, implements and documents self-hosted open-source backup and monitoring inside your own infrastructure, so the restore procedures required by 164.308(a)(7)(ii)(B) run on systems you control. In practice this means configuring a backup director such as Bareos, which schedules backup, restore and verify jobs and keeps a SQL catalog of what was backed up, and a repository tool such as restic, whose check command can read pack files back to confirm stored data is unmodified. Monitoring of backup job outcomes can be built with Grafana Alerting and Prometheus. DeployOpen prepares these systems, the written restore procedures and the records they produce. It does not issue audit reports, attestations or certifications. Independent assessors and certification bodies do that work, and HHS does not recognize private certifications for the Security Rule.

Before work starts, the scope is agreed in writing. A typical written scope should name the ePHI systems covered, the recovery priorities taken from your applications and data criticality analysis, the retention settings, the restore targets you will test, who in your organization owns each decision, and the deliverables, such as configuration baselines, runbooks and sample restore records. Ask any implementation partner to state which parts of the plan remain your responsibility, including the decisions on recovery targets, since the current rule sets no recovery time and the 2025 proposal is not final. Confirm the timeline and acceptance criteria in the same document, not in later correspondence.

Restore testing does not end at handover. Because the evidence an assessor reviews is a record of tests run over time, many organizations keep a retainer for recurring restore tests, monitoring tuning and procedure updates after changes to systems or staff. Ask what a retainer covers, how test results are recorded and who reviews them, and whether the partner will support your security official in the periodic evaluation required by 164.308(a)(8). Retainers and scope changes are priced from written statements of work, so define the restore test frequency and the systems in scope before signing.

164.308(a)(7)(ii)(B) Disaster recovery plan