HIPAA-Compliant Software: The Specific Technical Controls Auditors Check

HIPAA's technical requirements come down to a specific set of controls: encrypting patient data both at rest and in transit, enforcing role-based access so only authorized users can view specific records, logging every access to patient data with enough detail to reconstruct who saw what and when, and having a tested process for detecting and responding to a breach. Each of these has to be genuinely implemented and demonstrable, not just described in a policy document.

General explanations of HIPAA compliance tend to stay at the level of "protect patient data," which is true but not actionable. Here's what that actually breaks down into at the level of specific technical implementation, the level that matters when a covered entity or business associate agreement is actually being evaluated.

Encryption: At Rest and In Transit, Separately

HIPAA's technical safeguards expect patient data to be encrypted both while it's stored, called encryption at rest, and while it's moving between systems, called encryption in transit. These are two separate requirements that need two separate implementations. A system that encrypts data in its database but sends it over an unencrypted connection between two internal services has a real gap, even though the storage layer looks compliant on its own.

In practice, this means every API call that carries patient data, including internal service-to-service calls that never touch the public internet, needs to run over an encrypted connection, and every database or file storage system holding that data needs encryption enabled at the storage layer itself, not just at the application layer.

Role-Based Access, Enforced at the Data Layer

Access needs to be restricted to the specific people who need specific data for their specific job, sometimes called the minimum necessary standard. This has to be enforced technically, meaning the system itself blocks unauthorized access attempts, not just documented as a policy that staff are trained to follow voluntarily.

The common gap here is internal tooling. Customer-facing systems usually get this right because it's obviously required. Internal admin panels, support tools, and reporting dashboards that also touch patient data are frequently built with looser access controls, because they were built later, faster, and with less scrutiny, and they become the actual weak point an audit finds.

Audit Logs Detailed Enough to Reconstruct Access History

If a patient's record was viewed, changed, or exported, the system needs a log entry capturing who did it, when, and ideally what specifically was accessed or changed. This is exactly the same underlying discipline covered in our guide to shifting security left without slowing down engineering teams, where structured, tamper-resistant logging is treated as a built-in architectural requirement rather than something assembled as evidence right before an audit or investigation.

Logs also need to be protected from being altered after the fact. A logging system where an administrator can quietly edit or delete past log entries does not satisfy this requirement, since the entire point of the log is to serve as reliable evidence.

A Tested, Not Just Written, Incident Response Process

HIPAA expects organizations to have a process for detecting and responding to a security incident. The distinction that matters technically is between a written plan and a tested one. A plan that has never been exercised, even in a simulated scenario, tends to reveal gaps the first time it's actually needed, at exactly the worst moment for that discovery to happen.

Where This Gets Genuinely Hard: Third-Party Integrations

Most modern healthcare software doesn't operate in isolation. It connects to other systems, an electronic health record platform, a billing system, a lab results provider, and each connection is a point where patient data crosses a boundary. Every one of these integrations needs the same encryption and access control standards applied to it, and a business associate agreement with the third party covering their responsibility for the data as well.

This is exactly the same principle covered in our piece on why data governance is what separates useful AI from expensive AI, since ungoverned data flowing unchecked between systems is precisely where both compliance failures and unreliable AI outputs originate. Teams that carefully secure their own core system, but treat a third-party integration as someone else's problem, frequently discover during an audit that the integration point was never actually covered.

FAQ

What are the main technical controls HIPAA requires from software?
Encryption of patient data both at rest and in transit as separate requirements, role-based access enforced technically at the data layer rather than through policy alone, detailed and tamper-resistant audit logs of who accessed what data and when, and a genuinely tested incident response process rather than only a written plan.

Why do internal admin tools often fail HIPAA audits even when the main product passes?
Internal tools are frequently built later, faster, and with less scrutiny than customer-facing systems, which means their access controls are often looser even though they touch the same sensitive patient data.

Does encrypting a database satisfy HIPAA's encryption requirement?
Not on its own. HIPAA expects encryption both at rest and in transit, including internal service-to-service calls. Encrypting only the database while leaving internal data transfers unencrypted leaves a real gap.

Do third-party integrations need to meet the same HIPAA standards as the main system?
Yes. Every integration point where patient data crosses to another system needs the same encryption and access control standards, along with a business associate agreement covering the third party's responsibility.

Does HIPAA require a specific encryption standard, or just encryption in general?
HIPAA doesn't mandate one specific encryption algorithm, but it does expect organizations to use encryption methods that are current and considered secure by prevailing industry standards.