What a HIPAA reviewer asks for first

Teams preparing for a review usually start with encryption. It is the most visible control, it has a satisfying yes-or-no answer, and it is almost never where the conversation begins.

Reviews begin with scope. Not "is this data encrypted" but "show me everywhere this data is" — and that is the question most systems cannot answer without someone going and looking.

The order, and why it is that order

A reviewer is not auditing your code. They are testing whether your organisation understands its own system well enough to be accountable for it. The questions escalate accordingly.

1. Where does protected health information live?

Every place it enters, rests and leaves. Not the primary database — that one everybody remembers. The ones that get missed are the log line that captured a request body, the error tracker that received a stack trace with a patient identifier in a variable, the analytics tool, the backup bucket in a different region, the CSV somebody exported to debug an issue in 2023, and the queue payload that sat in Redis for four hours.

If this takes a week to answer, that is the finding. Everything after it is provisional, because a control you can describe is worthless over data you did not know you held.

2. Who can see it, and how do you know?

Not "we have roles". The question is whether there is an explicit matrix — every role against every action — or whether authorisation is a set of checks scattered through controllers that nobody has ever assembled into one view.

The difference shows up immediately under questioning. Ask a team with a matrix whether a billing clerk can open a clinical note and you get an answer. Ask a team without one and you get someone opening an editor.

3. What happened, and can you prove it?

This is where systems most often fail, and the failure is almost always the same one: a timestamp column mistaken for an audit trail.

updated_at says a row changed. A reviewer asks what it changed from, who changed it, and whether it changed more than once. A column that holds only the latest state cannot answer any of those, and the gap is not fixable retrospectively — for every record altered before the audit log existed, the honest answer is that you do not know.

Access logging carries the same trap in a subtler form. Logging that a record was written is routine. Logging that a record was read is the one reviewers care about, because inappropriate access is the common breach, and it leaves no trace in the data itself.

4. Who else receives this data?

Every third-party processor, what each one gets, and the agreement covering it. Model providers now appear on this list, and the answer "we send the note text to an API for summarisation" is a data disclosure whether or not anyone thought of it that way.

The subprocessor question is where AI features most often turn a contained system into an uncontained one, usually between two releases and without a decision being recorded.

5. What is the retention schedule, and where is it enforced?

Not what the policy document says. Where in the code the deletion happens, what triggers it, and what proves it ran. A retention period enforced by habit is a retention period that has already been missed.

6. Only then, the technical controls

Encryption in transit and at rest, key handling, least-privilege service accounts, scoped credentials. These matter, and they are last, because they are the easiest to fix and the least diagnostic. A team that answers the first five well has almost always handled these. A team that leads with them is usually hoping the earlier questions do not come.

What the evidence pack actually contains

By the end, a reviewer wants documents, not assurances:

• A data flow map covering every place personal data enters, rests and leaves
• The authorisation matrix: every role against every action
• The retention schedule, and the place in the code that enforces it
• Access log design — what is captured, and for how long
• A processor list with what each one receives
• Written answers to a standard vendor security questionnaire

Every item is derived from how the system is built. None can be written honestly by someone who has not read it, which is why producing this pack under deadline is so much more expensive than maintaining it as you go.

The part that is not a software problem

The attestation belongs to your organisation. A vendor cannot hold it for you, and any vendor saying otherwise is describing something that does not exist.

What a build can do is make the evidence a by-product of the system rather than an archaeology project: the audit trail written because the data model has one, the retention schedule enforced because a scheduled command runs it, the processor list accurate because adding a processor is a change to a file somebody reviews.

The lawful basis, the policies, the staff training and the incident response ownership stay with you. They are business decisions before they are technical ones, and the reviewer will know the difference.

If a review is coming and the first question is the one you cannot answer yet, our compliance readiness assessment is fixed in scope and produces the gap analysis as an evidence pack — what exists, what is missing, and what a reviewer will ask for first.