164.308(a)(7) Contingency plan: requirements and evidence

What the 164.308(a)(7) contingency plan standard asks you to prove

The contingency plan standard asks you to show that a fire, a system failure, a ransomware event or a natural disaster will not leave electronic protected health information unrecoverable or stop the processes that keep patients cared for. The standard requires policies and procedures for responding to these events, and the Appendix A matrix names three plans that must exist: a data backup plan, a disaster recovery plan and an emergency mode operation plan. The backup plan covers retrievable exact copies of ePHI. The disaster recovery plan covers restoring data after a loss. The emergency mode operation plan covers keeping critical business processes running, while protecting ePHI, during the event itself. Two further implementation specifications are addressable: testing and revision procedures, and applications and data criticality analysis. Addressable means you must assess whether each is reasonable and appropriate for your environment, and document your decision and any alternative if you do not adopt it. Assessors will expect the criticality analysis to set the priorities that the three plans follow.

The standard is hard in practice because plans often exist on paper while restores were never tested. An assessor will ask whether you can bring back a specific system, such as the electronic health record or the imaging archive, from your backups, how long that took, who performed it and what was missing afterward. Confirm that your backup jobs produce a record you can present, that restore tests are logged with dates and outcomes, and that test findings changed the plan. Tabletop exercises help with decision-making, but they do not prove that data can be restored. The current rule sets no recovery time objective, so your own risk analysis and criticality analysis must justify the targets you choose. The January 2025 proposed rule would add a requirement to restore critical systems and data within 72 hours of a loss. That proposal was not final as of October 2026, so confirm its status in the Federal Register before you rely on it, and plan now as though a fixed deadline may apply later.

Which systems and teams fall under the contingency plan standard

The contingency plan standard reaches every system that touches ePHI, the business processes that depend on those systems, and the third parties that host or back them up. Scoping decisions made early determine how much of the plan has to be written, tested and evidenced, and which teams must sign off on it.

Systems that hold or move ePHI

Start with an inventory of every system that creates, receives, maintains or transmits ePHI. That list usually includes the EHR, billing, imaging, email, file shares and endpoints, and it must include the backup repositories themselves, because copies of ePHI are ePHI. Check the inventory against the risk analysis so that no system carrying ePHI sits outside the contingency plan by accident. Ask whether each system's ePHI can be restored from a copy that is kept separately from production.

Business processes that depend on those systems

A system list does not show what the organization must keep running during an emergency. Map each clinical and administrative process, such as scheduling, medication orders, claims submission and results delivery, to the systems it needs. This mapping feeds the applications and data criticality analysis and sets the priorities for the emergency mode operation plan. Ask clinical operations which processes cannot pause, and for how long staff can work without them.

Teams that own each part of the plan

The security official is responsible for the plan as a whole, but recovery depends on infrastructure teams, application owners and clinical operations leaders. Assign a named owner for each system and each process, and record who approves changes to recovery priorities. Without that assignment, backup jobs may run for years without anyone confirming that a restore works. Confirm that these owners know their role during an incident, not only during the annual review.

Cloud hosts and managed IT providers

Cloud hosts, managed IT providers and backup vendors often run part of the ePHI environment. Each one that creates, receives, maintains or transmits ePHI for you is a business associate, so the contract must require the assurances the Security Rule expects. Find out where each provider keeps backups, how it restores them, and whether it tests restores on your behalf. Responsibility for the contingency plan stays with your organization even when a provider runs the recovery work.

Backup and restore tooling

Backup software sits inside the contingency plan and needs its own scope entry. Bareos keeps a SQL catalog of backed-up files and restores files from the current backup or from one taken before a given date and time, so its catalog and storage locations belong in the inventory. restic can confirm that stored data has not been modified when it is run with read-data checks. Record which tool covers which systems, where its credentials are kept, and who can restore data.

Endpoints, removable media and devices

Laptops, workstations, mobile devices and removable media often hold local copies of ePHI that no central system tracks. Include them in the scope so the plan covers data that exists only on a device, such as a clinician's downloaded report. Confirm which devices can be wiped or located, and how staff report a lost device so that the contingency plan and incident response procedures start together. Ask whether any endpoint is excluded from backup and why.

How an assessor tests the contingency plan

This table compares each area an assessor reviews under 164.308(a)(7), what they ask to see, the dated evidence that passes and the findings that appear most often. Read it as a checklist of what to assemble before an OCR review or outside assessment, since OCR's complaint and audit reviews ask for dated records rather than descriptions of what the organization intends to do.

Test area	What the assessor requests	Evidence that passes	Common findings
Written policies and procedures	The contingency planning policy, its owner, approval date and the procedures that tie the plans together	Approved, dated policy naming an owner, with review history showing it was revisited after system or staffing changes	Policy exists but is unsigned, undated or describes systems the organization no longer runs
Data backup plan	Backup scope, schedule, retention settings and proof that backups can be restored	Backup job logs, catalog or inventory of protected ePHI systems, and dated restore test results	Backups run successfully, but no restore has ever been tested or ePHI sources are missing from scope
Disaster recovery plan	Recovery procedures, recovery order, responsible roles and contact lists	Documented procedures with named roles and a record of a recovery exercise showing the steps were followed	Plan lists systems that no longer exist or relies on one person who has left the organization
Emergency mode operation plan	Procedures for keeping critical processes running and protecting ePHI during an outage	Dated manual workflows, access controls kept in place during emergency mode, and staff briefing records	Plan covers recovery after the event but says nothing about operating during it
Applications and data criticality analysis	The ranking of applications and data by business importance and the basis for each ranking	Dated inventory tied to ePHI locations, with owner sign-off and recovery priorities that match the disaster recovery plan	Criticality ranking is missing, or it does not match the recovery order used in practice
Testing and revision records	Schedule of tests, results, findings and changes made to the plans	Dated test reports, tabletop exercise notes and revision history showing findings were fixed	Tests were planned but not performed, or results were not fed back into the plans
Link to the risk analysis	How the risk analysis identified the outages and disasters the plans must address	Risk analysis entries for backup, outage and disaster scenarios that trace to specific plan sections and controls	Risk analysis lists no contingency scenarios, so the plans cannot be shown to address identified risks

How to implement the contingency plan standard in sequence

This sequence moves from a documented policy to tested, revised contingency plans that cover every ePHI system the organization depends on. Each step produces an artifact an assessor can read and trace back to 164.308(a)(7).

Set the contingency planning policy
The security official, with leadership sign-off, writes a contingency planning policy that names who declares an emergency, who owns each plan, and how the plans are kept current. This policy is the foundation the rest of the standard depends on, and it is the first document an assessor will ask for. It is done when the policy is approved, dated, versioned and distributed to the staff who will carry out the plans.
Complete the applications and data criticality analysis
Inventory every application and data store that holds ePHI, then rank them by how much the business and patient care depend on each one. This addressable specification sets the priority order for backup, recovery and emergency mode operation. The analysis should align with the risk analysis under 164.308(a)(1)(ii)(A), so that a system rated high-risk there is not rated low here. It is done when a ranked list is signed off and cross-referenced to the risk analysis.
Identify preventive measures
For each critical system, list the measures that reduce the chance a disruption damages ePHI or stops operations, such as redundant storage, power protection, patching cadence, immutable or separately credentialed backup copies and hardened recovery hosts. Record the owner and status of each measure. The output is a preventive measures register linked to the risks it addresses, and the step is complete when every critical system has at least one documented measure or a recorded reason for none.
Define the recovery strategy and recovery objectives
Using the criticality ranking, decide how each critical system will be restored and how much data loss and downtime the business can accept. The current rule does not set a recovery time, so the organization sets its own objectives and records the reasoning. The proposed 2025 revision would require restoration of critical systems within 72 hours, which is worth tracking but is not yet binding. The output is a recovery strategy document with stated objectives for each critical system.
Write the backup, disaster recovery and emergency mode plans
Write the three required plans as separate documents: the data backup plan for retrievable exact copies of ePHI, the disaster recovery plan for restoring data after a loss, and the emergency mode operation plan for keeping critical processes running while ePHI stays protected. Each plan names the systems it covers, the responsible roles, the steps and the contact list. Open-source backup tools such as Bareos, which keeps a SQL catalog and restores files from a chosen point in time, can support the backup plan, but the plan must describe how the organization actually uses them. The step is complete when each plan is approved and cross-references the criticality analysis.
Schedule and run restore and tabletop tests
Set a testing schedule that the security official approves, then run restore tests against real backup sets and tabletop exercises that walk staff through an outage scenario. Restore tests should confirm that ePHI comes back complete and unmodified, and integrity checks such as restic's check with data reads can provide evidence of that. Tabletop exercises test decision-making, communication and emergency mode operation. Record the date, scope, participants, results and gaps for each test. Confirm the testing frequency with your own policy, because the rule requires periodic testing without setting an interval.
Revise the plans from test results
Review each test record, log the gaps and assign owners and due dates for fixes. Update the backup, disaster recovery and emergency mode plans, the criticality analysis and the preventive measures where a test showed they were wrong. Keep the prior versions so an assessor can see how the plans changed over time. The step closes when every gap has a documented disposition and the revised plans are approved, redistributed and linked to the next testing cycle.

Evidence that passes a contingency plan review

An assessor testing 164.308(a)(7) looks for a documented plan, proof that it was tested, and a trail showing it changed when systems changed. The cards below describe the artifacts that connect those three points and the habits that keep them current between reviews.

Written contingency policy and plans

The contingency planning policy and each plan (data backup, disaster recovery and emergency mode operation) should carry a version number, an approval date and a named approver. Assessors check that the policy states the purpose, scope and roles, and that each plan matches what the systems actually do today. A plan that names a retired server or an old data center fails review even if it is well written. Confirm each document has an owner who reviews it on a fixed schedule.

Applications and data criticality inventory

This inventory ranks applications and data by how much the business depends on them, which sets recovery and emergency mode priorities. It should list every system that holds ePHI, its owner, its dependencies and the order in which it must return. Assessors compare the inventory against the backup scope and the disaster recovery plan to find systems that were ranked but never protected. Date the inventory and record who approved it.

Backup job logs and catalog reports

Backup logs show that jobs ran, completed and covered the systems named in the criticality inventory. Catalog reports show which files and snapshots exist and how far back they go. Keep failed-job records and the follow-up for each failure, because a clean summary with no failures visible often draws questions. Confirm the logs record job type, start and end times and target, and that someone reviews them on a set cadence.

Dated restore test results

Restore tests prove that backups can be read back into a working state. Each record should state the date, the systems restored, the data set used, the person who ran the test, whether the restored data matched the source, and the measured time to restore. Integrity checks on the backup repository, such as restic check with read-data options, can supplement restore tests. Assessors look for a pattern of tests over time, not one test before an audit.

Tabletop exercise records and corrective actions

Tabletop exercises walk staff through a realistic outage, such as ransomware encrypting a clinical system, and test whether the plans work in practice. The record should list participants, the scenario, decisions made, gaps found and an action owner with a due date for each gap. Assessors check whether findings were closed and whether the closed items appear in later plan versions. An exercise with no recorded findings is harder to defend than one with tracked fixes.

Change records and keeping evidence current

Change records show that plans were revised after system, vendor or data center changes, and they should link each revision to the test or incident that prompted it. Between audits, keep a recurring test calendar, retain backup and restore logs for a period your risk analysis sets, and store evidence where it cannot be quietly edited. Confirm with counsel and your auditor how long retention must run for your organization, because the Security Rule's documentation provisions and state law may differ.

What meeting the contingency plan standard costs

This table compares the main cost components of building and keeping a contingency plan under 164.308(a)(7), showing who is paid, whether each cost is one-time or recurring, and what drives it up. Use it to structure a quote request, since no price or duration is stated here. The main takeaway is that costs scale with the number of systems holding ePHI and the recovery objectives the organization sets.

Cost component	One-time or recurring	What drives it and how to keep it down
Backup and recovery tooling or licenses	Recurring (subscription or support) or one-time (perpetual)	Commercial licenses often scale per host, terabyte or client. Self-hosted open-source tools such as Bareos or restic remove license spend, but support, hardening and upgrades still need budget.
Engineering time for backup design and restore automation	One-time build, then recurring upkeep	Number of systems, heterogeneity of platforms and how much restore is scripted. Standardize backup patterns and automate restore runbooks to limit rework.
Storage and secondary site capacity	Recurring	Volume of ePHI, retention periods, backup frequency and whether copies sit off-site or in a second region. Tier data by criticality from the applications and data criticality analysis to avoid over-provisioning.
Restore and tabletop testing effort	Recurring	Number of plans tested, restore scope and whether full recovery is exercised or only samples. Rotate scenarios and test critical systems first.
Plan maintenance and revision	Recurring	Frequency of infrastructure change, staff turnover and how many documents must be kept current. Tie plan updates to change management so revisions happen in the same cycle.
External testing or review	Recurring or per engagement	Scope of independent review, whether it covers recovery objectives and how much preparation the internal team completes first. Ask for a fixed scope in writing before work starts.
Auditor or assessor sampling	Per engagement	Number of samples the assessor selects and how quickly evidence is produced. Keep restore logs, test records and revision history organized so sampling does not trigger extra work.

How Bareos and restic produce contingency plan evidence

Bareos and restic can generate much of the backup and restore evidence that 164.308(a)(7) Contingency plan calls for. The cards cover what each tool does, how its logs support restore evidence, and which licenses you must review. Neither tool writes your disaster recovery or emergency mode plans, so confirm fit against your own environment, workloads and recovery needs before you rely on either.

Scheduled backup and restore with Bareos

Bareos is an open-source backup system whose SQL catalog records which files each job backed up. Its Director schedules and supervises backup, restore, verify and archive jobs, so you can show which ePHI systems were covered and when. Restores can use the current backup or one taken before a chosen date and time, which lets you test recovery to a specific point. Check that every ePHI system appears in a job and that restore tests are scheduled as well as the backups.

Integrity checks with restic

restic stores backups as encrypted snapshots in a repository. Its check command verifies the structural consistency of snapshots, trees and pack files, which exposes a damaged repository. Adding --read-data or --read-data-subset makes restic read pack files back and confirm that the stored data is unmodified. Full reads take longer and add I/O load on large repositories, so set the subset size from your recovery objectives and your risk analysis.

Logs and reports as restore evidence

Job logs, catalog queries and check output become the proof an assessor asks for: that backups ran, that restores succeeded and that the repository was intact at a given time. Keep them with restore test records that list the systems tested, the scope and the person who approved the result. Confirm which log formats and report outputs your installed versions produce, then retain them under your documentation policy. Logs alone do not show that a restored system works, so pair them with application-level checks.

License obligations for each tool

Bareos is licensed under AGPL-3.0-only and restic under BSD-2-Clause. The BSD license is permissive and places few obligations on how you use or distribute restic. AGPL-3.0-only carries source-disclosure duties if you modify Bareos and make it available to users over a network, so ask counsel whether your deployment triggers them. Neither project provides a support contract, so budget for maintenance and for any outside help separately.

Who owns the contingency plan and what a partner can take on

The contingency plan is your obligation under 45 CFR 164.308(a)(7)(i). The assigned security official, named under 164.308(a)(2), is accountable for the policies and procedures being written, kept current and actually followed, but the work spans several owners. Business owners of each application or data set should set the recovery priorities and the acceptable loss of data and downtime, since these drive the applications and data criticality analysis. Clinical and operational leaders should approve the emergency mode steps that keep patient care running while ePHI is protected, because they know which workflows cannot stop.

Security official accountability: owns the contingency policy, the backup and disaster recovery plans, and the testing schedule.
Business owner decisions: set priorities for each system and record the recovery objectives they accept.
Clinical leader approval: signs off on which functions continue in emergency mode and for how long staff can work manually.
Final sign-off: an executive should approve the plans and the risk decisions behind them, with the approval recorded.
Evidence of ownership: keep dated approvals, meeting records and version history so an assessor can trace each decision to a named person.

Confirm that your own policies name each of these roles and that no single person is both the author and the only approver of the plan.

Common contingency plan gaps and how to close them

Most contingency plan failures are not missing documents. They are plans that were never exercised, owners who were never named, and backups that share a failure domain with production. The cards below pair each common gap with the step that closes it, so the plan holds up when an assessor asks for restore evidence.

Backups that were never restored

A backup job reporting success proves only that data was written, not that it can be recovered. Under 164.308(a)(7)(ii)(A), the data backup plan must keep retrievable exact copies of ePHI, so retrievability is the test. Schedule restores of representative systems, including a full database and a single file set, and record the time taken and the data verified. Ask whether the backup tool can verify stored data, not just catalog it. For example, restic's check command with read-data options reads pack files back to confirm they are unmodified.

Plans with no named owner or objective

A contingency plan that names no accountable owner, and sets no recovery objectives for systems, leaves nobody to decide under pressure. The disaster recovery plan under 164.308(a)(7)(ii)(B) needs a responsible role, a defined recovery order and a stated target for each critical system. The current rule sets no recovery time, so the organization must set one and justify it in the risk analysis. Confirm that the owner has authority to declare an emergency and that a deputy is named.

Criticality analysis missing or disconnected

Under 164.308(a)(7)(ii)(E), the applications and data criticality analysis sets the priority for backup, recovery and emergency operation. When it is missing, every system looks equally urgent, or the analysis lists systems that the risk analysis never mentions. Check that each system holding ePHI appears in both documents with matching ratings, and that the recovery order follows those ratings. Revisit the analysis when new systems or integrations are added.

Backups reachable by the same ransomware

Backups stored on domain-joined servers, with the same credentials or a persistent network mount to production, can be encrypted along with the data they protect. The data backup plan should keep at least one copy isolated from production credentials, such as an immutable or separately administered repository. Test whether an account compromised on a workstation can delete or overwrite backups. Bareos keeps a catalog of backed-up files and restores from a chosen point in time, so confirm that the catalog and storage are also protected.

No emergency mode procedure for clinical workflows

The emergency mode operation plan under 164.308(a)(7)(ii)(C) must keep critical business processes running while protecting ePHI during an outage. Many organizations write a disaster recovery plan but never define how clinicians order medications, view results or check in patients while systems are down. Document manual downtime forms, who can authorize them, how paper records are reconciled after restoration, and how access controls still apply. Walk through one scenario with clinical staff to confirm the procedure is usable.

Test records without dated findings

The testing and revision procedures under 164.308(a)(7)(ii)(D) call for periodic tests, but a record that says a tabletop exercise took place does not show what failed. Each test record should carry a date, the scenario, the systems involved, the measured results, each finding with an owner and a due date, and proof that the plan was revised. Assessors look for this feedback loop. Keep findings and their closure dates together so the trail shows the plan improved over time.

What the 2025 proposed rule would change for disaster recovery

The HHS proposed rule published January 6, 2025 would require procedures to restore critical relevant electronic information systems and data within 72 hours of a loss. That requirement is a proposal, not a final rule. As of October 2026 no final rule has been published, and the latest Unified Agenda entry for RIN 0945-AA22 lists final action as projected for July 2027. The current Security Rule sets no recovery time for the disaster recovery plan required under 164.308(a)(7)(ii)(B), so today the figure your organization commits to is a choice your risk analysis and contingency plan should justify, not a regulatory number. Read the proposed rule in the Federal Register yourself before you rely on its wording, because summaries of a proposal can drift from the text.

Do not write the proposal's terms into customer contracts, business associate agreements or board reporting as settled obligations. Before you set any recovery commitment, confirm the rule's status against the Federal Register and the Unified Agenda, and ask your counsel how a pending change would interact with the contract. Meanwhile, design recovery objectives that you can measure now. Name the critical systems that hold ePHI, using the output of your applications and data criticality analysis, and set a restore target for each one. Then run restores from your backup tooling, such as Bareos restores or restic restores verified with restic check --read-data-subset, and record the elapsed time from the request to a verified, usable system. Those timestamps are the evidence that a 72-hour or any other target was met or missed.

Treat the restore log as a living record. Each test should capture the system tested, the backup set used, who ran the restore, the start and finish times, what data was verified, and what failed. Feed the results into the testing and revision procedures under 164.308(a)(7)(ii)(D), so the disaster recovery plan changes when the measured time changes. If a restore consistently takes longer than your target, you have two options: fund changes to the architecture or storage, or document a reasoned decision to accept the gap in the risk management plan. Either way, a reader from OCR or an independent assessor will expect the decision to be visible in your records, not assumed.

Contingency plan questions buyers ask before hiring help

How much effort does a HIPAA contingency plan take to write and maintain?

The effort depends mostly on how many systems hold ePHI, how many of them are critical to patient care or billing, and how many teams own them. The Security Rule does not set a page count or a recovery time for the current plans, so the work is driven by the applications and data criticality analysis and by the number of backup, disaster recovery and emergency mode plans you need. Expect one-time effort to build the plans and recurring effort to test and revise them after system or staffing changes. Ask any partner to break its quote into analysis, plan drafting, restore testing and revision cycles so you can see where the hours go.

Can a small practice write its own HIPAA contingency plan from public guidance?

Yes, a small practice can draft its own plans if someone understands both the practice's systems and the Security Rule. The rule itself at 45 CFR 164.308(a)(7) and NIST SP 800-66 Rev. 2 describe the required policies, the three required plans and the addressable specifications in general terms, and NIST's guide is informational rather than binding. The harder part is making the plans specific: listing where ePHI lives, who restores what, and how long the office can run without its systems. A practice that cannot assign a named owner for each system, or cannot test a restore, should expect to pay for outside help at least for the first cycle.

How long does it take to build and test contingency plans?

No reliable general duration applies, because the timeline depends on scope and criticality. The factors that move it most are the number of ePHI systems, whether they run on-premises, in a cloud account or across both, and how much documentation already exists. The applications and data criticality analysis sets the order of work, since it determines which systems get recovery priority and which plans need detail first. Testing adds time because a restore test needs a maintenance window, a clean recovery environment and the system owner present. Ask a partner for a fixed-scope timeline that lists the systems in scope and the restore tests included.

What does the organization need to provide for contingency planning work?

The work needs named people more than it needs tools. Each critical system needs a system owner who can confirm its data, dependencies and acceptable downtime, and someone from operations who can approve restore tests on production-adjacent environments. You also need agreed restore windows, current inventories of applications and backup jobs, and access to backup catalogs and logs. Leadership should confirm which processes must keep running during an emergency, because that decision shapes the emergency mode operation plan. If these inputs are missing, the plans will be generic and hard to test, so confirm them before any drafting starts.

Can a partner run restore tests for our contingency plan?

A partner can design and run restore tests in your environment if the written scope includes them and your team approves the test plan. A typical test restores a sample of backed-up data or a system image, checks that it is complete and usable, and records the results for the testing and revision specification. Open-source tools such as Bareos and restic can support this work: Bareos schedules restore jobs and restores files from a chosen backup point, and restic's check command with read-data options reads pack files back to confirm stored data is unmodified. The organization still owns the decision to accept the results and the revision of its plans.

Does HHS certify that a contingency plan meets the HIPAA Security Rule?

No, HHS does not certify contingency plans or any other part of Security Rule compliance. HHS states that no Security Rule standard requires an entity to certify its compliance, and it does not endorse or recognize private certifications, which do not stop OCR from later finding a violation. A consultant can prepare your plans and test them, but the result is evidence for OCR or your own review, not a HIPAA certificate. When a vendor offers a HIPAA certification for contingency planning, ask what it covers and whether it is a third-party assessment report or a marketing claim.

What drives the cost of a contingency plan engagement?

Cost is driven by the number of systems in scope, how many environments need restore testing, and how much analysis the organization lacks already. One-time costs include the criticality analysis, plan drafting and the first round of restore tests. Recurring costs include revision after system changes, periodic testing and staff time to keep owner contacts current. Ask for a quote that separates these items, names which systems and environments are covered, and says what the organization must supply. Scope changes are easier to control when the written scope lists the systems, the test types and the number of test cycles.

Should we tie contingency planning to the proposed 72-hour recovery requirement?

Plan for it, but do not treat it as current law. The January 2025 proposed rule would require procedures to restore critical relevant electronic information systems and data within 72 hours of a loss, but it was not final as of October 2026. Under the current rule, the disaster recovery plan must restore lost data after an emergency without a set recovery time, so your own criticality analysis should define targets. Ask any partner to record recovery targets as configurable values so that the plan can be updated if the final rule changes the requirement.

How DeployOpen prepares contingency plan evidence

DeployOpen plans, implements and documents self-hosted open-source backup and recovery platforms inside your own infrastructure, so the contingency plan rests on systems you run and can show. We prepare the systems, plans and test records an assessor will ask for, while your organization owns the policies, the risk decisions and the final sign-off.

How we scope

Each engagement starts with a written scope that names the ePHI systems, backup targets and recovery objectives covered.
The scope lists which contingency plan elements we build, such as data backup, disaster recovery and emergency mode operation plans.
Scope also states who owns the applications and data criticality analysis, which your organization must approve before recovery priorities are set.

How we build

We deploy backup tooling such as Bareos or restic in your cloud accounts, data centers or air-gapped networks, with access controls you approve.
Configuration covers retention, encryption and catalog or repository settings, documented so each backup job can be traced to a system.
We build restore procedures and verification jobs, including integrity checks that read stored data back, so restorability can be demonstrated.

How we hand over

Deliverables include the written plan documents, configuration records, runbooks and restore test results agreed in the scope.
Testing and revision procedures are handed over with a schedule and a record template for each restore or tabletop exercise.
Your staff receive walkthroughs so they can run restores and update the plans without depending on DeployOpen for daily operation.

How we support

Ongoing support, upgrades and recurring restore testing are available as a retainer after the fixed-scope work closes.
Platform changes, new systems and updated risk analysis results can be folded into the plans through a scoped change request.
Confirm with your auditor or assessor which evidence they accept, since only independent assessors issue reports or attestations.