HIPAA and AI code review: what you actually have to document
Does HIPAA require code review?
No. The HIPAA Security Rule contains no code review standard and no software development lifecycle standard. Nothing in it says you must review code, AI-assisted or otherwise. Any vendor telling you HIPAA mandates code review is overstating the rule, and you should discount everything else they tell you accordingly.
What HIPAA does require is risk analysis, audit controls, and documentation you can produce six years later. Code review is one reasonable way to discharge those obligations. That distinction is the whole point of this post, because it changes what you build and what you keep.
Key takeaways
- The obligation is derived, not explicit. It comes from §164.308(a)(1)(ii), §164.308(a)(8), §164.312(b) and §164.316.
- Six years of documentation retention under §164.316. Most tools default to 30 to 365 days of logs.
- §164.312(b) says record and examine. Enforcement has repeatedly turned on logs that were collected and never reviewed.
- Keep PHI out of review logs. Test fixtures with realistic patient data are the usual leak path.
- A cloud reviewer transmitting diffs to a third party is a risk analysis question you must answer and document. Self-hosting removes the question instead.
Where the obligation actually comes from
Four provisions, none of which mention source code.
| Provision | What it requires | Why it reaches your SDLC |
|---|---|---|
| §164.308(a)(1)(ii) Risk analysis and risk management | Identify risks to ePHI and reduce them to a reasonable level | If a change can expose ePHI, how you review changes is part of the analysis |
| §164.308(a)(8) Evaluation | Periodic technical and non-technical evaluation against the rule | Your controls have to be re-checked when the environment changes, and adopting an AI reviewer is a change |
| §164.312(b) Audit controls | Mechanisms to record and examine activity in systems containing ePHI | This is the one that makes an audit trail a control rather than a nice-to-have |
| §164.316 Documentation | Written policies and records, retained six years | Whatever you decide, you have to be able to show it years later |
NIST SP 800-66 Revision 2 is the practical companion here. It walks each Security Rule requirement with implementation suggestions and is considerably more useful than the rule text if you are actually building something.
The six-year problem nobody plans for
This is the requirement that quietly breaks most setups.
§164.316 requires documentation to be kept for six years from creation or last effective date. Default log retention in most development tooling is 30 to 365 days. So the evidence that a review happened, that a gate fired, that someone approved an exception, has usually expired years before your obligation to produce it has.
Worse, pull request comments are not really documentation. They live in a git host's activity data, they can be edited or deleted, and they were never designed as a retained record. If your answer to "show me that this change was reviewed" is a link to a comment thread from 2023, you are relying on a third party's retention policy and an artifact with no integrity guarantee.
Record and examine, not just record
§164.312(b) has no implementation specifications beneath it, which makes it deliberately flexible and scaled to your size and risk. But the verb pair matters: record and examine.
Enforcement has repeatedly concerned organisations that enabled logging and then never looked at it. Collection alone is not the control. For code review this translates into an uncomfortable question: when your AI reviewer flags something at high severity and a developer merges anyway, does anyone ever see that? If the answer is no, you have a logging mechanism rather than an audit control.
The version that survives scrutiny records the decision, the policy that produced it, the person who overrode it, and their written reason. We covered the full shape of that in what an AI code review audit trail must prove.
Does an AI reviewer change your risk analysis?
Yes, and this is the part worth thinking through before procurement rather than after.
A reviewer reading source code is usually not handling ePHI. Source code is not patient data. But a cloud reviewer transmits your diffs to a third party, which expands the set of external parties touching systems relevant to ePHI, and that expansion is something your risk analysis has to address and your documentation has to record. It may well be acceptable. It is not automatically acceptable, and "the vendor is SOC 2" is an answer to a different question.
Running review inside your own infrastructure does not answer that question so much as delete it. If diffs never leave your network, there is no third party to analyse. That is the argument for self-hosted AI code review in a healthcare context, and it is a shorter argument than the alternative.
Keep PHI out of your review logs
A specific and underrated risk. Guidance on audit logging is consistent: minimise PHI, prefer identifiers, tokens and metadata over clinical content.
Code review has a particular exposure here. Test fixtures and seeded databases sometimes contain realistic patient records, and a reviewer that quotes diff content back into its findings can copy that data into a log, a ticket, or a vendor's cloud. Check what your reviewer stores, not just what it transmits.
Honest caveats
This is not legal advice. It is a practitioner reading of the Security Rule, and your compliance officer or counsel is the authority on your obligations. HIPAA is deliberately flexible and scaled to your organisation, so reasonable programmes differ.
Gatekeep is not SOC 2 certified and no tool makes you HIPAA compliant. Compliance is an assessment of your whole control environment. What tooling can do is make one control auditable. We label anything unbuilt as roadmap, and Gatekeep supports GitHub only as of July 2026.
What to document, concretely
If you adopt an AI reviewer on code that touches ePHI systems, the paperwork a reasonable assessor would expect:
- A written policy saying what gets reviewed, at what severity threshold changes are blocked, and who may override.
- Your risk analysis entry covering the reviewer itself, including where inference runs and what leaves your network.
- A retained record per change: that a review ran, what it found, what the gate decided, and the policy version in force.
- For every override: who, when, and the written justification. An empty override is the finding an assessor will pull on.
- Evidence the records are tamper-evident, whether by hash chain, signing, write-once storage, or an external copy.
- A retention configuration that actually reaches six years, checked rather than assumed.
Frequently asked questions
Does HIPAA require code review?
No. The HIPAA Security Rule contains no code review standard and no software development lifecycle standard. The obligation is derived from four places: risk analysis and risk management at §164.308(a)(1)(ii), periodic evaluation at §164.308(a)(8), audit controls at §164.312(b), and documentation at §164.316. Any vendor telling you HIPAA mandates code review is overstating the rule.
How long do you have to keep HIPAA documentation?
Six years. §164.316 requires required documentation to be retained for six years from creation or last effective date. This catches teams out because default log retention in most tools is 30 to 365 days, so the evidence a reviewer produced has usually aged out long before the retention obligation does.
What does §164.312(b) audit controls actually require?
Hardware, software or procedural mechanisms that record and examine activity in systems containing electronic PHI. There are no implementation specifications beneath it, which means the standard is deliberately flexible and scaled to your size, complexity and risk. The word examine matters: enforcement has repeatedly turned on organisations that enabled logging and then never reviewed it.
Does an AI reviewer touching our repo make it a business associate?
It depends on whether it handles ePHI. A reviewer reading source code is usually not handling ePHI, but a cloud reviewer transmitting your diffs to a third party expands the set of parties touching systems relevant to ePHI, which is a risk analysis question you have to answer and document. Running review inside your own infrastructure removes the question rather than answering it.
Should PHI ever appear in code review logs?
No. Minimise PHI in any log. Prefer identifiers, tokens and metadata over clinical content. This matters for code review specifically because test fixtures and seeded data sometimes contain realistic patient records, and a reviewer that quotes a diff back into a log can copy that data somewhere it was never meant to live.
The short version
Stop asking whether HIPAA requires code review, because it does not. Ask instead what you would hand an assessor who wants to know that a change to an ePHI system was reviewed, that a failing check stopped it, that any exception was authorised by a named human with a written reason, and that the record has not been edited since. Then check that record still exists in six years. That is the whole test, and most setups fail it on retention long before they fail it on rigour.