The HIPAA Audit Protocol Has 180 Questions. None of Them Say AI.

A medical assistant has forty seconds between patients. The note is messy. She pastes it into a free chatbot and asks for a cleaner version. The note has the patient's name, the diagnosis, and the medication list. She deletes the chat when the next patient walks in.

The practice has a HIPAA policy. It has an EHR with a signed agreement. It has never written the words "artificial intelligence" in a risk analysis, because nobody bought an AI product. A person with a login just created one.

OCR does not need a new rule with the word AI in the title. The risk-analysis question already asks whether you know every place electronic patient information goes, who is allowed to send it there, and whether you can prove it. If a vendor handles that information for you, the same questions already call for an agreement before it moves, and for a breach assessment if something goes wrong. There is no AI exemption.

Protected health information, PHI, is the patient information HIPAA covers. When it is on a computer, in email, or in a vendor system, it is electronic PHI, or ePHI. A medical practice is what the rule calls a covered entity. A vendor that handles PHI for the practice is a business associate.

What the protocol is

The page is titled Audit Protocol – Updated July 2018. It describes how OCR reviews the policies and procedures of medical practices and the vendors who handle patient information for them, against selected standards of the Privacy, Security, and Breach Notification Rules. The table was updated so it matches the HIPAA rules as revised in 2013. It is organized by rule. The audit covers a selection of requirements, and the selection can change with the type of organization.

Two instructions on that page matter more than the table of contents.

You send the documents the auditor named, in the version in use as of the date of the audit notice and the document request. A binder of every policy the organization has ever saved is not helpful. The instruction says the auditor will not hunt through that stack looking for the page that answers the question.

The same page tells auditors to treat workforce members as employees, on-site contractors, students, and volunteers, and to treat information systems as hardware, software, information, data, applications, communications, and people. Those are audit instructions. The regulation is narrower on workforce. Workforce means people whose work is under your direct control. A contractor who is not under your direct control generally needs a business associate agreement, not a badge that says "staff."

Each row pairs a rule citation with the question an auditor asks and the evidence that would answer it. On the Security Rule rows, implementation specifications are marked required or addressable. Privacy and Breach Notification rows leave that column blank. Those duties are not optional because the column is empty.

Addressable does not mean optional. If an addressable safeguard is reasonable and appropriate in your environment, you implement it. If it is not, you document why, and you implement an equivalent alternative if one is reasonable and appropriate. An equivalent is not always required. The written reason has to explain why the specification itself was not reasonable and appropriate.

Source: the public protocol table, HHS OCR, updated July 2018. Of the 72 Security Rule rows, 48 are marked required and 22 are marked addressable. Two Security Rule rows are general standards and are unmarked.

The question that puts a chatbot in scope

The Security Rule row for risk analysis, 45 CFR 164.308(a)(1)(ii)(A), is required. It asks two things, and both have to be yes.

Do you have a written way to assess the risks to the confidentiality, integrity, and availability of all the ePHI you create, receive, maintain, or transmit? Have you actually done that assessment?

In office language: have you found the risks to all electronic patient information you create, get, store, or send, and have you written it down?

"All" is the word that makes a chatbot relevant. The EHR is one system. So is email. So is the billing company, the imaging share, the laptop that went home, and the account a staff member opened because the note needed to sound better. If ePHI can land there, the assessment has to know it is there. Facts that belong inside that write-up, when they are true, include who at a vendor can see the text, whether the vendor uses prompts to train a model, and how long prompts are kept. Those facts are not a separate scored row. The row scores whether the assessment exists and whether it covers everything.

OCR has been enforcing that line without waiting for a random audit. On October 31, 2024, OCR announced a $90,000 settlement with Bryan County Ambulance Authority in Oklahoma after a ransomware attack affecting 14,273 patients. OCR's 2024 report to Congress says the investigation found that the authority had failed to conduct a compliant risk analysis. The announcement called it the first settlement under the Risk Analysis Initiative. Director Melanie Fontes Rainer's point was that skipping the analysis leaves health care organizations exposed to attacks such as ransomware, and that knowing where ePHI is held is part of complying with HIPAA. A settlement resolves potential violations. It is not a court verdict. The dollar figure is the small part of the story. A county ambulance service is not a national health system. The question is the same size for both.

A later round of audits was described in March 2025, when BankInfoSecurity reported remarks from Tim Noonan at OCR. He said a 2024–2025 round had started in late December 2024, covering 50 practices and vendors, aimed at Security Rule provisions tied to hacking and ransomware. He said that from 2020 through 2024, hacking incidents in large breaches rose 30 percent and ransomware rose 45 percent. He did not publish the list of rows. OCR's own 2024 report to Congress, covering that calendar year, says the office did not initiate any audits in 2024 because it lacked the resources. Those two public statements do not match, and OCR has not published a list of organizations audited in that round. What the same report does settle is the shape of the year: hacking accounted for 81 percent of the large-breach reports and 99 percent of the people affected by them.

The February 2024 ransomware attack on Change Healthcare, a UnitedHealth Group company, is the scale case for patient information held at a vendor. Change notified OCR on January 24, 2025, that about 190 million people were affected, and on July 31, 2025, that about 192.7 million were affected. OCR has not published a finding that a missing risk analysis caused the attack. The point that transfers is narrower. Patient information at a vendor is still patient information your risk analysis has to know about, before an incident, not after the notice.

A fuller walk-through of what belongs in the analysis is in the HIPAA risk assessment guide. The settlement pattern is the subject of OCR's ransomware cases and the risk analysis.

Three public cases, and the rows they actually sit on

Policies describe what the organization meant to do. These public OCR matters show what the agency said was missing. A resolution agreement settles potential violations, often without an admission. A civil money penalty is a different outcome. OCR imposes it.

The contractor who still had a login. On December 3, 2024, OCR announced a $1,190,000 civil money penalty against Gulf Coast Pain Consultants. The notice of final determination is dated September 27, 2024. OCR determined that a former contractor accessed the electronic medical record on three occasions and viewed information on about 34,310 people, including names, addresses, phone numbers, email addresses, dates of birth, Social Security numbers, chart numbers, insurance information, and primary-care details. The reported findings were four Security Rule failures: no accurate and thorough risk analysis, no regular review of information-system activity, no procedures to terminate access when the arrangement ended, and no procedures for how access is granted and changed. Termination procedures are addressable, at 45 CFR 164.308(a)(3)(ii)(C). OCR imposed the penalty anyway. This was a termination, activity-review, and access case. Unique user identification was not one of the findings.

The phished mailbox. On September 17, 2026, OCR announced a $700,000 settlement with Ambry Genetics after a January 2020 phishing attack on an employee email account. The protected health information of 225,370 people was potentially taken. OCR described potential Security Rule violations that included no accurate and thorough risk analysis, no termination procedures, and no unique name or number for identifying and tracking users in systems that hold ePHI. The public accounts describe one employee's mailbox. They do not say it was shared. A shared seat on a tool your practice runs is a separate problem under that same required specification, 45 CFR 164.312(a)(2)(i). You cannot show which person used it.

The file you keep either way. This review is different from the yearly risk analysis. The yearly analysis asks where ePHI lives and what could go wrong. After patient information goes somewhere it should not, a different set of questions asks whether patients have to be told.

The breach section is 19 questions. One of them asks whether you have a process for deciding if an impermissible use or disclosure requires notification, and it asks for three lists from the previous calendar year: breaches, security incidents, and breaches reported to HHS. Another asks whether people were notified without unreasonable delay and no later than 60 days after discovery. Another asks whether the notice said what happened, the kinds of information, what the person can do, what you are doing, and how to reach you.

Not every impermissible disclosure is a reportable breach. The protocol has a row for the exceptions. A good-faith, unintentional acquisition by a workforce member acting inside the job, an inadvertent disclosure between two people who were both allowed to have it, and a disclosure to someone who could not reasonably have kept it can fall outside the definition. Information secured under HHS encryption or destruction guidance can fall outside the notice requirement. If no exception applies and the information was not secured that way, you either document a low probability that it was compromised, using at least the four factors in 45 CFR 164.402, or you notify without that demonstration.

Deleting the chat is not one of those rows. On the facts in the opening — a workforce member, a note with a name, a diagnosis, and medications, a consumer tool the practice does not control — you still have an incident to assess. Deleting the chat does not finish that assessment, and it does not prove the vendor has no copy.

Where a new tool meets those questions

HIPAA does not have a separate artificial-intelligence rule. As of September 30, 2026, the Security Rule update proposed in January 2025 is still a proposal. HHS's regulatory agenda has pointed to July 2027 for final action. Until a final rule is effective, OCR enforces the current Security Rule. The 2018 protocol is the public checklist for that rule. What a proposed overhaul would change is a planning question. What an auditor can ask this quarter is already written down.

Risk analysis — required. The question is whether the assessment covered all ePHI the organization creates, receives, maintains, or transmits, and whether you did the assessment. A one-page AI policy that never names the product in use will not answer it. A scribe, a coding tool wired to the EHR, and a consumer account staff can paste into are in scope when patient information can reach them. The assessment names the system. It does not have to call the system "AI."

Business associate agreements — required when a vendor handles PHI for you. These questions appear under both the Privacy Rule and the Security Rule. They ask how you identify business associates, whether the agreements contain the required elements, whether the contract requires safeguards, whether the vendor must bind subcontractors that handle the PHI, and whether the vendor must report security incidents and breaches. You do not sign a separate agreement with every company behind your vendor. Your agreement has to match the product people actually use, and it has to require that vendor to bind the subcontractors who create, receive, maintain, or transmit the PHI.

An ambient scribe or a coding assistant is in that category when the vendor receives PHI to do the work for you. The agreement comes before the PHI moves. What a business associate agreement has to contain is the longer version of that row.

A free consumer account is a different problem. A company that will not act for your practice, and will not sign an agreement, is not your business associate. A workforce member who pastes a chart note into that account is disclosing PHI to a company you have no contract with. The failure is the disclosure. There is no missing contract to go collect from a vendor who was never working for you.

Audit records and the review of those records — both required, on systems you operate. One required question, 45 CFR 164.312(b), asks for a way to record and examine activity in information systems that contain or use ePHI. Another, 45 CFR 164.308(a)(1)(ii)(D), asks whether someone reviews those records on a schedule, how the review is documented, and what happens when something looks wrong. Keeping logs is not the same as reading them.

If a system your practice runs keeps the only record in a console you cannot examine, you are in a poor position on the first question. A login the whole office shares is a unique-user problem on a system you run. It does not, by itself, answer or fail the review question. A consumer chatbot the practice does not operate is an evidence problem for the breach assessment. It is not automatically an audit-control violation on a system that was never yours.

Unique user names — required on your systems. Ambry was one employee's email account. The specification still applies to a tool your practice administers. If three nurses share one seat, you cannot say who pasted which note.

Training — required, in two different places. Privacy Rule and Breach Notification training, 45 CFR 164.530(b), covers new workforce members within a reasonable time, and again when a material change in policies or procedures affects their work. Security awareness training, 45 CFR 164.308(a)(5)(i), is its own required standard. That is the row that asks how people are trained when the information systems change. Its smaller specifications — reminders, malicious-software protection, login monitoring, password management — are addressable.

A scribe turned on Thursday should drive a policy update and a security-awareness update that names the tool. The calendar date alone is not the Privacy Rule trigger. Training that never mentions the tools people have on their phones is a stack of certificates for a different workplace. A completed annual HIPAA course is not the update that names the scribe.

Removing the name is not enough. The protocol has a de-identification question, and it points auditors to HHS's de-identification guidance. Taking the name off a note does not make it anonymous. HIPAA either requires a set list of identifiers to come off, with no actual knowledge that the remainder can still identify the person, or a qualified person documents that the chance of recognizing the patient is very small. A diagnosis, a date of service, and a small clinic will often still identify the person. A separate set of questions covers minimum necessary: a person's access has to match the job.

Termination procedures — addressable, and still enforced. The question asks whether access to ePHI stops when the job or the contract ends, including for an independent contractor, and whether you chose an alternative measure instead. Gulf Coast is the public example of OCR treating a gap here as a violation. The same question covers a scribe seat and a shared team login your practice controls. A personal key or password left behind in a side project is a credential to shut off. The system is the service that key opens.

After something goes wrong. "We think the vendor deletes chats" is a fact you support with the contract and the settings, or it is a hope. The protocol asks for the incident list from the previous calendar year either way. The sanction question asks whether people were disciplined consistent with your policy. It is not a hunt for violations to punish. A policy nobody applies is only a document.

Three Tuesdays

These are illustrations, not client stories.

The grammar paste. The assistant in the opening used and disclosed PHI. The consumer tool is not in the risk analysis. That is the scope problem. She did not fail to sign a business associate agreement with a company that was never working for the practice, and the practice did not fail the unique-user or audit-control rules on a system it does not run. If someone later asks what left, the deleted chat does not finish the breach assessment and does not prove the vendor has no copy. The incident log should have a line for it. Someone still has to decide whether an exception applies and, if not, whether to document a low probability of compromise or notify.

The scribe that went live during the demo. A vendor offers to turn it on for this afternoon's clinic so you can hear it. Real patients are in the rooms. The agreement is still with the lawyer. For that afternoon the vendor is receiving PHI to do the work for you, and you cannot show the contract those rows ask for. A demo that uses today's schedule is not a dry run. After the agreement is signed, the work is not finished. The scribe belongs in the risk analysis. The agreement has to match the product in the room and require the vendor to bind subcontractors who handle the PHI. Staff need training that names the tool, says the draft is still PHI, and says a clinician reviews it before it becomes the record. Each visit needs an account you can tie to a person. A business associate agreement is the permission structure. It is not the whole protocol.

The spreadsheet someone ran "just to see." Someone exports upcoming visits and runs them through a model with a personal password for a tool they are trying out, to test no-show predictions. The spreadsheet is ePHI. The password is a credential. The service it opens is a system that received patient information. A pilot that never went through purchasing is still in scope for that reason. This is the same reason a homegrown app can look finished and still be unfit for PHI, which is the subject of vetting a new app before patient data moves.

One state law is narrower than the headlines. Vermont Act 156, signed June 17, 2026, bars a company from offering mental health services to the public, including through AI, unless a mental health professional provides them or the work is part of an approved research study. A professional may use an AI tool only if the statute's HIPAA-compliance condition is met and the professional reviews and approves the service. That is a state professional-practice law, enforced under Vermont's consumer-protection and licensing rules. It is not an OCR audit standard, and it does not cover every clinical use of AI. The running list of state and federal rules is on AI healthcare regulations.

What to have ready

An audit notice names the provisions. It does not ask for this whole list, and you do not get to pick the list after the letter arrives. What follows is a prep file for the questions above: Security Rule samples an auditor often requests, Breach Notification records the protocol dates to the previous calendar year, and the incident file you would already need if a paste or a demo had gone wrong. It is not the contents of a hacking audit letter.

1. The current risk analysis, dated, covering every system that creates, receives, maintains, or transmits ePHI, including email, vendors, and any tool a workforce member can reach with PHI.
2. The risk management record: the measures you put in place because of that analysis, and what is still open.
3. The vendor inventory and the signed agreements, including the duty for those vendors to bind subcontractors who handle PHI. An AI vendor that receives PHI for you and is missing from the inventory is a gap you should expect to be asked about.
4. On systems you run: unique user names, and the record that access was removed when people left. Termination procedures are addressable. Document the alternative if you did not implement them as written.
5. Training that matches the systems in use now. For a new tool, that means a policy update and security-awareness training that names the tool, not only a completed annual course.
6. Audit records for systems you run, and the review of those records: how often, by whom, and what you did the last time something looked wrong. A person does the review. A log that nobody opened does not.
7. The breach list, the security-incident list, and the list of breaches reported to HHS for the previous calendar year, with the worksheet for events you decided were not reportable breaches.
8. Sanction records showing the policy was applied when a workforce member put PHI where it forbids.

The tool in the room is usually missing from the file

The risk analysis names the EHR. The scribe someone started using, the account opened between patients to clean up a note, and the spreadsheet that went through a model are easy to leave off that page. The agreement in the folder, when there is one, names an older product. The course the staff already finished never mentions the tool on the desk.

The audit letter does not ask for the story of how that happened. It asks for the documents in use on the day of the notice. When the risk analysis, the vendor list, the training record, and the incident notes live in four places, someone has to pull them together after the letter arrives. The dates often do not match.

Live Compliance is the place those pages are kept together. The risk analysis, the vendors and their agreements, the training, the policies, and the notes from when something went wrong each have an owner and a date. An AI tool is added the same way as any other system that can hold patient information. A person still writes the analysis, reads the logs, and decides whether patients have to be told. The record is already in one place, so you are not assembling it the week the letter arrives.

See how that file is organized, or talk with us about the systems that already hold patient information, including the ones nobody purchased.