HIPAA Security Audit: A Complete Guide to Audit Controls

A HIPAA security audit is how a covered entity or business associate (BA) proves its safeguards work. At the center sits the audit controls standard at 45 CFR § 164.312(b), the technical requirement to record and examine activity in every system that touches ePHI. The HHS Office for Civil Rights (OCR) treats weak audit controls as an aggravating factor in most major enforcement actions.

This guide explains the HIPAA Security Rule, translates it into plain terms, and maps it to NIST controls. It covers audit-log content, program-level requirements, a pre/during/post checklist, testing, encryption, and the platform landscape. It also covers both the audit program (an organizational review practice) and the audit controls standard (the system-level logging requirement at 164.312(b)).

What Is a HIPAA Security Audit?

A HIPAA security audit is a structured review that tests whether an organization’s safeguards for ePHI meet the HIPAA Security Rule. It covers both the audit program that runs the review and the audit controls standard at 164.312(b) that the review inspects.

A HIPAA security audit verifies that a covered entity or business associate has implemented the administrative, physical, and technical safeguards required by the HIPAA Security Rule — anchored by the audit controls standard at 45 CFR § 164.312(b), which mandates hardware, software, and procedural mechanisms that record and examine activity in systems containing electronic protected health information (ePHI).

HIPAA security audits take two forms in practice. An internal audit is a self-assessment the organization runs on its own schedule, usually led by the designated HIPAA Security Officer, to confirm that safeguards work before a regulator asks. An external audit is conducted by an outside party: the HHS Office for Civil Rights under its HIPAA Audit Program, a client exercising a right-to-audit clause, or an independent assessor hired for third-party assurance. Both forms test the same safeguards against the same standards at 45 CFR Part 164 Subpart C.

The audit applies to every covered entity and business associate that handles ePHI: health plans, healthcare clearinghouses, care providers that transmit health data electronically, and the vendors that support them. Common triggers include an annual compliance cycle, onboarding of a new system or business associate, a merger or acquisition, and the period immediately after a security incident.

A complete audit reviews all three safeguard categories in the HIPAA Security Rule. Administrative safeguards cover risk analysis, workforce training, and program ownership. Physical safeguards cover facility access and device and media controls. Technical safeguards cover access control, transmission security, and the audit controls standard itself. Each safeguard is paired with evidence during the review: written policies, system configurations, log samples, and vendor agreements.

The stakes behind that review explain why OCR weighs audit findings so heavily.

Why HIPAA Audits Matter

HIPAA security audits matter because the HHS Office for Civil Rights treats audit-control failures as an aggravating factor in nearly every major enforcement action. The 2024–2025 ransomware wave put audit-trail integrity at the center of OCR’s settlement calculus.

Audit-control and log-retention gaps recur across OCR Resolution Agreements. They appear most often in ransomware cases, where investigators could not reconstruct the breach timeline because logs were missing or incomplete. OCR ran no HIPAA audits from 2017 to 2024. A November 2024 HHS OIG report found that OCR’s earlier audits assessed only 8 of 180 HIPAA requirements and recommended a stronger program. OCR opened its 2024–2025 audit phase covering 50 covered entities and business associates, focused on the Security Rule provisions most relevant to hacking and ransomware attacks. CEs and BAs should expect heightened audit-readiness scrutiny through 2026.

The 2025 HHS Notice of Proposed Rulemaking (NPRM), published January 6, 2025, would require an at-least-annual compliance audit of every Security Rule standard and make several technical controls mandatory, including encryption and multi-factor authentication. It does not create a new audit-log content list or a separate log-retention clock. The comment period closed March 7, 2025, and the rule remains unfinalized as of mid-2026. The HIPAA Security Rule updates for 2026 tracker follows its status.

The stakes are financial as well as regulatory. Healthcare is the most expensive sector for a data breach, at $7.42 million on average in IBM’s 2025 report and the highest of any industry for the 14th consecutive year. HHS’s 2024 Annual Report to Congress on breaches of unsecured PHI attributes the largest breaches to hacking and ransomware incidents. Strong audit logs shorten incident-response time and support the breach-notification analysis. Two terms carry the rest of this guide. The audit program is the organizational review practice. Audit controls are the specific technical requirement at 164.312(b). The regulation itself is where the standard begins.

HIPAA Audit Controls Standard

The audit controls standard at 45 CFR § 164.312(b) requires every covered entity and business associate to record and examine activity in systems that hold ePHI. The standard is Required, not Addressable, and has no implementation specifications beneath it.

The regulation reads: “Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic protected health information.”

In plain terms, the standard carries three obligations. “Record” means capturing activity in logs. “Examine” means reviewing those logs. Implicit between them is retention, since a log cannot be examined if it was never stored.

The phrase “information systems that contain or use” ePHI sets the scope: every system in the ePHI asset inventory produced during the HIPAA risk assessment. And “hardware, software, and/or procedural mechanisms” means HHS prescribes no specific technology. A security information and event management (SIEM) system, native operating-system audit logs, application-level logging, and a documented procedural review cycle all qualify when implemented appropriately.

Because 164.312(b) is Required, an organization cannot substitute a documented alternative the way it can for an addressable specification. The capture-and-examine activity must happen for every ePHI-containing system. HHS does not prescribe specific log fields, retention periods, or review cadence. That flexibility is the source of most enforcement findings. Organizations under-specify their audit-control program and get cited for inadequate evidence.

Official guidance is thin. OCR has not published a dedicated FAQ for 164.312(b). The clearest sources are HHS OCR Security Series Paper 4 (Technical Safeguards) and the audit-controls test procedures in the HHS OCR Audit Protocol. The 2025 NPRM would tighten audit expectations by requiring a documented annual compliance audit, but it does not prescribe specific log-content fields or a distinct retention period beyond the existing six-year documentation rule.

The strongest implementation reference is NIST. NIST SP 800-66 Rev. 2 (§ 6.3) maps 164.312(b) to the NIST SP 800-53 audit family: AU-2 (Event Logging), AU-3 (Content of Audit Records), AU-6 (Audit Record Review, Analysis, and Reporting), AU-11 (Audit Record Retention), and AU-12 (Audit Record Generation). Organizations running a federal program can adopt the NIST 800-53 AU control family for a more prescriptive pattern. The HIPAA Security Rule crosswalk to NIST provides the function-level mapping. Within the HIPAA Security Rule, 164.312(b) sits inside the HIPAA technical safeguards at 164.312, alongside Access Control, Integrity, Authentication, and Transmission Security.

A concrete example: a 200-bed hospital satisfies 164.312(b) by piping electronic health record (EHR) application logs, operating-system access logs, and database query logs into a SIEM with six-year retention. Its audit-control documentation records a quarterly log-review cadence by the security operations team and an annual sample review by the designated HIPAA Security Officer.

With the standard defined, the next question is what the logs must actually capture.

What HIPAA Audit Logs Must Capture

HIPAA audit logs must capture activity in any information system that contains or uses ePHI. At minimum, that means access events, modification events, and authentication events tied to identifiable users. HHS does not enumerate required content, so NIST SP 800-92 (log management) and NIST SP 800-53 AU-3 serve as the de facto standard. For certified electronic health record technology, ONC’s audit-log certification criterion at 45 CFR 170.315(d)(2) specifies concrete elements — user, action, timestamp, and affected record — that 164.312(b) leaves undefined.

Six event categories cover most ePHI systems. Access events record who accessed ePHI, when, from where, and through which system. Modification events cover create, read, update, and delete operations. Authentication events cover successful and failed logins and multi-factor outcomes. Privileged actions cover admin-level changes and account management. System events cover service starts, stops, and security-relevant configuration changes. Disclosure events cover outbound transmissions involving ePHI.

Per NIST SP 800-53 AU-3, each log entry should carry a consistent field set:

Retention is not fixed in 164.312(b). The Documentation standard at 164.316(b)(2)(i) requires policies and procedures to be retained for six years. Most practitioners apply the same six-year window to audit logs by analogy. No primary OCR guidance states that this six-year clock covers operational audit logs rather than the policies documenting audit-control procedures, so six-year log retention is a defensible convention, not settled OCR doctrine. The 2025 NPRM adds no separate log-retention period. Organizations running HIPAA alongside a federal program typically align log content to the NIST 800-53 AU control family, which gives prescriptive, defensible language. Log content is one piece. The program-level requirements are another.

HIPAA Security Audit Requirements

A defensible HIPAA security audit program combines the technical capture-and-review obligations of 164.312(b) with adjacent Security Rule standards that govern evaluation, documentation, and program ownership.

Four standards frame those requirements. Section 164.308(a)(1)(ii)(D), Information System Activity Review, is Required and makes the “examine” obligation explicit at the administrative level. Section 164.308(a)(8), Evaluation, is Required and covers periodic assessment of how well safeguards meet the Rule. Section 164.316(b) requires policies, procedures, and audit records to be retained for six years. And 164.308(a)(1)(ii)(B), Risk Management, is where audit findings feed the risk register, tying the program back to the HIPAA risk assessment cadence.

Ownership is explicit. The designated HIPAA Security Officer (164.308(a)(2)) owns the audit program, and its documentation must define scope, cadence, reviewers, escalation, and remediation tracking. Cadence typically runs on four tracks: continuous log capture, quarterly or more frequent operational review by the security operations team, an annual program-level audit, and trigger-based reviews after an incident or a system change. For multi-framework programs, NIST SP 800-66 Rev. 2 § 6.3 maps the HIPAA audit obligations to NIST 800-53 controls AU-1 through AU-12. To assess whether continuous log review is working as intended, NIST SP 800-137A provides a program-level evaluation methodology, and HHS’s Health Industry Cybersecurity Practices (HICP) frames log collection and security-operations monitoring as baseline practices for healthcare environments. Readers scoping the work want a flat checklist to run.

HIPAA Security Audit Checklist

A HIPAA security audit checklist runs the cycle across three phases: pre-audit preparation, the audit itself, and post-audit follow-up.

Pre-audit

• [ ] Confirm audit scope (systems, business associates, data flows)
• [ ] Inventory in-scope ePHI assets and business associates
• [ ] Confirm audit-control configuration (log sources, retention, review cadence)
• [ ] Verify documented policies and procedures (164.316(b))
• [ ] Confirm Security Officer assignment and program ownership
• [ ] Pull recent risk-analysis output for cross-reference

During the audit

• [ ] Test a sample of audit logs for completeness (164.312(b))
• [ ] Verify log retention against documented policy
• [ ] Test access control (164.312(a)), integrity (164.312(c)), and authentication (164.312(d))
• [ ] Test transmission security and encryption in transit (164.312(e))
• [ ] Sample BA agreements and BA security questionnaires
• [ ] Interview the Security Officer and system owners

Post-audit

• [ ] Document findings with severity ratings
• [ ] Map each finding to its originating safeguard (164.308 / .310 / .312)
• [ ] Create a remediation plan with owners and due dates
• [ ] Update the risk register with audit findings
• [ ] Schedule a re-test cadence
• [ ] Archive audit artifacts (six-year retention per 164.316(b)(2)(i))

The checklist mirrors the HHS OCR Audit Protocol, so it doubles as audit-prep documentation. Readers running it want artifacts to power each step.

HIPAA Audit Templates and Questionnaires

Several free templates and questionnaires support a HIPAA security audit. The most authoritative are the HHS OCR audit protocol, NIST SP 800-66 Rev. 2 implementation worksheets, and the SaltyCloud HIPAA Security Rule Crosswalk Toolkit.

The HHS OCR Audit Protocol enumerates the test procedures OCR auditors use during a HIPAA Audit Program review. Reading it is the cleanest way to anticipate what an audit examines. It is free on hhs.gov and structured by Privacy Rule, Security Rule, and Breach Notification Rule sections. NIST SP 800-66 Rev. 2 (Feb 2024) replaces the original 2008 publication and includes implementation worksheets that map HIPAA standards to NIST SP 800-53 controls. Those worksheets help organizations running HIPAA alongside NIST CSF or 800-53.

HIPAA security questionnaires distribute audit testing across system owners, department heads, and business associates. They turn the checklist above into something a multi-site organization can actually run, and several vendors, including Isora GRC, maintain prebuilt libraries.

For reference, access our HIPAA Security Rule Crosswalk Toolkit, a free mapping of every Security Rule control to NIST CSF and 800-53.

HIPAA Security Testing

HIPAA security testing (vulnerability scanning, penetration testing, and tabletop exercises) is not explicitly named in the Security Rule. It is how covered entities and business associates fulfill the periodic-evaluation requirement at 164.308(a)(8).

Section 164.308(a)(8) requires a “periodic technical and non-technical evaluation” of how well safeguards meet the Rule. Penetration testing and vulnerability scanning are the most defensible technical evaluations, and NIST SP 800-66 Rev. 2 references industry-standard cadences. Common testing types include:

• Vulnerability scanning, a quarterly practitioner baseline
• Penetration testing, an annual baseline covering ePHI systems and authentication boundaries
• Web-application testing for patient portals and BA-facing apps
• Tabletop exercises of incident-response playbooks
• Phishing simulation of security-awareness controls under 164.308(a)(5)

Scope should match the ePHI asset inventory from the HIPAA risk assessment. Business associates belong in the program through right-to-audit clauses in their agreements or through BA-provided attestations such as a SOC 2 Type II report plus a penetration-test letter. Test reports become audit artifacts under 164.316(b), and findings feed the risk register. Encryption is the safeguard whose testing comes up most often in audits.

Encryption Guidance — 45 CFR § 164.312(a)(2)(iv)

HIPAA’s encryption guidance lives at 45 CFR § 164.312(a)(2)(iv) (encryption of ePHI at rest) and 164.312(e)(2)(ii) (encryption in transit). Both are addressable, but HHS treats encrypted ePHI as not “unsecured” under the Breach Notification Rule, which makes encryption a de facto safe harbor.

“Addressable” does not mean optional. For an addressable specification, an organization must implement it, document an equivalent alternative, or document why implementation is not reasonable and appropriate. Enforcement actions involving lost or stolen unencrypted devices consistently treat the absence of encryption as an aggravating factor. The safe harbor is the reason encryption carries such weight. Under HITECH § 13402(h) and the Breach Notification Rule (164.402), encrypted ePHI is not “unsecured.” The loss of an encrypted device generally does not trigger notification. HHS guidance on rendering PHI unusable, unreadable, or indecipherable defines the encryption and destruction methods that qualify. The 2025 NPRM would make encryption mandatory at rest and in transit with limited exceptions, but that remains proposed, not current law.

HHS references NIST for acceptable methods. At rest, NIST SP 800-111 and Federal Information Processing Standards (FIPS) 140-2/3-validated cryptographic modules apply. In transit, NIST SP 800-52 Rev. 2 governs Transport Layer Security (TLS), with TLS 1.2 as the minimum and TLS 1.3 preferred. Encryption also connects back to audit controls. Auditors verify that encryption is configured, that key management is documented, and that encryption status is logged. That ties the safeguard to 164.312(b). The technology landscape that supports the program comes next.

HIPAA Audit Platforms

HIPAA audit platforms fall into two categories: technical-control platforms that satisfy 164.312(b) at the system level, and governance, risk, and compliance (GRC) or audit-management platforms that run the program-level audit cycle.

Technical-control platforms capture and examine activity directly:

• SIEM tools such as Splunk, Microsoft Sentinel, and Elastic
• Log-management tools such as Datadog and Sumo Logic
• Vulnerability scanners such as Tenable, Qualys, and Rapid7, which support the periodic evaluation under 164.308(a)(8)
• Cloud-native audit logs such as AWS CloudTrail and Azure Activity Log for cloud-hosted ePHI

GRC and audit-management platforms operate at the program level. They run the checklist, distribute questionnaires, track findings, manage remediation, and produce audit-defensible documentation. They fit multi-site CEs and organizations running HIPAA alongside NIST CSF, NIST 800-53, or the Gramm-Leach-Bliley Act (GLBA).

Selection criteria that matter: HIPAA-specific prebuilt content, an append-only audit log of program activity, multi-framework reuse, a BA inventory and assessment workflow, and six-year retention defaults. See HIPAA Security Rule compliance software for Isora GRC’s HIPAA audit-management capabilities.

How to Support a HIPAA Audit Program with Isora GRC

Isora GRC, the GRC Assessment Platform™, runs the program-level side of a HIPAA security audit: it distributes assessments, captures findings, and ties every audit artifact back to the safeguard it maps to. It does not perform system-level logging; it runs the audit program around those logs.

Prebuilt HIPAA questionnaires aligned to 164.308, 164.310, and 164.312 let system owners, department heads, and business associates complete audit assessments without training.

Risk management with an append-only audit log routes each finding into a connected risk register with full lineage back to its originating safeguard, producing the documented, current record OCR expects.

Download the HIPAA Security Rule Crosswalk Toolkit to map every Security Rule control to NIST CSF and 800-53, or see how Isora GRC supports HIPAA audits on the HIPAA Security Rule compliance software page.

Key Takeaways

A HIPAA security audit verifies the technical, physical, and administrative safeguards required by 45 CFR Part 164 Subpart C, anchored by the audit controls standard at 164.312(b). Audit-control failures are among the most-cited OCR findings, so a defensible 2026 program means strong log content, a documented review cadence, and audit-trail integrity.

Download the HIPAA Security Rule Crosswalk Toolkit, a free PDF mapping every Security Rule control to NIST CSF and 800-53, and see how Isora GRC supports HIPAA audits on the HIPAA Security Rule compliance software page.

HIPAA Security Audit FAQs

What is a HIPAA security audit?

A HIPAA security audit verifies that a covered entity or business associate has implemented the administrative, physical, and technical safeguards required by the HIPAA Security Rule. It reviews policies, procedures, system configurations, audit logs, and business-associate agreements against the standards at 45 CFR Part 164 Subpart C.

What are HIPAA audit controls under 164.312(b)?

HIPAA audit controls under 45 CFR § 164.312(b) are the hardware, software, and procedural mechanisms that record and examine activity in information systems containing ePHI. The standard is Required, not Addressable, and applies to every ePHI-containing system in scope.

How long must HIPAA audit logs be retained?

HIPAA does not specify a fixed audit-log retention period. The Documentation standard (45 CFR § 164.316(b)(2)(i)) requires policies and procedures to be retained for six years, and most practitioners apply the same six-year window to audit logs.

Is penetration testing required by HIPAA?

HIPAA does not name penetration testing as a required control. Section 164.308(a)(8) does require a periodic technical and non-technical evaluation of safeguards, and penetration testing is the most defensible technical evaluation. Annual penetration testing is the practitioner baseline.

Who enforces HIPAA security audits?

The HHS Office for Civil Rights (OCR) enforces the HIPAA Security Rule and runs the HIPAA Audit Program. State Attorneys General can also bring HIPAA enforcement under HITECH § 13410(e), an authority used far less often than OCR’s. Internal HIPAA security audits are typically owned by the designated HIPAA Security Officer.

What is the difference between an audit and audit controls under HIPAA?

An audit is the program-level review activity, internal or external, that evaluates safeguard implementation. Audit controls are the system-level technical requirement at 164.312(b) for capturing and examining activity logs. A HIPAA security audit verifies, among other things, that audit controls are implemented.

Does HIPAA require encryption?

HIPAA’s encryption specifications at 164.312(a)(2)(iv) and 164.312(e)(2)(ii) are addressable, not required. HHS Breach Notification guidance treats encrypted ePHI as not “unsecured,” which makes encryption a de facto safe harbor. Enforcement actions involving unencrypted devices treat the absence of encryption as an aggravating factor.

Does HIPAA apply to university health centers?

Yes. When a college or university delivers health care and transmits ePHI electronically, that unit is a HIPAA covered entity, and most institutions designate it as a hybrid entity so HIPAA applies only to the health-care component. The HHS and Department of Education Joint Guidance on FERPA and HIPAA explains when student treatment records fall under FERPA versus HIPAA, and HIPAA-covered components carry the same 164.312(b) audit-control obligations as any other covered entity.

This content is for informational purposes only and does not constitute legal or compliance advice. See our full disclaimer.