HIPAA compliance,
explained plainly

HIPAA is the Health Insurance Portability and Accountability Act of 1996, a US federal law. People reach for the name to mean "the rules about protecting health data," and that is the part most software teams deal with: HIPAA sets out how health information must be safeguarded, who is responsible for safeguarding it, and what has to happen when it is exposed.

The first thing to be clear about is what HIPAA is not. It is not a certification. The US Department of Health and Human Services (HHS) does not issue a HIPAA certificate, and no government body audits you and stamps you "compliant." You determine your own compliance against the law, and you have to be able to demonstrate it if asked. Anyone selling you a "HIPAA certified" badge is selling their own attestation, not a government one — and the law itself has no such thing.

What does exist is enforcement. The HHS Office for Civil Rights (OCR) investigates complaints, audits, and reported breaches, and can impose civil monetary penalties. So the practical bar is not "did you pass an exam" but "if OCR looked, could you show that you take this seriously and have the safeguards and records to prove it."

HIPAA protects "protected health information" (PHI): individually identifiable health information — a person’s health condition, care, or payment for care, tied to identifiers like their name, dates, or contact details. When that information is held or transmitted electronically, it is "electronic protected health information" (ePHI), and the Security Rule applies to it specifically. If your systems touch patient records, appointment data, or anything that links a person to their health, you are almost certainly handling PHI.

HIPAA applies directly to "covered entities": healthcare providers that transmit health information electronically, health plans, and healthcare clearinghouses. These are the organizations the law was written for. But the obligations do not stop there — they flow downstream to the vendors covered entities rely on.

A "business associate" is any vendor that creates, receives, maintains, or transmits PHI on behalf of a covered entity. A SaaS company storing patient data, a cloud host, an analytics provider working with health records — all are business associates, and all are directly liable under HIPAA. If you build software that handles PHI for healthcare customers, this is almost certainly the category you fall into, which is why HIPAA shows up in your sales conversations.

The Privacy Rule governs the use and disclosure of protected health information in any form — paper, electronic, or spoken. It sets the boundaries: when PHI may be used and shared (for treatment, payment, and healthcare operations, broadly), when an individual’s authorization is required, and what may never be disclosed without it.

Two ideas from the Privacy Rule come up again and again. The first is the "minimum necessary" standard: you should use or disclose only the smallest amount of PHI needed for the task at hand, rather than handing over a whole record when a single field would do. The second is the set of individual rights the rule grants — most notably the right of individuals to access and obtain a copy of their own health records, and to request corrections. For a software vendor, both translate into concrete product and access-control decisions, not just policy language.

The Security Rule is the part most engineering teams spend their time on, because it deals specifically with electronic PHI. It requires safeguards across three categories: administrative (the policies, training, and assignment of responsibility that govern how people handle ePHI), physical (controlling physical access to the systems and facilities that hold it), and technical (the access controls, audit logging, integrity protections, and transmission security built into the systems themselves).

A defining feature of the Security Rule is that its safeguards come as "implementation specifications" marked either "required" or "addressable." Required specifications must be implemented. Addressable does not mean optional — it means you assess whether the specification is reasonable and appropriate for your environment, and either implement it, implement an equivalent alternative, or document why it does not apply. That flexibility is deliberate: HIPAA is meant to scale from a small clinic to a large platform, so it tells you what to achieve and leaves room for how.

If there is one obligation that anchors the whole Security Rule, it is the risk analysis. HIPAA requires covered entities and business associates to conduct an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of the ePHI they hold — and then to manage those risks down to a reasonable and appropriate level.

This is not a one-time document. The risk analysis is the engine that decides which safeguards matter for your specific systems and how much effort each deserves, and OCR enforcement actions repeatedly come back to it — a missing, stale, or superficial risk analysis is one of the most common findings. Keeping it current as your systems change is most of what "running" a HIPAA program actually involves, much as a living risk register is the heart of any serious security program.

HIPAA does not assume nothing will ever go wrong; it tells you what to do when it does. The Breach Notification Rule requires that, following a breach of unsecured PHI, you notify the affected individuals, and notify HHS, without unreasonable delay and in no case later than 60 days from discovery. For larger breaches affecting many individuals in a region, the media must be notified as well, and notice to HHS is on a tighter footing.

For a business associate, the obligation typically runs to the covered entity you serve: you notify them of a breach so they can meet their own notification duties, on the timeline your BAA sets. The practical implication is that you need to be able to detect a breach, scope which records were affected, and produce that picture quickly — 60 days sounds generous until an incident is underway and you are reconstructing what happened from scattered logs. The work of staying audit-ready before an incident is exactly the work that lets you answer fast during one.

HIPAA is enforced by the HHS Office for Civil Rights. OCR responds to complaints, investigates reported breaches, and conducts audits, and where it finds non-compliance it can require corrective action and impose civil monetary penalties. Those penalties are tiered by culpability, broadly from a genuine lack of knowledge at the low end up to willful neglect that was never corrected at the high end, so what often matters most in an investigation is whether you can show you took reasonable steps and acted in good faith.

Because there is no certificate to hold up, that demonstration is the whole game. You cannot point to a stamp; you point to your risk analysis, your safeguards, your policies, your training records, and your BAAs. A program that is documented, current, and consistent is what stands between a manageable inquiry and a finding of neglect — which is why HIPAA, despite having no exam, rewards the same continuous discipline that certifiable frameworks do.

Teams that handle health data rarely face HIPAA in isolation. A US healthcare customer asks whether you are HIPAA compliant; a larger or international one also asks for SOC 2 or ISO 27001. The good news is that these overlap heavily at the level of actual practice: access controls, audit logging, encryption, risk assessment, incident response, vendor management, and security training are common to all three, even though each names and frames them differently.

The distinction worth keeping straight is what each one is. SOC 2 is an attestation report produced by an auditor against the Trust Services Criteria; ISO 27001 is an international certification of a management system; HIPAA is a law you must comply with and demonstrate compliance against, with no certificate at all. Different artifacts, different bodies — but largely the same underlying safeguards. Maintain those safeguards once, mapped to each framework’s requirements, and HIPAA stops being a separate project and becomes another view onto work you are already doing.

Since no one hands you a certificate, demonstrating HIPAA compliance means being able to produce a coherent body of evidence on request — for an OCR inquiry, a customer’s security review, or your own internal check. There is no official checklist, but the shape is consistent: a current risk analysis, the administrative, physical, and technical safeguards that address it, your written policies and procedures, records of workforce training, and signed BAAs with every vendor that touches PHI.

In practice this is where HIPAA programs succeed or fail. The safeguards are usually in place; what goes wrong is that the proof is scattered — the risk analysis is a year out of date, the policy says one thing and the systems do another, the BAAs live in someone’s inbox. Keeping all of it in one place, current, and linked to the requirement it satisfies is most of what staying compliant actually involves, and it is the difference between answering a security questionnaire in an afternoon and dreading it for a week.