HIPAA Audit Log Requirements: What to Track & Retain

Quick Answer: HIPAA requires logging all access to ePHI with user ID, timestamp, action, resource accessed, and outcome. Retain logs for minimum 6 years, protected from unauthorized access/modification. Log critical events: user login/logout, PHI access, data modifications, user management changes, security settings changes, and failed access attempts. Implement centralized logging, regular monitoring, and tamper-proof storage.

HIPAA Audit Control Requirements

HIPAA's Audit Controls (45 CFR § 164.312(b)) require healthcare organizations to implement hardware, software, and procedural mechanisms to record and examine access to ePHI. This ensures accountability and enables breach detection and investigation.

The Security Rule states organizations must "implement hardware, software, and procedural mechanisms that record and examine activity in information systems containing or using ePHI."

Required Log Events

User Authentication Events

Log all authentication-related activities:

  • Successful logins: User ID, timestamp, source IP, authentication method
  • Failed login attempts: Username attempted, timestamp, source IP, failure reason
  • Account lockouts: User ID, timestamp, reason (failed attempts, admin action)
  • Password changes: User ID, timestamp, who initiated change
  • MFA/2FA events: MFA enrollment, MFA bypass, MFA failures
  • Session timeouts: User ID, session duration, logout timestamp
  • Privilege escalation: User ID, privilege level, timestamp, authorization

Log Entry Example:

2026-03-11 09:15:23 | USER_LOGIN | user_id=jsmith | source_ip=192.168.1.100 | result=SUCCESS | session_id=abc123xyz | mfa_verified=true

PHI Access & Modification Events

Critical for tracking who accessed patient data:

  • View/Read PHI: User, timestamp, record accessed, specific data viewed
  • Modify PHI: User, timestamp, field changed, old value, new value
  • Create records: User, timestamp, record type, created data
  • Delete PHI: User, timestamp, record deleted, authorization
  • Export data: User, timestamp, data exported, destination
  • Unauthorized access attempts: User, timestamp, data requested, failure reason
  • Batch operations: User, timestamp, number of records affected, operation type

Log Entry Example:

2026-03-11 10:45:12 | PHI_ACCESS | user_id=mdoctor | action=VIEW | record_type=PATIENT_LAB_RESULTS | mrn=000123456 | fields=lab_values,test_date | source_ip=192.168.1.50 | result=SUCCESS

System & Security Events

Track security-related system changes:

  • User account management: Creation, deletion, modification, permission changes
  • Role/permission changes: User ID, timestamp, roles added/removed, authorized by
  • Security policy changes: Encryption settings, access controls, backup configuration
  • Software/patch updates: Timestamp, version numbers, systems affected, authorized by
  • Backup/restore operations: Timestamp, data backed up, volume, destination
  • Database schema changes: Changes to PHI database structure
  • Configuration changes: Security settings, firewall rules, network configuration
  • Certificate expiration: SSL/TLS certificate installations and renewals

System & Application Events

Operational events for audit trails:

  • System startup/shutdown: Timestamp, initiated by, reason
  • Critical errors: Error messages, timestamp, system affected, impact
  • Service interruptions: Downtime duration, root cause, data affected
  • Unusual access patterns: Off-hours access, bulk data access, access from new locations
  • Security alerts: IDS/IPS alerts, antivirus detections, firewall blocks
  • Database triggers: Stored procedure executions, query anomalies

Minimum Log Data Elements

Data Element Description Example
Timestamp Date and time of event (ISO 8601, UTC) 2026-03-11T14:30:45Z
User ID Unique identifier of user performing action jsmith@hospital.org
Event Type Category of action performed LOGIN, PHI_ACCESS, DELETE
Resource ID What was accessed (record, file, system) MRN-000123456
Action/Method Specific action taken READ, WRITE, DELETE, EXPORT
Source IP/Location Where request originated 192.168.1.100
Result/Status Success or failure of action SUCCESS, DENIED, FAILED
Additional Context Relevant details about event Role, session_id, failure_reason

Log Retention Requirements

Retention Period Standards

Log Type Retention Period Justification
Authentication logs Minimum 6 years HIPAA statute of limitations
PHI access logs Minimum 6 years Required for breach investigations
System event logs Minimum 1 year HIPAA guidance
Security incident logs 7+ years minimum Potential litigation evidence
Backup verification logs 3-7 years Recovery verification

Best Practice: Retain logs for 6-7 years to align with HIPAA statute of limitations and potential litigation timelines.

Log Storage & Protection

Logs themselves are PHI and must be protected:

  • Encryption: Encrypt logs at rest with AES-256
  • Access control: Restrict log access to authorized personnel only
  • Integrity protection: Implement tamper-evident measures
  • Backup: Back up logs regularly and independently
  • Geographic redundancy: Store logs in multiple locations
  • Write-once storage: Use WORM (Write Once Read Many) for immutability
  • Centralized logging: Consolidate logs from all systems into secure SIEM

Log Analysis & Review

Monitoring & Detection

Implement proactive log monitoring using SIEM tools:

SIEM (Security Information & Event Management) Features: - Real-time alert correlation - Anomaly detection algorithms - Failed login threshold alerts (5+ failures = alert) - Unusual access pattern detection - Off-hours access detection - Bulk data export detection - Privilege escalation tracking - Account creation/deletion alerts

Recommended SIEM Platforms:

  • Splunk Enterprise Security
  • IBM QRadar
  • Microsoft Sentinel (Azure)
  • Elastic Stack (open-source option)
  • ArcSight
  • Sumo Logic

Regular Log Review Procedures

Schedule formal log reviews:

  1. Daily monitoring: Automated alerts for critical events
  2. Weekly review: Manual review of alerts and anomalies
  3. Monthly analysis: Trending analysis and access pattern review
  4. Quarterly audit: Comprehensive log audit and policy compliance check
  5. Annual assessment: Full audit control assessment and risk analysis

Documentation Requirements:

  • Log review procedures documented
  • Responsibility assignments (who reviews which logs)
  • Review frequency and schedule
  • Escalation procedures for unusual activity
  • Audit trail of log reviews performed

Common Logging Standards & Formats

Structured Logging Formats

JSON Format (Recommended):

{ "timestamp": "2026-03-11T14:30:45Z", "event_id": "EVT-2026031114301", "user_id": "jsmith@hospital.org", "event_type": "PHI_ACCESS", "resource_type": "PATIENT_RECORD", "resource_id": "MRN-000123456", "action": "READ", "source_ip": "192.168.1.100", "status": "SUCCESS", "duration_ms": 245, "fields_accessed": ["name", "dob", "medical_history"], "session_id": "sess-abc123xyz" }

CEF (Common Event Format):

CEF:0|Hospital|EHR|1.0|LOGIN|User Login|5| src=192.168.1.100 duser=jsmith dvc=ehr01 cs1=session-123 result=SUCCESS

Syslog Format:

<134>Mar 11 14:30:45 ehr01 ehr-app[2847]: USER_LOGIN user=jsmith src=192.168.1.100 session=sess-abc123 result=success

Frequently Asked Questions

What happens if we lose logs due to a system failure? ▼

Log loss is a serious HIPAA compliance violation. Implement redundancy: (1) Send logs to centralized SIEM in real-time, (2) Back up logs daily to separate systems, (3) Use WORM storage to prevent accidental deletion, (4) Test recovery procedures quarterly. If logs are lost, document the incident, conduct forensic analysis if needed, and notify OCR if unauthorized access cannot be ruled out. Implement compensating controls to prevent future incidents.

Should we log all reads of patient data or just sensitive data? ▼

Log all ePHI access, not just sensitive fields. HIPAA defines ePHI broadly. While you may use risk assessment to determine what specific fields are "sensitive," it's safer to log all PHI access. The trade-off is log volume—implement tiered retention where detailed patient-level logs are kept 1 year, summary logs for 6 years. Use compression and archival to manage storage costs. Many organizations log all access, then filter during analysis.

Can we delete logs before 6 years if we've reviewed them? ▼

No. Review doesn't change retention requirements. HIPAA mandates 6-year retention regardless of how recently you reviewed logs. The logic: audits can request logs years later, and breach investigations may require historical context. Only delete logs after confirming: (1) 6+ years have passed since log creation, (2) No active litigation or audit involves the data, (3) Organization policy permits deletion. Document all log deletion in a destruction log.

Do we need to log normal patient lookups by their own doctors? ▼

Yes, log all access regardless of who accesses it. HIPAA doesn't create exceptions for "authorized" users viewing "their" patients. Logging everyone enables you to detect: (1) Doctors accessing patients they don't care for, (2) Unusual access patterns, (3) Breach investigations. The logs prove a doctor legitimately accessed their patient's data. If you implemented role-based access controls correctly, doctors should only have access to their patients anyway.

Implementation Checklist

  • [ ] Identify all systems handling ePHI requiring audit logs
  • [ ] Define logging requirements for each system
  • [ ] Configure centralized logging (SIEM) platform
  • [ ] Implement logging for all event categories (auth, PHI access, system)
  • [ ] Configure log encryption (AES-256) at rest
  • [ ] Establish 6-year minimum retention policy
  • [ ] Configure access controls for log systems
  • [ ] Implement tamper-detection mechanisms
  • [ ] Set up automated monitoring and alerting
  • [ ] Create log review procedures and schedule
  • [ ] Train staff on log monitoring importance
  • [ ] Document logging policies and procedures
  • [ ] Conduct quarterly log audits
  • [ ] Test log recovery procedures annually