Integrity

HIPAA’s Integrity requirement (45 CFR § 164.312(c)(1)) means you must implement policies and procedures that prevent electronic protected health information (ePHI) from being improperly altered or destroyed across systems, workflows, and third parties. Operationally, that translates to controlled change, tamper-evident logging, backups and recovery testing, and strong access controls tied to data-handling processes. (45 CFR Parts 160, 162, 164)

Key takeaways:

• Integrity is about preventing unauthorized or accidental changes and deletion of ePHI, and being able to detect it when it happens. (45 CFR Parts 160, 162, 164)
• Auditors look for enforceable controls: change control, access governance, logging, backup/restore testing, and data validation checks mapped to where ePHI lives. (45 CFR Parts 160, 162, 164)
• Evidence matters as much as design: policies, system configurations, audit logs, restore test results, and third-party contract artifacts need to be retained and reviewable. (45 CFR Parts 160, 162, 164)

Integrity failures rarely start as “malicious tampering.” In practice, most integrity findings come from ordinary operations: a misconfigured interface overwriting patient records, an admin account used without traceable approval, a failed patch that corrupts data, or a third party export process that drops fields and reimports incomplete records. HIPAA treats these outcomes the same way: if ePHI can be improperly altered or destroyed without prevention and detection controls, you have an integrity gap.

This requirement is deceptively short, but it forces cross-functional execution. You need governance (clear rules and approvals), technical guardrails (access, logging, immutability where appropriate), and operational routines (restore tests, reconciliation, exception handling). It also extends beyond your own environment: any third party system that creates, receives, maintains, or transmits ePHI must operate under integrity-protecting procedures you can evidence.

This page translates 45 CFR § 164.312(c)(1) into a control set you can assign to owners, implement in common stacks (EHR, data warehouse, integrations, cloud storage), and defend during audit. (45 CFR Parts 160, 162, 164)

Regulatory text

Requirement (verbatim): “Implement policies and procedures to protect electronic protected health information from improper alteration or destruction.” (45 CFR Parts 160, 162, 164)

Operator interpretation: You must (1) define how ePHI is allowed to change, (2) restrict who/what can change it, (3) record and review changes so you can detect improper alteration or destruction, and (4) ensure you can recover accurate ePHI if something goes wrong. This applies to ePHI in applications, databases, file stores, backups, audit logs, and integration pipelines. (45 CFR Parts 160, 162, 164)

Plain-English interpretation of the integrity requirement

Integrity under the HIPAA Security Rule is about trustworthy data:

• No unauthorized edits: Only approved users, systems, and processes can modify ePHI. (45 CFR Parts 160, 162, 164)
• No silent corruption: If ePHI is changed or deleted improperly, you can detect it through logs, checks, reconciliation, or alerts. (45 CFR Parts 160, 162, 164)
• Recoverability of accurate records: If data is destroyed or overwritten, you can restore it to a known-good state and validate that it is complete. (45 CFR Parts 160, 162, 164)

A useful test: if an auditor asked you to prove a specific patient record was not inappropriately changed last month, could you show who changed it, why, what controls approved it, and how you would recover the prior version if needed?

Who it applies to (entity and operational context)

This applies to:

• Covered Entities that store or process ePHI in EHR/EMR platforms, billing systems, imaging, patient portals, and analytics environments. (45 CFR Parts 160, 162, 164)
• Business Associates that host, process, transmit, or support systems containing ePHI (cloud hosting, managed services, revenue cycle, transcription, analytics, integration platforms). (45 CFR Parts 160, 162, 164)

Operationally, integrity controls must be implemented wherever ePHI flows:

• Endpoints: workstations used for charting, admin consoles, shared service accounts.
• Applications: EHR, CRM/patient engagement tools, ticketing systems with attachments.
• Data layer: databases, object storage, file shares, data lakes/warehouses.
• Interfaces: HL7/FHIR engines, ETL jobs, batch exports/imports, APIs.
• Third parties: SaaS platforms, hosted environments, outsourced support teams. (45 CFR Parts 160, 162, 164)

What you actually need to do (step-by-step)

1) Map “systems of record” and “systems of change”

Create a simple inventory focused on integrity:

• Where ePHI is created (intake, scanning, device feeds).
• Where ePHI is edited (clinical documentation, coding, billing corrections).
• Where ePHI is transformed (interfaces, ETL, normalization, de-duplication).
• Where ePHI is archived/backed up (backup platforms, cold storage).
• Which third parties touch those steps. (45 CFR Parts 160, 162, 164)

Deliverable: an “ePHI integrity map” you can hand to IT ops, app owners, and audit.

2) Define what “improper alteration or destruction” means in your environment

Write a short integrity standard that answers:

• What changes require authorization (clinical note edits, demographics, insurance, diagnosis codes, audit log access).
• What deletions are allowed and how they’re performed (soft delete vs hard delete).
• Who can approve changes (data owner, compliance, clinical leadership).
• What is never allowed (editing audit logs, bypassing workflows, bulk updates without validation). (45 CFR Parts 160, 162, 164)

Keep it enforceable. If it can’t be implemented as a workflow, it will fail in practice.

3) Implement access controls that prevent unauthorized changes

Integrity collapses if write access is broad or untraceable. Minimum actions:

• Enforce least privilege for all accounts that can modify ePHI (users, admins, service accounts). (45 CFR Parts 160, 162, 164)
• Require unique IDs for users and prohibit shared admin accounts where possible; if a shared account must exist, wrap it in check-out/approval and strong logging. (45 CFR Parts 160, 162, 164)
• Add segregation of duties for high-risk actions (bulk updates, exports, schema changes, disabling logging). (45 CFR Parts 160, 162, 164)

4) Control and document change for systems that store or process ePHI

Put formal change control around:

• Application updates and patches
• Database schema changes
• Interface mapping changes (HL7/FHIR fields)
• ETL logic changes
• Backup configuration changes
• Logging/monitoring configuration changes (45 CFR Parts 160, 162, 164)

A workable pattern:

• Require a ticket/change record with business justification, risk note, approval, and rollback plan.
• Require peer review for interface/ETL changes that can rewrite fields at scale.
• For emergency changes, allow after-the-fact approval with tight timebound review and evidence capture.

5) Detect improper alteration or destruction with logging + review

You need tamper-evident records of change activity:

• Enable audit logs in applications that hold ePHI (record create/edit/delete events where available). (45 CFR Parts 160, 162, 164)
• Centralize logs where feasible and restrict who can edit or delete them.
• Define review triggers: privileged access, bulk edits, mass deletion, failed integrity checks, abnormal API activity.
• Document who reviews alerts and what constitutes an incident vs routine operations. (45 CFR Parts 160, 162, 164)

6) Protect against destruction: backups, retention, and restore validation

Backups are an integrity control only if restores work and data is validated:

• Ensure systems containing ePHI are backed up per documented procedures.
• Perform restore tests and verify data completeness and accuracy against expected records.
• Document retention and deletion rules, including how you prevent accidental destruction (guardrails on admin actions, approval for destructive operations). (45 CFR Parts 160, 162, 164)

7) Put third parties under the same integrity expectations

For third parties that handle ePHI:

• Contractually require integrity protections (change control, access governance, audit logging, backup/restore, incident reporting).
• Confirm their procedures during onboarding and periodically through due diligence.
• Ensure offboarding includes secure return/retention and controlled destruction consistent with your requirements. (45 CFR Parts 160, 162, 164)

If you use Daydream to run third-party due diligence, align questionnaires and evidence requests to these integrity control families so you can show coverage across your ePHI map without chasing one-off documents.

Required evidence and artifacts to retain

Auditors will ask for proof that controls operate. Retain:

• Integrity policy/standard and supporting procedures. (45 CFR Parts 160, 162, 164)
• ePHI system inventory with data flows and change points. (45 CFR Parts 160, 162, 164)
• Role-based access control (RBAC) documentation: role definitions, permission sets, privileged access process. (45 CFR Parts 160, 162, 164)
• Change management artifacts: change tickets, approvals, test evidence, rollback plans, emergency change reviews. (45 CFR Parts 160, 162, 164)
• Audit log configuration screenshots/exports, log retention settings, and sample log reviews with sign-off. (45 CFR Parts 160, 162, 164)
• Backup configuration, restore test records, and validation results. (45 CFR Parts 160, 162, 164)
• Third party contracts/BAAs and due diligence evidence tied to integrity controls. (45 CFR Parts 160, 162, 164)
• Incident records for integrity events (unauthorized change, corruption, deletion), including root cause and corrective actions. (45 CFR Parts 160, 162, 164)

Common exam/audit questions and hangups

Expect questions like:

• “Show me how you prevent unauthorized edits to ePHI in System X. Who can write, who can admin, and how is access approved?” (45 CFR Parts 160, 162, 164)
• “How do you detect inappropriate changes or deletions? Show audit logs for a sample patient record.” (45 CFR Parts 160, 162, 164)
• “How do you control changes to interfaces and ETL jobs that transform ePHI?” (45 CFR Parts 160, 162, 164)
• “Prove you can recover ePHI after destruction or corruption. Show the last restore test and validation.” (45 CFR Parts 160, 162, 164)
• “Which third parties can alter ePHI, and what controls do they have?” (45 CFR Parts 160, 162, 164)

Hangups that drive findings:

• Logs exist but aren’t reviewed, or review is informal and not evidenced.
• “Backups exist” but restore testing is missing or undocumented.
• Too many admins, shared accounts, or service accounts with broad write permissions.

Frequent implementation mistakes (and how to avoid them)

• Mistake: treating integrity as a backup-only problem. Fix: pair backups with access control, change control, and detection logging. (45 CFR Parts 160, 162, 164)
• Mistake: ignoring interfaces/ETL. Fix: put change control and validation checks around transformations; these pipelines can overwrite thousands of records quickly. (45 CFR Parts 160, 162, 164)
• Mistake: audit logs are editable or deletable by the same admins who manage the systems. Fix: restrict log access, separate duties, and centralize logs where possible. (45 CFR Parts 160, 162, 164)
• Mistake: third parties are “trusted” without evidence. Fix: collect specific artifacts (logging, backup, access governance) and tie them to your ePHI integrity map. (45 CFR Parts 160, 162, 164)
• Mistake: policies describe ideals, not operations. Fix: write procedures that match real tools, real teams, and real approval paths.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this page, so this guidance focuses on what the text requires and what auditors typically request as proof. Your practical risk exposure still follows a predictable pattern: integrity failures increase the chance of patient safety issues, billing errors, operational disruption, and reportable security incidents if the root cause is unauthorized access or malicious activity. (45 CFR Parts 160, 162, 164)

A practical execution plan (30/60/90-day)

Use staged phases without artificial precision. Assign one accountable owner per deliverable.

First 30 days (Immediate stabilization)

• Produce the ePHI integrity map: systems, data stores, interfaces, third parties. (45 CFR Parts 160, 162, 164)
• Publish an integrity standard: allowed changes, approvals, deletion rules, minimum logging expectations. (45 CFR Parts 160, 162, 164)
• Identify top integrity risks: shared accounts, unmanaged admins, missing logs, untested restores, uncontrolled interface changes.
• Start evidence capture: current access lists, current backup settings, current logging settings.

Days 31–60 (Control implementation and evidence)

• Tighten write/admin access for priority systems; formalize privileged access workflow. (45 CFR Parts 160, 162, 164)
• Stand up change control requirements for ePHI-impacting changes, including interfaces/ETL. (45 CFR Parts 160, 162, 164)
• Enable/standardize audit logs for create/edit/delete and privileged actions where supported; define review ownership and cadence. (45 CFR Parts 160, 162, 164)
• Run at least one restore test per priority system and document validation steps and results. (45 CFR Parts 160, 162, 164)
• Update third-party due diligence to collect integrity artifacts for high-impact providers.

Days 61–90 (Operationalization)

• Expand controls to remaining systems in the integrity map; close gaps found in restore tests and log reviews. (45 CFR Parts 160, 162, 164)
• Implement recurring log review and exception handling with ticketed evidence.
• Perform a tabletop for an integrity incident (corruption, unauthorized edits, destructive admin action) and record lessons learned.
• Build an audit-ready packet: policy, map, access governance, change records, logs, restore tests, third-party evidence. (45 CFR Parts 160, 162, 164)

Frequently Asked Questions

Does HIPAA Integrity require a specific technology like hashing or digital signatures?

The text requires policies and procedures that protect ePHI from improper alteration or destruction, but it does not prescribe a specific technology. Choose controls that prevent, detect, and recover from improper changes, and keep evidence that they operate. (45 CFR Parts 160, 162, 164)

What’s the fastest way to reduce integrity risk before an audit?

Lock down write/admin access on your highest-impact systems, enable audit logs for create/edit/delete and privileged actions, and document a restore test with validation. Those items produce clear, reviewable evidence quickly. (45 CFR Parts 160, 162, 164)

How should we handle integrity for ETL jobs and interfaces that transform ePHI?

Treat ETL and interface mappings as high-risk change surfaces: require change tickets, peer review, test evidence, and rollback plans. Add validation checks and keep logs that show what was transformed and by which job version. (45 CFR Parts 160, 162, 164)

Are backups alone sufficient to meet the integrity requirement?

Backups address destruction and recovery, but integrity also requires preventing and detecting improper alteration. Auditors often expect access controls, change control, and audit logging alongside backups and restore testing. (45 CFR Parts 160, 162, 164)

How do we prove integrity controls for a third party that hosts a HIPAA application?

Collect contract language that requires integrity protections, then request evidence such as logging practices, access governance procedures, and backup/restore processes tied to the services handling your ePHI. Track findings and remediation the same way you would for internal systems. (45 CFR Parts 160, 162, 164)

What evidence is most often missing during HIPAA Security Rule reviews?

Teams often have controls configured but cannot show operation: log review sign-offs, restore test results with validation, and documented approvals for high-risk changes. Build evidence capture into the workflow so it’s produced automatically as work happens. (45 CFR Parts 160, 162, 164)