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) named audit controls among the key areas for improvement in its 2024 breach investigations.

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 the HIPAA Security Rule requires. Its anchor is the audit controls standard at 45 CFR § 164.312(b). That standard 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, such as the HHS Office for Civil Rights under its HIPAA Audit Program. Other outside parties include a client exercising a right-to-audit clause and 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. That group includes health plans, healthcare clearinghouses, care providers that bill or conduct other standard transactions 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, while 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 OCR’s 2024 breach investigations flagged audit controls and information system activity review as key areas for improvement. OCR’s 2024–2026 ransomware settlements most often cite a missing or inadequate risk analysis.

Many OCR Resolution Agreements include corrective action plans that require regular review of audit logs. Few list an audit-control failure among their findings, although Montefiore Medical Center’s 2024 agreement did after an employee sold patient data.

After its 2016–2017 Phase 2 audits, OCR ran no HIPAA audits until 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. Several technical controls would also become mandatory, including encryption and multi-factor authentication. Audit logging would move to real-time recording of all activity in relevant systems, with retention periods set by each entity’s policies.

The comment period closed March 7, 2025, and the rule remains unfinalized as of mid-2026. The latest Unified Agenda lists it as a long-term action, with final action projected for July 2027.

The stakes are financial as well as regulatory, since healthcare is the most expensive sector for a data breach. IBM’s 2025 report puts the average at $7.42 million, the highest of any industry for the 12th 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, while 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 covered entities and business associates 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, and “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, even though HHS does not prescribe specific log fields, retention periods, or review cadence. That flexibility is the source of most enforcement findings, because organizations under-specify their audit-control program and get cited for inadequate evidence.

Official guidance is thin, although OCR devoted its January 2017 Cybersecurity Newsletter to audit controls. Other useful 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 real-time activity logging and a documented annual compliance audit. Even so, it does not prescribe specific log-content fields, and each entity’s own policies would set the log-retention period.

The strongest implementation reference is NIST SP 800-66 Rev. 2, whose Appendix D crosswalk maps 164.312(b) to seven NIST SP 800-53 AU-family controls. They are AU-1, AU-2, AU-3, AU-4, AU-6, AU-7 and AU-8, covering logging policy, event logging, record content, log storage, review, report generation and time stamps. 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 is a 200-bed hospital that satisfies 164.312(b) by piping three log streams into a SIEM with six-year retention. Those streams are electronic health record (EHR) application logs, operating-system access logs, and database query logs. The hospital’s 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 that 164.312(b) leaves undefined. Those elements are the user, the action, the timestamp, and the affected record.

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, and 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, while 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. Six-year log retention is therefore a defensible convention, though not settled OCR doctrine, and 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, and 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 governing 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 records of required actions, activities, and assessments 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, beginning with continuous log capture and quarterly or more frequent operational review by the security operations team. The other two tracks are 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 Appendix D maps the HIPAA audit obligations to 800-53 AU, CA, IR and SI controls. To assess whether continuous log review is working as intended, NIST SP 800-137A provides a program-level evaluation methodology. 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, the NIST SP 800-66 Rev. 2 key-activity tables, and the SaltyCloud HIPAA Security Rule Crosswalk.

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 Rev. 1 from 2008. Its Appendix D crosswalk, published online in NIST’s CPRT tool, maps HIPAA standards to NIST SP 800-53 controls. That crosswalk helps 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, 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. Covered entities and business associates use it to fulfill the periodic-evaluation requirement at 164.308(a)(8).

Section 164.308(a)(8) requires a “periodic technical and nontechnical 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 lists penetration testing where reasonable and appropriate. 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. An organization must implement an addressable specification if it is reasonable and appropriate. Otherwise it must document why and implement an equivalent alternative if that is 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, HHS points to NIST SP 800-111. In transit, it points to NIST SP 800-52 for Transport Layer Security (TLS) and to other Federal Information Processing Standards (FIPS) 140-2-validated processes. NIST SP 800-52 Rev. 2 sets TLS 1.2 as the minimum and has required federal systems to support TLS 1.3 since January 2024.

Encryption also connects back to audit controls. Auditors verify that encryption is configured, that key management is documented, and that encryption status is logged, which 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, beginning with technical-control platforms that satisfy 164.312(b) at the system level. The other category is governance, risk, and compliance (GRC) or audit-management platforms, which 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, where 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 program audit log, 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. Rather than performing 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. Each finding keeps full lineage back to its originating safeguard, which produces the documented, current record OCR expects.

Download the HIPAA Security Rule Crosswalk to map every Security Rule control to NIST CSF and 800-53. To see how Isora GRC supports HIPAA audits, visit 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). OCR flagged audit controls as a key area for improvement in its 2024 breach investigations. A defensible 2026 program therefore means strong log content, a documented review cadence, and audit-trail integrity.

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

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 the HIPAA Security Rule requires. 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. 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?

A college or university is a HIPAA covered entity when it provides health care and bills health plans or conducts other covered transactions electronically. It can then become a hybrid entity, so HIPAA applies only to its designated health-care component. The HHS and Department of Education Joint Guidance on FERPA and HIPAA explains that FERPA generally governs student records at campus clinics. 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.