Log In 
Most healthcare organizations are generating HIPAA audit logs. Most of them are not reading them. That gap, between producing a log and actually reviewing it, is where the HIPAA Security Rule’s audit control requirements are most commonly violated, and it is not the gap organizations expect to have. This post covers what the Security Rule requires, what events you must track, how long you must keep the records, and how platforms like Knack Health automate record change logs so the audit trail is built into the operational system rather than managed as a separate compliance task.
Key takeaways
- The HIPAA Security Rule contains two separate, required audit obligations: generating logs of system activity (45 CFR §164.312(b)) and regularly reviewing those logs (45 CFR §164.308(a)(1)(ii)(D)). Both are required specifications, not addressable ones. Generating logs without reviewing them satisfies the first and fails the second.
- The regulation does not prescribe a specific log format or specify which software to use. It requires that organizations implement mechanisms to record and examine activity in systems that contain ePHI.
- Six years is the defensible minimum retention period for audit logs, derived from HIPAA’s broader documentation retention requirement. State law and CMS rules can push the period longer.
- At minimum, HIPAA audit logs should capture: user identity, timestamp, the record or system accessed, the action taken, and whether the action succeeded or failed.
- Platforms that build record change logs into the application layer, including Knack Health, satisfy the recording requirement automatically. The review requirement still demands a documented process.
- The proposed 2026 HIPAA Security Rule update would add more specific logging requirements. It is not yet finalized, but building to the proposed standard now is the lower-risk path.
What the HIPAA Security Rule actually requires for audit log compliance
The HIPAA Security Rule creates two separate, required obligations related to logging. Understanding that they are separate is important, because satisfying one does not satisfy the other.
Audit Controls (45 CFR §164.312(b) — Required). Covered entities and business associates must implement hardware, software, and procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information (ePHI). This is a required implementation specification. There are no exceptions, and no addressable alternatives to evaluate.
Information System Activity Review (45 CFR §164.308(a)(1)(ii)(D) — Required). Organizations must implement procedures to regularly review records of information system activity, including audit logs, access reports, and security incident tracking reports. This specification is also required, not addressable.
Read together, these two provisions say: generate logs of ePHI-system activity, and regularly review them. The review requirement is where most organizations fall short. Specifically, a system that generates comprehensive logs that no one reads is recording activity. It is not meeting the review obligation. When OCR investigates a potential breach, investigators ask for evidence that someone reviewed the logs during the period in question, not just evidence that logs were generated.
The regulation does not prescribe a specific log format, a specific software platform, or a specific review frequency. Organizations have flexibility in how they implement both obligations. That flexibility is bounded by the requirement that the implementation be reasonable and appropriate given the organization’s size, complexity, and resources, and that the logs must be sufficient to detect and investigate security incidents involving ePHI.
What events HIPAA audit logs must capture
The Security Rule does not produce an exhaustive list of specific events to log. Instead, it requires that organizations implement mechanisms sufficient to record and examine activity in systems that contain ePHI. Enforcement actions and OCR guidance have established a practical baseline. At minimum, HIPAA audit logs should capture the following.
User identity. Every log entry should identify the specific individual who performed the action. Shared credentials or generic accounts (such as a “front desk” login used by multiple staff members) make it impossible to trace a specific action to a specific person. The Security Rule’s unique user identification requirement at 45 CFR §164.312(d) reinforces this: every user who accesses a system containing ePHI must have a unique identifier.
Timestamp. Every log entry must include a precise timestamp indicating when the action occurred. Accurate timestamps require that system clocks be synchronized and that the logging system itself be auditable. An entry with no reliable timestamp carries little value in a breach investigation.
The record or system accessed. The log should capture which specific record, file, or system the user accessed. For a healthcare application, this means logging which patient record was viewed or modified, not just that a login occurred.
The action taken. What did the user do? Common actions to log include: viewing a record, creating a record, modifying a record, deleting a record, exporting data, printing, downloading, or attempting any of the above. Failed attempts are also important: a series of failed access attempts against a specific record can be an early indicator of a security incident.
Outcome. Capture whether each action succeeded or failed alongside the action itself. Failed login attempts, failed access attempts to records outside the user’s role, and failed export attempts are all meaningful security signals.
Beyond the baseline, comprehensive audit logging for HIPAA-regulated systems should also capture:
- Administrative actions, including user account creation, role changes, permission modifications, and credential resets
- System configuration changes that affect security controls
- Data export events, including printing, downloading, and bulk exports
- Emergency access events, sometimes called “break-the-glass” access, where a user bypasses normal role restrictions to access a record in an emergency
The practical test for whether your logging is sufficient: if OCR opened an investigation of an unauthorized disclosure that occurred six months ago, could you reconstruct exactly who accessed which patient records, when, and what they did with the information? If the answer is no, the logging implementation has gaps.
How long to retain HIPAA audit logs
This question is more complicated than it appears, because the HIPAA Security Rule’s audit controls standard does not explicitly state a retention period.
The six-year figure that most compliance guidance cites comes from an indirect chain of reasoning. HIPAA’s documentation retention requirement at 45 CFR §164.316(b)(2) states that organizations must retain documentation required by the Security Rule for six years from the date of its creation or the date it was last in effect. Because the Information System Activity Review standard requires that logs be reviewed and that security incidents be documented, those review records and incident records are documentation subject to the six-year clock. Regulators and OCR auditors treat the underlying log data as the evidence supporting that documentation, and accordingly expect the raw log data to be retained for the same period.
The practical argument for six years is straightforward. If OCR investigates a potential breach and requests the audit trail for the period in question, and that period falls within the six-year window, an organization that has already purged its logs has no way to demonstrate what occurred. Consequently, it also cannot rebut a breach finding. The absence of logs in an investigation tends to work against the organization, not in its favor.
When six years is not enough. Several other regulatory frameworks push the retention period beyond HIPAA’s six-year floor:
- Medicare and Medicaid. CMS requires that records for Medicare and Medicaid services generally be retained for at least ten years. Organizations that participate in these programs and handle ePHI should align their audit log retention with the longer of the two requirements.
- State law. Many state medical record retention laws require six to ten years for adult patients and longer for records created when the patient was a minor, sometimes extending to years past the patient’s age of majority. Confirm your state’s requirements.
- Litigation holds. Once an organization reasonably anticipates litigation or a regulatory investigation, it must preserve all relevant records, including audit logs, regardless of routine retention schedules.
The practical recommendation: inventory every retention obligation that applies to your organization, set your audit log retention schedule to satisfy the longest of them, and document that schedule in your written HIPAA policies.
The review requirement: what “regularly review” means in practice
Generating logs satisfies 45 CFR §164.312(b). Reviewing them regularly satisfies 45 CFR §164.308(a)(1)(ii)(D). The regulation does not define “regularly,” but OCR audit protocols and enforcement patterns give practical guidance.
A defensible review program includes the following.
A documented review schedule. The organization’s HIPAA policies must describe who reviews logs, how often, and what they are looking for. Specifically, a review schedule that exists only informally, or that no one follows, will not satisfy the review requirement in an enforcement action.
Documented review records. Each review session should produce a dated record showing that the review occurred, who conducted it, what was examined, and what, if anything, was flagged. A folder full of logs with no record of anyone ever opening them is not a compliant review program.
Anomaly detection and response. Design the review to surface unusual access patterns: access to records outside a user’s normal scope, access outside normal business hours, bulk data exports, repeated failed login attempts, or access to high-risk records such as those belonging to staff members or public figures. When anomalies surface, your program must investigate, document, and resolve them.
Security incident documentation. When the review identifies a potential security incident, document it from detection through resolution. A flagged incident that your documentation never closes is a compliance gap, not a compliance record.
How frequently should reviews occur? The regulation does not specify. Organizations typically align review frequency with their risk profile and system volume: real-time alerting for high-severity anomalies, weekly or monthly reviews for access pattern analysis, and quarterly reviews of access control and permission changes. Larger organizations with high ePHI transaction volumes may require daily monitoring.
The 2026 proposed HIPAA Security Rule update
HHS published a proposed update to the HIPAA Security Rule in 2025. As of September 2026, the rule is proposed but not yet finalized. Covered entities and business associates are still operating under the existing Security Rule. However, the proposed changes are relevant because they signal where enforcement expectations are heading, and building to the proposed standard now is a lower-risk posture than waiting for the rule to finalize.
The proposed update would, among other changes, add more specific logging requirements, require automated real-time monitoring in some contexts, and add enhanced log protection controls. Additionally, it would require that audit log capabilities appear in technology asset inventories.
The full scope of the proposed rule is covered in the HIPAA compliance cornerstone. For healthcare organizations currently evaluating their logging infrastructure, implementing controls that meet the proposed standard does not create additional compliance burden. It simply positions the organization to be compliant when the rule finalizes.
How Knack Health handles record change logs
Knack Health addresses the recording half of the HIPAA audit requirement through record change logs built into the platform at the application layer. The platform automatically logs every access to and modification of a patient record, capturing user identity, timestamp, the record accessed, and the action taken. These logs are not a separate configuration or a premium add-on. They run on every record in every HIPAA plan.
This matters for two practical reasons.
First, application-layer logging captures what system-level logs miss. An IT infrastructure logging tool captures network events, login activity, and system-level access. However, it does not capture which specific patient record a logged-in user opened, what fields they viewed, or what they changed. For HIPAA purposes, the patient record is the ePHI, and the audit trail needs to follow the record, not just the session. Consequently, Knack Health’s record change logs operate at the record level, which is where the HIPAA audit obligation lives.
Second, the audit trail is built into the operational system rather than siloed separately. When a staff member views a patient record, processes an authorization, or updates an intake form submission, Knack Health logs that action in the same system managing the patient record. Staff do not need to interact with a separate compliance layer. The compliance record is a natural byproduct of the operational workflow.
Beyond record change logs, Knack Health’s role-based access controls enforce the access boundaries that audit logs monitor. When access is properly restricted, the audit trail is simpler to review: unusual access is more visible because the baseline is narrower. In short, the two controls work together. For a full breakdown of the platform’s technical safeguard layer, the HIPAA-compliant forms guide covers each requirement.
What Knack Health’s record change logs do not replace: the review obligation. Generating a complete record change log satisfies 45 CFR §164.312(b). Your organization must still implement and document procedures for reviewing those logs regularly per 45 CFR §164.308(a)(1)(ii)(D). The platform handles the recording. The organization handles the review program.
Knack Health HIPAA plans start at $499/mo. Confirm current plan details at knack.com/health/pricing.
Building a practical HIPAA audit log program
For healthcare organizations that need to build or strengthen their HIPAA audit log program, the following steps represent a defensible baseline.
Step 1: Inventory every system that touches ePHI. Your audit logging program is only as complete as the list of systems it covers. For each system, confirm whether logging is enabled by default, what events are captured, and whether the log data is accessible and searchable.
Step 2: Confirm that logs capture the required elements. For each system, verify that logs include user identity, timestamps, the specific record or resource accessed, the action taken, and the outcome. If a system’s logs cannot identify which patient record someone accessed, address that gap before the system handles any more PHI.
Step 3: Document a review schedule and assign ownership. Write the review schedule into your HIPAA policies. Assign a named role or individual responsible for conducting reviews and documenting their findings. Set a cadence appropriate to your system volume and risk profile.
Step 4: Implement documented review records. After each review, produce a dated record showing that the review occurred and what was examined. Additionally, store these records for six years per HIPAA’s documentation retention requirement.
Step 5: Define escalation procedures for anomalies. When a review surfaces an unusual access pattern or a potential security incident, your program needs a defined escalation path: who gets notified, how quickly, and what the investigation and documentation process looks like.
Step 6: Confirm retention settings and protections. Verify that your systems retain logs for at least six years (or longer if state or CMS requirements apply) and that log files are protected against unauthorized modification or deletion. Logs that the users they monitor can edit or delete are not a reliable compliance record.
Step 7: Review the program annually. Review the program annually as part of your HIPAA risk analysis. Confirm that the systems inventory is current, that review records exist for the prior period, and that any incidents identified during the period were documented through resolution.
For a comprehensive checklist of HIPAA technical safeguard requirements, the HIPAA compliance checklist for no-code apps covers each item. For healthcare workflow automation that connects operational events to compliance records, the healthcare workflow automation guide covers how to build HIPAA-aware workflows in Knack Health.
FAQ
What is a HIPAA consent form?
The term “HIPAA consent form” is used informally to describe several different documents: the general consent for treatment, the Notice of Privacy Practices acknowledgment, and the authorization form for non-routine disclosures. In everyday healthcare practice, when staff say a patient needs to sign a “HIPAA consent form” before records are released to a third party, they almost always mean the authorization form. The consent for treatment form covers routine uses of PHI for treatment, payment, and healthcare operations. The authorization form covers everything outside those categories.
Is a HIPAA consent form the same as a HIPAA authorization form?
No. A consent for treatment form documents the patient’s agreement to receive care and permits routine uses of PHI for treatment, payment, and operations. A HIPAA authorization form permits a specific, defined use or disclosure of PHI that falls outside those routine categories. The authorization form has six required elements and three required statements that must all appear on the form. A consent for treatment form does not have the same specific requirements.
When is a HIPAA authorization form required?
An authorization form is required any time a covered entity wants to use or disclose PHI for a purpose that falls outside treatment, payment, and healthcare operations. Common examples include disclosing records to an employer, sharing PHI with a researcher, using patient information in marketing, disclosing records for legal or insurance purposes, and releasing psychotherapy notes. Authorization is also required when a patient requests that their records be sent to a specific third party of their choosing.
Does a patient need to sign an authorization form to receive treatment?
No. The HIPAA Privacy Rule permits covered entities to provide treatment without obtaining a consent or authorization form first. Treatment, payment, and standard healthcare operations do not require patient authorization under federal HIPAA. Many organizations collect a consent for treatment form anyway as a matter of practice, but it is not legally required under HIPAA for the treatment itself to proceed.
What is the Notice of Privacy Practices acknowledgment?
The Notice of Privacy Practices (NPP) is a document covered entities must provide to patients at the first visit, explaining how the organization uses and protects PHI. The acknowledgment is the patient’s signature confirming they received it. It is not a consent form and not an authorization form. It is a receipt. Covered entities must make a good-faith effort to obtain the acknowledgment, but treatment cannot be withheld if a patient declines to sign.
Can a consent for treatment form and an authorization form be combined?
They can appear in the same new-patient packet, but each must be clearly identified as a separate section with its own required elements. A single combined signature block that does not distinguish between the documents creates compliance ambiguity. Combining an authorization for psychotherapy notes with any other authorization in the same document is explicitly prohibited under HIPAA.
How long do HIPAA consent forms and authorization forms need to be retained?
Covered entities must retain authorization forms, consent forms, and NPP acknowledgments for at least six years from the date of creation or from the date the document was last in effect, whichever is later. State law may require longer retention periods for certain document types. Confirm your state’s requirements with legal counsel.
What happens if a patient revokes a HIPAA authorization?
A patient can revoke a HIPAA authorization at any time in writing. The revocation takes effect when the covered entity receives it. Disclosures already completed before the revocation arrived remain valid. After receiving a revocation, the organization must stop any further disclosures under that authorization and update the patient’s record accordingly. Organizations must have a documented process for receiving, recording, and acting on revocations. The HIPAA authorization form guide covers the revocation process in detail.
