For a small healthcare practice, the phrase "OCR audit" lands somewhere between a parking ticket and an IRS letter: vaguely threatening, poorly understood, and assumed to be somebody else's problem until it isn't. The reassuring part, if there is one, is that the mechanics are not secret. The HHS Office for Civil Rights publishes its audit authority, its enforcement process, and the actual audit protocol that auditors work from. A practice that has read those three documents knows more about what is coming than most practices that get the letter.

Here is what OCR actually does, in the order it does it, and why one document matters more than all the others.

Where the authority comes from

OCR's audit authority is not discretionary improvisation. The HITECH Act directs HHS to conduct periodic audits of covered entities and business associates to assess compliance with the HIPAA Privacy, Security, and Breach Notification Rules. The OCR HIPAA Audit Program page documents this authority and the program's history: the 2016-2017 audit round examined 166 covered entities and 41 business associates, and OCR has described renewed audit activity focused on the Security Rule provisions most relevant to hacking and ransomware.

The practical takeaway from the authority page is that audits are not exclusively complaint-driven. A practice can land in an audit population without anyone having filed a complaint against it. Selection happens. The defensible posture is not "we have never had a complaint, so we are fine." It is "we can produce the documents if selected."

Two ways OCR arrives at your door

The Compliance and Enforcement hub describes the two distinct paths by which OCR engages with a covered entity.

The first is the complaint-driven investigation. A patient, an employee, a competitor, or anyone else files a complaint alleging a HIPAA violation. OCR intakes it, reviews whether it states a potential violation within its jurisdiction, and, if it does, opens an investigation. This is the most common path for a small practice.

The second is the compliance review, which OCR can initiate on its own, often triggered by a reported breach. When a practice reports a breach affecting 500 or more individuals (as HIPAA requires), that report can itself initiate a compliance review. The breach notification is not the end of the obligation; it is frequently the start of the OCR conversation.

Both paths converge on the same first request.

The first thing OCR asks for

This is the single most important fact in this entire post, and it is documented directly in the OCR Audit Protocol.

The Audit Protocol, last updated July 2018 and still the working document, enumerates the specific inquiries auditors examine across the Privacy, Security, and Breach Notification Rules. Within the Security Rule inquiries, the protocol asks the covered entity to demonstrate compliance with the risk analysis requirement at 45 CFR §164.308(a)(1)(ii)(A). In plain terms: show us your Security Risk Analysis.

The Security Risk Analysis is the foundational Security Rule document. Nearly every other safeguard inquiry in the protocol assumes the risk analysis exists, because the risk analysis is what is supposed to have identified the risks the other safeguards address. When OCR opens an investigation or a compliance review, the request for the risk analysis comes early, and the quality of what the practice produces sets the tone for everything that follows.

A practice that produces a current, methodologically sound risk analysis (scope documented, threats and vulnerabilities identified, risk rated, evidence attached) is in a fundamentally different conversation than a practice that produces a partially-completed template downloaded three years ago when the EHR was installed. The first practice is demonstrating compliance. The second is demonstrating that it treated the most important Security Rule requirement as a checkbox.

What the timeline actually looks like

The HIPAA Journal's explainer on OCR's post-complaint process describes the cadence a small practice should expect. After OCR opens an investigation, it issues a data request: a written demand for specific documents and information. The response window is typically around 30 days. The practice produces what it has. OCR reviews it.

From there, two broad paths:

  • If the documentation demonstrates compliance, OCR may close the matter with no further action or with technical assistance.
  • If the documentation reveals gaps, OCR can require a corrective action plan, impose a resolution agreement with a monetary settlement, or in escalated cases pursue civil monetary penalties.

The critical insight is about where the 30-day clock starts. It starts when the data request arrives, not when the practice decides to begin building its documentation. A practice that has a current Security Risk Analysis on the shelf responds to the data request by retrieving a document. A practice that does not has 30 days to manufacture, under pressure and scrutiny, a document that is supposed to represent months of careful analysis. OCR has seen both. It knows the difference between an analysis that was done and an analysis that was performed in the 30 days after the letter arrived.

What a practice should actually do

The defensible posture is not complicated, and the public documents make it explicit:

  1. Have a current Security Risk Analysis. Not a template. A real analysis with documented scope, methodology, threat identification, risk ratings, and an evidence appendix. This is the document OCR asks for first.
  2. Maintain the companion Risk Management Plan. The Security Rule expects the risk analysis to drive a risk management process. The plan is the documented evidence that the analysis led somewhere.
  3. Keep the evidence current. The Audit Protocol examines safeguards, not just the existence of the risk analysis. Configuration evidence, training records, BAA inventory, and access controls all get examined. Stale evidence reads as a stale program.
  4. Read the Audit Protocol once. It is publicly available. It tells you exactly what an auditor examines. There is no reason to be surprised by a document the government published.

OCR is not arbitrary. Its authority is statutory, its process is documented, and its first request is predictable. The practices that struggle in an OCR audit are not the ones that drew the short straw. They are the ones that treated the most-requested document, the Security Risk Analysis, as something to produce when asked rather than something to maintain before being asked.