Does HIPAA apply to my SaaS company?

HIPAA applies to your SaaS company if you are a Business Associate, meaning you create, receive, maintain, or transmit Protected Health Information (PHI) on behalf of a Covered Entity (a healthcare provider, health plan, or healthcare clearinghouse). If hospitals, clinics, health plans, or other covered entities are your customers and their PHI flows through your system, you are a Business Associate and HIPAA applies. You do not need to be in healthcare yourself, being a technology vendor to healthcare organizations is sufficient.

What is a Business Associate Agreement?

A Business Associate Agreement (BAA) is a contract required by HIPAA between a Covered Entity and a Business Associate (or between two Business Associates). The BAA specifies how PHI can be used, requires safeguards for PHI, establishes breach notification obligations, and defines the terms under which PHI can be disclosed. You must have a signed BAA with every healthcare customer before they send you PHI. Operating without a BAA when you handle PHI is a HIPAA violation.

What are the HIPAA Security Rule requirements for SaaS?

The HIPAA Security Rule requires three categories of safeguards for electronic PHI (ePHI): Administrative safeguards (risk analysis, risk management, workforce training, access management procedures, contingency plans), Physical safeguards (facility access controls, workstation controls, device disposal procedures), and Technical safeguards (access controls, audit controls, integrity controls, encryption in transit and at rest). The Security Rule is technology-neutral, it does not prescribe specific tools, only that you implement reasonable and appropriate safeguards based on your risk analysis.

Does HIPAA require encryption?

HIPAA does not mandate encryption outright, it lists encryption as an addressable specification, meaning you must either implement it or document why an equivalent alternative measure achieves the same protection. In practice, any modern SaaS company handling ePHI should encrypt PHI at rest and in transit. Not encrypting ePHI and documenting a valid alternative is theoretically possible but almost never appropriate. Encrypt ePHI, both at rest (AES-256) and in transit (TLS 1.2+).

What is the difference between HIPAA and SOC 2 for healthcare SaaS?

HIPAA is a legal requirement for Business Associates, you must comply or face civil and criminal penalties. SOC 2 is voluntary but often required by enterprise healthcare customers to demonstrate that your security controls meet their vendor risk requirements. HIPAA defines what you must protect (PHI) and the minimum required safeguards. SOC 2 Type 2 demonstrates to customers that your security program is independently verified. Many healthcare SaaS companies need both, HIPAA compliance as a legal baseline, SOC 2 for customer trust.

HIPAA compliance checklist for SaaS startups: what you actually need

HIPAA compliance is not optional if you handle protected health information on behalf of healthcare organizations. The question is not whether to comply, it is how to build a compliance program that satisfies the regulation without derailing your engineering roadmap.

HIPAA compliance checklist for SaaS companies

This checklist covers what a SaaS startup operating as a Business Associate actually needs to implement. It skips the legal noise and focuses on what matters operationally.

First: confirm HIPAA applies to you

HIPAA applies to Business Associates. You are a Business Associate if you:

Provide services to a Covered Entity (hospital, clinic, health plan, pharmacy, health clearinghouse) AND
In providing those services, you create, receive, maintain, or transmit protected health information (PHI)

PHI is any individually identifiable health information, including demographic data, that is created or received by a healthcare provider and relates to an individual's health condition, provision of care, or payment for care.

If your SaaS product stores patient records, appointment data, lab results, insurance claims, or any other information that could identify an individual and relates to their healthcare, HIPAA applies.

If you only process de-identified data (where all 18 HIPAA identifiers have been removed according to the Safe Harbor or Expert Determination method), HIPAA's Privacy and Security Rules do not apply to that data.

The HIPAA compliance checklist

Business Associate Agreements

Sign a BAA with every covered entity customer before they transmit PHI to your system
Sign BAAs with your subprocessors that touch PHI, this includes cloud infrastructure (AWS, GCP, Azure all offer HIPAA BAAs), database providers, logging services, email providers, and any other vendor that processes PHI on your behalf
Create a BAA template reviewed by a healthcare attorney for use with customers
Track BAA status for every customer, know who has a signed BAA and who does not
Review BAAs annually or when the business relationship changes significantly

Note: AWS, GCP, and Azure all offer HIPAA BAAs for their services used to store or process ePHI. You must sign these BAAs, they do not apply automatically.

Risk Analysis and Risk Management

Conduct a risk analysis to identify threats and vulnerabilities to the confidentiality, integrity, and availability of ePHI in your systems
Document the risk analysis: OCR (the HIPAA enforcement agency) consistently cites lack of risk analysis as the top violation in audits
Create a risk management plan to reduce identified risks to a reasonable and appropriate level
Review and update the risk analysis at least annually and whenever your environment changes (new infrastructure, new features, new PHI data flows)
Keep evidence of both: auditors and OCR investigations require documentation of what you analyzed and what you did about it

Administrative Safeguards

Designate a HIPAA Privacy Officer: a named individual responsible for HIPAA compliance (can be a founder or senior employee at a startup)
Designate a HIPAA Security Officer: a named individual responsible for security policies and safeguards for ePHI (can be the same person as Privacy Officer)
Implement workforce training: all employees with access to PHI must be trained on HIPAA policies and procedures
Document training completion: maintain records of who completed training and when
Implement a sanction policy: define consequences for employees who violate HIPAA policies
Implement access management procedures: formal process for granting, modifying, and revoking access to systems containing ePHI
Implement a contingency plan: data backup, disaster recovery, and emergency mode operation procedures for systems containing ePHI
Conduct regular workforce training: at hire and at least annually thereafter

Physical Safeguards

Facility access controls: if you have on-premises infrastructure or an office where ePHI is accessed, control physical access
Workstation use policy: define how workstations that access ePHI should be used and protected (screen locks, clean desk policy, remote access requirements)
Device and media controls: procedures for the disposal, reuse, and removal of hardware and electronic media containing ePHI (secure wiping requirements)
Remote access policy: requirements for employees accessing ePHI from outside the office (VPN, MDM enrollment, encrypted devices)

For SaaS companies using cloud infrastructure, physical safeguards largely delegate to your cloud provider (covered by their HIPAA BAA), but you must still address workstation and device policies for your employees.

Technical Safeguards

Unique user identification: each user must have a unique identifier; no shared accounts for systems containing ePHI
Automatic logoff: sessions that can access ePHI should time out after a defined period of inactivity
Encryption in transit: all ePHI transmitted over networks must be encrypted (TLS 1.2 or higher)
Encryption at rest: all ePHI stored on servers, databases, and backups must be encrypted (AES-256)
Audit controls: implement audit logging for all access to ePHI, including who accessed what and when
Integrity controls: mechanisms to ensure ePHI is not improperly altered or destroyed (checksums, audit logs)
Access controls: role-based access limiting each user to the minimum PHI necessary for their role (minimum necessary standard)
Multi-factor authentication: required for all accounts with access to ePHI systems, including admin accounts
Emergency access procedure: a procedure for accessing ePHI in emergency situations when normal authentication methods are unavailable

Breach Notification

Breach notification procedure: a documented process for identifying, investigating, and reporting breaches of unsecured PHI
Breach determination criteria: documented criteria for determining whether a security incident constitutes a reportable breach (presumption of breach unless a 4-factor risk assessment shows low probability of compromise)
Covered Entity notification: within 60 days of discovering a breach, notify affected Covered Entities
Individual notification: for breaches affecting 500 or more individuals, affected individuals must be notified within 60 days; for smaller breaches, annual notification is permitted
HHS notification: report breaches to the Department of Health and Human Services; breaches affecting 500+ individuals in a state require immediate notification and media notice
Breach documentation: maintain documentation of all security incidents and breach determinations for 6 years

Policies and Procedures

HIPAA Privacy Policy: documented policies governing PHI use and disclosure
HIPAA Security Policy: documented policies for all Security Rule safeguards
Acceptable Use Policy: governing employee use of systems containing ePHI
Incident Response Plan: specific to security incidents involving ePHI
Media Sanitization Policy: for disposal of hardware and storage media
BAA Policy: governing when BAAs are required and how they are managed
Retention: all HIPAA documentation must be retained for 6 years from creation or last effective date, whichever is later

HIPAA and SOC 2 together

Many healthcare SaaS companies pursue both HIPAA compliance and SOC 2. The control overlap is significant:

Access management (SOC 2 CC6 ↔ HIPAA Technical Safeguards)
Incident response (SOC 2 CC7 ↔ HIPAA Breach Notification)
Risk assessment (SOC 2 CC3 ↔ HIPAA Risk Analysis)
Vendor management (SOC 2 CC9 ↔ HIPAA BAA requirements)
Audit logging (SOC 2 CC7 ↔ HIPAA Audit Controls)

Maintaining both with a compliance platform that maps evidence to both frameworks simultaneously avoids double work. Evidence collected once, access logs, training records, risk assessments, can satisfy both sets of requirements.

Common HIPAA mistakes at SaaS startups

Not signing BAAs before PHI flows in

This happens frequently when a startup moves fast and assumes the contract will follow. It is a violation from the moment PHI touches your system without a signed BAA.

Missing subprocessor BAAs

You need a BAA with every vendor that processes ePHI, including your cloud provider, database service, logging platform, and error tracking tool. AWS does not automatically cover you; you must sign their BAA.

No documented risk analysis

The most common OCR audit finding. "We do security things" is not a risk analysis. It must be documented.

Shared accounts

No shared logins for systems with ePHI. Each person needs a unique credential for audit log integrity.

Logging without reviewing

HIPAA requires audit controls, which means not just logging but having a process for reviewing logs for anomalies.

Running HIPAA and SOC 2 together, so one audit package covers both without double work, is exactly what a fractional CISO does instead of leaving it on your plate. Book a call to map your fastest path to both.

Want a security leader to run this?

Xorabyte is a fractional CISO for startups who can review your cloud for the gaps found first, so a blocked deal or an audit stops being your problem to carry alone. Book a call and you will leave with a clear path, not a sales pitch.