Audit Controls

HIPAA’s audit controls requirement means you must implement technical and/or procedural mechanisms to record and examine activity in any information system that contains or uses ePHI. Practically, that means defining what gets logged, turning on logging across key systems, protecting logs from tampering, and routinely reviewing them to detect inappropriate access or misuse. (45 CFR Parts 160, 162, 164)

Key takeaways:

• Scope systems that create, receive, maintain, or transmit ePHI, then enable audit logging for access and key administrative actions. (45 CFR Parts 160, 162, 164)
• Make audit logs reviewable: centralize, retain, protect integrity, and assign ownership for regular review and escalation. (45 CFR Parts 160, 162, 164)
• Evidence matters: keep configurations, samples of logs, review tickets, and incident follow-up records tied to ePHI systems. (45 CFR Parts 160, 162, 164)

Audit controls under the HIPAA Security Rule are frequently treated as “turn on logging.” That is not enough. The requirement is broader: you need mechanisms that both record and examine activity in information systems that contain or use ePHI. (45 CFR Parts 160, 162, 164)

For a CCO or GRC lead, the operational challenge is predictable. ePHI lives in more places than your EHR: identity providers, cloud storage, interface engines, billing platforms, ticketing systems with attachments, endpoints, backups, data warehouses, and third-party hosted apps. You need a defensible way to (1) identify which systems are in scope, (2) confirm appropriate logging is enabled, (3) ensure logs are reliable and protected, and (4) prove somebody is reviewing them and acting on what they find. (45 CFR Parts 160, 162, 164)

This page breaks the audit controls requirement into implementable steps, assigns clear control ownership, and lists the artifacts you should retain for audits, investigations, and internal assurance. It also calls out common hangups that slow teams down: “we don’t know what to log,” “our vendor won’t give us logs,” and “we have logs but no review process.” (45 CFR Parts 160, 162, 164)

Regulatory text

Requirement (verbatim): “Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.” (45 CFR Parts 160, 162, 164)

What the operator must do:
You must put mechanisms in place to (1) record relevant activity in ePHI systems and (2) examine that recorded activity. “Hardware, software, and/or procedural mechanisms” gives flexibility: you can meet the requirement with native system logs, SIEM/central logging, managed detection services, manual review procedures for smaller systems, or combinations of these. The non-negotiable is that the controls are real, cover your ePHI systems, and support review and follow-up. (45 CFR Parts 160, 162, 164)

Plain-English interpretation (what examiners expect)

If a workforce member, administrator, or third party accesses ePHI, changes permissions, exports data, disables logging, or otherwise performs sensitive actions in an ePHI system, you should be able to answer:

• Who did it (user/service identity)
• What they did (event type and object)
• When they did it (timestamp, time zone)
• Where/from what (source IP/device/app where available)
• What happened next (alerts, ticket, investigation outcome)

And you must demonstrate that someone is regularly looking at those records and escalating anomalies. (45 CFR Parts 160, 162, 164)

Who it applies to

Regulated entities: Covered Entities and Business Associates. (45 CFR Parts 160, 162, 164)

Operational context (systems in scope): Any information system that contains or uses ePHI, including:

• Clinical applications (EHR/EMR), PACS, LIS, RIS
• Identity and access systems (IdP, MFA, privileged access tools)
• Infrastructure that stores/transmits ePHI (databases, file shares, object storage, email gateways where ePHI may pass)
• Endpoints and servers used to access or process ePHI
• Integration tooling (HL7/FHIR interfaces, API gateways, ETL jobs)
• Security tooling where ePHI events are observable (SIEM, EDR) (45 CFR Parts 160, 162, 164)

Third parties: If a third party hosts or operates an ePHI system, your audit controls obligation shifts to: ensure the service provides adequate logging and access to relevant audit information, and ensure you can examine it (directly or through reports/alerts). (45 CFR Parts 160, 162, 164)

What you actually need to do (step-by-step)

1) Build and maintain an “ePHI systems audit log inventory”

Create a living inventory that lists each in-scope system and the audit control status:

• System name, owner, environment (prod/non-prod)
• ePHI role (contains/uses/transmits)
• Logging source (native logs, database audit, OS logs, app logs)
• Centralization method (SIEM, log pipeline, managed service, none)
• Review method (alerting rules, manual review, vendor reports)
• Gaps and remediation plan (45 CFR Parts 160, 162, 164)

This inventory becomes your audit map: it tells an auditor you know where ePHI is and how activity is recorded and examined.

2) Define minimum auditable events (your logging standard)

Publish a short “Audit Logging Standard for ePHI Systems” that states what must be recorded, at minimum, for any system in scope:

• Authentication events (login success/failure), session creation
• Authorization/role and permission changes
• Access to ePHI objects (view, query, print, download/export where available)
• Creation/modification/deletion of ePHI records (clinical and administrative)
• Administrative actions (user provisioning, configuration changes)
• Security-relevant events (logging disabled, audit policy changes) (45 CFR Parts 160, 162, 164)

Keep it implementable. Your engineering teams should be able to translate it into system settings and SIEM use cases.

3) Turn on logging and verify it works (configuration + test)

For each system:

• Enable the highest-fidelity audit logging your platform supports without breaking performance.
• Confirm timestamps, user identifiers, and event fields populate as expected.
• Generate test events (known logins, known access, known export) and confirm they appear in the log store. (45 CFR Parts 160, 162, 164)

A common failure mode is “logging enabled” in the UI but no events reaching the review point.

4) Centralize logs where it matters, and protect integrity

You do not need a single tool for every log source, but you do need a controlled log repository for systems where ePHI risk is meaningful. Your mechanism should address:

• Access controls: limit who can read and who can delete
• Integrity protections: prevent or detect tampering
• Availability: logs remain accessible for investigations and audits (45 CFR Parts 160, 162, 164)

If you cannot centralize a system (common with certain SaaS platforms), document compensating measures: vendor-provided audit reports, admin console exports, and an internal review cadence.

5) Operationalize “examine”: assign review, triage, and escalation

Recording is only half. Create an audit log review process with:

• Owner: Security operations, IT security, or a designated system administrator (named role)
• Review inputs: dashboards, scheduled reports, alert rules
• Triage steps: validate user/context, confirm authorization, check related events
• Escalation path: privacy officer, HR, legal, incident response
• Closure criteria: false positive rationale or documented investigation outcome (45 CFR Parts 160, 162, 164)

This is where many programs fail: plenty of data, no accountable review workflow.

6) Tie audit controls into third-party due diligence and contracting

For third-party hosted systems containing/using ePHI:

• Require contract language (or a security addendum) that audit logs exist, are retained, and are accessible to you (direct access, APIs, or timely reports).
• Validate in due diligence: request sample audit logs or screenshots of audit capabilities, plus role-based access controls around the logs.
• Define how you will examine: alerts routed to your SIEM, periodic reports, or case-by-case exports during investigations. (45 CFR Parts 160, 162, 164)

If you use Daydream for third-party risk management, map “audit log availability and access” as a specific due diligence requirement for ePHI vendors, then track evidence collection and renewal tasks in one workflow.

Required evidence and artifacts to retain

Keep artifacts that prove record and examine:

Design and scope

• ePHI systems audit log inventory (current + change history)
• Audit Logging Standard for ePHI Systems
• Data flow or system context showing ePHI touchpoints (as available) (45 CFR Parts 160, 162, 164)

Configuration and operation

• Screenshots/exported configurations showing audit logging enabled
• SIEM/log pipeline configuration snippets (sources enabled, parsing, retention settings if documented)
• Sample log entries for key event types (redacted as needed)
• Access control records for the log repository (who can view/administer) (45 CFR Parts 160, 162, 164)

Review and follow-up

• Scheduled review reports, dashboards, or alert lists
• Tickets/cases showing triage, investigation notes, and closure
• Evidence of remediation when issues are found (access removal, policy updates, training) (45 CFR Parts 160, 162, 164)

Common exam/audit questions and hangups

Expect questions like:

• “List the systems that contain or use ePHI and show how activity is logged and reviewed for each.” (45 CFR Parts 160, 162, 164)
• “Who reviews audit logs, how often, and what do they look for?” (45 CFR Parts 160, 162, 164)
• “Can an administrator delete or alter logs without detection?” (45 CFR Parts 160, 162, 164)
• “Show an example where audit logging supported an investigation or access concern.” (45 CFR Parts 160, 162, 164)
• “For your SaaS EHR/billing vendor, what audit information do you receive and how do you review it?” (45 CFR Parts 160, 162, 164)

Hangups that stall audits:

• No unified list of in-scope systems
• Logs exist but are inaccessible to compliance/security
• No evidence of review, only evidence of collection (45 CFR Parts 160, 162, 164)

Frequent implementation mistakes (and how to avoid them)

1. Relying on “we can pull logs if needed”
   Fix: define routine examination, even if it’s lightweight for low-risk systems. Keep evidence of actual reviews. (45 CFR Parts 160, 162, 164)

2. Logging without identity fidelity (shared admin accounts, generic service users)
   Fix: require named accounts and strong admin controls so audit events map to people or managed service identities. (45 CFR Parts 160, 162, 164)

3. Allowing the same team to administer systems and erase tracks
   Fix: restrict log deletion, separate duties where feasible, and monitor changes to audit settings. (45 CFR Parts 160, 162, 164)

4. Ignoring third-party auditability
   Fix: make audit log access a due diligence and contracting requirement for any third party handling ePHI. Track it like any other control dependency. (45 CFR Parts 160, 162, 164)

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so this page does not list specific cases. (45 CFR Parts 160, 162, 164)

Operationally, weak audit controls increase your exposure in three predictable ways:

• You cannot prove appropriate access to ePHI during investigations.
• You detect inappropriate access late, after more records are affected.
• You struggle to scope incidents because activity history is incomplete or unreliable. (45 CFR Parts 160, 162, 164)

Practical execution plan (30/60/90)

Exact timelines depend on system count and tooling maturity. Use phased milestones rather than calendar promises.

First 30 days: get to “scoped and owned”

• Publish the ePHI systems audit log inventory (draft is fine, but complete coverage is the goal). (45 CFR Parts 160, 162, 164)
• Identify log owners per system and a single program owner accountable for audit controls. (45 CFR Parts 160, 162, 164)
• Issue the minimum auditable events standard and socialize it with IT/security/app owners. (45 CFR Parts 160, 162, 164)
• For top-risk systems, confirm logging is enabled and produce sample logs. (45 CFR Parts 160, 162, 164)

By 60 days: make examination real

• Centralize logs for the highest-risk ePHI systems or implement a documented alternative for SaaS sources. (45 CFR Parts 160, 162, 164)
• Stand up review workflows: alerts, review checklists, ticketing paths, escalation contacts. (45 CFR Parts 160, 162, 164)
• Run a tabletop-style validation: simulate a suspicious access scenario and confirm you can retrieve and interpret logs end-to-end. (45 CFR Parts 160, 162, 164)

By 90 days: harden and prove repeatability

• Expand logging coverage to remaining in-scope systems, closing the largest gaps first. (45 CFR Parts 160, 162, 164)
• Add monitoring for audit log health (sources silent, log pipeline failures, audit disabled events). (45 CFR Parts 160, 162, 164)
• Build an evidence pack: configurations, sample logs, review records, and at least one completed investigation workflow (even if it’s a benign test case). (45 CFR Parts 160, 162, 164)
• For third parties, ensure audit log access/reporting expectations are in contracts and tracked in your third-party inventory; tools like Daydream can keep renewals and evidence requests from turning into email chases. (45 CFR Parts 160, 162, 164)

Frequently Asked Questions

Do audit controls require a SIEM?

No. The rule allows hardware, software, and/or procedural mechanisms, as long as you record and examine activity in systems that contain or use ePHI. A SIEM often helps at scale, but documented manual reviews can satisfy parts of the requirement for smaller footprints. (45 CFR Parts 160, 162, 164)

What systems are “information systems that contain or use ePHI”?

Treat any system that stores ePHI, processes it, or enables access to it as in scope. That includes identity systems and admin consoles if they govern access to ePHI applications. (45 CFR Parts 160, 162, 164)

If a SaaS vendor won’t give us raw logs, can we still comply?

Potentially, if you can examine activity through vendor audit reports, admin audit views, or exports tied to meaningful events. Document the limitation, contract for improved access where possible, and define how reviews and investigations will work. (45 CFR Parts 160, 162, 164)

What does “examine activity” mean in practice?

It means assigned staff review audit data or alerts to detect inappropriate access or risky admin actions, then document triage and outcomes. The proof is your review records and follow-up tickets, not the existence of logs. (45 CFR Parts 160, 162, 164)

How do we prove logs weren’t tampered with?

Restrict permissions to delete or alter logs, separate administrative privileges where feasible, and monitor for changes to audit settings. Retain system configurations and access control evidence for the logging platform. (45 CFR Parts 160, 162, 164)

Should compliance own audit log reviews?

Compliance should set requirements and verify performance; day-to-day review typically sits with security operations or system owners who can investigate events. Make the RACI explicit so reviews do not fall into a gap. (45 CFR Parts 160, 162, 164)