HIPAA Compliance for SaaS Startups: What You Actually Need

HIPAA Compliance for SaaS Startups: What You Actually Need

TL;DR

• If your SaaS product creates, receives, maintains, or transmits protected health information (PHI) on behalf of a healthcare provider, health plan, or clearinghouse, you are a Business Associate under 45 CFR 160.103 and HIPAA applies to you directly.
• The Security Rule (45 CFR §§ 164.308, 164.310, 164.312) applies to Business Associates in the same manner as it does to covered entities — a direct obligation created by the HITECH Act (42 USC 17931), not just a contractual one.
• You need signed Business Associate Agreements (BAAs) before handling any PHI — with your healthcare customers and with any subcontractor that touches that data.
• Encryption, access controls, audit logging, and a documented risk analysis are the non-negotiable floor. "Addressable" specifications in the Security Rule are not optional — you must implement them or document an equivalent.
• Civil monetary penalties under 42 USC 1320d-5 range from $100 per violation (unknowing) to $50,000 per violation (willful neglect uncorrected), with annual caps up to $1.5 million per violation category. Documentation is your primary defense.

Who This Is For

This guide is written for founders and technical leads at SaaS startups who are building products that will touch healthcare customer data. It assumes you are not a lawyer and do not have a compliance team yet. The goal is a clear picture of your obligations and a realistic first-year implementation path. For legal interpretation specific to your product, engage a healthcare privacy attorney.

Does HIPAA Apply to Your Product?

HIPAA applies to Covered Entities — healthcare providers, health plans, and healthcare clearinghouses — and to their Business Associates. Under 45 CFR 160.103, a Business Associate is any person or entity that creates, receives, maintains, or transmits PHI on behalf of a Covered Entity in the course of providing services such as data analysis, software hosting, claims processing, or quality assurance.

If a healthcare provider or health plan is your customer and your product touches their patient data, you are a Business Associate. The HITECH Act (42 USC 17931) made the Security Rule's requirements apply directly to Business Associates — not just through contract, but as a matter of federal law. That means OCR can investigate and fine you directly, not only your healthcare customer.

What qualifies as PHI? Under 45 CFR 160.103, PHI is individually identifiable health information transmitted or maintained in any form. The Safe Harbor de-identification standard at 45 CFR 164.514 lists 18 categories of identifiers that must be removed before data is considered de-identified: names, geographic subdivisions smaller than state level, all date elements except year, telephone and fax numbers, email addresses, Social Security numbers, medical record numbers, health plan beneficiary numbers, account numbers, license numbers, vehicle identifiers, device identifiers, web URLs, IP addresses, biometric identifiers, full-face photographs, and any other unique identifying number or code.

Remove all 18 and confirm the covered entity has no actual knowledge the remaining data could identify an individual, and the data exits HIPAA's scope. Remove 17 of them and it is still PHI.

De-identification vs. pseudonymization: Replacing patient names with internal IDs while keeping diagnosis codes and dates of service is pseudonymization, not de-identification. Pseudonymized data is still PHI.

The scheduling data question: Appointment scheduling data that pairs a patient's name with a provider name and a date of service likely qualifies as PHI, because it reveals a person's health-seeking activity. If you are unsure, this is worth a short consult with a healthcare privacy attorney before you sign a contract with a healthcare customer.

The Two Rules You Must Comply With

The Privacy Rule (45 CFR Part 164, Subpart E)

The Privacy Rule governs how PHI may be used and disclosed. For a SaaS Business Associate, the operational impact is primarily contractual: your BAA will specify the limited purposes for which you can use your customer's PHI. Under 45 CFR 164.502, you may only use or disclose PHI "as permitted or required by its business associate contract or other arrangement" — not for your own product development, analytics, or marketing without explicit authorization.

The minimum necessary standard applies: when using or requesting PHI, you must "make reasonable efforts to limit protected health information to the minimum necessary to accomplish the intended purpose." That has a direct architectural implication — your application should not ingest full patient records if only a subset of fields is required for your service.

The Security Rule (45 CFR Part 164, Subpart C)

The Security Rule applies specifically to electronic PHI (ePHI) — PHI stored or transmitted electronically. This covers your databases, API traffic, log files, backups, and any other digital medium. It divides required controls into three categories.

Administrative safeguards (45 CFR 164.308) include:

• Risk analysis (required): a documented assessment of threats and vulnerabilities to ePHI confidentiality, integrity, and availability.
• Risk management (required): security measures to reduce risks identified in the analysis to reasonable levels.
• Assigned security responsibility (required): a named Security Officer responsible for policy development and implementation.
• Sanction policy (required): documented consequences for workforce members who violate security policies.
• Information system activity review (required): regular examination of audit logs, access reports, and incident tracking records.
• Security incident procedures (required): documented procedures for identifying, responding to, and mitigating incidents; outcomes must be documented.
• Contingency plan (required): data backup procedures, disaster recovery, and emergency mode operations.

Physical safeguards (45 CFR 164.310) for cloud products largely delegate to your infrastructure provider's data center controls. Your direct obligations: workstation security policies, media disposal procedures (ensuring ePHI is removed before hardware is reused or discarded), and maintaining records of equipment and media movements.

Technical safeguards (45 CFR 164.312) include:

• Unique user identification (required): every user who accesses ePHI must have a unique identifier.
• Emergency access procedure (required): a way to obtain ePHI in an emergency.
• Audit controls (required): mechanisms to record and examine activity in systems containing ePHI.
• Person or entity authentication (required): verify the identity of those seeking ePHI access.
• Integrity controls (addressable): mechanisms to verify ePHI has not been altered or destroyed without authorization.
• Automatic logoff (addressable): sessions terminate after a defined period of inactivity.
• Encryption at rest (addressable): a mechanism to encrypt and decrypt ePHI.
• Transmission security — encryption (addressable): encrypt ePHI when transmitted.

"Addressable" Does Not Mean Optional

This is the most common misreading of the Security Rule. "Addressable" means you must either implement the specification or document why an equivalent alternative is sufficient for your environment. Under OCR guidance, if encryption is reasonable and appropriate for your systems (and for virtually every cloud product it is), you must implement it. The addressable designation gives you flexibility in how you encrypt, not whether you do.

Business Associate Agreements

A BAA is a contract required by 45 CFR 164.504(e) before you may handle PHI. It must specify:

• The permitted and required uses and disclosures of PHI by you as Business Associate.
• Your obligation to not use or disclose PHI beyond what the contract permits.
• Your obligation to use appropriate safeguards and comply with the Security Rule.
• Your obligation to report any breach or unauthorized use or disclosure to the covered entity.
• Your obligation to pass the same restrictions down to subcontractors.
• Termination provisions requiring you to return or destroy PHI when the contract ends.
• The covered entity's right to terminate if you materially violate the agreement.

You need BAAs in two directions. Healthcare customers sign them with you. You sign them with every subcontractor that touches PHI on your behalf.

Which subcontractors need a BAA? Any service that processes or stores ePHI, including your cloud infrastructure provider, your managed database, your log aggregation service, your error tracking tool, and any support platform where customer data might appear. AWS, Google Cloud, and Microsoft Azure all offer HIPAA BAA programs — but you must request and execute those agreements. Simply choosing a HIPAA-eligible service tier is not sufficient.

The Slack / support tool problem: If a support ticket, a Slack message, or an error log ever contains PHI and you have no BAA with that vendor, you have a potential unauthorized disclosure. The fix is either to ensure PHI never enters those channels (preferred, and achievable with clear internal policies) or to obtain BAAs where the vendor offers them.

One practical note on BAA templates: Many vendors provide their own BAA template. Review it. Some vendor templates limit your breach notification window or restrict your audit rights in ways that conflict with your obligations to your healthcare customers. Flag these with legal counsel before signing.

The 2013 Omnibus Rule: Why You Are Directly Liable

Before the HITECH Act (enacted February 17, 2009) and the 2013 Omnibus Rule that implemented its provisions, Business Associates' HIPAA obligations were primarily contractual — your covered entity customer could be penalized for your failures. That changed.

Under 42 USC 17931, the Security Rule's administrative, physical, and technical safeguard requirements apply to Business Associates "in the same manner" as they apply to covered entities. The civil and criminal penalty provisions at 42 USC 1320d-5 apply directly to you. OCR has brought enforcement actions against Business Associates including software vendors.

Penalty tiers under 42 USC 1320d-5:

The distinction between Tier 1 and Tier 4 is documentation. An organization that can show a documented risk analysis, implemented controls, training records, and incident response procedures is far more likely to receive a Tier 1 or Tier 2 finding than one that cannot show it ever thought about the problem.

What the Risk Analysis Actually Requires

The risk analysis is the most important single document in your HIPAA program. It is required by 45 CFR 164.308(a)(1) and it is the first thing OCR requests in a breach investigation.

A defensible risk analysis for a startup covers:

• A map of every system that creates, receives, maintains, or transmits ePHI (your data flow diagram).
• The threats and vulnerabilities relevant to each system.
• The likelihood that each threat will exploit each vulnerability.
• The potential impact of each exploitation on ePHI confidentiality, integrity, and availability.
• Your current controls and their adequacy against each risk.
• A residual risk rating for each item.
• A remediation plan for unacceptable residual risks.

This document should be updated when your systems change and reviewed at least annually. Generic templates are a starting point, not a finished product — the analysis must reflect your actual architecture.

Breach Notification

Under 45 CFR 164.410, if you discover a breach of unsecured PHI, you must notify the covered entity without unreasonable delay and in no case later than 60 calendar days after discovery. A breach is discovered on the first day you know about it, or would have known through reasonable diligence.

Your notification must include, to the extent possible, the identities of the individuals whose PHI was involved, plus any other information the covered entity needs to fulfill its own notification obligations.

The covered entity then has obligations to notify affected individuals and, for breaches affecting 500 or more people in a state, the media. It must also report to HHS. HHS publishes a public breach log (the "Wall of Shame") listing all breaches affecting 500 or more individuals.

The 60-day clock applies to Business Associates notifying covered entities. The covered entity then has its own 60-day clock to notify individuals. Build your incident response plan so that breach determination, containment, and vendor notification can realistically happen within 30 days of discovery, leaving margin before the deadline.

A Minimum Viable Security Control Set

This is not a comprehensive checklist — it is the floor for a startup preparing to sign its first BAA.

Encryption. Enable encryption at rest for all databases and storage containing ePHI. TLS 1.2 or higher for all ePHI in transit. Most managed cloud databases support encryption at rest natively; you must enable it explicitly. Under 45 CFR 164.312, encryption is addressable, but for cloud-hosted products it is invariably reasonable and appropriate.

Access controls and MFA. Implement role-based access so that only staff with a business need can access ePHI. Enforce multi-factor authentication on all accounts with ePHI access. Maintain unique user identifiers — no shared credentials. Document your access authorization and termination procedures.

Audit logging. Log access to ePHI: who, when, what action. Protect logs from tampering. Retain logs for at minimum six years (consistent with HIPAA's general record retention requirement at 45 CFR 164.530(j)). This is the most commonly skipped control at early-stage companies and the first control auditors examine.

Designated Security Officer. Identify one person as your Security Officer per 45 CFR 164.308(a)(2). At seed stage, this is usually a technical co-founder or CTO. The role requires enough authority to implement policies and investigate incidents — not a title, but a function.

Written policies. You need documented policies for: workforce access, acceptable use, workstation security, incident response, breach notification, BAA management, media disposal, and training. The specific content matters less than the fact that they exist, are tailored to your environment, and are actually followed.

Workforce training. Under 45 CFR 164.308(a)(5), security awareness training for all workforce members who handle ePHI is an addressable requirement. Run initial training at onboarding and annual refreshers. Document completion.

Risk analysis. See the previous section. Start here. Every other investment decision flows from this document.

When to Engage Privacy Counsel

You do not need outside legal counsel for every aspect of HIPAA compliance. You probably do for these:

Before your first BAA. Have an attorney review your BAA template — both the one you will present to customers and the ones your cloud vendors present to you. A BAA that misaligns your notification windows, limits your audit rights, or indemnifies only the vendor creates downstream liability.

When you receive a security questionnaire from a health system. Large health systems send detailed vendor security questionnaires, and the representations you make in them can expose you to contract liability beyond HIPAA. A healthcare attorney or experienced compliance consultant should review your responses before you submit.

If you have any doubt about whether HIPAA applies. The threshold questions — is this PHI, is this entity a covered entity, am I a business associate — have legal consequences. A 30-minute consult is cheaper than building a product incorrectly.

If you experience a potential breach. The breach notification analysis (is this actually a breach? what is the harm standard?) involves legal judgment. Engage counsel before making the determination, not after.

HIPAA vs. SOC 2: Which to Do First?

These are different in structure: HIPAA is a regulation with direct enforcement by OCR; SOC 2 is a voluntary attestation against the AICPA's Trust Services Criteria. Being "SOC 2 compliant" means a CPA firm attested to your controls; being HIPAA compliant means you have actually implemented the required safeguards.

They share significant control overlap — access controls, encryption, audit logging, incident response, and risk management appear in both. The fastest path if you need both is to run your HIPAA control implementation first (it is prescriptive and legally required) and map your SOC 2 evidence collection on top of it.

Do not let a vendor sell you SOC 2 as a proxy for HIPAA compliance. They measure different things. A SOC 2 Type II report with a HIPAA criteria overlay can support your HIPAA program, but it does not replace a documented risk analysis, BAAs, or HIPAA-specific policies.

See our SOC 2 Compliance Checklist for a side-by-side look at the control overlap, and our Cybersecurity Compliance Checklist for a broader framework map.

Mini-FAQ

We only store appointment scheduling data, not clinical records. Does HIPAA apply?

Possibly. Appointment data that pairs a patient's name with a named healthcare provider and a date likely reveals health-seeking activity. Under 45 CFR 160.103, PHI is individually identifiable health information in any form. Whether your specific data set qualifies depends on what fields you store and how they combine. Get a legal opinion before assuming you are outside HIPAA's scope.

Is there such a thing as "HIPAA certified"?

No. HHS does not issue HIPAA certifications. Vendors that claim to be "HIPAA certified" are typically referring to a third-party audit or a compliance platform's assessment. These can be useful indicators of control maturity, but they carry no regulatory status. Your obligations under HIPAA exist regardless of whether you have paid for an audit.

What happens if we have a breach before our controls are fully implemented?

A breach before your program is documented and implemented typically results in a higher penalty tier, because it is harder to demonstrate reasonable cause rather than negligence. OCR's investigation will look for whether you knew about the risk (through your risk analysis or otherwise) and failed to act. If you are in the process of building your program, document that progress — dated work products showing you are actively addressing identified risks are meaningful evidence.

Do we need a full-time HIPAA Compliance Officer?

No — but 45 CFR 164.308(a)(2) requires you to designate both a Privacy Officer and a Security Officer (these can be the same person). The roles require authority and practical knowledge of your systems. For an early-stage startup, this is typically a technical co-founder, head of engineering, or a part-time vCISO engagement. The title is less important than whether the person can actually investigate an incident and enforce policies.

Our cloud provider signed a HIPAA BAA with us. Are we compliant now?

No. The BAA with your cloud provider establishes that provider's obligations to you. Your obligations to your healthcare customers — and to OCR — are independent. You still need your own documented policies, risk analysis, access controls, workforce training, and BAAs with every other subcontractor that touches PHI. A BAA from AWS is a necessary component of a HIPAA program, not a substitute for one.

90-Day Startup Readiness Plan

This is a sequenced path from zero to a defensible first compliance posture. It assumes a technical founder who owns the effort without a dedicated compliance team.

Weeks 1–2: Map your data and establish your foundation

• Identify every system that creates, receives, maintains, or transmits ePHI. Draw the data flow.
• Designate your Privacy Officer and Security Officer.
• Contact your cloud infrastructure provider and sign their HIPAA BAA. Audit your vendor stack and identify every subcontractor that touches PHI.

Weeks 3–4: Execute your risk analysis

• Using your data flow map, document threats and vulnerabilities for each system.
• Rate likelihood and impact. Identify unacceptable residual risks.
• Produce a written risk analysis document. Date it and sign it.
• Draft your remediation plan for identified gaps.

Weeks 5–8: Implement technical controls

• Enable encryption at rest on all databases and storage containing ePHI. Verify TLS 1.2+ on all endpoints.
• Implement RBAC and principle of least privilege. Enforce MFA on all ePHI-capable accounts.
• Deploy audit logging to a tamper-protected destination. Verify retention.
• Remove all shared credentials. Document unique user assignments.
• Implement automatic session timeout for applications that access ePHI.
• Sign BAAs with all subcontractors identified in Week 1.

Weeks 9–10: Write your core policies

• Incident response and breach notification policy (reference 45 CFR 164.410 timelines explicitly).
• Access management and termination policy.
• Acceptable use and workstation security policy.
• BAA management policy (who reviews, who signs, where they are stored).
• Media disposal procedure.

Weeks 11–12: Train, test, and finalize your BAA template

• Run initial security awareness training for all staff with ePHI access. Document completion.
• Conduct a tabletop exercise on your breach notification procedure: who discovers, who decides it is a breach, who notifies the covered entity, who tracks the 60-day clock.
• Have an attorney review your customer-facing BAA template before you countersign your first customer agreement.
• Document the completion of your risk analysis remediation items or set dated target dates for open items.

At the end of 90 days, you should have: a signed BAA with your cloud provider and all ePHI-processing subcontractors, a documented risk analysis, implemented technical controls, written policies, a trained workforce, a breach notification procedure, and a customer BAA template reviewed by counsel. That is a defensible first posture. Maintain it through annual risk analysis reviews, policy updates when systems change, and ongoing training.

Sources

1. 45 CFR 160.103 — Definitions (covered entity, business associate, PHI, ePHI). Cornell Law Legal Information Institute. https://www.law.cornell.edu/cfr/text/45/160.103. Accessed 2026-05-12.
2. 45 CFR 164.308 — Administrative safeguards. Cornell Law Legal Information Institute. https://www.law.cornell.edu/cfr/text/45/164.308. Accessed 2026-05-12.
3. 45 CFR 164.310 — Physical safeguards. Cornell Law Legal Information Institute. https://www.law.cornell.edu/cfr/text/45/164.310. Accessed 2026-05-12.
4. 45 CFR 164.312 — Technical safeguards. Cornell Law Legal Information Institute. https://www.law.cornell.edu/cfr/text/45/164.312. Accessed 2026-05-12.
5. 45 CFR 164.410 — Notification by a business associate. Cornell Law Legal Information Institute. https://www.law.cornell.edu/cfr/text/45/164.410. Accessed 2026-05-12.
6. 45 CFR 164.502 — Uses and disclosures of protected health information: general rules. Cornell Law Legal Information Institute. https://www.law.cornell.edu/cfr/text/45/164.502. Accessed 2026-05-12.
7. 45 CFR 164.504 — Uses and disclosures: organizational requirements (Business Associate provisions). Cornell Law Legal Information Institute. https://www.law.cornell.edu/cfr/text/45/164.504. Accessed 2026-05-12.
8. 45 CFR 164.514 — Other requirements relating to uses and disclosures of protected health information (de-identification). Cornell Law Legal Information Institute. https://www.law.cornell.edu/cfr/text/45/164.514. Accessed 2026-05-12.
9. 42 USC 17931 — Application of security provisions and penalties to business associates of covered entities. Cornell Law Legal Information Institute. https://www.law.cornell.edu/uscode/text/42/17931. Accessed 2026-05-12.
10. 42 USC 1320d-5 — General penalty for failure to comply with requirements and standards. Cornell Law Legal Information Institute. https://www.law.cornell.edu/uscode/text/42/1320d-5. Accessed 2026-05-12.

Sources used

1. 45 CFR 160.103 — accessed 2026-05-12
2. 45 CFR §§ 164.308, 164.310, 164.312 — accessed 2026-05-12
3. 42 USC 17931 — accessed 2026-05-12
4. 42 USC 1320d-5 — accessed 2026-05-12
5. Safe Harbor de-identification standard at 45 CFR 164.514 — accessed 2026-05-12
6. 45 CFR 164.502 — accessed 2026-05-12
7. 45 CFR 164.310 — accessed 2026-05-12
8. 45 CFR 164.312 — accessed 2026-05-12
9. 45 CFR 164.504(e) — accessed 2026-05-12
10. 45 CFR 164.410 — accessed 2026-05-12

Last reviewed: 2026-05-12. This article was prepared by the Security Compliance Guide Editorial Team. We use AI to draft initial summaries of publicly available cybersecurity compliance documentation, then verify every claim against primary sources before publication. We are not licensed auditors, attorneys, or compliance consultants. For binding decisions, consult a qualified professional. See our editorial standards for full sourcing rules.