HIPAA

HIPAA is US federal law. The Administrative Simplification rules most product teams mean when they say "HIPAA" live primarily in 45 CFR Part 164: the Privacy Rule (uses and disclosures of PHI), the Security Rule (safeguards for ePHI), and the Breach Notification Rule. Covered entities — health plans, most health care clearinghouses, and health care providers who transmit health information in connection with certain transactions — and business associates who create, receive, maintain, or transmit PHI on behalf of covered entities carry compliance duties.

The Security Rule organizes safeguards into administrative, physical, and technical categories. Implementation specifications are labeled Required or Addressable. Required means implement as stated. Addressable does not mean optional: you must assess whether the specification is reasonable and appropriate in your environment and either implement it, implement an equivalent alternative, or document why it is not reasonable and appropriate — with compensating measures as needed. Treating Addressable as "skip" is a common failure mode in startup security questionnaires.

Health-tech SaaS companies that handle PHI for providers, plans, or other covered entities are typically business associates and need BAAs, Security Rule safeguards, and breach processes aligned to OCR expectations. SOC 2 or ISO/IEC 27001 can support a security narrative and reuse access-control evidence (see /controls/soc-2/cc6-1) but do not replace HIPAA. Use /tools/framework-selector when sequencing HIPAA against SOC 2 or GDPR for mixed buyer pipelines.

OCR (HHS Office for Civil Rights) enforces these rules, publishes guidance, and investigates breaches and complaints. Prefer primary regulatory text and OCR materials over vendor "HIPAA compliant hosting" marketing. Deep technical entry points include /controls/hipaa/164-312-a-1 for access-control themes under the Security Rule.

Independence note: this site explains frameworks and tradeoffs without selling a compliance product. Counsel and qualified privacy/security advisors should apply the rules to your facts — especially entity classification, BAA scope, and breach risk assessment.

The Health Insurance Portability and Accountability Act of 1996 and subsequent rulemaking created a national framework for certain health information privacy and security obligations. For SaaS and security practitioners, the operative detail is largely in 45 CFR Part 160 and Part 164. Part 164 includes the Privacy Rule (Subpart E), the Security Rule (Subpart C), and the Breach Notification Rule (Subpart D), among other provisions. "HIPAA compliant" in casual speech usually collapses these into a single slogan; precise programs address each rule's requirements separately.

Protected health information (PHI) is individually identifiable health information held or transmitted by a covered entity or business associate in any form. Electronic PHI (ePHI) is PHI transmitted by or maintained in electronic media — the Security Rule's focus. De-identification under Privacy Rule standards can take data outside PHI definitions when properly done; "we hashed the MRN" is not automatically de-identification.

Covered entities are defined in the regulations: health plans, health care clearinghouses, and health care providers who transmit health information in electronic form in connection with covered transactions. Business associates are persons or entities that perform functions or activities involving PHI on behalf of, or provide services to, a covered entity (with regulatory definitions and exceptions). Modern cloud EHR add-ons, billing platforms, care-coordination tools, and analytics vendors are frequently business associates. Subcontractors of business associates that handle PHI are also business associates under the cascade the rules established.

The Privacy Rule governs permitted uses and disclosures, individual rights (access, amendments, accounting of disclosures in scope), notice of privacy practices for covered entities, and minimum necessary standards. Business associates must comply with applicable Privacy Rule provisions and only use or disclose PHI as permitted by the BAA and the rules — not for their own unrelated marketing whims.

The Security Rule requires covered entities and business associates to ensure the confidentiality, integrity, and availability of ePHI; protect against reasonably anticipated threats and impermissible uses or disclosures; and ensure workforce compliance. Safeguards are administrative (risk analysis, workforce security, contingency planning, and more), physical (facility and workstation controls), and technical (access control, audit controls, integrity, authentication, transmission security). Implementation specifications under those standards are Required or Addressable as designated in the regulatory text — for example, unique user identification is Required under access control, while encryption of ePHI at rest or in transit appears as Addressable and must be evaluated with documentation.

The Breach Notification Rule defines breach, exceptions, risk assessment factors for whether notification is required, and timelines for notifying affected individuals, HHS, and in some cases the media. Business associates notify covered entities so the covered entity can fulfill downstream duties as applicable. OCR's enforcement posture and published resolutions make risk analysis, access management, and encryption decisions recurring themes in public cases.

HIPAA does not certify products the way ISO 27001 issues a certificate. OCR does not stamp "HIPAA certified SaaS." Compliance is an ongoing obligation evidenced by risk analysis, policies, BAAs, safeguards, and incident response — sometimes supported by third-party assessments customers request, but those assessments are not a statutory HIPAA certificate.

Covered entities need HIPAA privacy and security programs as a core regulatory obligation. Business associates need them when they create, receive, maintain, or transmit PHI for covered entities (and when they use subcontractors that do). If your SaaS stores clinical notes, claims data, patient schedules tied to identifiers, or other PHI for a hospital, clinic, payer, or clearinghouse customer, you are likely in business associate territory — confirm with counsel rather than guessing from marketing categories.

Not every health-adjacent product is automatically a business associate. Consumer apps that receive health information directly from individuals outside covered-entity relationships may fall under different regimes (FTC expectations, state laws, FDA considerations for medical devices, GDPR if EU users are involved). Conversely, calling yourself "wellness only" does not avoid HIPAA if you actually handle PHI for a covered entity. Entity classification is fact-specific.

Trigger events for SaaS teams include: first provider or payer customer asking for a BAA; a health system security review listing Security Rule controls; cyber insurance applications asking about ePHI; or a marketplace (for example EHR app stores) requiring BAAs and security attestations. Waiting until procurement week to invent risk analysis documentation is how deals slip a quarter.

Persona ownership: legal owns BAAs, Privacy Rule interpretations, and breach notification legal judgments; security owns Security Rule risk analysis and safeguard implementation; engineering owns access control, audit logging, encryption, and backup restore for systems with ePHI; customer success and support need minimum-necessary and disclosure discipline; sales must not sign BAAs that promise capabilities the product lacks. Use /tools/framework-selector when leadership asks whether to lead with HIPAA readiness, SOC 2, or ISO 27001 for a mixed pipeline.

Geographic and vertical notes: HIPAA is US-focused. EU health data may simultaneously implicate GDPR special-category rules — a US telehealth vendor serving EU patients can face both. SOC 2 remains the common US B2B attestation ask even in health tech; many buyers want a BAA plus a SOC 2 Type II. Neither replaces the other. See /compare/soc-2-vs-iso-27001 for assurance-artifact sequencing adjacent to HIPAA legal duties.

Avoid vanity claims. "Hosted in a HIPAA-eligible cloud region" means the cloud provider will sign a BAA for covered services — you still must configure, operate, and monitor safeguards for your application layer. Shared responsibility does not evaporate because the infrastructure vendor is sophisticated.

Workforce size does not create an exemption. Small covered entities and small business associates still need risk analysis and applicable safeguards scaled to their environment; OCR has pursued small organizations. Scale your program to risk and complexity, but do not confuse "startup" with "exempt."

A practical HIPAA program for a SaaS business associate has five interlocking layers: classification and scoping, BAAs and subcontractors, Security Rule risk analysis and safeguards, Privacy Rule use/disclosure discipline, and breach readiness. Scoping defines which systems, environments, and data stores create, receive, maintain, or transmit ePHI. Out-of-scope corporate tools should not silently receive production PHI exports. Ambiguous boundaries — analytics sidecars, support tooling, and unmanaged laptop sync — are frequent audit and incident findings.

Business Associate Agreements document permitted uses and disclosures, safeguard duties, breach reporting to the covered entity, termination and PHI return or destruction, and flow-down to subcontractors. Negotiate BAAs as controlled templates when possible; one-off promises about encryption, audit rights, or indemnity can conflict with actual architecture. Maintain an inventory of signed BAAs and the products they cover.

Security Rule compliance centers on an accurate, organization-specific risk analysis: identify where ePHI lives, threats and vulnerabilities, likelihood and impact, and current controls. Risk management then implements measures to reduce risk to a reasonable and appropriate level. The safeguard standards and implementation specifications in 45 CFR §164.308 (administrative), §164.310 (physical), and §164.312 (technical) structure the work. Technical safeguard examples include unique user IDs, emergency access procedures, automatic logoff, encryption and decryption (Addressable — evaluate and document), audit controls, authentication, and transmission security. Access control patterns often align with evidence you already produce for SOC 2; see /controls/hipaa/164-312-a-1 and /controls/soc-2/cc6-1 for complementary deep dives.

Required versus Addressable must be operationalized in writing. For each Addressable specification, record the decision: implemented as stated, equivalent alternative, or not reasonable/appropriate with rationale. Encryption decisions are classic Addressable documentation — many organizations implement encryption widely because residual risk and customer expectations make it reasonable and appropriate, but the regulatory logic is documented analysis, not folklore.

Administrative safeguards include security management process (risk analysis and risk management), assigned security responsibility, workforce security, information access management, security awareness and training, security incident procedures, contingency planning (disaster recovery, backup, emergency mode), and evaluation. Physical safeguards cover facility access, workstation use and security, and device/media controls — including laptop encryption and media disposal for a remote-heavy SaaS workforce.

Privacy Rule operations for business associates emphasize permitted uses only, minimum necessary where applicable, and support for covered-entity obligations such as individual access when the BA holds the designated record set data. Do not use PHI for independent product R&D or model training unless the BAA and rules permit that purpose — a recurring modern flashpoint for AI features.

Breach Notification Rule workflows require detection, investigation, and a risk assessment against regulatory factors to determine whether an incident is a breach requiring notification. Business associates notify covered entities without unreasonable delay so timelines can be met. Tabletop exercises should include lost devices, misdirected exports, and ransomware affecting ePHI systems.

OCR guidance and enforcement settlements repeatedly stress risk analysis quality, access controls, audit logging, and encryption. Treat those as priority engineering themes. Customer SOC 2 reports and penetration tests help due diligence but do not erase Security Rule duties.

Classify your entity role with counsel: covered entity, business associate, subcontractor BA, or not in scope. Inventory products, environments, and vendors that touch PHI. Freeze a clear ePHI system boundary and data-flow diagram that sales, security, and engineering share.

Execute BAAs with covered-entity customers before PHI lands in production. Flow BAAs to subcontractors that create, receive, maintain, or transmit PHI — cloud providers, support platforms, email for care communications, and analytics tools as applicable. Prefer providers willing to sign BAAs for the specific services you use; "HIPAA eligible" is not the same as "covered under your BAA."

Perform and document an enterprise-wide Security Rule risk analysis. Prioritize remediation: identity and access management, unique IDs, MFA for privileged and remote access, audit logging on ePHI systems, encryption in transit and at rest where reasonable and appropriate, backup and restore testing, vulnerability management, and workforce training. Document Addressable decisions explicitly. Map safeguards to owners and evidence sources so customer questionnaires and OCR inquiries do not rely on tribal knowledge.

Publish and train on policies that match practice: access management, incident response, contingency planning, device security, and sanctions. Implement joiner-mover-leaver processes tied to your IdP. Restrict production ePHI access to roles that need it; separate environments so unrestricted developer sandboxes do not hold real PHI.

Stand up incident and breach response with legal escalation criteria, forensic capability proportionate to risk, and notification playbooks for BA-to-covered-entity reporting. Test backups and emergency access procedures — contingency planning is a Security Rule expectation, not optional IT hygiene.

Prepare customer assurance packets: BAA template summary, security whitepaper mapped to administrative/physical/technical safeguards, recent SOC 2 report under NDA if available, penetration test executive summary if part of your program, and subprocessor or subcontractor disclosure. Keep questionnaire answers consistent with the risk analysis. Link internal control references such as /controls/hipaa/164-312-a-1 for access control narratives.

Review the program on a cadence: update risk analysis when systems or threats change materially; retrain workforce; revisit Addressable decisions after architecture shifts (for example new data stores). If you also pursue ISO 27001, reuse risk and access-control work inside an ISMS without treating certification as HIPAA completion — compare assurance sequencing at /compare/soc-2-vs-iso-27001.

Before enabling AI, data-lake, or secondary-analytics features on PHI, return to Privacy Rule permissions and BAA scope. Engineering convenience is not a permitted use.

HIPAA readiness timelines vary with whether you already operate mature access, logging, and incident controls. A SaaS team with strong SOC 2 Security practices can often reach a credible BA posture in roughly three to six months of focused work: BAA templates, risk analysis, Addressable documentation, ePHI boundary cleanup, and breach playbooks. Organizations inventing IAM and audit logging from scratch commonly need six to twelve months before enterprise health systems will accept residual risk.

Critical path slips usually involve: discovering PHI in unmanaged tools (support inboxes, spreadsheets, shadow analytics); negotiating first BAAs with unfavorable terms under sales pressure; completing a written risk analysis leadership will stand behind; encrypting legacy data stores; and implementing audit controls that actually record access to ePHI. Parallelize legal BAA work with technical remediation; serial execution doubles calendar time.

Customer procurement adds external clocks. Health systems may require evidence before go-live: signed BAA, security questionnaire, sometimes SOC 2 Type II freshness, and architecture review. Align your observation windows and pen-test dates with those expectations rather than promising dates you cannot evidence. Use /tools/framework-selector when deciding whether HIPAA BA readiness or SOC 2 fieldwork is the longer pole for a specific deal.

Ongoing timeline is continuous: risk analysis updates, access reviews, training, contingency plan tests, and vendor BA renewals. Major product launches that change how PHI is processed should pass a privacy-and-security gate before production. Breach response capability should be tabletop-tested at least annually — or after major org changes — because notification clocks start when you discover an incident, not when it is convenient.

If GDPR also applies (EU individuals' health data), build dual-regime milestones: DPA plus BAA, Article 32 plus Security Rule mappings, and separate rights versus individual-access workflows where legal regimes differ. Do not assume one policy binder satisfies both.

Accelerators that work: reuse SOC 2 populations for access reviews; appoint a single security owner for risk analysis updates; freeze nonessential PHI-adjacent architecture changes in the weeks before a strategic customer assessment. Decelerators: expanding PHI into new microservices without updating the risk analysis, and signing BAAs for products not yet safeguard-ready.

HIPAA program cost combines legal spend (BAA templates, entity classification, breach counsel retainers), security engineering for Security Rule safeguards, workforce training, possible compliance or GRC tooling, third-party assessments customers request, and the soft cost of deal delay when BA readiness lags pipeline. There is no official OCR "HIPAA certification fee." Customer-required SOC 2 examinations, penetration tests, and security questionnaires are adjacent costs often budgeted in the same year.

Cloud BAAs from major providers are typically included in eligible service agreements but do not remove your application-layer obligations — shared responsibility still demands configuration, monitoring, and access discipline. Tooling for logging, SIEM, endpoint management, and backup is often already justified by SOC 2; attribute it once and map to HIPAA safeguards rather than double-counting.

Educational cost context for SOC 2 programs at /costs/soc-2/overview helps finance model dual-track years when health-tech buyers want both a BAA and a Type II report. Published blog ranges for "HIPAA compliance projects" are not regulatory quotes — scope your risk analysis and architecture before treating influencer numbers as budgets.

Soft costs include engineering pulled into questionnaire archaeology, reworking AI features that improperly used PHI, and breach investigation expenses. Underfunding audit logging and access management is false economy given OCR enforcement themes. Insurance may ask about HIPAA program maturity; premiums and coverage terms can move with demonstrated controls, but insurance is not a safeguard substitute.

When leadership wants a single annual number, separate: (1) legal and training, (2) incremental engineering for ePHI safeguards beyond existing SOC 2 controls, (3) assurance artifacts (SOC 2, pen tests) driven by customer demand, and (4) contingency for incident response retainers. Revisit after entering first enterprise provider contracts — questionnaire burden and BAA negotiation time often surprise first-time health-tech vendors.

Compare build-versus-buy for logging and access-review automation against the size of your ePHI workforce and customer audit frequency. A small BA with few privileged users may operate disciplined IdP reviews; a multi-product platform with many integrators may need stronger continuous monitoring investment.

SOC 2 is the most common complementary assurance artifact for US health-tech SaaS. Buyers often request a BAA plus a current SOC 2 Type II covering Security. Control overlap is high for access control, change management, logging, and vendor management, but SOC 2 does not implement the Privacy Rule or satisfy Security Rule documentation duties by itself. ISO/IEC 27001 similarly structures ISMS risk management that can parallel HIPAA risk analysis — still not a HIPAA certificate. Sequencing of SOC 2 versus ISO 27001 for general SaaS markets is covered at /compare/soc-2-vs-iso-27001; health-tech teams usually keep HIPAA legal compliance on its own track while choosing assurance artifacts for procurement.

GDPR applies when you process personal data in scope of that Regulation, including special-category health data for people in the EEA. A US BA serving EU patients may need both BAAs and GDPR processor/controller constructs. Article 32 security measures resemble Security Rule goals but differ in legal tests and rights operations — do not paste HIPAA policies into a GDPR register without legal review.

HITRUST, state breach laws, FTC expectations for health apps, and CMS or program-specific requirements may appear in enterprise packets. Treat each as a separate mapping exercise. NIST CSF can help communicate risk posture to boards and align with Security Rule risk analysis language without replacing 45 CFR Part 164.

Maintain one engineering control set with crosswalks to SOC 2 criteria, ISO Annex A, HIPAA safeguard citations, and GDPR Article 32 where applicable. Entry points on this site include /controls/hipaa/164-312-a-1 and /controls/soc-2/cc6-1. Use /tools/framework-selector when prioritizing roadmap investment across regimes.

Avoid marketing claims that "SOC 2 equals HIPAA" or "HIPAA-compliant hosting equals company compliance." Precise language — BAAs in place, Security Rule risk analysis performed, safeguards implemented with Required/Addressable decisions documented — survives customer and regulator scrutiny better than slogans.