If your SaaS product creates, receives, maintains, or transmits electronic protected health information, HIPAA applies to you, full stop. The moment you touch that data on behalf of a healthcare provider or health plan, you become a business associate under federal law, with direct legal exposure. Your first move isn't a policy binder. It's a documented risk analysis and a plan for Business Associate Agreements with every covered entity you serve.
TL;DR:
- SaaS products creating, receiving, or maintaining ePHI automatically become business associates under HIPAA and must conduct documented risk analyses and establish Business Associate Agreements with all covered entities and vendors involved.
- Compliance requires ongoing effort, including implementation of tailored controls based on risk assessments, comprehensive BAAs with all subcontractors, and continuous documentation of safeguards and system changes.
- Handling any of the 18 HIPAA-defined identifiers in your app designates your data as protected, making de-identification or limited datasets necessary for lighter obligations, which is often impractical for core SaaS functions.
- An effective HIPAA compliance program hinges on a living risk analysis, thorough documentation, and rapid breach response, with notification obligations starting immediately upon discovering unauthorized PHI access, often within days.
- Enterprise buyers increasingly expect third-party attestations like SOC 2 or HITRUST, which serve as independent proof of HIPAA control implementation, and aligning these with your BAA and risk analysis streamlines procurement.
Table of Contents
- What HIPAA for SaaS Actually Means for Your Company
- Who Needs HIPAA: Covered Entities, Business Associates, and Your Liability
- The 18 PHI Identifiers: What Counts as Protected Data in Your App
- Privacy, Security, and Breach Notification: The Three Rules That Govern SaaS
- Building Safeguards: Administrative, Physical, and Technical Controls
- BAAs, Contracts, and Shared Responsibility With Your Cloud Provider
- Risk Analysis and Documentation: Building an Audit-Ready Program
- Breach Response: Timelines You Cannot Miss
- Your 30/90/180-Day HIPAA Compliance Roadmap
- SOC 2, HITRUST, and What Enterprise Buyers Actually Want
- The StartupMD's Perspective: Compliance as a Growth Lever
- How The StartupMD Helps SaaS Founders Get HIPAA-Ready
- Sources
- FAQ
What HIPAA for SaaS Actually Means for Your Company
HIPAA compliance is not a certificate you earn once and frame on the wall. It's an operating condition, one you either maintain continuously or fall out of the moment a control lapses. That distinction trips up more founders than any technical requirement in the rulebook.
The trigger is simple to state and easy to miss in practice: if your platform creates, receives, maintains, or transmits electronic protected health information (ePHI) on behalf of a covered entity, or on behalf of another business associate, you're a business associate yourself, with direct liability under HIPAA's business associate provisions. It doesn't matter if you call yourself a "workflow tool" or a "scheduling app." The label on your homepage means nothing to the U.S. Department of Health and Human Services. The data flow is what counts.
Here's the part that surprises technical teams: HHS doesn't hand you a checklist and call it done. The Security Rule uses what regulators call "flexibility of approach," meaning you choose controls appropriate to your size, complexity, and risk profile, then document why those choices are reasonable. There's no universal password policy or single approved cloud configuration. A five-person startup and a 200-engineer platform can both be compliant with very different technical stacks, as long as each can justify its decisions on paper.
Who Needs HIPAA: Covered Entities, Business Associates, and Your Liability
Covered entities are the healthcare providers, health plans, and clearinghouses that generate PHI in the first place: hospitals, physician practices, insurers, billing services. Business associates are everyone downstream who touches that data to help the covered entity operate. If you sell scheduling software to a clinic, patient engagement tools to a hospital system, or analytics dashboards to a health plan, you're almost certainly a business associate.
This matters because HITECH amendments and subsequent OCR rulemaking gave regulators the authority to enforce HIPAA directly against business associates, not just the covered entities that hire them. Before 2013, a vendor's compliance failures were mostly the covered entity's problem to manage contractually. That's no longer true. Direct liability provisions mean OCR can investigate and fine your company independently for failing to implement required safeguards or for missing a breach notification deadline.
The liability chain doesn't stop at your front door, either. If you use a subcontractor, a cloud hosting provider, a customer support platform, an analytics vendor, that touches ePHI, you need a signed BAA with them too. Startups routinely miss this. A vendor inventory that tracks every third party with ePHI access, paired with a current BAA on file for each one, is not optional paperwork. It's a legal requirement that regulators and enterprise buyers both expect to see.
The 18 PHI Identifiers: What Counts as Protected Data in Your App
PHI isn't limited to diagnosis codes and lab results. HIPAA defines 18 specific identifiers that, when linked to health information, make that data protected. Your product likely stores several of these in fields you don't think of as "medical."
- Names, and geographic subdivisions smaller than a state
- Dates directly tied to an individual (birth, admission, discharge, death)
- Phone and fax numbers, email addresses
- Social Security numbers, medical record numbers, health plan beneficiary numbers
- Account numbers, certificate or license numbers
- Vehicle identifiers, device identifiers and serial numbers
- URLs and IP addresses tied to a patient
- Biometric identifiers, full-face photos, and any other unique identifying number or code
A scheduling app storing a patient's name and appointment date has PHI. So does a support ticket system logging a customer's email alongside a symptom description. If you strip out all 18 identifiers, you may qualify for a de-identified dataset or a limited data set under separate rules, which carry lighter obligations. Most SaaS products can't realistically de-identify their working data without breaking core functionality, so plan your compliance program around the assumption that you're handling PHI, not around hoping you aren't.
Privacy, Security, and Breach Notification: The Three Rules That Govern SaaS
Three HIPAA rules do almost all the work for SaaS companies, and each demands a different kind of evidence.
The Privacy Rule governs how PHI can be used and disclosed. For a SaaS product, this shows up in feature design: who inside your customer's organization can see what data, whether your analytics features aggregate PHI in ways that require special handling, and whether your marketing or product-improvement uses of customer data cross a line the covered entity hasn't authorized.
The Security Rule is where most engineering effort goes. It requires a documented Risk Analysis and "reasonable" administrative, physical, and technical safeguards, including access controls, audit controls, and encryption of ePHI in transit and at rest. This isn't a one-time audit. It's a living risk register you revisit as your architecture changes.
The Breach Notification Rule defines what happens when something goes wrong: an unauthorized disclosure, a lost device, a misconfigured database exposed to the internet. As a business associate, you're required to notify the covered entity, and the clock starts the moment you discover the incident, not when you finish investigating it. Every SaaS founder should treat these three rules as the spine of their compliance program, not three separate side projects.
Building Safeguards: Administrative, Physical, and Technical Controls
The Security Rule splits controls into three categories, and understanding "required" versus "addressable" saves startups from over-engineering the wrong things first. Required means you must implement it. Addressable means you must implement it, an equivalent alternative, or document why it isn't reasonable for your environment. Addressable is not optional. It's flexible.
Administrative controls come first because they're foundational and cheap to start: a written security policy, role-based access so employees only see what their job requires, a documented incident response plan, and annual security awareness training for every employee who touches PHI.
Technical controls are where most of your engineering budget goes: encryption for ePHI both in transit (TLS 1.2 or higher) and at rest (AES-256 is the common baseline), unique user IDs for every person accessing the system, multi-factor authentication, automatic session timeouts, and audit logs that capture who accessed what data and when. Continuous monitoring and alerting on anomalous access patterns rounds this out.
Physical controls matter even in a cloud-first world: workstation security policies, device encryption for laptops that can access production systems, and documented data center controls if you manage any on-premise infrastructure. Backup and disaster recovery planning falls here too.
Pro Tip: Start with access controls and audit logging before you touch encryption-at-rest configurations. Most early-stage breaches trace back to overly broad employee permissions, not sophisticated attacks, so fixing who can see what buys you more risk reduction per engineering hour than any other control.
BAAs, Contracts, and Shared Responsibility With Your Cloud Provider
A Business Associate Agreement is a legal contract, not a compliance formality you attach to your Terms of Service. It must specify how you'll use and safeguard PHI, your breach notification obligations and timelines, your requirement to ensure subcontractors sign equivalent agreements, and your duty to return or destroy PHI when the relationship ends. HHS guidance is unambiguous: a covered entity using your platform without a signed BAA is already in violation, and so are you.
A BAA doesn't replace your master service agreement or commercial terms. It sits alongside your MSA, handling the HIPAA-specific obligations while your MSA still covers pricing, SLAs, liability caps, and termination rights. Founders sometimes assume signing a BAA template satisfies their entire legal relationship with a customer. It doesn't. You still need a proper commercial contract underneath it.
Shared responsibility gets confusing fast with cloud infrastructure. A common misconception: if your cloud provider only stores encrypted ePHI and never holds the decryption key, it's off the hook. HHS guidance says otherwise. A CSP maintaining encrypted ePHI is still a business associate even without key access, though the Security Rule's flexibility allows you to allocate specific access-control duties differently between you and the provider. Map out exactly who configures what, in writing, and get a BAA in place with every infrastructure vendor in your stack.
Risk Analysis and Documentation: Building an Audit-Ready Program
A risk analysis under 45 CFR §164.308 isn't a form you fill out once. It's a structured inventory of where ePHI lives in your systems, what threats and vulnerabilities could expose it, how likely each scenario is, and what controls you've put in place to reduce that risk to a reasonable level. HHS expects this to be revisited whenever your architecture changes meaningfully, not annually on autopilot.
Keep the artifacts that prove your program is real, not aspirational: a current data flow inventory showing where PHI enters, moves, and exits your systems; access logs and audit trail exports; vulnerability scan and penetration test results; change management records showing security review before production deployments; and a signed BAA for every vendor and subcontractor touching PHI. The seven-step framework for a defensible HIPAA risk assessment walks through how to structure this evidence in a way regulators and auditors both recognize.
Enterprise buyers will ask for a security pack before they sign anything, and having one ready cuts weeks off your sales cycle. Version your documentation, date every review, and treat this pack as a living sales asset rather than a compliance archive nobody opens until something goes wrong.
Breach Response: Timelines You Cannot Miss
The moment you discover unauthorized access to PHI, the clock starts running, and your contractual obligations to covered entities may be tighter than the federal baseline, often requiring faster notification timelines. Move through incident response in a defined sequence:
- Contain the incident immediately. Isolate affected systems, revoke compromised credentials, and stop the exposure before you do anything else.
- Preserve evidence. Capture logs, timestamps, and system states before remediation overwrites the forensic trail you'll need for the investigation.
- Determine scope. Identify exactly what PHI was involved, how many individuals are affected, and whether the exposure meets HIPAA's definition of a reportable breach.
- Notify the covered entity without unreasonable delay. As a business associate, you're required to notify the covered entity, and the outer limit is generally no later than 60 calendar days after discovery, though most BAAs contractually require faster notice, often requiring notification within a few days.
- Support the covered entity's downstream obligations. If the breach affects 500 or more individuals in a state, the covered entity faces media notification requirements on top of individual and HHS Secretary notice, and they'll need your cooperation and documentation to meet those deadlines.
Your BAAs should specify forensic investigation cooperation, cost allocation for breach response, and exactly what documentation you'll hand over within what timeframe. Negotiate this language before you sign, not during an actual incident when adrenaline and legal fees are both running high.
Your 30/90/180-Day HIPAA Compliance Roadmap
Compliance work overwhelms founders when it's presented as one giant undertaking. Broken into phases, it's manageable alongside a normal product roadmap.
- Days 1 to 30: Scope and stop the bleeding. Identify every place ePHI touches your systems, get BAAs signed with your top customers and critical infrastructure vendors, and fix any obvious exposure like publicly accessible storage buckets or missing multi-factor authentication on admin accounts.
- Days 31 to 90: Build the core program. Complete a full documented risk analysis, implement the technical controls that came out of it, encryption, access controls, audit logging, and run security awareness training for every employee with system access.
- Days 91 to 180: Formalize and sustain. Conduct an internal audit against your own risk analysis findings, sign BAAs with every remaining subcontractor, decide whether a SOC 2 or HITRUST attestation makes sense for your sales motion, and establish a recurring cadence, quarterly access reviews, annual risk analysis updates, so the program doesn't decay the moment you stop thinking about it.
Founders who treat month six as the finish line usually find themselves back at square one during their next enterprise security review. Compliance is a maintenance cost baked into your operating model, not a project with an end date.
SOC 2, HITRUST, and What Enterprise Buyers Actually Want
HIPAA is a federal law. SOC 2 and HITRUST are independent attestations, third parties auditing your controls and issuing a report. That distinction matters more than it sounds. A HIPAA-compliant SaaS product can operate without ever pursuing SOC 2 or HITRUST, but enterprise health system buyers increasingly expect one or both as proof, because they can't independently audit every vendor's HIPAA program themselves.
SOC 2 Type II typically takes three to twelve months and demonstrates operational controls over time. HITRUST is more prescriptive and expensive, often a stronger signal for larger health system deals but overkill for an early-stage company selling to independent practices. Present your BAA, risk analysis summary, and whichever attestation you hold as one combined evidence package during procurement. Buyers want to see the law and the audit trail pointing the same direction.
The StartupMD's Perspective: Compliance as a Growth Lever
Founders often treat HIPAA as a legal cost center to minimize. That's backward. A documented risk analysis and a clean BAA process shorten procurement cycles and signal to enterprise buyers that you understand their risk tolerance, not just their workflow needs.
The real question isn't whether to comply. It's when to bring in outside expertise versus building compliance capability in-house. Early-stage teams often need fractional guidance to sequence this correctly against product milestones and go-to-market timing, rather than a full-time hire before there's enough surface area to justify one.
— Paul Bergeron MD, MBA
How The StartupMD Helps SaaS Founders Get HIPAA-Ready
Most compliance guides stop at the checklist. The StartupMD works alongside founders who need someone who has sat on both sides of the table, clinical operations and startup growth, to sequence risk analysis, BAA review, and incident response planning against real fundraising and sales timelines.
Engagements typically start with a scoped assessment of where your product stands against the roadmap outlined above, then move into fractional Chief Medical Officer support or targeted advisory work depending on what your stage actually calls for. That might mean reviewing your BAA templates before a health system pilot, building your incident response playbook before your first SOC 2 audit, or preparing the clinical narrative your investors will ask about during diligence. Founders get direct access to guidance grounded in real patient care and startup experience, not generic checklist consulting.
If you're deciding whether to tackle HIPAA readiness in-house or bring in outside expertise, start with a conversation. Visit The StartupMD's advisory and fractional CMO services to scope your first deliverable, whether that's a risk analysis kickoff or a BAA audit across your vendor list.
Sources
For the legal detail behind every claim in this article, go directly to the federal sources. HHS's Office for Civil Rights guidance on business associates covers BAA requirements in depth, while the Security Rule regulatory text lays out safeguard specifications section by section. If your product functions overlap with a regulated medical device, the FDA's guidance on multiple function device policy explains where separate regulatory paths apply. For contract-specific BAA language, the breakdown of required BAA clauses covers what every agreement must include.
This article is general information, not a substitute for advice from a qualified doctor. Consult a qualified healthcare professional about your own circumstances before acting on anything here.
FAQ
Does HIPAA apply to tech companies?
Yes, if a tech company creates, receives, maintains, or transmits ePHI on behalf of a covered entity or another business associate, it qualifies as a business associate under HIPAA and carries direct legal liability. The label "tech company" doesn't matter; the data handling does.
What is the new HIPAA rule in 2026?
HHS periodically updates guidance and proposed rulemaking around the Security Rule, but the core framework, the Privacy Rule, Security Rule, and Breach Notification Rule, remains the governing structure for SaaS compliance. Check current Security Rule regulations directly on HHS.gov, since proposed changes move through federal rulemaking on their own timeline.
Is there a HIPAA-compliant version of ChatGPT?
Whether an AI tool is HIPAA compliant depends on whether the vendor will sign a Business Associate Agreement and implement the required safeguards, not on the tool's general capabilities. If a provider won't sign a BAA covering your specific use case, you cannot input PHI into that tool regardless of its features.
Is Google Cloud storage HIPAA compliant?
Google Cloud offers a BAA for eligible services and supports the technical safeguards required by the Security Rule, but compliance depends on how you configure and use those services, not the platform alone. Even a fully encrypted, no-key-access cloud storage setup still makes the provider a business associate under HIPAA, and you remain responsible for your own access controls and configuration choices on top of it.
How much does The StartupMD's HIPAA advisory work cost?
Pricing for advisory services and fractional Chief Medical Officer engagements is available directly through The StartupMD's services page, since scope varies by company stage and the specific compliance work needed.