Safeguard
Compliance

Define HIPAA: What the Law Actually Requires of Software Teams

HIPAA gets invoked constantly and understood rarely. Here is a plain-English definition, the rules that matter for engineers, and where software supply chain fits in.

Yukti Singhal
Security Analyst
6 min read

To define HIPAA in one sentence: it is the 1996 U.S. Health Insurance Portability and Accountability Act, and for software teams it is the federal law that dictates how electronic protected health information must be safeguarded. People say "that's a HIPAA thing" as if HIPAA were a single checklist. It is not. It is a statute with several distinct rules, and the parts that land on engineers are narrower and more concrete than the mythology suggests. This guide separates what the law says from what people assume it says.

The Short, Accurate Definition

HIPAA stands for the Health Insurance Portability and Accountability Act, enacted in 1996 and enforced in the United States by the Department of Health and Human Services, specifically its Office for Civil Rights. Its original purpose was health-insurance portability, but the provisions everyone cites today come from the administrative-simplification rules that followed, which govern the privacy and security of health data.

The law applies to two categories of organization. Covered entities are health plans, health-care clearinghouses, and providers who transmit health information electronically. Business associates are the vendors that handle protected health information on a covered entity's behalf, and this is the bucket most software companies fall into. If you build software that stores or processes patient data for a hospital, you are almost certainly a business associate, and you are bound by HIPAA through a Business Associate Agreement.

What Counts as PHI

The object HIPAA protects is protected health information, or PHI. When it lives in electronic systems it is ePHI, and that is the version engineers deal with. PHI is health information tied to an identifiable individual: not just diagnoses and lab results, but names, dates, addresses, medical record numbers, and any of eighteen identifier categories when linked to health data.

The practical consequence is that PHI is broader than "medical records." A log line that pairs a patient's name with an appointment time is PHI. A support ticket screenshot showing a member ID is PHI. Teams get into trouble by protecting the primary database carefully and then leaking the same data through logs, analytics pipelines, error trackers, and CI artifacts.

The Three Rules Engineers Care About

HIPAA is not one rule. Three of them shape day-to-day engineering.

The Privacy Rule governs how PHI may be used and disclosed. Its operating principle is minimum necessary: use and share only the smallest amount of PHI needed for the task. In software terms this pushes you toward tight access controls, purpose-scoped queries, and not copying whole tables into environments that do not need them.

The Security Rule is the one written for technical people. It requires administrative, physical, and technical safeguards for ePHI, organized as required and addressable specifications. The technical safeguards map onto things you already recognize: access control with unique user IDs, audit controls that log who touched what, integrity controls, and transmission security, which in practice means encryption in transit and, as an addressable specification, encryption at rest.

The Breach Notification Rule dictates what happens after a leak. If unsecured PHI is breached, you must notify affected individuals, HHS, and in large breaches the media, generally within sixty days. "Unsecured" is the key word: properly encrypted PHI that is exposed may fall under safe-harbor and not trigger notification, which is a strong practical argument for encrypting everything.

What This Means for Your Codebase

HIPAA does not prescribe specific technologies, which frustrates engineers who want a checklist. What it demands is that you can demonstrate reasonable, documented safeguards. In a modern stack that translates into:

  • Encryption in transit and at rest for anything touching ePHI, so a breach has a shot at safe-harbor treatment.
  • Unique per-user authentication and least-privilege access, with no shared service accounts silently reading patient tables.
  • Comprehensive, tamper-evident audit logging of PHI access, retained long enough to support an investigation.
  • PHI kept out of places it does not belong: logs, error trackers, analytics events, test fixtures, and screenshots. This is where most real incidents originate.
  • Vendor and dependency diligence, because your business associates and your open-source dependencies both extend the boundary of systems that can leak PHI.

That last point is where software supply chain enters the picture. Every third-party library and service in a system that handles ePHI is part of your attack surface, and a vulnerable dependency in a HIPAA-scoped application is a compliance problem, not just a security one. Knowing exactly what is in your build, through an SCA and SBOM workflow, is part of demonstrating the "reasonable safeguards" the Security Rule asks for. For teams also chasing SOC 2 or other frameworks, much of the control work overlaps, and our notes on where compliance frameworks meet the supply chain cover that overlap.

HIPAA Myths Worth Killing

A few things HIPAA does not do, which people constantly assume it does:

  • It does not require any specific certification. There is no "HIPAA certified" stamp from HHS; vendors who claim one are describing a self-attestation or a third-party assessment, not a government seal.
  • It does not name approved technologies. AES, TLS versions, and cloud providers are your choices to justify, not HIPAA's to mandate.
  • It does not apply to all health data everywhere. A fitness app you built for consumers, with no covered entity in the chain, may not be HIPAA-covered at all, though other laws can still apply.

FAQ

What does HIPAA stand for?

HIPAA stands for the Health Insurance Portability and Accountability Act, a U.S. federal law passed in 1996 and enforced by the Department of Health and Human Services Office for Civil Rights.

Is my software company subject to HIPAA?

If you store, process, or transmit protected health information on behalf of a covered entity such as a hospital, clinic, or health plan, you are a business associate and are bound by HIPAA through a Business Associate Agreement. If no covered entity is in your chain, you may not be covered, though other privacy laws can still apply.

Does HIPAA require encryption?

Encryption is an addressable specification, not a flat mandate, meaning you must either implement it or document a justified alternative. In practice, encrypting ePHI in transit and at rest is the standard expectation and also the path to breach safe-harbor, so most teams simply encrypt everything.

How is HIPAA enforced and what are the penalties?

The HHS Office for Civil Rights investigates complaints and breaches. Penalties scale with culpability, from smaller fines for unknowing violations up to millions of dollars per year for willful neglect, and serious cases can carry criminal liability.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.