HIPAA Audit Controls 164.312(b): What Your Logs Must Capture
HIPAA audit controls, defined in 45 CFR 164.312(b), require hardware, software or procedural mechanisms that record and examine activity in systems containing electronic protected health information. The most common gap is simple: many applications log changes but not reads, while viewing a patient record is exactly the activity auditors and investigators need to trace. This guide explains what your logs must capture, how long to keep them, how to make them tamper-resistant and how to review them. Ask our team to assess your current audit logging.
What the Audit Controls Standard Requires
The audit controls standard is short, but its implications are broad. It requires mechanisms that both record and examine activity in information systems that contain or use ePHI. It has no separate implementation specifications, so the standard itself is required. Recording without reviewing does not satisfy it. This page goes deeper than our HIPAA Security Rule technical safeguards overview, focusing specifically on practical logging design and review for healthcare software teams.
Record Activity
Systems must capture activity involving ePHI, as our HIPAA compliance guide explains, including access, creation, modification, deletion and export. The goal is being able to reconstruct who did what, to which records, and when it happened.
Examine Activity
Organizations must review recorded activity, not just store it. Define review responsibilities, frequency and escalation rules, so suspicious access is detected and investigated rather than discovered months later during incidents.
Reads Matter as Much as Writes
Snooping on records, such as staff viewing a celebrity's or relative's chart, involves reads only. Applications that log edits but not views cannot detect or investigate these privacy violations. Log every view.
Cover People and Software
Log activity by users and by software programs, including integrations, APIs and scheduled jobs. Service activity can expose large volumes of ePHI and needs the same traceability as human access.
Scale to Your Risk
The standard allows flexibility based on risk analysis. Higher-risk systems, such as those holding sensitive records or serving many users, need more detailed logging, alerting and review than low-risk internal tools.
What HIPAA Audit Logs Must Capture
HIPAA audit log requirements are not written as a field list, but investigations consistently expect the same core information. Each entry should answer who accessed data, which patient or record was involved, what action occurred, when it happened and from where. Missing any of these makes investigations slow or impossible. Design your audit log schema early, because retrofitting consistent logging across an existing application is expensive and often incomplete. EHR/EMR integration feeds need the same coverage.
User or Service Identity
Record the unique user ID or service identity performing the action. Include role or permission context where useful, because it helps investigators understand whether access was appropriate for that person's job.
Patient or Record Identifier
Record which patient, record or resource was accessed, using an internal identifier rather than names. This lets investigators produce accounting-style reports showing everyone who viewed a specific patient's information. Avoid storing names.
Action Performed
Record the action type, such as view, search, create, update, delete, print, export or share. Distinguish searches from record views, because broad searches can reveal information about many patients at once.
Timestamp and Time Zone
Record precise timestamps with time zones, using synchronized clocks across servers. Inconsistent time sources make it difficult to correlate application, database and infrastructure events during an investigation. Use UTC consistently everywhere.
Source and Outcome
Record source IP address, device or client application, and whether the action succeeded or failed. Failed access attempts often reveal compromised accounts or misconfigured integrations before real damage occurs. Alert on repeated failures.
Sample Audit Log Schema and Log Types
A consistent schema makes audit logs searchable, reportable and reliable across services. The example below shows a practical structure for application-level audit events. It stores identifiers rather than clinical content, keeping logs useful without turning them into another copy of PHI. Application logs are only one layer, so organizations also need database and infrastructure logs. Our Mirth Connect consulting team applies the same principles to integration engines. Our HIPAA software development checklist lists related tasks.
Example Audit Event Structure
Each event records the actor, patient reference, action, resource, timestamp, source, outcome and a request identifier linking related events. Clinical values never appear in the audit record itself. Keep fields consistent.
{
"event_id": "evt_01J8Z6",
"timestamp": "2026-09-29T14:32:08.412Z",
"actor_id": "user_4821",
"actor_role": "nurse",
"patient_ref": "pt_90417",
"action": "view",
"resource": "lab_result",
"resource_id": "res_55120",
"source_ip": "10.20.4.17",
"client": "web-portal",
"outcome": "success",
"request_id": "req_7f3a2c"
}Application Logs
Application audit logs capture business actions, such as viewing a chart or exporting a report. They are the most meaningful layer for privacy investigations, because they reflect what users actually saw.
Database Logs
Database logs capture direct queries and administrative access, including activity that bypasses the application. They are essential for detecting privileged misuse by administrators, developers or compromised database credentials. Enable them in production.
Infrastructure Logs
Infrastructure logs cover servers, networks, cloud consoles and identity providers. They show logins, configuration changes and network activity, helping investigators understand how attackers entered and moved through systems. Retain them consistently.
Keeping PHI Out of Logs
Debug and error logs often leak names, diagnoses and full request bodies. Redact sensitive fields, separate audit logs from debug logs and scan log stores regularly for exposed patient data.
Retention, Tamper Resistance and Log Review
Audit logs are only valuable if they survive long enough, cannot be quietly altered and are actually reviewed. Many organizations get one or two of these right and miss the third. HIPAA requires documentation of policies and procedures to be kept for six years, and many organizations align audit log retention to the same period or longer, based on their risk analysis. Review processes should be documented, assigned and evidenced through regular reports.
Setting Retention Periods
Base retention on your risk analysis, legal advice, state requirements and contractual obligations. Many organizations keep audit logs for six years, with older logs moved to cheaper, encrypted archive storage.
Making Logs Tamper-Resistant
Store audit logs in append-only or write-once storage, separate from application databases. Restrict deletion rights, use hashing or signing to detect changes, and log all access to the logs themselves.
Centralizing Logs
Send logs from applications, databases and infrastructure to a central platform, such as a SIEM. Centralization enables correlation, alerting and consistent retention, even when individual servers fail or are rebuilt.
Defining a Review Process
Assign reviewers, frequencies and triggers, such as access to VIP records, after-hours access or unusual volumes. Document each review, findings and actions, because evidence of review is essential during audits.
Automating Alerts
Automate alerts for high-risk patterns, such as mass record access, repeated failed logins or access to flagged records. Automation helps small teams meet review obligations without manually reading every log entry.
Frequently Asked Questions
How should an EMR system administrator configure audit logging to meet HIPAA technical safeguard requirements?
Enable logging for every access to ePHI, including views, searches, edits, exports and prints. Capture user ID, patient identifier, action, timestamp, source and outcome. Send logs to tamper-resistant central storage, restrict who can alter them, define retention based on risk analysis, and schedule documented reviews with automated alerts for suspicious activity.
What does 45 CFR 164.312(b) require?
45 CFR 164.312(b) requires hardware, software or procedural mechanisms that record and examine activity in information systems containing or using ePHI. It has no separate implementation specifications, so the standard itself is required. Organizations must both capture relevant activity and review it, rather than only storing logs.
Does HIPAA require logging read access?
HIPAA does not list specific events, but the audit controls standard covers activity in systems containing ePHI, and viewing records is key activity. Many privacy violations involve only viewing records. Without read logging, organizations cannot detect snooping, respond to patient access inquiries or investigate incidents effectively.
How long should HIPAA audit logs be kept?
HIPAA does not specify audit log retention directly. It requires documentation of policies and procedures to be retained for six years, and many organizations align audit log retention with that period. Set retention using your risk analysis, state laws, contracts and legal advice, then document the decision.
Should audit logs contain PHI?
Audit logs should contain identifiers needed for investigation, such as patient reference and user ID, but not clinical content like diagnoses or results. Minimizing PHI in logs reduces risk if logs are exposed. Protect logs with access controls and encryption, because identifiers alone can still be sensitive.
How often should HIPAA audit logs be reviewed?
HIPAA does not set a frequency, so base it on risk. Many organizations review high-risk systems weekly or daily through automated alerts, and perform broader reviews monthly or quarterly. Document who reviews logs, what was found and what actions were taken, because review evidence matters during audits.
Need an Audit Logging Assessment?
Our integration engineers are ready to help. Free consultation, no obligation.