16 Business Continuity & Disaster Recovery: evidence

What HITRUST business continuity and disaster recovery asks for in practice

If you are the compliance lead or platform owner responsible for in-scope systems, the first thing to understand is that assessors do not stop at confirming that backups run. Domain 16, Business Continuity & Disaster Recovery, covers continuity planning, backups, restore testing and the resilience of the systems in scope, and the question an assessor asks is whether you can recover those systems and their data after a failure. A nightly job that reports success tells them little. They will want to see a restore that was performed, the date it was performed, what was recovered and whether the result matched what the business expected. The risk the domain addresses is a prolonged outage or unrecoverable data after an incident, a failed component or a cloud region problem, and that risk is the reason the requirements exist.

The domain is hard to run because no single team owns it. Business owners must define how long each service can be unavailable and how much data loss is tolerable. Platform teams build the backup jobs, replication and runbooks. Cloud or hosting providers supply redundant regional services, and HITRUST's own inheritance example treats this domain as only moderately inheritable: the provider offers the infrastructure, while the customer designs cross-region resilience, takes backups and tests restores. Before you scope an assessment, confirm in writing which of these responsibilities sit with your organization, which sit with each provider, and who signs off on recovery objectives. Gaps between those groups are where evidence goes missing.

The stakes are visible in the assurance data. The HITRUST 2025 Trust Report lists Business Continuity & Disaster Recovery as 4.9% of failing domains in 2024, and it ranks a continuity planning requirement ninth among the most frequent corrective action plans. Those figures are a reason to check your evidence early, not a prediction for your own assessment. Ask whether your continuity plan names the systems in scope and their recovery objectives, whether restores are tested on a schedule, and whether each test leaves a record that a third party can read. The HITRUST Assessment Handbook describes how assessors sample and validate this kind of evidence, so read it alongside your own test records.

Which systems, teams and providers fall inside domain 16 scope

Domain 16 scope is set by which applications, data stores, backups and providers the continuity and recovery work must cover. Each decision below changes how much evidence an assessor will ask for, so settle them in writing before readiness work starts.

In-scope applications and data stores

Every application in the assessed environment needs a recovery position, and each one stores data that must be restorable. List each application with its databases, object stores, queues and file shares, because an application left off the list is usually the one that fails a restore test. Ask the business owner which systems support regulated data and confirm that the scope statement matches the system inventory used for other domains.

Backup repositories and their locations

Backup repositories are in scope even when they are not production systems, and their location decides who owns which controls. A repository in the same region as production shares the same failure domain, while a copy held in another region or account protects against a wider event. Document where each copy sits, who can delete it, and whether it is encrypted, since an assessor will test the copy you name.

Recovery time and recovery point decisions

Recovery time and recovery point objectives are business decisions, so the business owner should approve them rather than the platform team choosing them alone. These values decide how often backups run, how many copies are kept and how quickly restores must complete during testing. Record the approval, the date and the owner so that a restore test can be measured against a documented target.

Cloud regions and redundant provider services

When a cloud provider offers redundant regional services, HITRUST treats part of the resilience as inherited, but the customer still designs cross-region recovery, takes backups and tests restores. Confirm which redundancy the provider documents, which parts you configure yourself, and where the provider's responsibility ends. Your shared responsibility matrix should reflect that split, and it should match what the provider's own report says.

Third parties that host or restore data

A backup vendor, managed database operator or disaster recovery site that stores or restores in-scope data becomes part of the continuity picture. Their contracts should state restore responsibilities, notice periods and test participation, and their evidence should be reviewed alongside your own. Domain 14 covers the oversight itself, so here confirm which providers hold recoverable copies and how quickly each can supply restore evidence.

AI systems in scope

HITRUST's AI security certification places AI security requirement statements in this domain, so an AI system in scope adds continuity work. Model artifacts, training data snapshots, vector stores and agent memory may all need backup and restore procedures. Ask whether any AI component must be recoverable within the same objectives as the applications it supports, because that answer determines whether those assets appear in your restore tests.

How an assessor tests backups, continuity plans and restores

This table compares what an assessor does, what evidence they ask for and where organizations usually fall short for each continuity and recovery area in scope. Read each row as a test the organization should be able to pass with records it already holds. Only an Authorized HITRUST External Assessor performs the validated assessment, and sampling happens within a fieldwork window of at most 90 days, so records must exist before that window opens.

Area	Test approach	Evidence requested	Common findings
Continuity plan and approval	Confirm a written plan covers the in-scope systems and that an accountable owner approved it, then check the approval date against the plan's review cycle.	Approved plan, version history, approval record, and the list of systems the plan covers.	Plan exists but was never tested, or it describes systems that have since been retired or added.
Business impact and recovery objectives	Trace each in-scope system to a documented impact rating and recovery time and data loss targets, then confirm the targets drove the backup and failover design.	Business impact analysis, recovery objective register, and the sign-off that links them to the plan.	Objectives were set for the application but not for the supporting databases, identity services or third-party components it depends on.
Backup configuration and coverage	Compare the backup job list against the in-scope asset inventory and sample configurations for frequency, retention, encryption and off-site copies.	Backup policy, job schedules, asset-to-job mapping, retention settings and encryption configuration.	Backups exist for most servers, but newer workloads, containers or SaaS data sources are missing from the job list.
Restore testing with recorded results	Select sampled restore events and confirm the test scope, who ran it, what was restored, whether the data was usable and what failed.	Restore test records with dates, scope, outcomes, timings and follow-up actions for each failure.	Backups show as successful, but no restore has ever been tested, or test records do not show what was actually recovered.
Failover and redundancy design	Review the architecture for single points of failure and confirm the failover path has been exercised at least once against the stated objectives.	Architecture diagrams, failover runbooks, and records of failover or switchover exercises.	Redundancy is documented at the provider level, but cross-region resilience and dependent components were never designed or tested by the customer.
Job failures, logs and alerts	Review job logs and monitoring for a sampled period, check that failed backups generated alerts, and confirm someone reviewed and resolved each failure.	Job logs, alert rules and notifications, ticket records for failed jobs, and evidence of periodic review.	Failed jobs appear in logs but no alert fired, or failures were recorded without a documented fix or follow-up.
Ownership and periodic review	Confirm named owners for backups, recovery and continuity, and check that the plan and objectives were reviewed after major changes.	Role assignments, review minutes or sign-offs, and change records that triggered plan updates.	Responsibilities sit with a team that has changed, and reviews did not follow significant infrastructure changes.

Implementing continuity and restore controls in sequence

This sequence moves from knowing which systems are in scope to proving that data can be restored and that failures are noticed. Each step leaves a record that an independent assessor can sample during fieldwork.

Confirm the in-scope system inventory
Start by listing every system, data store and service that the assessed environment depends on for business operations, including cloud resources, databases, identity services and third-party platforms. The organization owns this list, and the security or platform lead confirms it against the scope statement used for the HITRUST assessment. The step is complete when the inventory is approved and each entry names an owner. The assessor will look for a dated inventory that matches the scope boundary and reconciles to the asset register.
Set recovery objectives with business owners
For each inventoried system, business owners state how much data loss and how much downtime the business can tolerate, and these values become the recovery targets the technical design must meet. Engineers document the assumptions behind them, such as dependencies and peak periods. The step closes when owners sign the recovery objectives. The assessor will look for signed objectives per system, with a record showing the business impact analysis that supports them.
Design backup and redundancy for each system
Engineers decide, system by system, which combination of redundant services, cross-region resilience and backups will meet the recovery objectives. Where a cloud or hosting provider supplies redundant regional services, the organization still designs the cross-region layout, backup copies and restore paths that sit in its own control. The design is finished when it is reviewed against the objectives and the gaps are recorded as risks. The assessor will look for an approved architecture or design document that maps each system to its backup and redundancy method.
Configure backup jobs and retention
Platform engineers build backup jobs for each system and set schedules, retention periods and storage locations as the design requires. Open-source tools such as Bareos can run and supervise backup, restore, verify and archive jobs and keep a catalog of what was backed up, while restic can store encrypted snapshots in a repository. Protection of backup copies, including encryption and access restriction, is configured at this point. The step ends when a job schedule and retention settings can be exported from the tool. The assessor will look for a schedule export, retention configuration and evidence that backup copies are access controlled.
Run and record restore tests
Operators restore selected systems or files from the backups, ideally including a point-in-time restore, and compare the results against the recovery objectives. Where the backup tool supports it, integrity checks such as restic's check with data reads confirm that stored backup data is unmodified. Each test records who ran it, what was restored, the elapsed time, the outcome and any defects, with corrective actions assigned. The step is complete when the restore results are dated and reviewed by the system owner. The assessor will look for dated restore test records with outcomes and follow-up actions, not only a statement that backups exist.
Write and approve the continuity and recovery plan
Based on the inventory, objectives, design and restore results, the organization writes the business continuity and disaster recovery plan, covering roles, escalation, recovery order and communication. The plan should reference the tested recovery procedures rather than restate assumptions. Senior management or the designated owner approves the plan, and the plan is reviewed when systems change. The step closes with a signed and versioned plan. The assessor will look for an approved plan with version history, named roles and evidence that the plan reflects the most recent restore tests.
Set monitoring and alerts on failed jobs
Operations teams configure monitoring so that failed or missed backup jobs, stalled restores and storage problems generate alerts to a named responder. Tools such as Prometheus can collect job metrics and Grafana Alerting can build alert rules from metrics and logs, with alerts managed from one view. The step is complete when test alerts reach the responder and the alert history is retained. The assessor will look for alert rule definitions, notification routing and records of alerts raised and how they were handled.
Review results and keep evidence current
On a schedule the organization sets, owners review backup job reports, restore test results, alert history and plan changes, and record the review and any actions. Significant changes to systems or providers trigger a review of the affected objectives, design and tests. The step is complete when the review is signed and the evidence set is filed for the assessment. The assessor will look for review records that show the cycle operated over the assessment period, not only at a single point.

Evidence that passes domain 16 and how to keep it current

Domain 16 is judged on whether a documented continuity capability works in practice, so assessors look for a connected set of records rather than a single plan. The cards below cover the evidence families that tie the plan, backups, restores, failover design and corrective actions together, along with the routine that keeps each one current between assessments.

Approved continuity and disaster recovery plan

The plan names the in-scope systems, recovery priorities, roles and the escalation path used when a disruption occurs. Assessors check that it was approved by an accountable owner, that its version history shows reviews after significant changes, and that its recovery objectives match what the business has agreed. Between audits, schedule a review at least annually and after every material architecture change, and keep each approved version in a change-controlled repository.

Backup inventory and job configurations

An inventory lists every in-scope system, its data set, backup frequency, retention period and storage location. Job configuration exports show the schedules and policies that produce those backups. Reconcile the inventory against the asset register each quarter, because a system added without a backup job is the most common gap in this family. With Bareos, the Director configuration and job definitions can be exported and stored under version control.

Job success logs and alert history

Assessors look for evidence that backups actually completed, not only that they were scheduled. Keep job completion records, failure notifications and the time each failure was acknowledged. Alerting rules in Grafana or Prometheus can flag missed or failed jobs, and the alert history shows that someone responded. Export a sample of logs each quarter and confirm that gaps have a documented ticket.

Dated restore test records

Restore tests prove that backups can be recovered. Each record should state the date, the person who ran the test, the system and data set restored, the target environment and what was verified, such as application startup or data integrity. Restores from the current backup and from an earlier point in time are both worth recording. Schedule restore tests on a fixed cadence, and record the result even when the test succeeds. For repositories built with restic, run restic check with a data-read option periodically and keep the output as integrity evidence.

Failover and cross-region design documents

Design documents describe how workloads move to a secondary site or region, which services depend on the provider's redundancy, and which resilience tasks the organization owns, such as cross-region data copies and restore testing. In HITRUST's inheritance example, the provider supplies redundant regional services while the customer designs cross-region resilience, so the document should draw that boundary explicitly. Review it whenever network topology or cloud services change, and confirm that failover steps still match the current environment.

Corrective action records for failed tests

A failed restore, a missed recovery objective or a failed failover test should produce a corrective action record with a root cause, an owner, a target date and a retest result. HITRUST's 2025 Trust Report lists a continuity planning requirement among the most frequent corrective action plans, so assessors will look closely at how gaps are closed. Keep these records in the same tracker as other findings and confirm that each one is retested before it is marked closed.

What meeting domain 16 costs in money and effort

This table breaks down the cost and effort components of meeting domain 16 Business Continuity & Disaster Recovery, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to see where open-source tooling removes spend and where people time remains, then request a written scope before comparing quotes.

Cost component	One-time or recurring	What drives it and how to keep it down
Tooling or licenses	Recurring if commercial licenses are used	Self-hosted open-source backup and monitoring tools such as Bareos, restic, Prometheus and Grafana can remove license spend, but infrastructure, storage and staff time for running them remain.
Engineering time for backup and redundancy design	One-time, with later changes	Driven by the number of in-scope systems, recovery targets and cross-region design. Scope the systems in writing to avoid rework.
Restore test effort	Recurring	Driven by how often restores are tested, how many systems are covered and whether tests are documented to evidence standard. Agree the frequency and sample size in the quote.
Continuity plan writing and business owner time	One-time, then periodic review	Driven by the number of business processes in scope and the time owners need to validate recovery priorities. Reuse existing business impact analyses where they exist.
Evidence upkeep	Recurring	Backup job reports, restore test records, alert history and plan revision logs must be kept current. Automated retention of logs and reports lowers manual effort.
External readiness review	One-time before assessment, optional repeats	Priced by the review scope and the reviewer's time. Ask whether it covers evidence sampling and gap reporting, not only a document read.
Assessor fee and sampling effort	One-time per assessment cycle	Set by the assessor, not the organization or implementation partner, and driven by the sampling the assessor performs. Ask the assessor for its written fee basis and evidence request list before fieldwork.

How open-source backup and monitoring tools produce domain 16 evidence

Domain 16 assessors look for proof that backups run, that stored data can be restored and that failures get noticed. The tools below each produce a different slice of that proof, and none of them replaces the organization's own continuity plan or testing schedule. Confirm each tool against your evidence requirements and retention policy before relying on its output.

Scheduled backup and restore jobs

Bareos is an open-source backup system whose Director schedules and supervises backup, restore, verify and archive jobs. It keeps a SQL catalog of backed-up files, so the job history and file inventory can be exported as evidence that backups ran on schedule. Its point-in-time restore lets you select files from the current backup or from one taken before a given date and time, which is the mechanism you need to show that a specific recovery point can be reached. Check that the catalog and job logs are retained long enough for the look-back period your assessor will sample. Bareos is licensed AGPL-3.0-only, so confirm with counsel whether its terms fit how you distribute or host it.

Snapshot integrity and data read-back

restic is a backup tool that checks its own repository. The check command verifies the structural consistency of snapshots, trees and pack files, and with the read-data or read-data-subset options it reads pack files back to confirm the stored data is unmodified. Running these checks on a schedule and keeping the output gives you dated evidence that backup data is intact, not only that a job completed. Full read-data checks are slower and costlier on large repositories, so decide on a subset strategy and document it. restic is licensed BSD-2-Clause, which carries fewer distribution conditions than the AGPL tools in this set.

Alert rules across metrics and logs

Grafana Alerting builds alert rules from queries and expressions across multiple data sources, so a single rule can watch backup job metrics alongside log entries from the backup servers. It lets teams create, manage and act on alerts from one view, which helps show who was notified of a failed backup and what they did next. The evidence is the rule definition, the notification history and the response record, so keep all three. Grafana is licensed AGPL-3.0-only, so review the terms before you modify or redistribute it, and confirm that your notification channels retain delivery records.

Time series showing job health

Prometheus collects metrics from instrumented jobs through a pull model over HTTP and stores them as time series identified by metric name and labels on local storage. Queried with PromQL, these series can show when backup jobs started, how long they ran and whether they succeeded over time, which gives assessors a trend rather than a single snapshot. Local storage has its own retention setting, so confirm that the period covers your policy and that the data is copied to a location that survives a site failure. Prometheus is licensed Apache-2.0, a permissive license with few distribution obligations.

Who owns domain 16 work: your team, a partner and the assessor

Your organization owns the controls in domain 16 and every decision that a control depends on. Only your leadership can say how much downtime the business will accept for each service and how much data loss is tolerable. Those answers drive the recovery objectives that the technical design must meet, so they cannot be delegated to a vendor. Your team also approves the continuity plan, signs off on test results and keeps the plan current as systems change.

Business impact decisions: Decide which services are critical, their acceptable downtime and their acceptable data loss, and record who approved those values.
Continuity plan ownership: Write, approve and review the plan, and name the people who activate it and their backups.
Test scheduling and sign-off: Set the restore and failover test cadence, and review results and the remediation of any failed test.
Scope and inheritance decisions: Decide which resilience functions come from a cloud provider and which remain your responsibility, and document the shared responsibility split.
Evidence custody: Keep approved plans, test records and exception decisions in a location the assessor can access.

Before engaging anyone, confirm that a named executive owns these decisions and that the recovery objectives have been approved in writing.

Common gaps in domain 16 and how to close them

Domain 16 gaps tend to share a root cause: the continuity design exists on paper but has not been exercised, approved or recorded. The cards below cover the gaps assessors most often raise, the closing action for each, and the evidence that shows the gap is closed.

Plans that were never tested

A continuity plan that has never been run is an untested assumption, and assessors look for test records rather than plan text. Schedule an exercise for each in-scope system, record the scenario, the participants, the time taken to recover and the gaps found. Close the finding by showing the corrective actions from the exercise were assigned, tracked and retested. Evidence: dated exercise reports, a signed after-action log and the retest results for each open item. Ask for the last exercise report before the assessor does.

Backups without restore evidence

Backup job logs show data was written, not that it can be read back. For each in-scope system, run a timed restore to a non-production target and keep the output. Bareos keeps a catalog of backed-up files and restores from the current backup or one before a given date and time, so restore requests and results can be logged against it. restic's check command with the read-data option reads pack files back to confirm the stored data is unmodified. Evidence: restore tickets, job outputs and integrity check logs for each tested system.

Recovery objectives never approved

Recovery time and recovery point targets set by engineers are often never signed off by the business owners who carry the impact. Document the target for each in-scope service, have the business owner approve it in writing, and confirm that backup frequency and restore timing actually meet it. Where they do not, record the gap as a risk decision with an accepted owner. Evidence: approved recovery objective register, owner sign-off records and the test results that compare achieved times against those targets.

Cloud redundancy assumed, not documented

Teams often assume a cloud provider's regional redundancy covers their own continuity, but the customer is responsible for cross-region design, backups and restore testing. HITRUST's inheritance example treats this domain as moderately inheritable for that reason. Document which resilience features come from the provider, which the organization configures and which it tests, using a shared responsibility matrix. Evidence: the matrix, architecture diagrams showing failover paths and the provider's reports the organization relies on, checked against its own tests.

Retention that does not match the plan

Backup retention is often set by storage cost rather than by the recovery objectives and legal obligations the business has approved. Compare each retention period in the backup configuration with the approved recovery point target and any data retention rule in scope, then correct the mismatch or document the exception. Check that retention changes go through change control. Evidence: the retention schedule, the backup policy configuration, change tickets and a restore from the oldest point the policy claims to hold.

Alerts that go to nobody

Backup failures and capacity warnings that land in an unmonitored mailbox give no warning before a recovery is needed. Prometheus collects metrics from instrumented jobs and stores them as time series, and Grafana Alerting can build rules across metrics and logs, so backup failures can route to a named on-call owner. Confirm each alert has a recipient who acknowledges it and a documented response. Evidence: alert rule exports, notification routing configuration, and tickets showing alerts were received and handled.

What buyers ask about domain 16 cost, timing and effort

Is business continuity and disaster recovery harder to pass than other HITRUST domains?

Domain 16 is not usually the hardest domain, but it is one that depends on evidence from several teams at once. HITRUST's 2025 Trust Report lists Business Continuity & Disaster Recovery as 4.9% of failing domains in 2024 and ranks a continuity planning requirement ninth among the most frequent corrective action plans. The effort comes from proving that plans were tested, backups restored and results acted on, not from writing the plan itself. Domains that depend on tooling or on several owners, such as access control or third-party assurance, usually take more coordination. Ask your assessor or readiness partner to compare the domain against your current evidence before you estimate effort.

Can our own team prepare domain 16 without outside help?

Yes, many organizations prepare this domain in-house, provided someone owns the program and has time to run tests. The work includes writing continuity and recovery plans, setting recovery objectives, configuring backups, running restore tests and keeping records of each test. The main cost is staff time, which recurs every test cycle. Outside help is usually considered for designing the test program, reviewing whether evidence will stand up to a validated assessment, or building the restore environment. Only an authorized HITRUST External Assessor can perform the validated assessment, so the in-house team cannot issue the result.

What do business owners need to provide for continuity testing?

Business owners must define which services matter most, how long each can be unavailable and how much data loss is acceptable. Technology teams cannot set these values alone. Owners also need to approve the plans, join tabletop exercises and sign off on restore results for their systems. Ask each owner to name a decision-maker who can accept or reject a recovery target, because unclear ownership is a common reason test evidence stalls. Put these responsibilities in the written scope so that both parties know who signs what before fieldwork starts.

How long does it take to build a track record of restore tests?

The track record depends on how often your organization runs restore tests and how many systems are in scope, so no fixed duration applies. An assessor looks for evidence that tests were performed over a period and that failures led to corrective action. The assessor's fieldwork window is at most 90 days for e1, i1 and r2 assessments, but that window covers the assessment itself, not the months of testing that come before it. Plan an incubation period in which tests run on a regular schedule, and confirm with your assessor how much history they will accept for each system in scope.

Does using a cloud provider remove the continuity work from our scope?

No. HITRUST's inheritance example describes domain 16 as moderately inheritable: the provider offers redundant regional services, while the customer still designs cross-region resilience, takes backups and tests restores. Inheritance can reduce the requirements you must evidence, but only for the parts the provider actually covers and that the assessor accepts. Review the provider's shared responsibility matrix line by line and list each continuity requirement as inherited, shared or customer-owned. Any requirement you own still needs its own evidence.

What should a written scope for continuity and restore work include?

A written scope should name the systems in assessment scope, the backup and recovery tools in use, the recovery objectives for each system and the test types you will run. It should also list deliverables such as continuity plans, restore test records, backup configuration exports and monitoring dashboards, along with who approves each one. Add dates for each phase, the acceptance criteria and what happens if a test fails. A partner should state which parts it will build and which parts remain with your staff. Fixed-scope agreements in this kind of work are easier to compare when these items appear in writing before work starts.

Can an assessor design the continuity plan for us?

No. An authorized assessor tests the controls and reports results, and independence rules prevent it from designing the controls it will later assess. The organization owns its continuity plan and must decide its recovery objectives and test scenarios. An implementation partner can help build the backup configuration, restore environment and monitoring, and can prepare evidence, but it does not issue the assessment result. Ask your assessor early which design questions it will answer and which must come from your team, so that the design work is not repeated.

How DeployOpen prepares domain 16 systems and evidence

DeployOpen works on domain 16 by preparing the self-hosted open-source systems that back up, restore and monitor the in-scope environment, inside your own cloud accounts, data centers or air-gapped networks. The organization keeps ownership of its continuity plans and risk decisions, while DeployOpen documents and tests the technical controls and evidence an independent HITRUST assessor will review.

How we scope

Agree in writing which systems, regions and applications fall inside the domain 16 scope before work starts.
Map which resilience duties sit with your cloud provider and which sit with your team, so responsibilities are clear.
Confirm the recovery objectives, backup frequency and retention periods your own business owners have approved.

How we build

Deploy Bareos to schedule backup, restore, verify and archive jobs and keep a SQL catalog of backed-up files.
Configure restic repositories with scheduled check runs, including read-data checks that confirm stored backup data is unmodified.
Build Prometheus and Grafana alert rules that flag failed backup jobs and stale restore points to the owning team.

How we hand over

Deliver runbooks for restore testing, with records of each test, its result and any remediation taken.
Provide configuration documentation and screenshots or exported logs that show backup and monitoring controls operating.
Walk your team through the evidence index so your assessor can trace each domain 16 requirement to its artifact.

How we support

Engagements are fixed-scope, and ongoing support, upgrades and continuous testing are available as a retainer.
Retainers can cover periodic restore tests and backup platform upgrades, scoped in writing before work starts.
Ask your DeployOpen contact to confirm which continuity evidence needs refreshing before an r2 interim or renewal assessment.