164.312(c)(1) Integrity: requirements and evidence

What 164.312(c)(1) integrity asks for and why it is hard to prove

When an auditor or customer asks whether stored ePHI is protected from unauthorized change or loss, the answer under 45 CFR 164.312(c)(1) is that you need written policies and procedures, backed by working technical measures, that keep ePHI from being improperly altered or destroyed. The standard is short, but the proof is not. Under 45 CFR 164.304, integrity means data has not been altered or destroyed in an unauthorized manner, so the question is whether your systems would notice and show unauthorized change, not whether a configuration exists on a given day. The only implementation specification under this standard is addressable: a mechanism to authenticate ePHI. Addressable means you must decide whether such a mechanism is reasonable and appropriate for your environment, and if you decide it is not, document why and adopt an equivalent measure where one is reasonable.

Integrity is hard to prove because it is a property shown over time. NIST SP 800-66 Rev. 2 treats this standard as a cycle: identify the users who are authorized to change ePHI, identify the sources that could intercept or modify it, set an integrity policy, implement procedures, implement an authentication mechanism, and monitor whether the process works. An assessor will ask for the baseline of your ePHI stores, the alerts raised when files or databases change, how those alerts were reviewed, and what happened next. A single hashing setting or encrypted volume does not answer that. Confirm with your own assessor which evidence they expect, such as change logs, integrity check reports, restore test records and review sign-offs, and build the collection of that evidence into the design from the start.

The practical decision is which stored ePHI needs an authentication mechanism and how you will prove it stays unchanged. Start by listing the locations where ePHI rests, including databases, file shares, backup repositories and object storage, and record who may write to each. Then decide whether checksums, file integrity monitoring or signed records are reasonable for each location, and write down the reasoning if you choose a different approach. Open-source tools such as Wazuh can alert on unexpected changes to monitored files, and restic can verify backup data by reading pack files back, but each tool produces evidence only if someone reviews its output and keeps the record.

Which systems, data and third parties fall under integrity controls

Integrity controls under 164.312(c)(1) apply wherever ePHI is stored, copied or restored, not only in the primary application. The decisions below determine how many systems, copies and relationships your integrity evidence must cover, and they are the first place where effort grows or shrinks.

Production databases and file stores

Start with the systems where ePHI is written and changed every day: relational databases, document stores, and file shares or object storage holding clinical documents, images and exports. Each of these needs a defined way to detect unauthorized alteration or destruction. Check which tables, buckets and directories hold ePHI, because scoping by application alone often misses exports and shared folders. Effort rises with the number of distinct stores and the number of people able to write to them directly.

Backups and snapshots

Backups are copies of ePHI, so a corrupted or tampered backup can defeat recovery even when production data is intact. Confirm which backup jobs, retention sets and snapshot policies contain ePHI, and whether your tool can verify stored data against its catalog or repository structure. Verification runs and their logs become part of the evidence. Effort depends on how many backup targets exist and how often verification is scheduled and reviewed.

Kubernetes clusters and persistent volumes

Containers are rebuilt often, so integrity depends on the persistent volumes and the cluster resources that define workloads. Inventory which namespaces, persistent volume claims and configuration objects touch ePHI, and decide how cluster resource backups are restored after loss. A restore into another cluster is also an integrity event that needs to be checked. Effort grows with the number of clusters, environments and volumes that carry ePHI.

Endpoints and servers that touch ePHI

Workstations, application servers and jump hosts can alter ePHI locally before it reaches a central system, and malware often targets them first. Decide which endpoints access ePHI and whether file integrity monitoring will baseline their critical directories and configuration files. Alert routing matters as much as coverage, because an alert nobody reviews provides no evidence. Effort scales with the number of hosts, the change rate of monitored paths and the staff who review alerts.

Vendors that store or process ePHI

A vendor that hosts or processes ePHI for you holds part of your integrity obligation, and its controls become your evidence gap if they are missing. Obtain each vendor's written description of how it detects alteration, restores data and protects backups, and confirm that a business associate agreement covers these duties. Ask what the vendor can show you on request. Effort depends on how many vendors touch ePHI and how much of their evidence you can obtain without custom requests.

Transfers between systems

Data changes in transit between applications, interfaces and external parties, and that movement is covered by integrity controls as well. Identify interfaces, file transfers and API calls that move ePHI, and confirm which of them can detect modification before the data is stored. Transit protections are assessed separately under transmission security, so record where the two standards overlap. Effort depends on the number of interfaces and on how many are maintained by third parties.

How an assessor tests the integrity standard

This table sets out how an assessor typically tests 164.312(c)(1) across its policy, authentication mechanism, change monitoring and backup verification components, and what evidence supports each. Read it as a checklist of what the entity must be able to show, since HHS does not endorse private certifications and the outcome rests on the entity's own documentation.

Test area	What the assessor looks for	Evidence requested	Common findings
Written policy	A documented policy and procedures that protect ePHI from improper alteration or destruction, approved and assigned to an owner	Current integrity policy, version history, approval record, and the procedures that implement it	Policy exists but names no owner, is not tied to the risk analysis, or was never reviewed after system changes
Authentication mechanism (addressable)	Either an implemented mechanism such as checksums, digital signatures or hashing, or a documented reason it is not reasonable and appropriate plus an equivalent alternative	Configuration of the mechanism, sample verification outputs, or the documented assessment and alternative measure	No decision recorded for an addressable specification, or a mechanism configured but never run against stored ePHI
Monitoring of change	Alerts on creation, modification or deletion of ePHI files and system components, and evidence that a person reviews them	Monitored file scope, baseline records, alert logs, and tickets showing review and follow-up of unexpected changes	Monitoring deployed but alerts go unreviewed, or monitored scope omits systems where ePHI is stored
Backup verification	Evidence that backups of ePHI are checked for integrity so stored copies are known to be unmodified before restore	Scheduled integrity check results, restore test records, and the documented frequency and scope of checks	Backups taken but never verified, or verification covers only metadata and not the stored data
Monitoring the process	Periodic review that the integrity process is working and is updated after incidents or system changes	Review records, metrics on alerts and exceptions, and corrective action logs	No periodic review, so the process drifts from the risk analysis after infrastructure changes
Consistency with risk analysis	Integrity controls are traceable to identified threats to ePHI in the entity's risk analysis	Risk analysis entries referencing unauthorized alteration or destruction and the controls mapped to them	Risk analysis is silent on integrity, so the controls appear unjustified to the assessor

How to implement integrity controls step by step

The sequence below follows the key activities NIST SP 800-66 Rev. 2 lists for this standard, moving from knowing who and what could change ePHI to a monitored, reviewed process that shows stored data has not been altered or destroyed without authorization.

Identify authorized users and systems
Start by listing who is allowed to create, change or delete ePHI and which systems, applications and service accounts touch it. The privacy or security lead works with system owners to build this list, and the output is a named inventory of authorized users, roles and service identities. You know the step is done when every ePHI repository has an owner and every account that can write to it appears on the list.
Identify unauthorized sources of change
Next, map the ways ePHI could be altered or destroyed without permission. Typical sources include compromised credentials, malware or ransomware, misconfigured storage, insiders acting outside their role, and software updates that modify data. Security engineering runs this review against the system inventory, and the output is a threat list tied to each repository. The step closes when each listed source has a named control or a documented reason it is accepted.
Write the integrity policy and requirements
Document the rules that apply to ePHI integrity: which data must be protected from alteration, how changes are authorized, who reviews integrity alerts, and how destroyed or corrupted data is reported and restored. The security official approves the policy, and the output is a signed-off document that maps each requirement to a system. Because the Security Rule requires written policies and procedures, retain the approved version with its effective date and revision history.
Implement integrity procedures
Translate the policy into day-to-day procedures for system owners and administrators. These cover change approval for ePHI stores, restricted write permissions, separation of duties for data changes, and backup verification before restores. Operations teams carry out the work, and the output is a set of runbooks with named owners. You know the step is complete when a sample change to an ePHI system can be traced from request to approval to completion in the records.
Implement a mechanism to authenticate ePHI
Because the addressable specification calls for a mechanism to authenticate ePHI, choose one that fits each repository, such as file integrity monitoring with checksums, backup verification or application-level hashing. Your risk analysis should record whether the mechanism is reasonable and appropriate, and if you choose an alternative, document why. Wazuh's file integrity monitoring records a baseline of checksums and attributes for monitored paths and raises alerts when files are created, modified or deleted. Bareos Verify jobs compare files against cataloged attributes, and restic check with --read-data reads pack files back to confirm stored backup data is unmodified. The output is a baseline record for each monitored path and a documented decision for each mechanism.
Monitor and review integrity alerts
Run the mechanism on a schedule or in real time, and route alerts to a person who can judge whether a change was authorized. Confirm that alerts identify what changed, when and by whom, and test that a deliberate change to a monitored file produces an alert. The output is an alert review log showing each alert, the reviewer, the decision and any follow-up. Reviews should also check that baselines are refreshed only after approved changes, so that an unauthorized change cannot be absorbed into the baseline.
Test restores and refresh the process
Periodically restore ePHI from backup into a test environment and compare the result with the source records. Include backup platforms such as Velero for Kubernetes resources and persistent volumes, and confirm the restored data matches the expected baseline. Feed the findings back into the inventory, threat list and policy. The output is a dated test record and a list of changes made to the process. Ask your implementation partner or assessor to confirm the test frequency that suits your risk analysis, since the researched facts do not set one.

What meeting the integrity standard costs in money and effort

This table breaks the cost of meeting 164.312(c)(1) into components, showing who is paid, whether each cost is one-time or recurring, and what moves it up or down. No supplied fact gives a price or duration, so the table names what to request in a written quote instead of estimating figures.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Tooling and licenses	Software vendor, if a commercial file integrity or backup tool is chosen	Usually recurring (subscription or support)	Number of endpoints and ePHI systems in scope. Open-source options such as Wazuh (GPL-2.0-only), Bareos (AGPL-3.0-only) and restic (BSD-2-Clause) remove license fees, though support contracts may still apply
Engineering to deploy and tune monitoring	Internal staff or implementation partner, under a fixed-scope agreement	One-time, with periodic tuning	Number of monitored paths, noise from legitimate changes, and how closely baselines match approved configurations
Backup verification setup	Internal staff or implementation partner	One-time build, then recurring test runs	Data volume, how often restores are tested, and whether read-data checks (for example restic --read-data) are scheduled across the full repository or a subset
Evidence upkeep (alert review, log retention)	Internal security or operations staff	Recurring	Alert volume, who reviews integrity alerts and how quickly, and how long integrity logs must be retained under the organization's documentation policy
Change approval and reconciliation	Internal change management and system owners	Recurring	Frequency of planned changes to ePHI systems. Each alert must be matched to an approved change or investigated
External testing or review	Independent testers or assessors, not DeployOpen for audit opinions	Recurring or per engagement	Scope of systems tested, whether testing covers data tampering scenarios, and how often the risk analysis changes
Auditor or assessor sampling	Independent assessor or OCR-facing evidence review	Per assessment	Number of systems sampled, quality of documented integrity policy, and how well alerts and backup test results are organized
Documenting the addressable decision	Compliance lead or security official	One-time, updated on change	Whether the organization documents why a mechanism is reasonable, or why an equivalent alternative is used, under 164.306(d)

Which open-source tools produce integrity evidence

Open-source tools can produce the records that show stored ePHI has not been altered or destroyed, but they do not make an organization compliant on their own. Under 164.312(c)(1), the organization owns the policies, the decisions about what counts as an improper change, and the people who review what the tools report. The tools supply the evidence that those policies are working. Before relying on any of them, confirm each tool's fit in your own environment, including which systems hold ePHI, who can change them, and how alerts reach a responsible person. Wazuh's file integrity monitoring (GPL-2.0-only) is the most direct fit for detecting changes to ePHI-related files and configurations. It records a baseline of checksums and attributes for the files and directories you define, then alerts when a user or process creates, modifies or deletes a monitored item. Alerts can run on a schedule or in real time and record how and when a change occurred and who made it. Confirm which paths you monitor, how the baseline is protected from tampering, and whether alerts are reviewed and retained for as long as your documentation policy requires.

Bareos (AGPL-3.0-only) covers a different question: whether backed-up data still matches what was written. Its Verify jobs compare files on a storage or client against attributes cataloged at backup time, which gives a Tripwire-like check for changes after a break-in. restic (BSD-2-Clause) check verifies the structural consistency of snapshots, trees and pack files, and with --read-data or --read-data-subset it reads pack files back to confirm the stored data is unmodified. Velero (Apache-2.0) backs up Kubernetes cluster resources and persistent volumes so they can be restored after loss or into another cluster, whether it runs with a cloud provider or on premises. Restore tests, not just backup jobs, are what show that the recovery path works. Confirm which of these tools can read your storage, how often verification runs, and whether the results are retained alongside your risk analysis.

Evidence that passes and how to keep it current

An assessor testing 164.312(c)(1) Integrity looks for a written policy, a defined set of protected systems, proof that changes are detected, and proof that detected changes were reviewed and resolved. The cards below list the artifacts that show this, with a refresh cadence for each between audits. The organization owns these records; an implementation partner can prepare the tooling and the templates, but the review decisions remain the organization's.

Signed integrity policy

This is the written policy and procedures the standard requires to protect ePHI from improper alteration or destruction. It should name the systems in scope, the people accountable for reviewing integrity alerts, the rules for authorized changes, and how the mechanism to authenticate ePHI is used. Check that an accountable owner has approved it and that its wording matches what the tools actually do. Review it at least once a year and after any material change to the environment, such as a new EHR, a cloud migration or a new backup target.

Monitored-path inventory

This is the list of files, directories, databases and backup repositories that hold or protect ePHI and are watched for changes. An assessor will compare it against the system inventory from the risk analysis, so gaps show up quickly. Record the reason each path is monitored and who owns it. Refresh the inventory whenever a system is added, retired or moved, and reconcile it against the asset list at least quarterly so that new ePHI stores are not left unwatched.

Baseline and alert records

A baseline captures checksums and attributes of each monitored item, and alerts record when a user or process creates, modifies or deletes it. Wazuh file integrity monitoring, for example, can run on a schedule or in real time and record how, when and by whom a file changed. Keep baseline snapshots and exported alert logs, and confirm that they are retained and cannot be altered by the administrators they monitor. Confirm the retention period with your own policy and the tool documentation.

Alert review tickets

Each alert that matters needs a ticket showing who received it, who examined the change, whether it was authorized, and how it was resolved. Assessors use these tickets to test whether monitoring leads to action rather than sitting unread. Require a named reviewer and a closure reason, and escalate unexplained changes to incident response. Sample tickets monthly, and confirm that the reviewer is not the same person who made the change being reviewed.

Backup verification reports

Verification reports show that stored backup data has not been modified or corrupted. Bareos Verify jobs compare files with previously cataloged attributes, and restic check can read pack files back with the read-data options to confirm the stored data is intact. Keep the job logs and the command output with dates and repository identifiers. Run verification on a schedule that matches your recovery objectives and review failures the same day they occur, because a failed check is a possible integrity event.

Restore test records

A verified backup is only useful if it restores. Restore test records show the date, the scope, the source backup, the target environment, the person who ran the test, and whether the restored ePHI matched expected results. For Kubernetes workloads, Velero can restore cluster resources and persistent volumes into the same or another cluster, and those restores should be recorded the same way. Schedule restore tests at least once a year for each critical system, and after any change to the backup tooling or storage.

Who does what: your team, a partner and the auditor

Your organization owns the integrity requirement under 45 CFR 164.312(c)(1). Leadership and the HIPAA security official decide which systems hold ePHI, what counts as improper alteration or destruction for each, and whether the addressable mechanism to authenticate ePHI is reasonable and appropriate. If it is not adopted, your risk analysis must document why and what equivalent measure you chose instead. Those decisions cannot be delegated to a vendor or consultant.

Policy and scope: Approve the integrity policy, name the systems in scope and assign an owner for each.
Authorized users and sources: Maintain the list of people and processes allowed to change ePHI, and the sources that could intercept or modify it.
Alert handling: Review integrity alerts, decide what is an incident and route confirmed events into incident response.
Periodic review: Confirm that monitoring and backup verification still run as designed and that exceptions are recorded.
Documentation: Keep the written policies and evidence for the retention period your compliance program requires.

Check that each in-scope system has a named owner who can explain its integrity controls to an assessor without help from the vendor.

Where integrity controls usually fail an assessment

Integrity controls under 164.312(c)(1) tend to fail on coverage, follow-through and governance rather than on the tools themselves. The cards below cover the gaps assessors most often find when they ask an organization to show that stored ePHI has not been altered or destroyed without authorization.

Monitored paths miss where ePHI lives

Integrity monitoring is only as good as its scope. Teams often watch operating system directories and miss the application data stores, database volumes, file shares and object buckets where ePHI actually sits. Wazuh file integrity monitoring records a baseline of checksums and attributes for the directories you configure, so anything outside that list is invisible to it. Map every ePHI location from your risk analysis, then confirm each one appears in the monitoring configuration and that the baseline covers it.

Alerts with no recorded review

An integrity alert that no one reviews does not show that the entity protects ePHI. Assessors ask who received each alert, what was decided, and where that decision is written down. Set a named owner for integrity alerts, define how each one is triaged and closed, and keep the ticket or log entry that proves the review happened. Confirm that alert routing still works after staff changes, since an unread queue looks the same as no monitoring at all.

Backups never verified by restore

Backups protect integrity only if the stored copies can be shown to be unmodified. Many teams run backup jobs for years without testing them. Bareos Verify jobs compare files against previously cataloged attributes, and restic check with --read-data or --read-data-subset reads pack files back to confirm stored data is intact. Schedule these checks, keep their output, and record a periodic test restore of ePHI so the evidence covers both integrity and recoverability.

Shared administrator accounts blur accountability

When several engineers share one administrator login, a changed file or altered record cannot be tied to a person. This weakens every integrity claim the organization makes. Assign individual administrative accounts, restrict the shared credential to documented emergency use, and make sure monitoring records the acting user. Check that changes made through service accounts or automation are attributed to the job or person that triggered them.

Integrity policy never approved

The standard requires policies and procedures, so a draft that no one signed is an open finding. The policy should name the ePHI systems in scope, the authorized users who may change them, the mechanisms used to detect alteration or destruction, and the review cycle. Obtain written approval from the security official and leadership, store the approved version with its date, and show that the procedures in the policy match what the systems actually do.

What buyers ask before they bring in help on integrity controls

What drives the cost of implementing integrity controls for ePHI?

The main cost drivers are how many systems hold ePHI, how many of them need file integrity monitoring or backup verification, and how much of the work is new versus adjusting existing tooling. Cost is split between the organization's own staff time, any implementation partner fees for the agreed scope, and the infrastructure that runs the tools. Some costs are one-time, such as design, deployment and initial baselining. Others recur, such as monitoring, alert review, backup verification runs and periodic reviews of the integrity policy. Ask any partner for a written scope that lists each system, each mechanism and each deliverable, because the quote follows from that scope.

How long does integrity control work take in our environment?

The duration depends on the size and age of the environment, how documented the ePHI systems already are, and how many teams must approve changes. Work usually follows a sequence: confirm which systems hold ePHI, agree which files and data sets need protection, set baselines, deploy monitoring and verification jobs, then test alerts and document the results. No fixed timeline applies to every organization, so ask the partner to show the phases in the written scope and to name which of them depend on your team's availability. Your own risk analysis under 45 CFR 164.308 will also shape how far the work reaches.

What does our team need to provide during the engagement?

Your team needs to supply access to the systems in scope, an inventory of where ePHI is stored, named owners for each system, and decisions on which changes are authorized. Someone must also own the alerts that integrity monitoring produces, because a control that raises alerts nobody reviews does not meet the standard's intent. Expect to provide review time for the baseline, sign-off on the integrity policy and procedures, and access to backup repositories for verification tests. Confirm these items in writing before work starts so that delays are visible early.

Can we implement integrity controls ourselves with open-source tools?

Yes, many organizations do. Wazuh's file integrity monitoring records a baseline of checksums and attributes for monitored files and directories and alerts when a user or process creates, modifies or deletes a monitored file. Bareos Verify jobs compare files against previously cataloged attributes, and restic check with --read-data or --read-data-subset reads pack files back to confirm stored backup data is unmodified. Doing this in-house requires skills in deployment, tuning, alert triage and documentation. Confirm each tool's current capabilities and licensing terms in its own documentation before you rely on them, since the features described here are the ones the vendors document.

Can an outside firm certify that we comply with the HIPAA Security Rule?

No. HHS states that no Security Rule standard requires an entity to certify compliance, and that HHS does not endorse or recognize private organizations' certifications. Such a certification also does not prevent HHS from later finding a violation. An independent assessor can test your controls and report findings, and a partner can prepare systems and evidence, but neither issues a HIPAA certificate that HHS recognizes. Treat any firm offering a HIPAA certification with caution and ask it to explain what HHS recognizes. Your organization owns its compliance position.

What should we ask for in a quote for integrity control work?

Ask for a written scope that lists the systems, data sets and mechanisms covered, along with the deliverables and the acceptance criteria for each one. Request a breakdown of one-time setup effort versus recurring support, and confirm what is included in ongoing monitoring and verification. Ask which items your team must provide, which assumptions the estimate depends on, and how changes to scope are priced. Also confirm who documents the work, who owns the evidence, and whether the partner will prepare evidence for an independent assessor. DeployOpen plans and implements these items under fixed scopes agreed in writing before work starts.

What evidence will show our integrity controls work?

Assessors typically look for a written integrity policy and procedures, a documented inventory of ePHI systems, baseline records for monitored files, alert logs with documented review, and records of backup verification runs. They also test whether alerts are investigated and whether changes are matched to authorized requests. Keep dated outputs from monitoring and verification jobs, and record who reviewed each alert and what action followed. Ask your assessor to confirm which evidence format they accept before the work begins, since expectations vary between organizations and between engagements.

How DeployOpen scopes and prepares integrity evidence

DeployOpen works on 164.312(c)(1) Integrity by building and documenting the integrity mechanisms inside your own infrastructure, so your team can show how stored ePHI is protected from improper alteration or destruction. Your organization owns the policies and the compliance decision, and an independent assessor or auditor issues any report.

How we scope

Engagements are fixed-scope, with the systems holding ePHI and their integrity controls named in writing before work starts.
The written scope lists which hosts, file paths, backup targets and Kubernetes clusters fall under integrity monitoring.
Deliverables, timelines and responsibilities for policy, mechanism and evidence work are agreed in the same written scope.

How we build

We deploy file integrity monitoring such as Wazuh against agreed directories, recording a baseline of checksums and attributes.
We configure scheduled or real-time alerting for creation, modification or deletion of monitored ePHI files, with user and process detail.
We set up backup verification with tools such as Bareos Verify jobs and restic check, including data reads of pack files, in your environment.

How we hand over

We document the integrity policy, the procedures and the authentication mechanism your team operates day to day.
We deliver a mapping from each key activity in NIST SP 800-66 Rev. 2 for this standard to the configured tool, owner and evidence source.
We provide sample alert records, verification job logs and configuration exports that your assessor can review directly.

How we support

Ongoing support, upgrades and monitoring tuning are available as a retainer after handover, if your organization wants them.
We can review alert trends and verification results with your security official on a schedule agreed in writing.
Before any assessment, confirm with your auditor or assessor which evidence formats and retention periods they expect for integrity records.