What a HIPAA-compliant file-sharing audit trail actually contains

If you run compliance for a covered entity or business associate, you've already seen the 2027 HIPAA Security Rule update language. The NPRM moves "audit controls" from a flexible, addressable specification toward a much more prescriptive one — and the field-level expectations under §164.312(b) are what your auditor is going to ask about next time. This is a checklist post, not a "why audit logs matter" post.

We've sat through enough HIPAA audits with healthcare customers — and watched enough sharing tools fail the same questions — to know which specific log fields trip people up. Here's the field-by-field map, why each one exists in the rule, and what "good" actually looks like in a file-sharing tool that touches ePHI.

What §164.312(b) actually says — and what's changing

The current rule is short: covered entities must "implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information." Addressable. Vague on field-level requirements.

The 2025 NPRM, if finalized as drafted (likely 2027 compliance date), tightens three things:

1. Audit logging is proposed to become a required specification, not addressable. Covered entities would no longer document a "reasonable and appropriate" reason for not implementing it.
2. Specific event categories are enumerated. The proposed rule names access attempts (successful and failed), modifications, disclosures, and deletions as distinct capture obligations.
3. Tamper-evidence becomes an explicit expectation. The NPRM language adds requirements for mechanisms to detect unauthorized modification of audit records — language no prior version of the Security Rule contained.

That last one is the change that breaks most file-sharing tools today. A log file that can be edited by anyone with database access — or by the vendor themselves — is not an audit trail under the updated reading. It's a log. An audit trail has integrity. More on that below.

If your file-sharing tool exports a CSV from a mutable database table and calls it an audit log, you have until 2027 to fix that. Your auditor will too.

The eight fields a HIPAA-aligned audit row must contain

Here's the field-by-field checklist. If a file-sharing tool can't show you all eight per event, it's going to create a gap in your audit-controls program.

1. Event type — what happened, in a closed enum

Not free text. Closed enum. The auditor needs to filter to "every PHI disclosure event in Q3" without parsing prose. Required event types for a sharing tool:

• Share created (sender uploaded a payload)
• Share viewed (recipient opened the link)
• Share downloaded (recipient pulled bytes)
• Share modified (sender changed expiry, recipient list, or content after send)
• Share revoked (sender pulled it back early)
• Share expired (time, view, or download cap hit)
• Authentication failure (wrong passphrase, wrong identity)

What goes wrong: tools that log "activity" as a single category. Your auditor wants to see the specific verb. "User accessed file" is not enough — was it a view, a download, or a metadata read?

2. Actor identity — who did it, deterministically

The acting principal must be identified with enough fidelity to tie back to a specific person, not "user-1234" or "anonymous." For internal users that's a verified email and a stable user ID. For external recipients (the bidder in an M&A data room, the outside counsel reviewing a draft, the patient's family member receiving discharge instructions) it's the verified email of the recipient — verified through an out-of-band magic link, not a free-text field the sender typed.

What goes wrong: tools that record "Anonymous recipient downloaded file" because the link was sent without identity binding. That row is forensically useless. If you can't tell which of the four people on the To: line opened it, you can't honor §164.528 disclosure-accounting requests.

3. Timestamp — UTC, monotonic, and not editable

Sounds obvious. Isn't. The timestamp must be captured server-side at the moment the event commits, not pulled from a client clock. It must be stored in UTC (not localized). And it must be ordered such that two events that happened a millisecond apart can be told apart.

What goes wrong: tools that timestamp using the recipient's browser clock. A recipient with a wrong clock — or a malicious recipient who set their clock back — corrupts your forensic ordering.

4. Source IP and geo — where it came from

The IP of the actor at the time of the event, plus a geo lookup (city + country at minimum). This is one of the fastest ways to spot an account-compromise incident: a share that's normally viewed from Boston suddenly gets viewed from a hosting provider in another country. Your SOC needs that signal.

For healthcare specifically, geo data also supports the §164.308 risk-analysis program. You can show your auditor that your sharing tool produces the same access-pattern data your EHR does, so the same monitoring playbooks cover both.

5. Resource identity — what was acted on

The opaque ID of the share (or sub-resource — specific file in a multi-file share) the event applies to. Not the filename — the filename is PHI and you don't want it in the audit row by default. The opaque ID is what your sharing tool tracks; the filename lookup happens through a separate authorized query path. This matters because audit logs themselves can be subject to access requests; you don't want PHI in metadata.

6. Event-specific metadata — bounded, categorical, no free text

Each event type has supporting context that's useful for forensics:

• Share viewed → user-agent fingerprint, identity-verification status
• Share downloaded → byte count delivered, retry count, whether the download completed
• Share modified → which fields changed (categorical: "recipient added," "expiry extended"), not the new values themselves
• Share revoked → reason category if the sender provided one (incident response, policy violation, etc.)

What goes wrong: tools that dump everything into a JSON blob, including PHI fields. We've seen audit rows that contained the entire patient name and the partial SSN — because the developer used the metadata field as a kitchen sink. PHI in an audit row creates a new disclosure event the moment any other person reads the log.

7. Linkage to the prior event — the integrity chain

This is the §164.312(b) tamper-evidence requirement the 2027 update makes explicit. Each row must reference the previous row in a way that makes after-the-fact editing detectable. The mechanism most security architects expect is a cryptographic hash chain: each row contains a hash that depends on the previous row's hash, so altering any historical row breaks every row that came after it.

In practice, what your auditor wants to see is:

• An independent verifier that walks the chain end-to-end and confirms it's intact.
• Per-share cryptographic anchors that customers retain — e.g., signed receipts containing the chain anchor at destruction time — so the vendor can't silently rewrite history without breaking the receipts you already hold.
• Evidence that the integrity check runs on a schedule, not just on demand when an auditor asks.

This is the field most tools fail. A sharing platform that stores audit logs as ordinary database rows in a vendor-controlled cloud database has no answer to "how do you know nobody edited row 1,247 last Tuesday?" The honest answer is "we don't, but trust us." That's not what §164.312(b) is asking for in 2027.

You can read more about how we approach this on the security and architecture page, and you can run a chain verification yourself on the verifier tool — that's the demonstration of the property, not a brochure claim.

8. Outcome — succeeded or failed, with reason category

Every event row carries an outcome: did the operation complete? Failed attempts matter as much as successful ones — sometimes more. A burst of "passphrase failed" events on a single share is a brute-force signal. A burst of "view denied — identity unverified" events is recipient confusion you need to fix in your sender training. Without the outcome field, those patterns are invisible.

What a HIPAA-compliant retention story looks like

Field-level capture is half the answer. The other half is what happens to the rows after they're written.

The 2027 update doesn't change the six-year retention rule, but it does add expectations around how retained logs are protected. A few specifics:

• Logs must outlive the share itself. When a share is "permanently deleted" (the central marketing claim of every self-destructing-link tool, including ours), the ciphertext goes away — the audit trail does not. The row that says "this share existed, was viewed twice, and was deleted on 2026-03-15 by these specific events" stays for six years. Your auditor will ask you to demonstrate that. Demonstrate it by showing the audit row alongside a confirmation that the underlying payload is gone.

• Access to audit logs must itself be logged. Meta-audit. When your compliance team pulls Q1 logs to respond to a §164.528 request, that pull is itself an event. The tool needs to capture which compliance officer ran the query, when, and what filters they used.

• Export must produce a verifiable artifact. A CSV export is fine for ad-hoc analysis but it's not a forensic artifact. For litigation hold, regulatory response, or post-incident review, your tool needs to produce a signed export — something an outside expert can independently verify hasn't been altered between when you exported it and when they received it. CIPH4 ships signed Proof-of-Deletion Receipts per share-termination event for Enterprise customers; the audit-window CSV is unsigned today, with chain integrity demonstrated via the prev-hash values in the export (assessor can recompute SHA-256 offline) and per-share receipts that anchor to specific chain positions.

The five questions to ask any sharing vendor

If you're evaluating tools right now for the 2027 transition, here's the buyer-side checklist we hand healthcare prospects. Walk through it with the vendor's solutions engineer, not their salesperson:

1. Show me a single audit row for a share-viewed event. Look for the eight fields above. If half are missing or the row is a prose string instead of structured data, walk away.

2. How do you detect tampering with historical rows? A vendor whose answer is "row-level permissions in our database" or "AWS CloudTrail" is missing the point. The integrity proof has to be cryptographic and independently verifiable, not dependent on the vendor's own access controls.

3. What happens to the audit row when the share is destroyed? Confirm the row persists for the full retention window after the ciphertext is gone. Confirm the row references the destruction event itself (event type "share burned" or equivalent, with the trigger reason).

4. What integrity proof comes with the audit export, and can I verify it offline? A signed Ed25519 receipt per destruction event plus a CSV export whose prev-hash chain you can recompute offline is the load-bearing answer. Walking a verifier through the recomputation is the operational test.

5. Who else in your company can edit historical audit rows? The honest answer for most SaaS vendors is "our DBAs, in an emergency, with break-glass procedures." That's tolerable if the integrity chain detects it. It's not tolerable if the integrity chain doesn't exist.

For more on how this maps to the broader compliance picture — including business associate agreement scope, breach-notification triggers, and the way audit trails interact with the §164.528 accounting-of-disclosures rule — see the compliance overview for healthcare workflows and the healthcare-specific industry page.

What to do next

If you have a sharing tool in place today, pull a sample of audit rows this week and walk through the eight-field checklist with your privacy officer. The gaps you find are your 2027 work plan. If you're evaluating new tools, make the five-question script above part of your RFP — and ask for a working chain verifier as a deliverable, not a slide.