Most engineering teams encounter HIPAA the same way: a checklist drops into Jira, someone Googles "HIPAA Security Rule", and the team ships the controls that look most like code. Encryption-at-rest? Done. Access logs? Done. BAAs? Legal handles that.
Then the audit happens. And the auditor doesn't ask about any of those things first.
What auditors actually ask in the first hour
We've sat through six HIPAA audits in the last 18 months — across hospital systems, digital health startups, and one MedTech vendor. The pattern is consistent. Auditors don't start with the controls. They start with the process around the controls.
- Who decided this PHI flow was necessary? Show me the decision document.
- Who has access to production data, and when was that list last reviewed?
- Show me the last access review. Show me the one before it.
- Walk me through what happens when an engineer leaves the team.
- When was the last time someone tried to access this and was denied? Show me the log.
Notice what's not on this list: encryption algorithm choices, TLS version, IAM policy syntax. Auditors assume those are correct, or they assume they can verify them later. What they're testing in the first hour is whether your organization can answer process questions consistently.
The three things that surprise engineering teams
First: access reviews are a quarterly event for the auditor, not an annual one. If you have a quarterly access review process documented but you can only produce evidence for the last review — that's a finding. Auditors want a chain of evidence, not a snapshot.
Second: the BAA flows downward. If your team uses a tool that touches PHI — even indirectly, like a log aggregator — your BAA needs to cover that tool, and the tool's vendor needs to have signed one with you. Most teams discover this when the auditor asks to see the BAA with the SaaS vendor and the answer is "we'll get back to you." That's a finding too.
Third: incident response drills count. If your IR plan has been written but never tested, auditors treat it as if it doesn't exist. We run our IR drills twice a year, and we keep the redacted post-drill notes specifically because the auditor will ask for them.
Auditors aren't testing whether you can build secure systems. They're testing whether your organization can operate secure systems — under turnover, scope changes, and pressure.
What we recommend teams do, in order
- Pick one PHI dataflow. Write the decision document explaining why it exists. Sign it. Date it.
- Generate your access list today. Sign and date that list.
- Schedule the next access review for 90 days from now. Calendar invite.
- Inventory every SaaS tool. Mark the ones that touch PHI directly or indirectly. Get a BAA from each.
- Schedule an IR drill for next quarter. Run it even if it feels rehearsed. Keep notes.
Engineering instinct is to build the technical control first and document later. The auditor's instinct is the inverse. Both are right — but the documentation cadence is what they actually evaluate.