Most healthcare organizations believe they are more prepared for a HIPAA audit than they actually are. They have policies. They run annual training. They have a signed stack of Business Associate Agreements somewhere in a shared drive. What they often do not have is the thing that matters most when an assessor walks in the door: evidence.
The distinction between having a security program and being able to prove you have a security program is where most HIPAA audit failures happen. OCR’s audit protocol is not designed to take your word for it. It is designed to test whether the controls you say are in place are actually operational — and whether you can demonstrate that through contemporaneous, documented, independently verifiable records. Policies without logs. Training without completion records. Encryption without verification. These are the gaps that turn a routine assessment into a corrective action plan, and a corrective action plan into a financial penalty.
Understanding precisely what an assessor will ask for — and in what order — is the first step toward being genuinely ready.
How Assessors Actually Work
HIPAA assessors, whether conducting an OCR audit, a third-party compliance review, or a pre-audit readiness assessment, follow a structured protocol that maps to the Security Rule’s administrative, physical, and technical safeguard requirements. The HHS OCR Audit Protocol, last updated in 2016 and referenced in every subsequent enforcement action, identifies 180 audit procedures across those three domains.
In practice, assessors work from the outside in — starting with governance and documentation, then moving progressively toward technical validation. The further into that process they go without finding complete evidence, the more scrutiny everything behind it receives. A missing risk analysis at the top of the review does not just create a finding about the risk analysis. It signals to the assessor that the entire program may be underdeveloped, and they will look harder at everything downstream.

Tier 1: Policies, Governance & Risk Analysis
The first thing an assessor will request is your written security policies — and specifically, your most recent risk analysis. Under 45 CFR §164.308(a)(1), a thorough, organization-wide risk analysis is not optional. It is the foundational requirement from which every other security control is supposed to flow.
What assessors look for is not the existence of a risk analysis document but the quality and currency of it. Is it organization-wide, or does it cover only part of the environment? Does it identify specific threats and vulnerabilities, assess their likelihood and impact, and document the controls in place to address them? Has it been updated to reflect changes in the environment — new cloud infrastructure, new vendors, new clinical systems?
Alongside the risk analysis, assessors will request workforce training records. Not a policy stating that training is required — actual completion logs, with names, dates, and the content covered. Sanction policy documentation, breach notification procedures, and the designation of a security official are all reviewed at this stage. If any of these are missing or undated, the assessment has already found findings before reaching a single technical control.
Tier 2: Access Controls & Identity Management
Access control is where administrative policy meets technical reality, and it is one of the most common areas where the two diverge. The HIPAA Security Rule requires unique user identification, emergency access procedures, automatic logoff, and encryption or equivalent safeguards for workstation access — all of which must be demonstrable through evidence, not assertion.
Assessors will request samples. They will ask to see the user provisioning and deprovisioning process, and then they will ask for evidence that it was followed for specific employees — including those who have left the organization. Terminated accounts that remain active are a recurring and consequential finding. Role-based access reviews, showing that permissions were examined and confirmed appropriate on a scheduled basis, are expected to exist as documented records, not as informal processes someone performs but does not record.
Multi-factor authentication enforcement is increasingly a specific focus area. If MFA is described as a control but logs cannot confirm it is enforced for all users accessing systems containing PHI — including remote access, cloud platforms, and administrative consoles — the control is considered unverified.
Tier 3: Audit Logs & Activity Monitoring
Under 45 CFR §164.312(b), covered entities are required to implement hardware, software, and procedural mechanisms to record and examine access and other activity in systems containing PHI. In an OCR audit or post-breach investigation, audit logs are often the most consequential evidence category — both for what they contain and for what their absence reveals.
Assessors will ask three things: are logs being generated, are they being retained for an appropriate period, and are they being reviewed? All three must be demonstrable. Logs that exist but are never reviewed satisfy the first requirement and fail the other two. A documented log review process — showing who reviews what, on what cadence, and what the response procedure is when anomalies are identified — is what assessors are looking for.
The absence of audit logs is particularly damaging in a post-breach context. If an incident occurs and logs are incomplete or missing, the organization cannot determine what was accessed, by whom, or for how long. OCR has assessed penalties specifically for the absence of audit controls, independent of whether a breach was confirmed.
Tier 4: Technical Safeguard Validation
This is where the evidence requirements become the most technically specific — and where many organizations discover that their documentation significantly overstates their actual control posture.
Encryption evidence is the most common gap. Policies stating that PHI is encrypted in transit and at rest are common. Documentation confirming that encryption is actually implemented across all systems, storage volumes, laptops, backup media, and cloud environments — with key management practices that meet current standards — is far less common. Assessors may request configuration evidence, not just policy statements.
Patch and vulnerability management documentation is examined closely. What is the organization’s defined SLA for remediating critical vulnerabilities? Is there evidence that it is being met? Vulnerability scan results, with remediation tracking showing open findings, assigned owners, and closure dates, are the expected form of evidence. Assessors want to see a living process, not a one-time scan result.
This is also where offensive security activity — penetration testing — becomes directly relevant to a HIPAA audit readiness posture, even if it is not explicitly required by the Security Rule. An organization that can produce documentation of independent penetration testing, including findings and evidence of remediation, demonstrates a level of technical diligence that significantly strengthens its position. It shows that vulnerability management is not just self-reported — it has been adversarially validated. For organizations that have undergone a prior OCR enforcement action, or that operate in high-risk environments, this kind of evidence carries meaningful weight.
Tier 5: Incident Response, Breach Records & Vendor Management
The final tier of evidence an assessor will examine covers how the organization has handled incidents, how it manages vendors, and whether its breach response program has been tested.
Incident response documentation should include a written IR plan, records of tabletop exercises or simulations, and — if applicable — records of actual incidents handled, including the timeline from discovery to notification. OCR’s breach notification rule requires covered entities to notify affected individuals within 60 days of discovery. Evidence that this timeline was met, or documentation explaining why it was not, will be reviewed.
Business Associate Agreement inventory is examined both for completeness and currency. Assessors will ask whether every vendor with access to PHI has a signed BAA, whether those agreements have been updated to reflect current HIPAA requirements, and whether there is a process for identifying new vendor relationships before PHI access is granted. A single vendor without a BAA is a finding. A pattern of incomplete BAA management suggests systemic gaps in the program.
Vendor security assessment records — evidence that the organization has evaluated the security posture of its most critical business associates — are increasingly expected, particularly in organizations that have experienced third-party-originating breaches or that handle large volumes of sensitive PHI.
The Evidence Gap Most Organizations Don’t See Coming
The most common HIPAA audit failure mode is not ignorance of the requirements — it is the gap between a program that exists on paper and a program that can be demonstrated through records. Healthcare security leaders who invest in building genuine, operational controls, and who document that those controls are working on an ongoing basis, are in a fundamentally different position than those who assemble documentation reactively when an audit is announced.
The organizations that navigate assessments with the fewest findings are those that treat audit readiness as a continuous operational state, not a pre-audit sprint. Their risk analysis is updated when the environment changes. Their access reviews happen on schedule and are recorded. Their audit logs are reviewed regularly and the reviews are documented. Their incident response plan has been tested within the last twelve months. Their BAA inventory is maintained in real time.
That posture is not built in the weeks before an assessor arrives. It is built over time, through consistent program execution — and demonstrated through the evidence that execution leaves behind.
Ready to assess your current HIPAA evidence posture before an assessor does?Learn more at sprocketsecurity.com or reach out at contact@sprocketsecurity.com.