Does My SaaS Need to Be HIPAA Compliant? The Answer Most Founders Get Wrong

If your software touches, stores, transmits, or processes Protected Health Information on behalf of a healthcare organization, health insurer, or any other HIPAA-covered entity — yes, you almost certainly need to be HIPAA compliant. Specifically, you are likely a Business Associate, which means you are directly subject to HIPAA's Security Rule, Privacy Rule, and Breach Notification Rule, whether you signed a Business Associate Agreement or not. The most dangerous assumption founders make is that HIPAA only applies to hospitals and insurance companies. It does not. It applies to the software they use. If your product is in that stack, you are in scope. This guide tells you exactly how to determine whether HIPAA applies to your SaaS or AI product, what being a Business Associate actually requires, and the fastest path to compliance for a technical team that has never done this before.

Why This Question Is Hitting SaaS and AI Founders Right Now

Three converging trends are pulling non-healthcare software companies into HIPAA's orbit faster than ever before.

The first is the explosion of health data APIs. Electronic Health Record platforms — Epic, Cerner, Athenahealth — have opened their APIs in response to federal interoperability mandates. This means developers can now build directly on clinical data that was previously locked within hospital systems. Every integration that touches that data creates a potential Business Associate relationship.

The second is the rise of AI copilots in clinical workflows. Ambient documentation tools, clinical decision support systems, AI-powered prior authorization platforms, and virtual care assistants are being deployed into healthcare settings at an enormous scale. Many of these tools are built by companies whose founders came from consumer tech — and who have never encountered HIPAA before their first enterprise health system prospect asks for a Business Associate Agreement.

The third is the broadening definition of health-adjacent software. Employee wellness platforms, mental health apps used through employer benefit programs, chronic disease management tools, and remote patient monitoring systems all sit in a gray zone where PHI flows through software built by teams that did not consider themselves healthcare companies when they started.

The pattern is consistent: a founder builds a product, lands a healthcare customer, is asked for a BAA, and realizes for the first time that their product architecture, data handling practices, and vendor contracts were not built with HIPAA in mind. This guide exists to help you get ahead of that moment.

Step 1: Determine Whether HIPAA Applies to Your Product

HIPAA applies to two categories of organizations: Covered Entities and Business Associates.

Covered Entities are healthcare providers, health plans, and healthcare clearinghouses — the traditional healthcare organizations most people think of when they hear HIPAA. If you are building a SaaS product, you are almost certainly not a Covered Entity. But you may be something equally important under HIPAA law.

A Business Associate is any organization that creates, receives, maintains, or transmits Protected Health Information on behalf of a Covered Entity, or on behalf of another Business Associate. The definition is deliberately broad and has been expanded multiple times since HIPAA's original passage.

You are likely a Business Associate if any of the following describe your product:

Your software stores patient records, clinical notes, lab results, imaging data, or any other health information provided by a healthcare organization. Your API receives or transmits health data from an EHR, a health insurer, or a healthcare provider. Your AI model processes clinical text, medical records, or health-related personal information to generate outputs used in healthcare decisions. Your analytics platform processes de-identified or identified patient data on behalf of a health system. Your communication platform transmits messages between patients and providers that contain health information. Your cloud infrastructure hosts applications that handle PHI for healthcare customers.

The critical point is that the Business Associate relationship is defined by the function your product performs — not by whether you signed a BAA or even whether your customer told you they were sending you PHI. If PHI flows through your system, you are a Business Associate under HIPAA law, with or without a formal agreement in place.

Step 2: Understand What PHI Actually Is

Protected Health Information is individually identifiable health information that relates to an individual's past, present, or future physical or mental health condition, the provision of healthcare to an individual, or the past, present, or future payment for healthcare.

The individually identifiable component matters most to software teams. PHI is not just a diagnosis or a medication record. It is any health-related information combined with an identifier that could be used to identify the individual. HIPAA defines eighteen specific identifiers, including name, address, date of birth, phone number, email address, Social Security number, medical record number, account number, IP address, and device identifiers.

This means that a patient's name, combined with their appointment date, is PHI. An email address combined with a prescription history is PHI. An IP address combined with a mental health assessment score is PHI. For AI products in particular, this creates significant complexity — a model that ingests clinical notes, generates summaries, or produces risk scores is almost certainly processing PHI even if the raw output looks like a prediction rather than a health record.

The only way to remove information from HIPAA's scope is through one of two de-identification methods: the Safe Harbor method, which requires removing all eighteen specified identifiers, or the Expert Determination method, which requires a statistical expert to certify that the risk of re-identification is very small. Tokenization, pseudonymization, and encryption do not constitute de-identification under HIPAA — they protect PHI but do not remove it from HIPAA's scope.

Step 3: Know What Being a Business Associate Actually Requires

Being a Business Associate is not just a contractual status — it is a direct legal obligation under federal law. The 2013 HIPAA Omnibus Rule made Business Associates directly liable for HIPAA compliance, meaning you can be audited, fined, and prosecuted regardless of whether your Covered Entity customer takes any action against you.

The three rules that apply to Business Associates are the Security Rule, the Privacy Rule as it applies to Business Associates, and the Breach Notification Rule.

The Security Rule

The Security Rule requires Business Associates to implement administrative, physical, and technical safeguards to protect the confidentiality, integrity, and availability of electronic PHI. Unlike SOC 2 or ISO 27001, the Security Rule does not prescribe specific technologies or configurations — it requires you to assess the risks to ePHI in your environment and implement safeguards that are reasonable and appropriate given the nature of your business and the sensitivity of the data you handle.

Administrative safeguards include a formal security management process with documented risk analysis and risk management, security awareness training for all workforce members with access to ePHI, documented contingency planning covering data backup, disaster recovery, and emergency operations, and a formal evaluation process that reviews your security controls periodically.

Physical safeguards cover the physical security of systems that store or process ePHI. For SaaS companies running on cloud infrastructure, this primarily means ensuring your cloud provider has appropriate physical security controls — which major providers like AWS, GCP, and Azure do — and that your own physical office environments do not create unauthorized access risks to systems handling ePHI.

Technical safeguards cover access controls, audit controls, integrity controls, and transmission security. MFA, role-based access controls, encryption of ePHI at rest and in transit, audit logging of access to ePHI systems, and automatic logoff for inactive sessions are all relevant here. For AI products specifically, technical safeguards need to address model access controls, training data security, inference logging, and output access restrictions.

The Breach Notification Rule

If a security incident results in unauthorized access to, acquisition of, or disclosure of unsecured PHI, you are required to notify affected individuals, the relevant Covered Entity, and — for breaches affecting 500 or more individuals — the Secretary of Health and Human Services. Notification must occur within 60 days of discovering the breach.

The Breach Notification Rule applies directly to Business Associates. If your system is breached and PHI is compromised, you cannot wait for your healthcare customer to handle the notification. You have independent obligations and independent liability.

Business Associate Agreements

A Business Associate Agreement is a contract between a Covered Entity and a Business Associate — or between a Business Associate and a subcontractor — that specifies the permitted uses and disclosures of PHI, requires the Business Associate to implement appropriate safeguards, and establishes the obligations of each party in the event of a breach.

You need a BAA with every Covered Entity customer that sends you PHI. You also need BAAs with any of your own vendors and subcontractors who process PHI on your behalf — this includes your cloud infrastructure provider, your logging and monitoring vendor, your customer support platform if it handles support tickets containing PHI, and any AI or analytics vendor that processes PHI as part of your product.

HIPAA compliance does not automatically flow from your cloud provider's BAA to you. Their BAA covers the infrastructure layer. Your compliance obligations cover everything built on top of it — your application architecture, access controls, data handling practices, and workforce training.

Step 4: Conduct Your HIPAA Risk Analysis

Risk analysis is a foundational requirement of the Security Rule and the most common finding in HHS enforcement actions. An extraordinary number of Business Associates have security controls in place but have never conducted a formal, documented risk analysis, which is itself a HIPAA violation regardless of how good the controls are.

A HIPAA risk analysis requires you to identify where ePHI exists in your environment — every system, application, database, storage service, and transmission path that touches PHI. For SaaS companies this means mapping data flows from ingestion through processing, storage, and deletion. For AI products, this means specifically identifying where PHI enters model pipelines, where it is stored during training or inference, and where outputs are stored or transmitted.

For each identified PHI location and flow, you assess the threats that could compromise confidentiality, integrity, or availability — unauthorized access, data corruption, ransomware, insider threat, accidental disclosure, and so on. You assess the likelihood and potential impact of each threat given your current controls, producing a prioritized risk register. You then document your risk treatment decisions — which risks you are mitigating with specific controls, which you are accepting with documented rationale, and how you will monitor the risk environment over time.

The risk analysis is not a one-time exercise. It must be reviewed and updated in response to environmental or operational changes — a new product feature, a new cloud service, a new category of PHI, or a security incident — all of which trigger the need for an updated analysis.

The HIPAA Compliance Checklist for SaaS and AI Startups

For a technical team implementing HIPAA compliance for the first time, the following checklist covers the foundational requirements that auditors and enterprise healthcare customers will look for.

Documentation and policy: Written HIPAA security policies and procedures covering all required administrative safeguards, a designated Privacy Officer and Security Officer, a documented workforce training program with completion records, and a formal sanctions policy for workforce members who violate HIPAA requirements.

Risk management: Completed and documented risk analysis covering all ePHI in your environment, risk management plan with specific controls mapped to identified risks, and a review schedule for ongoing risk assessment.

Access controls: Unique user identification for every workforce member with access to ePHI systems, MFA enabled across all systems with access to ePHI, role-based access controls limiting PHI access to workforce members with a legitimate need, automatic logoff for inactive sessions, and documented access provisioning and deprovisioning procedures.

Audit controls: Logging enabled for all access to and modification of ePHI, log retention meeting your risk analysis requirements, and a process for regular log review and alerting on suspicious activity.

Encryption: ePHI encrypted at rest using AES-256 or equivalent, ePHI encrypted in transit using TLS 1.2 or higher, and encryption key management documented and secured.

Backup and recovery: Documented data backup procedures covering ePHI, tested restoration procedures, and a disaster recovery plan covering scenarios that would affect access to ePHI.

Vendor management: BAAs executed with all Covered Entity customers and all subcontractors who process ePHI on your behalf, and a security review process for new vendors before granting access to ePHI.

Breach response: Documented breach response plan covering detection, containment, notification procedures, and timelines, and post-incident review requirements.

Training: Initial HIPAA training for all new workforce members, annual refresher training, and documented records of completion for all training.

HIPAA for AI Products: The Specific Considerations

AI products pose HIPAA compliance challenges that extend beyond standard SaaS security requirements due to the way data flows through machine learning pipelines.

Training data is the first critical question. If your model was trained on or fine-tuned using PHI — clinical notes, EHR data, medical imaging — that training data must have been handled in compliance with HIPAA. Using PHI for model training without proper authorization from the Covered Entity that provided it is a HIPAA violation. This applies to historical training data, ongoing fine-tuning, and retrieval-augmented generation architectures that pull from PHI data stores at inference time.

Inference logging is the second critical question. AI products often log model inputs and outputs for debugging, quality monitoring, and model improvement purposes. If those inputs contain PHI — and for clinical AI products, they almost always do — those logs are themselves PHI and must be secured accordingly. Sending PHI-containing inference logs to a third-party observability platform without a BAA is a HIPAA violation regardless of how it is framed internally.

Model outputs require careful consideration. An AI model that generates a clinical summary, a risk score, or a care recommendation based on PHI inputs is producing an output that may itself constitute PHI if it is individually identifiable and health-related. Access controls, audit logging, and transmission security requirements apply to model outputs just as they apply to source data.

De-identification for model development is technically achievable — HIPAA's Expert Determination method allows organizations to use statistical techniques to produce de-identified data suitable for model training — but it requires genuine statistical expertise and documented methodology. Simply removing names and dates of birth before training does not satisfy HIPAA's de-identification standard.

What Happens If You Get This Wrong

HIPAA enforcement is conducted by the HHS Office for Civil Rights, which has steadily increased both the volume and the severity of enforcement actions since 2019. Business Associates are now directly in scope for OCR audits — you do not need your Covered Entity customer to complain about you for OCR to open an investigation.

Penalties are tiered by culpability. Violations resulting from willful neglect — knowingly failing to implement required safeguards — carry a minimum penalty of $10,000 per violation, with no cap on annual penalties. Even violations resulting from reasonable cause, rather than neglect, carry a minimum penalty of $1,000 per violation. The phrase "per violation" is significant: a single breach affecting 10,000 patients can be treated as 10,000 separate violations.

Beyond regulatory penalties, the commercial consequences of a HIPAA breach are severe for a startup. Healthcare organizations have contractual rights to terminate relationships with Business Associates who experience breaches, and the reputational damage in a relationship-driven industry like healthcare is difficult to recover from. Enterprise health system customers conduct security due diligence before signing contracts — and a startup that cannot demonstrate a mature HIPAA compliance program simply does not advance in those procurement processes.

How DSALTA Helps SaaS and AI Startups Achieve HIPAA Compliance

DSALTA's compliance platform guides SaaS and AI companies through HIPAA compliance from initial risk analysis through ongoing evidence collection and audit readiness. For startups implementing HIPAA for the first time, DSALTA provides the risk analysis methodology, policy templates calibrated to the Security Rule's requirements, automated evidence collection from your existing cloud and engineering infrastructure, and a real-time compliance dashboard that shows exactly where you stand against each HIPAA safeguard category.

For AI companies with complex data pipelines, DSALTA's framework specifically addresses PHI data-flow mapping, training-data governance, and inference-logging compliance questions that standard HIPAA tools are not built to handle.

For organizations managing multiple compliance frameworks — a common position for health tech startups pursuing both SOC 2 and HIPAA simultaneously — DSALTA's cross-framework architecture maps overlapping controls so you build once and satisfy both requirements rather than running parallel programs.

Key Takeaways

HIPAA applies to your SaaS or AI product if it touches PHI on behalf of a healthcare organization — regardless of whether you have signed a BAA or been formally told you are a Business Associate. The Business Associate definition is broad and has been aggressively enforced since the 2013 Omnibus Rule. The foundational requirements — risk analysis, documented policies, technical safeguards, BAA execution, and breach response planning — are achievable for a technical team with the right framework and tooling. The cost of getting it wrong — in regulatory penalties, enterprise sales losses, and reputational damage — far exceeds the cost of building a compliant program from the start.

If your product is in a healthcare data flow, assume HIPAA applies and build accordingly. The alternative is discovering your obligation at the worst possible moment.

Frequently Asked Questions

Does HIPAA apply to my SaaS company if we are not a healthcare company? Yes, if your software processes PHI on behalf of a healthcare organization, you are a Business Associate under HIPAA and directly subject to its requirements — regardless of whether you consider yourself a healthcare company.

What is a Business Associate Agreement, and do I need one? A BAA is a contract specifying the permitted uses of PHI and the security obligations of both parties. You need a BAA with every Covered Entity customer that sends you PHI, and with every subcontractor or vendor you use that processes that PHI. Operating without a BAA when one is required is itself a HIPAA violation.

Does my AI model need to be HIPAA compliant if it processes clinical data? Yes. If your AI model ingests, processes, or produces individually identifiable health information, HIPAA's Security Rule applies to that processing. This includes training data handling, inference logging, and model output storage and transmission.

What is the difference between HIPAA and SOC 2 for healthcare software? SOC 2 is a voluntary framework demonstrating security controls across five Trust Services Criteria. HIPAA is a federal law with mandatory requirements for any organization handling PHI. Many healthcare enterprise customers require both SOC 2 as evidence of security maturity and HIPAA compliance as a legal requirement. DSALTA supports both simultaneously with overlapping control coverage.

How long does HIPAA compliance take for a startup? A startup with modern cloud infrastructure and no prior HIPAA program can complete initial HIPAA compliance — including risk analysis, policy documentation, implementation of technical safeguards, execution of BAAs, and workforce training — in 8 to 12 weeks using a compliance platform. Ongoing maintenance requires continuous evidence collection and an annual review of risk analyses.

What are the penalties for HIPAA violations? Penalties range from $100 per violation for unknowing violations to $50,000 per violation for willful neglect, with annual caps that vary by violation category. Breaches affecting large numbers of individuals can result in total penalties in the millions of dollars, in addition to reputational damage and contract termination rights held by Covered Entity customers.

DSALTA is an AI compliance software company helping SaaS and AI startups achieve HIPAA, SOC 2, ISO 27001, and GDPR compliance faster. Learn more at dsalta.com.