164.308(a)(7)(ii)(E) data criticality analysis guide

What the applications and data criticality analysis asks you to decide

Section 164.308(a)(7)(ii)(E) asks you to decide which applications and data matter most, and to write that ranking down. The standard calls for an assessment of the relative criticality of specific applications and data in support of the other contingency plan components. In practice, the ranking tells you which electronic protected health information must come back first after a ransomware event, a failed data center or a cloud region outage, and which systems can keep running in degraded form during an emergency. It is an addressable specification under 45 CFR 164.306(d)(3), so you must assess whether it is reasonable and appropriate for your environment. If you decide it is not, you must document why and adopt an equivalent alternative measure if one is reasonable and appropriate. Few organizations will find a reason to skip it, because the backup, disaster recovery and emergency mode plans all depend on its output.

The hard part is knowing what you actually run. Clinical and billing applications often depend on interfaces, file shares, print services, identity providers and reporting databases that nobody listed as dependencies. Departments buy software-as-a-service tools or run spreadsheets that hold patient data outside IT's view, and system owners may be unclear or may have left. Each gap means a system can be ranked too low, or missing from the plan entirely. Start by listing systems and data stores with their owners, then map which ones feed clinical care, scheduling, billing and reporting. Ask each owner what would happen if the system were unavailable for one day, one week and one month. Their answers, not guesses about technical importance, should drive the ranking.

NIST SP 800-66 Rev. 2, published in February 2024, places this analysis second among the contingency plan key activities, after developing the contingency planning policy. The guide is informational rather than binding, but assessors often use it as a reference for what a reasonable process looks like. The January 2025 proposed rule (90 FR 898) would go further by requiring that non-critical systems and data be restored in line with this analysis. That change was still proposed, not final, as of October 2026, so confirm the current status with the Federal Register and the Unified Agenda before you rely on it. Whatever happens to the rule, a documented ranking that names an owner, a restoration priority and the date of last review is the evidence you will need to show how your recovery sequence was chosen.

Which applications and data the criticality analysis must cover

A criticality analysis is only as good as its inventory. The cards below cover the systems that fall inside scope, the places they hide, and how third parties and ownership change who ranks them. Each decision affects which applications end up with backup, recovery and emergency mode priorities.

Every system that touches ePHI

Scope starts with any system that creates, receives, maintains or transmits electronic protected health information. That includes clinical applications, billing, scheduling, email, file shares, reporting databases and the interfaces between them. Ask each system owner to confirm whether ePHI passes through, is stored in, or is only referenced by their application. A system that touches ePHI for even a short time belongs in the inventory, because the contingency plan has to account for it. Document the decision for systems you exclude, with the reason.

Hosted and SaaS applications

Software-as-a-service tools are often missed because no one runs them on the internal network. Scope them with the same rigor as on-premises applications, including vendor-hosted portals, telehealth tools and analytics dashboards that receive ePHI. For each one, record where the data lives, how it can be exported, and what the vendor commits to restore. Your criticality ranking should reflect what your organization can actually recover, not only what the vendor advertises.

Backup repositories and identity services

Backup repositories hold copies of ePHI, so they belong in scope even though no clinician uses them directly. Identity services such as directory, single sign-on and multi-factor systems are equally critical, because without them other applications cannot be restored or accessed during an emergency. Rank these components explicitly. If the identity provider fails, the ranking of every dependent application changes.

Inventory sources that find the systems

Build the inventory from more than one source, because no single list is complete. Asset management records, endpoint inventory agents and network discovery each surface different systems. Open-source options include GLPI, whose Assets module can be filled manually or through the GLPI Agent, and Wazuh, whose Syscollector module reports installed software, open ports and services from each endpoint. Reconcile the sources and flag systems that appear in one but not the others.

Third parties and business associates

Vendors that create, receive, maintain or transmit ePHI for you are business associates, and their systems affect your contingency plan even though you do not operate them. Record which vendor hosts which data, whether a business associate agreement is in place, and what recovery commitments the vendor has made. Your analysis should rank a vendor-hosted system by its effect on your operations, and note where your own backups are the only recovery path.

Ownership and who ranks each application

Each application should have a named business owner who confirms its criticality and the acceptable downtime for it. Clinical leaders, finance staff and IT often disagree about priority, so the security official should resolve those differences and record the final ranking. Ownership changes when systems are reorganized or outsourced, so review the owner list whenever the inventory changes. An application with no owner is a finding in its own right.

How an assessor tests applications and data criticality

This table compares what an assessor checks, the evidence requested and the findings that commonly appear for the applications and data criticality analysis. Read each row as a test question: the left column names the check, and the other columns show what passes and where organizations usually fall short.

Assessment area	Test approach and evidence requested	Common findings
Current, dated ranking	Request the criticality ranking with an approval or revision date, confirm it is recent relative to the last major system change, and check that it covers every system holding ePHI.	Ranking is undated, predates a migration, or omits cloud services, SaaS tools and devices that store ePHI.
Coverage of ePHI systems	Compare the ranking against the risk analysis asset inventory and data flow maps. Sample several ePHI systems and confirm each appears with a criticality level.	Ranking covers core clinical systems but misses billing, imaging, backup repositories or shadow applications.
Link to backup priorities	Trace a high-criticality system to its data backup plan entry and confirm backup frequency and retention reflect its rank.	Backup jobs treat all systems equally, so the ranking has no effect on what is backed up first.
Link to disaster recovery priorities	Review the disaster recovery plan for restoration order and confirm it follows the ranking. Ask for the last restore test that used this order.	Recovery sequence is copied from an old network diagram, or restoration order is undocumented.
Link to emergency mode operation	Confirm the emergency mode plan names the processes and systems that must keep running, and that these match the top tier of the ranking.	Emergency mode lists clinical functions but does not identify which applications and data support them.
Addressable decision documented	Check for a written decision on whether this specification is reasonable and appropriate. If it was not adopted as written, look for the documented reason and the equivalent alternative measure.	Specification is marked as implemented with no rationale, or the decision was never reviewed when the risk analysis changed.
Owner approval	Request sign-off from system or data owners and from the security official or leadership, with dates and the version approved.	Ranking was produced by IT alone, with no evidence that clinical or business owners reviewed it.
Change tracking	Compare ranking revisions with change records, asset inventory changes and risk analysis updates. Confirm that new or retired systems were re-ranked.	New applications were deployed without a criticality assignment, and retired systems remain in the ranking.

Steps to run the criticality analysis and feed the contingency plan

This sequence turns the addressable applications and data criticality analysis into a documented, owner-approved ranking that sets backup, disaster recovery and emergency mode priorities. Each step closes with a named output that can be filed as evidence.

Confirm scope and the contingency planning policy
The security official and the contingency plan owner confirm which facilities, business units, systems and vendor-hosted services hold or touch ePHI, and check that a written contingency planning policy exists to govern the analysis. The step closes with a signed scope statement listing in-scope systems, named owners and the policy version the analysis will follow. If the policy is missing, draft it before any scoring starts, because the criticality ranking has no authority without it.
Build the application and data inventory
Start from the asset and data flow records in the risk analysis, then list every application, database, file share and interface that stores, processes or transmits ePHI. Open-source inventory tools such as GLPI and Wazuh's system inventory can help confirm hardware, installed software and services, but staff who own each system must verify the list. The output is an inventory with one row per application or data set, its ePHI content, hosting location and business owner.
Score criticality against impact and dependencies
For each inventory item, the business owner and IT rate the effect of losing or being unable to use the item, including patient care impact, revenue, regulatory exposure and the other systems that depend on it. Record the dependency chain, because a low-visibility authentication or interface service can be more critical than the application users see. The output is a scored register with the rating scale, the rationale for each score and the names of the people who agreed to each rating.
Assign recovery and emergency mode priorities
Group the scored items into tiers and map each tier to the other contingency plan components: the data backup plan, the disaster recovery plan and the emergency mode operation plan. Specify which systems must be available during an emergency, which can wait for restoration and which can be restored in a later wave. The output is a priority table that tells backup and recovery teams what to restore first and which processes must continue while ePHI is protected. Ask your recovery vendors to confirm they can meet each tier in writing.
Document the addressable decision
Because this specification is addressable, record whether applying it is reasonable and appropriate for each contingency component the analysis touches. If a criticality-driven measure is not adopted, document why and state the equivalent alternative measure, as 45 CFR 164.306(d) requires. The output is a decision memo that links each rationale to the risk analysis and to the policy from step one, so an assessor can trace the reasoning without interviewing the authors.
Obtain owner sign-off
Present the scored register, priority table and decision memo to the system owners, clinical or operational leaders and the security official for approval. Approval should name each owner and the date, and any disagreement should be resolved and recorded before sign-off. The output is a signed approval record. Without it, the priorities cannot reliably drive restore tests or disaster recovery decisions.
Feed priorities into testing and schedule review
Pass the approved priorities to the testing and revision procedures so that restore tests cover the highest tier first and tabletop exercises include the emergency mode steps. Set a review trigger tied to the risk analysis update, significant system changes and new applications, and confirm the review date in the policy. The output is a test plan referencing the approved tiers and a review calendar. Ask the security official to confirm how the review record will be retained alongside other Security Rule documentation.

Evidence that passes an applications and data criticality analysis

An assessor testing 164.308(a)(7)(ii)(E) will look for a ranking that is dated, justified and tied to the rest of the contingency plan. The cards below cover the artifacts that show the analysis was done, approved and kept current as systems change.

Dated criticality ranking and scoring method

This is the core artifact: a ranked list of applications and data sets with a date, a named author and the scoring criteria used to place each item. Criteria usually cover how long the business can run without the system, how much ePHI it holds and how many patients or workflows depend on it. Check that every ranking carries a version and that the method is written down well enough for a second assessor to reproduce the order.

Application and data inventory

The ranking is only as good as the inventory it draws from. Keep a current list of applications, databases, file shares and interfaces that store or transmit ePHI, with system owners and hosting locations. Open-source asset tools such as GLPI can hold this record, and Wazuh system inventory data can confirm what is actually running. Ask whether the inventory is reconciled against the ranking so no system is ranked without being listed.

Mapping to backup and recovery priorities

The criticality ranking exists to set order for the other contingency plan components. Show a traceable link from each ranked system to its backup schedule, its recovery priority and its emergency mode treatment. Tools such as Bareos record which jobs cover which data, and restic verification output can show that backups for high-ranked data were tested. An assessor will sample a critical system and expect to follow the chain end to end.

Documented addressable decisions

Because this specification is addressable, the file should record whether the entity judged the analysis reasonable and appropriate. Where an element is not adopted, the record should explain why and name the equivalent alternative measure chosen. Keep the decision, the risk analysis input it relied on and the reviewer's sign-off together. Vague entries such as "not applicable" tend to fail review.

Owner approvals and change records

Each ranking needs approval from the people accountable for the systems and data, not only from the security team. Record who approved the ranking, when, and what they reviewed. Change records should then show re-ranking after major events such as a new EHR module, a cloud migration or a retired application. Ask for the ticket or meeting record that links each change to a revised ranking.

Review cadence and currency checks

Set a review trigger in policy, both a calendar cycle and event-based triggers such as acquisitions or new ePHI flows, and keep the evidence of each review. The NIST SP 800-66 Rev. 2 guide places this analysis early in contingency planning, so assessors often compare its date with the dates of system changes. Confirm your own review interval with counsel or your assessor, because the rule itself sets no fixed frequency for this specification.

What an applications and data criticality analysis costs to meet

This table breaks down the effort and spend behind the criticality analysis by cost component, showing who is paid, whether each cost is one-time or recurring, and what pushes it up or down. Use it to shape a quote request, since no price or duration for this specification is supplied, so every sizing figure must come from the written scope and your own environment.

Cost component	Who pays or does the work	One-time or recurring	What drives it up or down
Business impact interviews	Internal staff time from clinical, billing and operations owners, plus any facilitator	One-time, then repeated at each review	Number of applications, number of owners, and whether owners can state downtime and data loss tolerances
Application and data inventory	Internal IT or an implementation partner, with inventory tooling	One-time build, recurring upkeep	Quality of the existing asset records, how many systems hold ePHI, and how many interfaces connect them
Tooling and licenses	The organization, through license or subscription spend	Recurring where licensed	Self-hosted open-source inventory and backup tools can remove license spend; confirm support and hosting costs with the vendor or partner
Owner approvals	Application owners and the security official, as internal time	Recurring at each review cycle	Number of owners, sign-off routing, and whether criticality rankings are documented in one place
Updates after changes	Internal change managers and IT staff	Recurring	Frequency of system changes, new integrations, mergers, and cloud migrations that shift where ePHI lives
External review	Independent assessor or consultant, if engaged	Often one-time per cycle, optional	Scope of the review and whether the analysis is checked against NIST SP 800-66 Rev. 2 sample questions; request a fixed-scope quote in writing

Open-source tools that build the criticality inventory and backup priorities

A criticality analysis is only as good as the inventory behind it. The four tools below help you list the systems that hold or touch ePHI, see what runs on them, and prove that the backups for the most critical data can be read back. They produce evidence for your decisions, but the ranking of what matters most stays with your organization.

GLPI Assets inventory

GLPI's Assets module records computers, monitors, software, network equipment, peripherals, printers, phones and racks. Entries can be typed in by hand or pushed automatically by the GLPI Agent through native inventory, which is built into GLPI from version 10. For 164.308(a)(7)(ii)(E), use it as the starting list of systems, then add an owner, a business function and a data classification to each asset that touches ePHI. Confirm the asset list is complete by comparing it against network discovery before you rank anything. GLPI is licensed under GPL-3.0-or-later, so review the license terms before you modify or redistribute it.

Wazuh Syscollector software records

The Wazuh Syscollector module collects hardware, operating system, installed software, network interfaces, open ports, running processes, services, users and groups, and Windows updates from each endpoint. It stores these records in the Wazuh indexer, where the dashboard can show inventory views and reports. For criticality work, these records show which applications actually run on an ePHI system and which ports and services they expose, so the analysis reflects reality rather than what the asset register says. Check that the agents cover every host in scope. Wazuh is licensed under GPL-2.0-only, so confirm the license obligations that apply to your deployment.

Bareos backup job scheduling

The Bareos Director schedules and supervises backup, restore, verify and archive jobs. It keeps a SQL catalog of the files it has backed up and can restore files selected from the current backup or from one taken before a given date and time. In the criticality analysis, the job definitions and catalog show which systems are backed up, how often, and how far back a restore can reach, which lets you set backup and recovery priorities for each tier. Confirm that the catalog itself is backed up and that restores are tested. Bareos is licensed under AGPL-3.0-only, which carries source disclosure duties if you modify it and offer it over a network.

restic integrity checks

restic's check command verifies the structural consistency of snapshots, trees and pack files. With the --read-data or --read-data-subset options, it reads pack files back to confirm that the stored backup data is unmodified. This matters for critical data because a backup that exists but cannot be read is not a recovery option. Schedule the deeper read checks for the highest-priority data sets, and record the results as evidence for the contingency plan. restic is licensed under BSD-2-Clause, a permissive license with a short attribution condition.

In-house work versus partner work on the criticality analysis

Your organization owns the criticality analysis in full. Someone with authority over operations must decide how each application and data set ranks, and business owners must confirm that the ranking matches how care, billing or other services actually depend on those systems. The Security Rule places the obligation on the covered entity or business associate, so no partner or auditor can take it over. Your team also owns the approvals that make the ranking binding on the rest of the contingency plan.

Ranking decisions: Leadership decides the order of applications and data sets and records the reasoning behind it.
Business owner input: Department heads describe downtime tolerance, workarounds and dependencies that technical staff may not see.
Approval and sign-off: Named officials approve the ranking, usually the security official together with the executives who accept operational risk.
Link to the risk analysis: Your team connects criticality ratings to the risk analysis and risk management plan so backup and recovery priorities follow the risks.
Periodic review: Staff revisit the ranking after system changes, new services or significant incidents.

Before engaging anyone, confirm that a named owner can explain every ranking to an assessor without relying on the partner who helped prepare it.

Where criticality analyses usually fall short and how to close each gap

A criticality analysis under 164.308(a)(7)(ii)(E) is only as good as the inventory, owner sign-off and backup alignment behind it. The gaps below recur in risk reviews and assessments, and each one breaks the link between what the organization ranks as critical and what its contingency plan can actually restore.

Inventory misses SaaS and shadow systems

The ranking is built from a list of servers and applications that IT maintains, so SaaS platforms, departmental spreadsheets and unsanctioned tools that hold ePHI never get scored. Check the inventory against identity provider application lists, expense records and cloud account billing, then record where each system stores ePHI. An asset tool such as GLPI can hold the list, with the GLPI Agent pushing data from managed endpoints, but discovery still depends on the people who know what the business uses.

Rankings lack business owner sign-off

IT often assigns criticality levels on its own, which means the clinical or billing owner who depends on a system never agreed that it sits at a given tier. Ask each system owner to confirm the tier, the acceptable downtime they described and the data loss they can tolerate, then record their name and date beside the decision. Without that sign-off, the ranking is hard to defend when an assessor asks who decided it.

Priorities do not match the backup catalog

A system ranked as critical may have no backup job, or only a nightly job that runs after a lower-tier system with a longer restore path. Compare the criticality ranking with the Bareos job definitions and catalog entries, confirming that each critical system has a schedule, a retention setting and a tested restore path. Where the catalog and the ranking disagree, one of them is wrong, and the contingency plan cannot rely on either until they match.

Undocumented decisions on unnecessary measures

Because this specification is addressable, an organization may decide that a measure such as an off-site or hot standby copy is not reasonable and appropriate for a given system. Many analyses skip the written reasoning, so the decision looks like an oversight. For each system ranked below the critical tier where a measure was skipped, record the risk, the reason it was judged unnecessary, and the equivalent alternative measure, then have the security official approve it.

No re-ranking after migrations

Cloud moves, platform replacements and mergers change where ePHI lives and which system depends on which, yet the criticality list often stays frozen at its original date. Tie the analysis to change management so that any migration, new integration or retired application triggers a review of its tier and of the backup and recovery steps around it. Schedule a periodic review as well, so drift is caught even when no change ticket is raised.

How much effort and outside help does the criticality analysis need?

How long does an applications and data criticality analysis take?

The duration depends mainly on how many applications and data stores hold ePHI and how well those systems are already documented. A single clinic with a few systems is a very different job from a health system with hundreds of interfaces, shared databases and cloud services. The rule sets no duration, so the timeline is a function of scope. Ask any provider to break the estimate into inventory, business owner interviews, ranking and documentation, and to tie each phase to the systems in scope.

What drives the effort of the criticality analysis?

Four factors usually move the effort most:

The size and currency of the application and data inventory, including shadow systems and SaaS tools that staff adopted without central review.
The number of dependencies between systems, since a ranking is only useful if it shows what breaks when a system is down.
How many business owners must be consulted, and how quickly they can answer.
Whether the results must feed directly into the backup, disaster recovery and emergency mode plans, which requires more detail than a list of priorities.

Count these before requesting a quote.

Can our own team complete the criticality analysis in-house?

Yes, a covered entity or business associate can perform the analysis itself, and the rule does not require outside help. The work is mostly coordination: an inventory built from asset records, interviews with clinical and operational owners, and a documented ranking that the security official and leadership approve. Teams that lack owners willing to commit time, or that have never mapped system dependencies, often find the analysis stalls. Inventory tooling such as GLPI can help assemble the asset list, but it does not decide criticality.

What does the criticality analysis need from business owners?

Business owners supply the knowledge the technical team cannot infer. They should state which processes depend on each application, how long a process can run without it, what manual workarounds exist, and which data must be available first after an event. Owners also confirm that the ePHI inventory is complete for their area. Schedule these sessions early, record decisions in writing and ask owners to sign off on their rankings, because the analysis is only defensible if the people running the business accept it.

Is hiring a consultant for the criticality analysis worth it?

A consultant is worth considering when the internal team lacks time, has no inventory of ePHI systems, or needs an outside perspective on how the ranking will be tested. A consultant does not take ownership of the decision. The covered entity remains responsible for the analysis, its results and the contingency plans built on it. DeployOpen plans, implements and documents systems and evidence for compliance readiness, but it does not issue audit reports or attestations. Ask whether the scope covers only the analysis or also the downstream backup and recovery work.

What should we ask for in a quote for this work?

A useful quote lists the scope in writing before work starts. Ask for the list of systems and data stores covered, the owner interviews included, the output format of the ranking, and the deliverables that feed the contingency plan. Confirm who signs off on the results, how changes are handled after delivery, and whether any support is included for later reviews. Request that fees and timelines be tied to the agreed scope, and ask what changes would trigger a revised quote.

Does the 2025 proposed rule change the criticality analysis requirement?

The January 2025 proposed rule would require restoring non-critical systems and data in line with the criticality analysis, but it is a proposal, not a final rule. As of October 2026, no final rule has been published, so the current requirement remains addressable. Organizations should document their analysis now in a form that can support tighter recovery priorities later. Confirm the status of the rulemaking in the Federal Register proposal and with counsel before changing commitments.

What will an auditor ask to see for the criticality analysis?

An assessor typically asks for the documented analysis, the inventory it was built from, the ranking criteria and the reasoning behind each placement. They will want to see that the ranking connects to the backup plan, disaster recovery plan and emergency mode operation plan, and that the analysis was reviewed when systems changed. Evidence of owner approval and dated revisions matters. Auditors test the record, so keep the documentation current and confirm with your assessor which formats they accept.

How DeployOpen works on this

DeployOpen plans, implements and documents self-hosted open-source platforms inside your own infrastructure, so the criticality analysis is tied to the systems that actually hold ePHI. We prepare the inventory, backup and recovery evidence that supports your analysis, while your organization owns the decisions about criticality and priority.

How we scope

Scope is agreed in writing before work starts, listing the systems, data stores and business units included in the criticality review.
Engagements are fixed-scope, so deliverables such as the inventory, criticality ranking and documentation are named in the written agreement.
We confirm with your security official who approves criticality ratings and which ratings feed the backup, disaster recovery and emergency mode plans.

How we build

We build an asset inventory of applications, servers and data stores that hold or process ePHI, using open-source tooling where your environment allows it.
We record data owners, dependencies and business functions for each application so ratings reflect how care and billing actually depend on them.
We configure backup jobs and integrity checks to match the priority tiers your organization assigns, then test restores against those tiers.

How we hand over

Handover includes the criticality register, the rationale for each rating and the mapping to backup and recovery priorities.
Documentation records how the analysis was performed, who approved it and when it should be revisited after major system changes.
We walk your team through the inventory tooling and restore evidence so your staff can maintain the analysis without us.

How we support

Ongoing support and upgrades are available as a retainer, covering inventory updates when new applications or data stores are added.
Retainers can include periodic restore tests and review of the criticality register against changes in systems or the risk analysis.
An independent auditor or assessor reviews the analysis and evidence. DeployOpen prepares the material but does not issue audit reports or attestations.