What "HIPAA-Compliant" Actually Means When You're Building an App

If you build software anywhere near healthcare in Nashville, someone will ask, "Is it HIPAA compliant?" It's a fair question with a misleading shape. It sounds like a yes-or-no property of an app, like whether it works on a phone. It isn't.

I build and run systems at my day job that handle Social Security numbers, military service records and signed physician forms describing medical conditions for elderly clients. Here's how I explain HIPAA and SOC 2 to people who need software built, with every rule checked against HHS and AICPA sources. I'm a developer, not a lawyer or an auditor, so treat this as a map, not legal advice.

Building something that will hold health information? Get a free quote, or read on for how I think about it.

HHS answers this one directly in an FAQ: no standard in the Security Rule requires a company to "certify" compliance. A company has to periodically evaluate how well its own security measures hold up, and it can hire an outside firm to help. But HHS says it "does not endorse or otherwise recognize private organizations' 'certifications'" and a certificate doesn't stop HHS from later finding a violation.

So when a vendor says its product is "HIPAA certified," read it as marketing. The useful question is narrower: does this software give your company the safeguards it needs, and will the vendor sign a business associate agreement?

HIPAA's rules apply to covered entities, which are health plans, health care clearinghouses and most health care providers, and to their business associates. Per HHS, a business associate is a person or company that creates, receives, maintains or transmits protected health information on a covered entity's behalf. Its examples include cloud providers, IT contractors who maintain systems holding health data, and app developers who build patient-facing apps for a provider.

That's why a developer can't hand-wave this. If I'm building or supporting a system that holds a clinic's patient data, I'm probably in the chain, and so is every service the app runs on.

The Security Rule splits its requirements into administrative, physical and technical safeguards. The technical ones, in 45 CFR 164.312, are the part that lands on a developer's desk:

• Access control: a unique login for every user (required), a way to get at records in an emergency (required), automatic logoff after inactivity (addressable), and encryption (addressable).
• Audit controls: a way to record and examine activity in systems that hold health information.
• Integrity: protection against records being changed or destroyed improperly.
• Authentication: proof that the person signing in is who they claim to be.
• Transmission security: protection for data moving over a network.

Two more pieces shape the screens themselves. The Privacy Rule's minimum necessary standard says to limit use and disclosure to what a task needs, and the Security Rule backs it by requiring access based on a person's role. In practice, that means a scheduler sees appointments, not diagnoses. And the contingency plan standard requires backups, a way to restore lost data, and a plan for operating during an emergency.

The rule is deliberately technology-neutral. It doesn't name a framework, a cipher or a host. It tells you what has to be true and leaves the how to your risk analysis.

This trips up a lot of people. HHS's summary is clear: an addressable item isn't optional. You implement it if it's reasonable and appropriate, and if it isn't, you document why and use an equivalent alternative where that makes sense.

Encryption is the big one. In the proposed rule published January 6, 2025, HHS wrote that encryption "generally would be reasonable and appropriate" and that regulated entities "should already have done so in most circumstances." There's also a practical reason. Under HHS's breach guidance, health data encrypted to NIST-tested standards, with the key kept safe and separate, isn't "unsecured," so losing it doesn't trigger the breach notification rules.

My default: TLS everywhere, encryption at rest for the database, file storage and backups, and keys kept away from the data they unlock.

HHS proposed a major update to the Security Rule in December 2024. Per the HHS fact sheet, it would, among other things, make every implementation specification required (with limited exceptions), require encryption of health data at rest and in transit, require multi-factor authentication, require vulnerability scanning at least every six months and penetration testing at least once a year, and require written procedures to restore certain systems and data within 72 hours.

It isn't final. HHS's regulatory agenda moved it to long-term actions and now projects final action in July 2027, and the current rule stays in effect until then. I'd still build to it. Every one of those items is good practice, and retrofitting MFA and encryption into a live system is a lot harder than starting with them.

A business associate agreement is the contract HIPAA requires before an outside company handles a covered entity's health information. Per HHS, it spells out what the company may do with the data, commits it to the Security Rule's safeguards, and makes it report security incidents and breaches. Business associates need the same kind of agreement with their own subcontractors.

For software, the chain gets long fast: host, database, file storage, email sender, SMS provider, error tracker, analytics. HHS's cloud guidance says a cloud provider that stores health data is a business associate even if the data is encrypted and the provider holds no key. Storing health data with a cloud provider without a BAA is itself a violation.

Check the plan, not just the vendor. Vercel, for example, says it signs BAAs with eligible Pro and Enterprise customers, and its pricing page lists the BAA as unavailable on the free Hobby plan. If a service in the path won't sign, health data doesn't go through it.

Your developer is a different question. Most BAAs on a project are between your company and the vendors that store or send the data. A developer only becomes a business associate when the work actually exposes them to patient data, such as supporting a live system that holds it. I sign a BAA in that case, and I'd expect to be asked. Otherwise I build and test with fake data, and my part is helping you pick vendors that will sign.

SOC 2 comes from the AICPA, the CPA profession's standards body, not from the government. It's an examination by an independent CPA firm of a service organization's controls, measured against the AICPA's Trust Services Criteria. There are five categories: security, availability, processing integrity, confidentiality and privacy. Security, the common criteria, is always in scope, and the company picks which of the others to add.

A Type 1 report looks at whether the controls are designed well as of one date. A Type 2 report also tests whether they actually worked over a period of time, which is the one enterprise buyers usually ask for.

The common criteria cover things like logical access, system operations and change management. That's why the developer matters even though the report is about the whole company. The auditor will ask who can get into production, how a change gets reviewed and shipped, how you know when something breaks, and how you restore it. The software should answer those questions with records, not memory.

• Map the data first. Where sensitive data enters, where it's stored, who sees it and where it leaves. Everything else follows from this list.
• Collect less. The safest Social Security number is the one you never stored. If a field isn't needed, it doesn't get a column.
• One login per person, access by role, and a fast way to turn access off when someone leaves.
• MFA and session timeouts on anything that shows health information.
• Audit logs for who viewed, changed, downloaded or deleted sensitive records, protected from quiet edits.
• Logs without the data. Error logs, analytics and alert emails get record IDs, not names or diagnoses.
• Private file storage for signed forms and scans, with short-lived download links.
• Encrypted, tested backups kept apart from the live system, with a restore that's actually been run.
• A BAA with every vendor in the path, confirmed on the plan you're paying for.
• Fake data in development. Real patient records stay out of laptops, test databases and screenshots.
• Write it down. Access matrix, vendor list, change history, backup notes. The Security Rule expects required documentation to be kept for six years.

The forms I work with at my day job describe why an elderly person needs assisted living or outside care. Next to them sit Social Security numbers and service records. Everything I build there has to stay compliant, so care is part of every decision, not a final check, and that work keeps me sharp. By default each role sees only its own work, there's a trail of who touched what, and sensitive details stay where they belong. Those defaults are what keep data safe on a busy Tuesday.

That's the real meaning of "HIPAA-compliant" for a developer. Not a badge, just a system where the safe thing is the easy thing.

Can an app be HIPAA certified?

No. HHS says it doesn't endorse or recognize private HIPAA certifications. Compliance belongs to the covered entity or business associate, and the software either supports it or gets in the way.

Is encryption required by HIPAA?

Today it's an addressable specification, which HHS says isn't optional: you implement it or document why an alternative works. HHS has proposed making it required, with limited exceptions, and projects final action in July 2027.

Does my developer need to sign a BAA?

Only if their work exposes them to your protected health information. A developer who creates, receives, maintains or transmits it, for example by supporting a live system that holds it, is a business associate under HHS rules and needs a BAA. A developer who builds with fake data and never touches real records usually doesn't. Most of the BAAs on a project are between your company and the vendors that hold the data.

What's the difference between SOC 2 Type 1 and Type 2?

Type 1 looks at whether controls are designed well as of a single date. Type 2 also tests whether they operated effectively over a period of time.

Which SOC 2 categories are required?

Security, the common criteria, is always in scope. Availability, processing integrity, confidentiality and privacy are added depending on what the company commits to its customers.

Can my website be on WordPress if we handle health information?

Yes, if health information doesn't flow through it. Send forms that collect health details to a hardened app or a vendor that has signed a BAA, not into the WordPress database or a contact-form email.

• HHS, Summary of the HIPAA Security Rule
• 45 CFR 164.312, Technical safeguards (Cornell LII)
• HHS FAQ, Are we required to "certify" our organization's compliance with the Security Rule?
• HHS, Business Associates FAQs
• HHS, Guidance on HIPAA and Cloud Computing
• HHS, Minimum Necessary Requirement
• HHS, Guidance to Render Unsecured PHI Unusable, Unreadable, or Indecipherable
• HHS, HIPAA Security Rule NPRM fact sheet (Dec 27, 2024)
• Federal Register, HIPAA Security Rule To Strengthen the Cybersecurity of ePHI (Jan 6, 2025)
• Reginfo.gov, RIN 0945-AA22 timetable
• AICPA & CIMA, SOC suite of services
• AICPA, 2017 Trust Services Criteria (With Revised Points of Focus, 2022)
• Vercel, Security and compliance measures