What Is HIPAA Compliance? A Complete Guide for 2026

What Is HIPAA Compliance? A Complete Guide for 2026. HIPAA compliance means meeting the U.S. rules that protect health data. Learn the HIPAA rules, who must comply, what PHI is, BAAs, penalties, and how to comply.

Last updated: August 2026

HIPAA compliance means following the U.S. laws and regulations that protect the privacy and security of health information. Any organization that handles protected health information (PHI), whether a hospital, an insurer, or a software vendor that stores health data on their behalf, must put specific administrative, physical, and technical safeguards in place and can face significant penalties if it does not.

This guide explains what HIPAA is, who has to comply, what counts as protected health information, the safeguards the law requires, the role of the Business Associate Agreement (BAA), the penalties for non-compliance, and the practical steps to become compliant. It also covers what HIPAA means specifically for the cloud and SaaS vendors that modern healthcare runs on.

What is HIPAA?

HIPAA is the Health Insurance Portability and Accountability Act of 1996, a U.S. federal law. Its Administrative Simplification provisions, and the regulations issued under them by the U.S. Department of Health and Human Services (HHS), set national standards for protecting sensitive patient health information.

Two later updates matter for anyone assessing compliance today:

• The HITECH Act (2009) strengthened enforcement, introduced mandatory breach notification, and extended direct liability to the vendors that handle health data on behalf of healthcare organizations.
• The HIPAA Omnibus Rule (2013) finalized those changes, making “business associates” and their subcontractors directly accountable under the law.

HIPAA is enforced by the HHS Office for Civil Rights (OCR). The authoritative source for the rules is the HHS HIPAA site.

The HIPAA Rules

HIPAA is not a single checklist. It is a set of interlocking rules, and knowing which one applies to a given obligation is half the battle.

For a cloud or software vendor, the Security Rule and the Breach Notification Rule carry most of the day-to-day obligations. The Privacy Rule applies mainly to the healthcare organization itself, though vendors inherit pieces of it through their contracts.

Who must comply with HIPAA?

HIPAA obligations flow down a chain, and each link is directly accountable to HHS.

• Covered Entities. Healthcare providers that transmit health information electronically, health plans, and healthcare clearinghouses. A hospital, a clinic, and a health insurer are all covered entities.
• Business Associates. Any person or company that creates, receives, maintains, or transmits PHI on behalf of a covered entity. A cloud host, an analytics provider, a billing service, and an identity platform that authenticates patients are all business associates.
• Subcontractors. A business associate’s own vendors that touch PHI are also bound, one step further down the chain.

Since HITECH, business associates are directly liable to HHS, not only contractually liable to their customer. This is why a SaaS vendor cannot simply promise to “be careful” with health data; it has to meet the Security Rule itself and sign agreements that make the obligation enforceable.

What is Protected Health Information (PHI)?

Protected Health Information (PHI) is any individually identifiable health information held or transmitted by a covered entity or business associate. When it is stored or transmitted electronically, it is called electronic PHI (ePHI).

PHI is broader than most people expect. It includes obvious clinical data such as diagnoses, lab results, and treatment records, but it also includes identifiers tied to health context, for example a name, email address, or account that reveals a person is a patient of a particular provider. The fact that jane@example.com has an account on a specific hospital’s patient portal is itself PHI, because it links an identifiable individual to the receipt of care.

That last point matters enormously for identity and access management, which we return to below.

The HIPAA Security Rule safeguards

The Security Rule organizes its requirements into three categories of safeguards. This is the framework auditors, and your customers’ security teams, will hold you to.

Administrative safeguards

• A documented security management process, including a risk analysis (the single most-requested piece of evidence in any HIPAA review).
• A designated security official.
• Workforce security, access management, and security awareness training.
• A contingency plan (data backup, disaster recovery, emergency operations).
• Regular evaluation of controls.

Physical safeguards

• Facility access controls.
• Workstation and device security.
• Media controls, including secure disposal of hardware that held ePHI.

Technical safeguards

• Access control: unique user identification, least privilege, and automatic logoff.
• Audit controls: recording and examining activity in systems that contain ePHI.
• Integrity controls: protecting ePHI from improper alteration or destruction.
• Authentication: verifying that a person or system seeking access is who they claim to be.
• Transmission security: encryption of ePHI in transit.

If those technical safeguards sound like the core of a modern identity and access management platform, that is not a coincidence. Access control, authentication, audit logging, and encryption are exactly what an authentication layer provides. In Keycloak specifically, the Security Rule’s “unique user identification” maps to per-user accounts and roles, “automatic logoff” maps to realm session and idle-timeout settings, “authentication” maps to multi-factor authentication, and “audit controls” map to Keycloak’s login and admin event logging.

What is a Business Associate Agreement (BAA)?

A Business Associate Agreement (BAA) is the contract that makes HIPAA enforceable down the chain. Before a covered entity may share PHI with a vendor, the two must sign a BAA. Before that vendor may pass PHI to its own subcontractors, it must sign BAAs with them.

A BAA is not a trust signal or a nice-to-have. It is a legal gate. Without a signed BAA, a healthcare organization cannot lawfully send PHI to a vendor at all. A standard BAA requires the business associate to:

• Use PHI only as permitted and required.
• Apply the Security Rule safeguards to ePHI.
• Report security incidents and breaches, typically within 60 days.
• Ensure its subcontractors agree to equivalent protections.
• Make PHI available for access and amendment, and cooperate with HHS.
• Return or destroy PHI when the contract ends.

Think of the BAA as the health-data equivalent of a GDPR Data Processing Agreement: it does not, by itself, make you compliant, but it is the written promise that you already are.

HIPAA penalties for non-compliance

HIPAA penalties are tiered by culpability and are adjusted annually for inflation. As of the most recent adjustments, civil monetary penalties run from roughly $137 per violation at the least-culpable tier to tens of thousands of dollars per violation at the most serious tier, with an annual cap of over $2 million for repeated identical violations.

The four tiers are:

1. No knowledge: the entity did not know and could not reasonably have known of the violation.
2. Reasonable cause: the violation was due to reasonable cause, not willful neglect.
3. Willful neglect, corrected: willful neglect that was corrected within 30 days.
4. Willful neglect, not corrected: the most serious tier, with the highest penalties.

Beyond fines, the reputational damage of a reportable breach, and the loss of enterprise healthcare deals that require a signed BAA, are often the larger commercial cost.

HIPAA compliance for cloud and SaaS vendors

Almost no healthcare organization runs entirely on its own hardware anymore, which means HIPAA compliance is now a shared-responsibility exercise across a chain of cloud and SaaS vendors.

Two principles are worth internalizing:

• There is no “HIPAA certification.” HHS certifies no one. Any vendor selling you a “HIPAA certificate” has invented it. What actually exists is a signed BAA, a documented risk analysis, and independent evidence of the underlying controls, most commonly a SOC 2 Type II report and an ISO/IEC 27001 certificate. Those third-party audits are what give a vendor’s self-attested HIPAA posture its credibility.
• The conduit exception is narrow. A vendor that merely transmits data without storing it may sometimes avoid business-associate status, but HHS closed that door for cloud providers that store ePHI, even encrypted, even without holding the keys. If you store the data, you are a business associate and you need a BAA.

When you evaluate a vendor for a healthcare workload, ask three questions: Will you sign a BAA? Can you show a risk analysis scoped to ePHI? Do you hold SOC 2 Type II and ISO 27001 as independent evidence of your controls?

HIPAA and identity: why authentication is in scope

Identity and access management sits squarely inside the HIPAA Security Rule. Every technical safeguard the rule names, access control, unique user identification, automatic logoff, audit controls, authentication, and transmission security, is delivered by the authentication layer in front of a healthcare application.

There is also a subtler point. As noted earlier, the mere fact that an identifiable individual has an account on a healthcare system is PHI. That means your authentication logs are PHI: a log entry showing that a specific user signed in to a specific provider’s portal reveals that the person is a patient. Any system that authenticates patients, and any system that stores those authentication events, is handling PHI and belongs inside your HIPAA scope, with a BAA in place. (For a deeper look at how Keycloak records these events, see our guide to Keycloak auditing and event logging.)

For teams running Keycloak as their identity layer, this has a practical consequence: the Keycloak deployment, and the infrastructure that hosts it, must be covered by the same HIPAA controls and BAAs as the rest of the health application. Encryption at rest and in transit, least-privilege access, mandatory multi-factor authentication for administrators, and complete audit logging are not optional add-ons; they are the Security Rule’s technical safeguards expressed in an IAM system.

How to become HIPAA compliant: a practical checklist

Becoming HIPAA compliant is less about a single event and more about standing up a documented, ongoing program. For a technology organization, the core steps are:

1. Scope your ePHI. Identify every system that creates, receives, maintains, or transmits PHI, including authentication and logging systems.
2. Conduct a risk analysis under the Security Rule. This is mandatory and is the first thing HHS or a customer will ask for.
3. Implement the safeguards across administrative, physical, and technical categories: risk management, access control, MFA, encryption, audit logging, backup, and disaster recovery.
4. Sign BAAs down the chain. Execute BAAs with every subcontractor and cloud provider that touches PHI (for example, your cloud host), and be ready to offer your own BAA to customers.
5. Document a breach response that meets the Breach Notification Rule’s timelines.
6. Train your workforce and repeat annually.
7. Get independent evidence. Maintain SOC 2 Type II and ISO 27001 to give your program third-party credibility.
8. Review continuously. HIPAA is not a point-in-time certificate; it is an ongoing obligation.

Frequently asked questions

Is there such a thing as HIPAA certification? No. HHS does not certify or endorse any organization as HIPAA compliant. Compliance is demonstrated through a signed BAA, a documented risk analysis, and independent control evidence such as SOC 2 Type II and ISO 27001, not through a certificate.

Does a SaaS or cloud vendor need to be HIPAA compliant? Yes, if it creates, receives, maintains, or transmits PHI on behalf of a healthcare organization. Storing ePHI makes a vendor a business associate, which requires a signed BAA and compliance with the Security Rule, even if the data is encrypted.

What is the difference between a BAA and being HIPAA compliant? A BAA is a contract; HIPAA compliance is meeting the law’s requirements. Signing a BAA does not make you compliant, it makes you liable. You must already meet the Security Rule for the BAA to be a promise you can keep.

Are authentication logs considered PHI? They can be. A log entry showing that an identifiable individual authenticated to a specific healthcare provider’s system reveals that the person is a patient, which is protected health information. Systems that store patient authentication events are typically in HIPAA scope.

How fast must a breach be reported under HIPAA? A business associate must notify the affected covered entity of a breach of unsecured PHI without unreasonable delay and no later than 60 calendar days after discovery, under 45 CFR 164.410. Related reading: how Keycloak handles GDPR data erasure and retention, another regulation with strict data-handling rules.

HIPAA-ready managed Keycloak with Skycloak

Skycloak provides managed Keycloak with the technical safeguards the HIPAA Security Rule requires built in: encryption at rest and in transit, least-privilege role-based access, mandatory MFA for administrative access, complete audit logging, dedicated isolated clusters per customer, and U.S. hosting for regulated workloads. Skycloak is HIPAA-compliant and BAA-ready, backed by SOC 2 Type II and ISO 27001, and executes Business Associate Agreements with healthcare customers.

To discuss a HIPAA workload or request a BAA, visit our security page or get in touch.

Ready to run HIPAA-ready managed Keycloak? See Skycloak pricing.