What do HIPAA audit controls actually require?

Section 164.312(b) requires mechanisms that record and examine activity in systems containing ePHI. The rule is deliberately non-specific about how, which is why implementations range from a mutable database table to a cryptographically verifiable ledger.

HIPAA Audit Trails and Tamper-Evidence: What the Security Rule Really Requires (2026)

Q: What is tamper-evidence?

A property where any alteration of a record is detectable. Techniques include append-only storage, hash-chaining (each entry commits to the previous one), and digital signatures — so editing, reordering, or deleting an entry breaks verification.

Q: Isn't a database audit log good enough?

It records activity, but if a privileged user or DBA can update or delete rows, its integrity rests on trust rather than proof. In an investigation that gap becomes a finding: you can't rule out alteration. Tamper-evident designs remove the need to trust.

Audit controls and integrity are two of the Security Rule’s hardest technical safeguards — and the place software most often fails quietly. What “good” looks like.

Two of the HIPAA Security Rule’s technical safeguards do the quiet, load-bearing work of compliance: audit controls (45 CFR §164.312(b)) and integrity (§164.312(c)(1)). Nearly every system claims to satisfy them. Far fewer can prove it when an auditor or a breach forensic actually asks.

What the rule requires — and leaves open

Audit controls require “hardware, software, and/or procedural mechanisms that record and examine activity” in systems with ePHI. Integrity requires protecting ePHI from “improper alteration or destruction.” Notice what the rule does not say: how. That flexibility is why two systems can both check the box while offering wildly different assurance.

The gap: a log you can edit isn’t evidence

A conventional audit log is a database table. It records who did what — but with enough privilege, a user, an administrator, or a DBA can update or delete rows. Its integrity rests on trusting those people and that database. In an OCR audit or a breach investigation, that’s exactly the weak point: you can attest the log is complete, but you can’t rule out that it was altered. “We can’t prove it wasn’t tampered with” is how a control becomes a finding.

What tamper-evidence looks like

Tamper-evident means any alteration is detectable. Three techniques, usually combined:

Append-only storage — entries are added, never edited or deleted in place.
Hash-chaining — each entry includes a cryptographic digest of the previous entry, so the whole history is linked. Change one entry and every entry after it fails to verify.
Digital signatures — the chain is signed with a protected key, so no one can forge or rewrite it and re-sign.

Add offline verifiability — the ability to hand a third party a slice of the record they can check without your servers — and integrity stops being something you re-audit periodically and becomes something anyone can confirm on demand.

Weak vs. strong, side by side

Property	Weak implementation	Strong implementation
Storage	Editable table rows	Append-only log
Alteration	Possible with privilege, undetected	Breaks a hash chain — detectable
Trust model	Trust the admin & database	Verify with math
Proof to a third party	“Take our word for it”	Signed export, verifiable offline
Integrity check	Periodic review	On demand, byte-for-byte

What to look for in a system

Ask: Is the audit log append-only? Can an administrator alter or delete history? Is it cryptographically verifiable? Can you export a record whose completeness a third party can confirm independently? “Yes” to those is the difference between a log and evidence — a question worth putting on your vendor checklist.

ClaimZen’s ledger is append-only and hash-chained, Ed25519-signed with a key sealed at rest, and every case exports as a signed evidence packet that verifies offline against a BLAKE3 state root — so you prove integrity rather than assert it. See HIPAA compliance by design.

Frequently asked questions

What do HIPAA audit controls require?

Mechanisms that record and examine activity in systems with ePHI (§164.312(b)). The rule doesn’t specify how, so assurance varies widely.

What is tamper-evidence?

A property where any alteration is detectable — via append-only storage, hash-chaining, and signatures, so editing or deleting an entry breaks verification.

Isn’t a database audit log good enough?

It records activity, but if privileged users can change it, its integrity rests on trust. Tamper-evident designs let you prove it instead.

Sources

HHS, HIPAA Security Rule, audit controls 45 CFR §164.312(b) and integrity §164.312(c)(1).
HHS, person or entity authentication, 45 CFR §164.312(d).
NIST, SP 800-66 Rev. 2, Implementing the HIPAA Security Rule.
NIST, SP 800-92, Guide to Computer Security Log Management.
ClaimZen, HIPAA compliance by design and system architecture.

General information, not legal or compliance advice. HIPAA obligations depend on your organization, your data, and your contracts — consult your privacy/security officer and counsel.

HIPAA audit trails and tamper-evidence: what the Security Rule really requires