HIPAA Audit Preparation: An 8-Step Checklist for OCR Audits and Self-Audits
Group COO & CISO
Operational excellence, governance, and information security. Aligns technology, risk, and business outcomes in complex IT environments
HIPAA Audit Preparation: An 8-Step Checklist for OCR Audits and Self-Audits
An OCR audit is not a hypothetical. The Office for Civil Rights conducts compliance reviews triggered by patient complaints, breach reports, media coverage, and the periodic audit programme authorised by §13411 of the HITECH Act. The 2016-2017 Phase 2 audit programme reviewed 166 covered entities and 41 business associates; OCR has signalled that future audit waves will continue, and complaint-driven investigations have not slowed — OCR resolved 31,395 complaint cases in fiscal year 2023 alone. Preparation is not optional. The question is whether your team has done it before the letter arrives.
This checklist is built from the artefacts OCR investigators actually request in the initial document production list, the items they consistently cite as missing in resolution agreements, and the structure of the HHS Audit Protocol last updated in 2024. It applies to both formal OCR audits and the self-audits a mature compliance programme runs annually under §164.308(a)(8).
Step 1: Build the ePHI Asset Inventory
Every audit starts with the same question: what systems, applications, and datasets create, receive, maintain, or transmit ePHI? If you cannot answer that in writing, the rest of the audit goes badly. The inventory should list every system, the categories of ePHI it handles, the location (cloud account, region, on-prem facility), the responsible owner, the BAA covering any vendor in the data path, and the controls implementing the §164.312 technical safeguards.
Most organisations discover during this exercise that ePHI has spread to systems no one knew about: a developer's S3 bucket of de-identification test data that turned out to be re-identifiable, a vendor analytics platform receiving extracts from the EHR, a Slack channel where care coordinators posted patient details. Find these before OCR does.
Step 2: Produce a Current Security Risk Analysis
The §164.308(a)(1)(ii)(A) risk analysis is the most-cited deficiency in OCR enforcement actions. The 2024 HHS Guidance on Risk Analysis Requirements describes the expected methodology: scope, threat identification, vulnerability identification, assessment of current security measures, likelihood determination, impact determination, risk determination, and documentation.
A risk analysis OCR will accept has six properties: it covers the entire ePHI estate (not just the EHR), it is documented in writing, it is current (within the last 12 months for most organisations), it identifies real threats and vulnerabilities (not generic categories), it produces a prioritised risk register, and it ties to the §164.308(a)(1)(ii)(B) risk management plan that drives remediation. NIST SP 800-30 Rev. 1 is the baseline methodology HHS endorses.
Need expert help with hipaa audit preparation?
Our cloud architects can help you with hipaa audit preparation — from strategy to implementation. Book a free 30-minute advisory call with no obligation.
Step 3: Inventory and Verify Every Business Associate Agreement
Under §164.308(b) and §164.314(a), a covered entity must have a written BAA with every business associate before disclosing ePHI. The BAA must include the elements specified in §164.504(e): permitted uses, prohibition on further disclosure, safeguard requirements, breach notification obligations, subcontractor flow-down, and termination provisions.
Pull the master vendor list, filter to vendors that touch ePHI, and verify a signed BAA exists for each one. Audit the BAA terms against the §164.504(e) checklist. Confirm any subcontractor with ePHI access has a flow-down BAA from the prime BA. Memorial Hermann (OCR settlement, 2017, $2.4 million) and Triple-S (2015, $3.5 million) both included missing or deficient BAAs in their resolution agreements.
Step 4: Pull Audit Logs and Access Reviews
The §164.312(b) audit-controls standard and the §164.308(a)(1)(ii)(D) information-system-activity-review standard require not only that you collect logs but that you review them. OCR investigators routinely ask for evidence of periodic log review, not just the existence of logs.
For each ePHI system, document the log sources (CloudTrail, application audit logs, database audit logs, EHR access logs), the retention period (HIPAA does not specify a number; six years is the de facto floor because §164.530(j) requires that policies be retained six years), the SIEM or review tooling, the review cadence, and the documented outputs of recent reviews. Show OCR the log entries plus the ticket history of investigations triggered by them.
Step 5: Validate Encryption and Transmission Security
OCR's working assumption is that any laptop, server, database, backup, or transmission containing ePHI is encrypted to NIST-approved standards. Demonstrate this with concrete evidence per system: AES-256 at rest with documented key management (KMS, Key Vault, Cloud KMS), TLS 1.2+ in transit with mTLS for service-to-service, encrypted backups, encrypted device-level storage on every workstation and mobile device.
The HHS Guidance to Render Unsecured PHI Unusable provides safe harbour: ePHI encrypted to FIPS 140-2 (now FIPS 140-3) approved standards is not "unsecured PHI." A laptop loss with verifiable encryption is not a reportable breach. A laptop loss without it is the most expensive single mistake in HIPAA, period.
Step 6: Document the Workforce Security Lifecycle
The §164.308(a)(3) workforce security and §164.308(a)(4) information-access-management standards require documented authorisation, clearance, and termination procedures. Pull a sample of recent hires and terminations and walk through them: who approved access, what role was provisioned, what access reviews have run since, what was deprovisioned on termination, what residual access (former-employee API keys, shared service accounts, unrevoked SSH keys) was checked.
The recurring failure mode is the contractor or terminated employee whose access lingered. New York Presbyterian / Columbia University (2014, $4.8 million) included an inadequate workforce-security implementation in the underlying breach. Document the joiner-mover-leaver process and prove it runs.
Step 7: Test the Incident Response and Contingency Plans
The §164.308(a)(6) security-incident procedures and §164.308(a)(7) contingency plan must exist in writing and must be tested. OCR does not accept a binder on a shelf — they want evidence the plan has been exercised. The contingency plan has six implementation specifications: data backup plan (required), disaster recovery plan (required), emergency mode operation plan (required), testing and revision (addressable), applications and data criticality analysis (addressable), and the security-incident procedures sit alongside.
Run a tabletop exercise at least annually. Produce a memo documenting the scenario, participants, findings, and remediation actions. Do the same for a backup-restore test and a failover test. The artefacts are short — three to five pages each — but the absence of them is a finding waiting to happen.
Step 8: Prepare the Initial Document Production Package
When an OCR Letter of Authorisation arrives, the entity has typically 30 days to produce a defined list of documents. Assemble the package in advance:
- Current Security Risk Analysis and Risk Management Plan
- Privacy Rule and Security Rule policies and procedures (the full P&P set)
- Notice of Privacy Practices and acknowledgements
- Workforce training materials and completion records
- BAA register and sample agreements
- Sample audit logs and evidence of system activity reviews
- Incident response plan, contingency plan, and most recent test results
- Sanction policy and sample sanction records (anonymised)
- Most recent §164.308(a)(8) periodic evaluation
- Asset inventory and network diagram for ePHI systems
Treat this as a living package the compliance team refreshes quarterly. The first time it is assembled in a hurry under a 30-day OCR clock is the worst time to find out it is incomplete.
How Opsio Helps
Opsio runs HIPAA audit-readiness engagements for healthcare providers, payers, and business associates preparing for OCR audits, internal-audit reviews, or customer due diligence. Our HIPAA compliance services for healthcare include risk analysis facilitation, BAA inventory and gap remediation, technical-safeguard validation across cloud and on-prem estates, IR and contingency-plan tabletop exercises, and the documentation packaging that turns a control set into an audit response. We commonly pair the work with compliance readiness review and penetration and vulnerability testing so the technical evidence is current when the auditor arrives.
About the Author
Group COO & CISO
Fredrik is the Group Chief Operating Officer and Chief Information Security Officer at Opsio. He focuses on operational excellence, governance, and information security, working closely with delivery and leadership teams to align technology, risk, and business outcomes in complex IT environments. He leads Opsio's security practice including SOC services, penetration testing, and compliance frameworks.
Editorial standards: This article was written by a certified practitioner and peer-reviewed by our engineering team. We update content quarterly to ensure technical accuracy. Opsio maintains editorial independence — we recommend solutions based on technical merit, not commercial relationships.