Last updated: March 2026

HIPAA's audit log retention requirement is four words in the regulation. The implementation is everything the regulation doesn't say.

The Security Rule requires covered entities and business associates to retain documentation of security policies, procedures, and activities for six years from the date of creation or last effective date. That includes audit logs. But the standard leaves the operational details almost entirely undefined: what events count as loggable, what format logs must be in, how they must be stored, how they must be protected, and how you demonstrate compliance to an auditor.

This guide covers the full requirement as it applies to engineers and technical teams responsible for implementing and maintaining HIPAA-compliant infrastructure.

This chapter covers what to log, how long to keep it, how to protect it, and what auditors check. For how to write audit log entries in application code, see App Development. For the infrastructure layer (immutable storage, log drains, and platform-level logging), see Hosting Requirements. For LLM-specific logging requirements, see HIPAA & AI.

In this guide

The regulation says less than you think

Two provisions in the HIPAA Security Rule govern audit logging.

45 CFR § 164.312(b): Audit Controls (required): "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 § 164.316(b)(2): Retention (required): Retain documentation of policies and procedures for six years from the date of creation or the date when it last was in effect, whichever is later.

That is the entire regulatory foundation. Notice what's missing: no prescribed log format, no required fields, no specific event types, no storage architecture. The regulation tells you to log activity and keep those logs for six years. Everything else is interpretation.

This matters because a lot of teams either overbuild (logging everything to every destination with no retention policy) or underbuild (relying on whatever a platform keeps by default, without ever defining an explicit retention policy). Both create audit risk.

The audit control standard is a required specification, not an addressable one. There is no risk-based flexibility here. Every covered entity and business associate must implement it.

Business associates are fully covered

A common misconception is that business associates have softer obligations than covered entities. They don't. The HITECH Act extended the Security Rule to business associates directly. If you're a digital health startup building a platform that processes PHI on behalf of a hospital, health plan, or another covered entity, you have the same audit logging and retention obligations as the covered entity you're serving.

Your Business Associate Agreement will typically include language about audit log access and retention. If your BAA specifies retention periods shorter than six years, note that HIPAA sets the floor.

What you actually need to log

HIPAA doesn't publish a required event list. But OCR's HIPAA Audit Program, NIST guidance on HIPAA implementation, and the record of actual enforcement actions point to the same categories.

Authentication and access events

• Successful and failed login attempts

• Password resets and MFA changes

• Session creation and termination

• API key creation and revocation

PHI access events

• Who accessed a record containing PHI, when, and what action was taken (read, create, modify, delete)

• Which system or application generated the access

Administrative and privileged actions

• User and role creation, modification, and deletion

• Permission changes and privilege escalation

• Access to audit logs themselves

Infrastructure and configuration changes

• Changes to systems that store or process PHI

• Network configuration and firewall rule changes

• Encryption key rotation or changes

Data export and transmission events

• PHI exports from the system

• Transmissions to third parties

• Backup creation and restoration

The level you need to log at is broader than most teams assume. Application-level logs capture user actions, but they typically miss OS-level events, database access patterns, infrastructure changes, and anything that happens at the container or network layer. Auditors look at the full stack.

HIPAA doesn't mandate a specific log format, but structured, machine-readable logs are far easier to query on short notice. If an auditor asks you to produce all access events for a specific user between two dates, you want to run a query, not manually scrape unstructured text files.

Six years, and the details that trip teams up

The six-year retention period runs from the creation date or last effective date, whichever is later. For a log entry, the creation date is the timestamp. For a policy document, the effective date may be the last time it was updated or confirmed.

Three things that catch teams off guard:

State law can require longer retention, but only when it is more stringent. HIPAA sets the federal floor. Where state law imposes a longer retention period for specific record types, the stricter requirement governs. HIPAA does not preempt state law that provides greater protections. Business associates operating in multiple states should confirm the applicable requirements for each, since a retention period sufficient under federal law may fall short in specific states.

Retention doesn't mean active retention. Logs don't need to stay in your primary log aggregation system for six years. They need to be retrievable for six years. Archiving to S3 with appropriate access controls and an explicit lifecycle policy that prevents deletion before the retention period expires is a valid approach. The requirement is that you can produce them when asked.

The clock doesn't reset when you delete a resource. If you terminate a container, tear down an environment, or offboard a customer, the logs from that system don't disappear from your retention obligation. This is one of the most common gaps in practice: logs exist while resources are running, but nobody has thought through what happens to them when the resource is gone.

Protecting audit logs

Logs are only useful for compliance and forensics if they're trustworthy. HIPAA's audit control standard implies, and OCR's enforcement record confirms, that you need more than retained logs. You need logs that haven't been tampered with.

Immutability matters. If someone with admin access can delete or modify audit logs, you can't credibly present those logs as evidence of your controls. Audit logs should be stored in a system where they are append-only once written. In AWS, S3 Object Lock with a WORM (write once, read many) configuration is a common implementation. The point is that even your own administrators shouldn't be able to alter historical log records.

Separate access controls from the systems being logged. The people who can modify your production systems should not be the same people who can modify the logs for those systems. Access to audit logs should be restricted to specific roles, and access to the logs themselves should also be logged.

Log access to the logs. Who accessed the audit log store? When? Access to your audit trail is itself an auditable event. Auditors specifically look for whether you have controls over who can access, export, or delete logs.

Encrypt logs at rest and in transit. Audit logs contain a record of who accessed what PHI and when. That data is sensitive in its own right. Logs must be encrypted at rest (AES-256) and in transit (TLS 1.2+), and encryption key management should follow the same controls you apply to your primary PHI storage.

Where log retention breaks in practice

The regulations aren't the hard part. The hard part is infrastructure that wasn't designed with six-year retention in mind.

Container and ephemeral instance logs are the most common gap. When a container exits, its local filesystem goes with it. If your logging pipeline relies on stdout being scraped from running containers, and you haven't set up centralized log aggregation, logs from stopped containers disappear. This is a real gap in a lot of containerized architectures.

Log rotation without archival. Log rotation is good practice for disk management, but if your rotation policy deletes logs after 30 or 90 days without shipping them to a longer-term store first, you're non-compliant. Default CloudWatch Logs retention is often set to "never expire" or left at short intervals depending on how the log group was created. Neither is a retention policy.

No documented retention policy. This is what auditors cite most often. Even if your logs are technically retained for six years, if you can't produce a written policy that states your retention period, your classification of loggable events, and your procedures for accessing logs on request, you have a documentation gap. The policy is as required as the logs.

Siloed logs across services. Most cloud architectures generate logs in multiple places: CloudWatch for application logs, VPC Flow Logs for network traffic, RDS logs for database access, S3 access logs for object storage. If each has a different retention period, different access controls, and a different owner, you don't have a log retention program. You have several loosely related configurations.

The goal is centralized log aggregation with a single, documented retention policy: one place, one policy, one access control model, one answer when an auditor asks.

What auditors actually check

The gap between what the regulation says and what auditors examine is significant. Based on OCR's audit protocol and the pattern of HIPAA enforcement actions involving audit controls, here's what gets scrutinized:

A written log retention policy. Required documentation under § 164.316. You need a written policy that defines what you log, how long you retain it, how logs are protected, and who can access them.

Log completeness. Can you demonstrate that logs exist for the full retention period with no unexplained gaps? Gaps raise questions about whether logs were deleted or whether the logging system was functioning. Auditors look for evidence of continuous logging, not snapshots.

Access controls on log data. Who can read your logs? Who can delete them? Can you show that log access is restricted and monitored?

The ability to produce logs on request. "We have logs" is not sufficient. You need to be able to produce logs for a specific date range, user, or resource on short notice. If that requires a week of engineering work, that's a problem.

Evidence of regular log review. The audit control standard requires that you both record and examine activity. Retaining logs is necessary but not sufficient. You need documented procedures for reviewing logs and evidence that you actually follow them.

How Aptible handles this

Aptible captures logs from all application containers and managed databases automatically. Logs ship to a centralized drain and are available for export and query. Every infrastructure-level event (deploys, configuration changes, access events, database operations) is captured in Aptible's activity feed with full attribution and timestamps.

This covers the infrastructure layer that most application-level logging misses. Logs persist independently of whether a container or database is still running, which addresses the ephemeral resource gap directly.

For long-term retention, teams using Aptible typically pair the platform's built-in log shipping with an external destination (Datadog, Splunk, or an S3-based archive) configured with explicit six-year lifecycle policies. Aptible's observability features give you the audit trail at the platform level; your log management tooling handles archival.

See how Aptible's observability and audit logging works.

FAQs

Does HIPAA require exactly six years of log retention?

Yes, six years is the floor. The retention clock starts from the date of creation or the last effective date, whichever is later. Some states impose longer requirements for specific record types. Six years is the minimum regardless.

What types of logs fall under HIPAA's audit control requirement?

The regulation covers logs from any information system that contains or uses ePHI. In practice, that means application logs, database access logs, infrastructure and configuration change logs, network access logs, and authentication events. It is not limited to the application layer.

Do business associates have to retain audit logs, or just covered entities?

Both. HITECH extended the Security Rule directly to business associates. The same audit control and retention requirements that apply to covered entities apply to business associates.

What happens if audit logs are missing during an OCR investigation?

Missing or incomplete logs are treated as evidence of a control failure, not simply a documentation gap. In enforcement cases where OCR found inadequate logging, the absence of logs was taken as inability to demonstrate that required controls were in place. Penalties have been issued specifically for audit control failures, separate from whatever incident triggered the investigation.

Is the audit control standard required or addressable?

Required. Unlike some Security Rule provisions that are "addressable" (meaning you can implement an equivalent alternative or document why they don't apply), the audit control standard at § 164.312(b) is a required implementation specification. There is no risk-based opt-out.

Next steps

If you don't have a written log retention policy yet, that is the first gap to close. The documentation requirement is as binding as the technical one. Define what you log, how long you retain it, how logs are protected, and who can access them. One document. Written and signed.

Audit your current logging coverage against the event categories in this guide. Authentication events, PHI access, privileged actions, infrastructure changes, data exports. Map what you currently log against what you need to log. Gaps in scope are easier to close before an audit than during one.

Check your retention configuration. Where does each log type live? What is the retention period configured on each log group or destination? Is there a lifecycle policy that prevents deletion before six years? If you cannot answer these questions quickly, that is the operational gap to address.

Verify your ephemeral resource coverage. If you run containers, confirm that your logging pipeline ships logs to centralized storage before container shutdown. Logs that exist only on running containers are not retained logs.

Review the infrastructure layer alongside the application layer. This guide covers the retention requirements. For what your infrastructure must log at the hosting layer, see HIPAA Hosting Requirements. For how to write audit log entries in application code, see App Development.

Run through the full checklist. Audit logging is one control family. HIPAA Compliance Checklist maps all Security Rule safeguards with implementation notes.