Integrity Controls

HIPAA’s integrity controls requirement means you must put technical safeguards in place so ePHI stays tamper-evident while it is electronically transmitted, and you can detect improper changes before the data is disposed of. Operationally, this is about protecting ePHI in motion with authenticated transport, message integrity checks, and monitoring that produces audit-ready proof. (45 CFR Parts 160, 162, 164)

Key takeaways:

• Protect ePHI in transit with authenticated encryption plus integrity validation, not encryption alone. (45 CFR Parts 160, 162, 164)
• Build detection and evidence: logs, alerts, and validation records that show you would catch modification. (45 CFR Parts 160, 162, 164)
• Apply controls to real transmission paths: APIs, interfaces, email, SFTP, EDI, portals, and cloud-to-cloud data flows. (45 CFR Parts 160, 162, 164)

“Integrity Controls” under the HIPAA Security Rule is easy to misunderstand because teams often treat it as “turn on TLS.” The actual requirement is narrower and stricter: you must implement security measures so electronically transmitted ePHI is not improperly modified without detection, and you maintain that protection until the information is disposed of. (45 CFR Parts 160, 162, 164)

For a Compliance Officer, CCO, or GRC lead, the fastest way to operationalize this is to (1) map where ePHI moves electronically, (2) decide what “integrity validation” looks like for each transmission method, (3) configure the technology so integrity failures are detectable and investigated, and (4) retain artifacts that prove the control works. This page gives you requirement-level implementation guidance you can hand to security engineering and third-party owners, then test in an audit.

You will see this control show up in multiple operational contexts: interfaces between EHR and labs, claims files to payers, patient portal messaging, remote access by workforce members, and third-party connections. The same logic applies in each case: authenticate endpoints, protect the data stream, and create evidence that tampering would be caught. (45 CFR Parts 160, 162, 164)

Regulatory text

Requirement (addressable implementation specification): “Implement security measures to ensure that electronically transmitted electronic protected health information is not improperly modified without detection until disposed of.” (45 CFR Parts 160, 162, 164)

What the operator must do

You must implement technical and operational controls that make unauthorized changes to ePHI in transit detectable. This typically includes authenticated transport (so you know who is on each end), cryptographic integrity protections (so the payload can’t be altered silently), and monitoring/logging (so integrity failures and suspicious transmission events are visible and investigated). The “until disposed of” clause means you should maintain tamper-evidence across the transmission lifecycle, including intermediate queues, interface engines, and transient storage that is part of transmission workflows. (45 CFR Parts 160, 162, 164)

Plain-English interpretation (what “integrity controls requirement” means)

For ePHI being sent electronically, you need controls that answer two audit questions:

1. Can an attacker or mistaken system change the transmitted ePHI without you knowing?
2. If something changes, do you detect it and can you prove you would detect it? (45 CFR Parts 160, 162, 164)

Encryption helps, but integrity controls focus on detecting modification. If you cannot show detection (via validation failures, alerts, logs, or reconciliation), you have not fully met the intent of this requirement. (45 CFR Parts 160, 162, 164)

Who it applies to (entity + operational context)

In-scope entities

• Covered Entities (health plans, health care clearinghouses, and most health care providers that transmit health information electronically in connection with covered transactions). (45 CFR Parts 160, 162, 164)
• Business Associates that create, receive, maintain, or transmit ePHI for a Covered Entity. (45 CFR Parts 160, 162, 164)

In-scope operational contexts (common transmission paths)

Treat these as your default inventory list for integrity controls:

• APIs and app integrations (EHR APIs, FHIR, custom APIs, webhooks).
• Interface engines and HL7 feeds (lab orders/results, ADT, referrals).
• File transfers (SFTP, managed file transfer, batch claims files, EDI).
• Email and secure messaging where ePHI is sent.
• Remote access sessions where ePHI is transmitted (VDI, VPN, browser-based portals).
• Cloud-to-cloud transfers (object storage replication, ETL pipelines, analytics exports).
• Third-party connections where the third party transmits ePHI to you or you transmit ePHI to them. (45 CFR Parts 160, 162, 164)

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

1) Build a transmission inventory for ePHI

Create a living list of every electronic path where ePHI leaves a system boundary or crosses a trust boundary:

• Source system, destination system
• Protocol/method (TLS API, SFTP, SMTP, HL7 over VPN, etc.)
• Whether data passes through intermediaries (integration platform, message broker, interface engine)
• Owner (system owner + business owner)
• Third parties involved (if any) (45 CFR Parts 160, 162, 164)

Operator note: If you can’t name the owners, audits stall here. Assign accountable owners per flow.

2) Define “integrity check” per transmission method

You need an integrity mechanism appropriate to the path. Examples that generally satisfy the intent when correctly configured:

• TLS with strong endpoint authentication for APIs and portals, paired with server certificate validation and modern cipher suites; confirm you are not allowing downgrade or invalid cert acceptance. (45 CFR Parts 160, 162, 164)
• SFTP/SSH with key-based authentication and controlled host keys for file transfer; maintain checksums and reconcile file receipt. (45 CFR Parts 160, 162, 164)
• Signed messages or payload checks (digital signatures, HMAC) when data may traverse intermediaries or be stored briefly before delivery, and you need end-to-end tamper evidence. (45 CFR Parts 160, 162, 164)
• Application-layer reconciliation for batch workflows (record counts, control totals, hash totals) to detect missing/altered records even if the channel is protected. (45 CFR Parts 160, 162, 164)

Write the decision down: for each flow, specify the exact integrity method and where verification occurs (sender, intermediary, receiver). (45 CFR Parts 160, 162, 164)

3) Implement detection: what happens when integrity fails

Integrity controls fail in the real world due to misconfigurations, expired certificates, mismatched keys, replay attempts, partial files, and interface errors. Your procedure must define:

• What constitutes an integrity event (signature mismatch, checksum mismatch, TLS validation failure, unexpected retransmission, duplicate message IDs).
• Where it is logged (system logs, SIEM, integration platform logs).
• How it is alerted (ticket, paging, SOC queue).
• Who triages and within what operational expectations your organization sets.
• Containment steps (pause feed, quarantine file, block sender, rotate keys/certs).
• Recovery steps (re-send, reconcile, verify no downstream corruption).
• Incident documentation expectations when ePHI integrity may have been impacted. (45 CFR Parts 160, 162, 164)

4) Address “until disposed of” across intermediate handling

Map transient handling that is still part of transmission:

• Message queues, retry buffers, dead-letter queues
• Temporary files in MFT tools
• Integration platform staging storage
• Client-side caches for portal uploads/downloads (45 CFR Parts 160, 162, 164)

Then confirm your integrity controls still apply (for example, signed payloads verified at the final receiver, or checksums validated after any staging step). Ensure disposal processes (retention limits, secure deletion where applicable) align with your transmission workflow so tamper evidence is not lost prematurely. (45 CFR Parts 160, 162, 164)

5) Extend controls to third parties through due diligence and contracts

Where a third party sends or receives ePHI:

• Require documented transmission methods and integrity protections (protocols, signing, key management, certificate management).
• Require logging and the ability to support investigations (what logs exist and how you can get them).
• Confirm subcontractor transmission paths, if applicable.
• Make integrity requirements explicit in security addenda and implementation guides, not buried in generic language. (45 CFR Parts 160, 162, 164)

If you use Daydream to manage third-party risk, treat “ePHI integrity in transit” as a standard due diligence control with required evidence fields (for example: supported protocols, message signing support, logging export capabilities, and incident response commitments). That turns a vague HIPAA requirement into a trackable control with review workflows.

6) Validate the control with testing you can show an auditor

Pick tests that prove detection, not just configuration:

• Attempt a controlled mismatch scenario in a non-production environment (alter a file, change a record count, present an invalid certificate) and confirm detection, alerting, and ticketing.
• Run periodic configuration reviews for certificate validation, SSH host key pinning, allowed protocols, and integration settings.
• Confirm that logs are retained and searchable for investigations. (45 CFR Parts 160, 162, 164)

Required evidence and artifacts to retain (audit-ready)

Maintain artifacts that connect the requirement to real systems and real detections:

• Transmission inventory of ePHI flows with owners and methods. (45 CFR Parts 160, 162, 164)
• Data flow diagrams or architecture diagrams for high-risk interfaces and third-party connections. (45 CFR Parts 160, 162, 164)
• Configuration standards for secure transmission (TLS requirements, SFTP requirements, certificate validation rules, approved protocols). (45 CFR Parts 160, 162, 164)
• System configurations/screenshots/exports showing enforcement (MFT settings, API gateway settings, interface engine settings). (45 CFR Parts 160, 162, 164)
• Integrity validation records (signed payload verification logs, checksum manifests, reconciliation reports, control totals). (45 CFR Parts 160, 162, 164)
• Monitoring evidence (SIEM rules, alert definitions, sample alerts, ticket records showing investigation and closure). (45 CFR Parts 160, 162, 164)
• Third-party documentation (security addenda, implementation specs, third-party attestations of transmission controls, escalation contacts). (45 CFR Parts 160, 162, 164)
• Test results from negative testing or tabletop scenarios that demonstrate detection and response. (45 CFR Parts 160, 162, 164)

Common exam/audit questions and hangups

Expect auditors to press on these points:

• “Show me all ways ePHI is transmitted electronically.” Missing a feed is a common failure mode. (45 CFR Parts 160, 162, 164)
• “How do you detect tampering?” If your answer is only “it’s encrypted,” you will get follow-ups about integrity validation and monitoring. (45 CFR Parts 160, 162, 164)
• “Where are the logs and how long are they retained?” Be ready to pull an example investigation trail. (45 CFR Parts 160, 162, 164)
• “How do you control third-party transmissions?” They will ask for contracts plus technical proof that the connection is protected and monitored. (45 CFR Parts 160, 162, 164)
• “What happens when integrity checks fail?” If the process is undefined, the control is not operational. (45 CFR Parts 160, 162, 164)

Frequent implementation mistakes (and how to avoid them)

Mistake 1: Treating integrity as “encryption only”

Fix: Add explicit integrity verification points (signature/HMAC verification, checksum/control totals, and monitoring that flags mismatches). (45 CFR Parts 160, 162, 164)

Mistake 2: Inventory stops at “major systems”

Teams forget “side doors” like manual file drops, ad hoc exports, or third-party support transfers. Fix: Build the inventory by interviewing revenue cycle, lab, imaging, and integration owners, then confirm via network/config discovery where possible. (45 CFR Parts 160, 162, 164)

Mistake 3: No evidence of detection

Controls exist but nobody can prove they work. Fix: Run periodic negative tests in a controlled environment and retain the alert/ticket artifacts. (45 CFR Parts 160, 162, 164)

Mistake 4: Weak endpoint authentication

Example: SFTP with shared credentials or APIs without strong client authentication where required. Fix: Standardize on keys/certs, manage rotation, and document exceptions with compensating controls. (45 CFR Parts 160, 162, 164)

Mistake 5: Third-party integrity is assumed

The contract says “HIPAA compliant,” but the implementation uses insecure or unverifiable paths. Fix: Require transmission implementation specs and validate the integration configuration during onboarding and periodically after changes. (45 CFR Parts 160, 162, 164)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not cite enforcement outcomes. Practically, integrity failures create patient safety risk (wrong data acted upon), billing/claims disputes, and breach response complexity if you cannot demonstrate whether ePHI was altered in transit. The operational goal is provable tamper-evidence across your highest-risk transmission paths. (45 CFR Parts 160, 162, 164)

Practical execution plan (30/60/90-day)

You asked for speed to operationalize; use this phased plan as a workback. Treat the phases as sequence, not a promise of elapsed time. (45 CFR Parts 160, 162, 164)

First 30 days (Immediate stabilization)

• Name an owner for integrity controls (Security + Integration Engineering + Compliance).
• Create the first version of the ePHI transmission inventory; capture third-party connections explicitly. (45 CFR Parts 160, 162, 164)
• Set a minimum secure transmission standard for common methods (API, SFTP, email) and document allowed exceptions with approval. (45 CFR Parts 160, 162, 164)
• Identify the highest-risk flows (external, high volume, clinical impact) and confirm they have integrity validation plus logs. (45 CFR Parts 160, 162, 164)

Day 60 (Operationalize detection + evidence)

• Implement or tune logging and alerting for integrity failures across priority systems (API gateway, MFT, interface engine, email security tools). (45 CFR Parts 160, 162, 164)
• Document the integrity failure playbook: triage, containment, recovery, escalation.
• Start collecting proof artifacts (sample logs, sample tickets, reconciliation reports). (45 CFR Parts 160, 162, 164)
• For third parties, update onboarding checklists to require transmission specs and evidence; track in Daydream so owners can’t close onboarding without artifacts. (45 CFR Parts 160, 162, 164)

Day 90 (Prove it works and expand coverage)

• Run at least one controlled integrity-failure test per major transmission type in a non-production setting; retain tickets and results. (45 CFR Parts 160, 162, 164)
• Expand inventory coverage to lower-volume and “shadow” feeds; close gaps or record compensating controls.
• Build a recurring review cadence for certificates/keys, protocol configurations, and third-party integration changes.
• Package an audit-ready binder: inventory, standards, configs, monitoring, tickets, test results. (45 CFR Parts 160, 162, 164)

Frequently Asked Questions

Does TLS automatically satisfy the integrity controls requirement?

TLS can provide integrity protection for the transport session, but auditors often expect you to show endpoint authentication, certificate validation, and evidence that integrity failures would be detected and investigated. Build monitoring and retain logs/tickets that prove detection. (45 CFR Parts 160, 162, 164)

What counts as “electronically transmitted” ePHI for this control?

Any ePHI sent over electronic communications networks or interfaces is in scope, including APIs, file transfers, portal access, and third-party connections. If ePHI crosses a trust boundary, treat it as a transmission flow that needs integrity controls. (45 CFR Parts 160, 162, 164)

We use an interface engine. Where should integrity validation happen?

Define whether validation happens end-to-end (sender signs, receiver verifies) or at each hop. If the interface engine stages or transforms messages, document how you prevent undetected modification across that staging and how you would detect integrity failures. (45 CFR Parts 160, 162, 164)

How do we operationalize integrity controls for batch files (claims, eligibility, reports)?

Pair secure transport (for example, SFTP with strong authentication) with content validation like checksums, control totals, and reconciliation reports. Keep the manifests and reconciliation outputs as artifacts that show you would detect alteration. (45 CFR Parts 160, 162, 164)

What evidence do auditors ask for most often?

A complete transmission inventory, proof of secure configuration for major channels, and monitoring artifacts that show integrity failures generate alerts and tickets. If you cannot produce logs for a sample transmission, expect a finding. (45 CFR Parts 160, 162, 164)

How should we handle integrity controls with third parties that “only receive” ePHI from us?

Treat them as in scope because transmission is still occurring. Require their transmission method documentation, confirm mutual authentication where appropriate, and ensure you can obtain logs or incident support if integrity is questioned. Track this in your third-party risk workflow so evidence doesn’t live in email threads. (45 CFR Parts 160, 162, 164)