HIPAA Audit Logging Requirements: What to Log, How to Protect It, and Why It Matters in an Investigation

HIPAA's audit control requirement (45 CFR 164.312(b)) is exactly one sentence long: "Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information."

That's it. No specifics on what to log, how long to keep it, or what format to use. This is by design -- HIPAA is technology-neutral and scales from solo dental practices to massive hospital networks. But it means the implementation details are on you.

Here's what actually matters when building audit logging for HIPAA-covered systems.

What You Need to Log

Authentication Events

• Successful logins (user, timestamp, source IP, device identifier)
• Failed login attempts (especially important for detecting brute force attacks)
• Password changes and resets
• MFA enrollment and verification events
• Session creation and termination
• Account lockouts

PHI Access Events

This is the most critical category and where most systems fall short:

• Record-level access -- Which user accessed which patient's records, when, and from where
• What action was taken -- View, create, modify, delete, print, export, download
• Search queries -- What search terms were used to find patient records (this catches the employee who searches for a celebrity patient's name)
• Bulk operations -- Any export, report generation, or query that returns multiple patient records
• Emergency access ("break the glass") -- When someone overrides normal access controls for emergency patient care, log it with extra detail

System Configuration Changes

• Access control modifications (role changes, permission grants/revocations)
• Encryption setting changes
• Audit log configuration changes (meta-logging -- who turned off logging?)
• Network security changes (firewall rules, security group modifications)
• Backup configuration changes
• User account creation, modification, and deactivation

Data Movement

• PHI exports (to files, reports, external systems)
• Data transfers to business associates
• Backup operations
• Data destruction/deletion events
• Print jobs containing PHI

How to Structure Audit Logs

Every log entry needs these fields at minimum:

{
  "timestamp": "2026-04-03T14:23:17.445Z",
  "event_type": "phi_access",
  "action": "view",
  "user_id": "provider_12345",
  "user_role": "physician",
  "patient_id": "patient_67890",
  "resource": "medical_record",
  "resource_id": "record_11111",
  "source_ip": "10.0.1.45",
  "session_id": "sess_abc123",
  "result": "success",
  "facility": "main_clinic"
}

Key principles:

• Use UTC timestamps -- Consistent timezone eliminates confusion during investigations
• Include both user and patient identifiers -- You need to answer "who accessed this patient's data?" and "what data did this user access?"
• Structured format -- JSON or similar structured format. Free-text logs are nearly impossible to query at scale during an investigation.
• Immutable -- Once written, log entries cannot be modified or deleted

Log Protection

This is where many organizations fail. Logs that can be tampered with are worthless in an investigation.

Immutability

• Write logs to append-only storage (S3 with Object Lock, WORM storage, immutable database tables)
• Separate log storage from application infrastructure -- a compromised application server shouldn't be able to delete its own audit trail
• Use a dedicated logging account/project with restricted access

Access Control

• Only the security/compliance team should have read access to audit logs
• No one should have delete access (enforce through storage-level immutability)
• Application service accounts should have write-only access -- they can create log entries but not read or modify them
• Log access to the logs (yes, meta-logging is necessary)

Retention

HIPAA requires 6-year retention for compliance documentation. While audit logs aren't explicitly called out in the retention requirement, OCR investigations routinely request historical logs, and organizations that can't produce them face harder scrutiny.

Recommended approach:

• Hot storage (searchable, fast query): 90 days to 1 year
• Warm storage (archived but retrievable): 1-3 years
• Cold storage (compressed, longer retrieval time): 3-6 years

Encryption

Audit logs themselves may contain PHI references (patient IDs, user actions on specific records). Encrypt logs at rest and in transit using the same standards as your ePHI.

Real-Time Monitoring and Alerting

Logging without monitoring is just creating evidence of breaches you didn't catch. Set up alerts for:

• Unusual access patterns -- A user accessing significantly more records than their normal baseline
• After-hours access -- PHI access outside of normal business hours (especially for roles that shouldn't need it)
• Failed authentication spikes -- Potential brute force or credential stuffing attacks
• Bulk data exports -- Any export exceeding a threshold should trigger review
• Privilege escalation -- Role changes or permission modifications
• Geographic anomalies -- Access from unexpected locations
• Configuration changes -- Any modification to security controls

Audit Log Review

Having logs isn't enough -- HIPAA expects you to actually review them. Document your review process:

• Frequency -- At minimum monthly, with real-time alerting for critical events
• Who reviews -- Designated compliance or security team members
• What they look for -- Anomalous patterns, policy violations, unauthorized access attempts
• Documentation -- Record that reviews occurred, what was found, and what actions were taken
• Escalation procedures -- Clear process for when a review identifies a potential incident

Common Audit Logging Failures

Only logging authentication

Many systems log who logged in and out but nothing about what they did once inside. OCR wants to see PHI access logs, not just login records.

Logging too little detail

"User accessed patient record" isn't useful. You need the specific record, what they viewed/modified, and the context.

Mutable log storage

If your logs are in a database table that application admins can modify, they won't hold up under scrutiny. Immutability is non-negotiable.

No log review process

Creating logs and never looking at them is a compliance gap. Document your review procedures and actually follow them.

Short retention

Deleting logs after 90 days means you can't respond to OCR requests about incidents from a year ago.

The Compliance Connection

Your audit logging implementation should be driven by your Security Risk Analysis. The SRA identifies which systems contain ePHI and what threats exist -- audit logging is a key control for detecting and investigating those threats.

For the risk analysis foundation that drives your logging requirements: HIPAA Risk Analysis Tools

And for comprehensive compliance management including audit controls: HIPAA Compliance Solutions

---

Joe Gellatly is CEO of Medcurity, a HIPAA compliance platform that helps healthcare organizations manage risk assessments, compliance programs, and security documentation.