HIPAA for SaaS startups: what to have in place before you sign a BAA

Updated

If your product creates, receives, maintains or transmits protected health information (PHI) on behalf of a covered entity, you are a business associate under the HIPAA regulations (45 CFR 160.103). A business associate agreement (BAA) is the contract that comes with that role, and the Security Rule applies to you directly whether or not you sign one. Before you sign, have these in place: a written risk analysis, security policies, workforce training, access and audit controls, a breach notification process, and BAAs with your own vendors that touch PHI, starting with your cloud host. This guide is not legal advice. It shows you where the rules are written so you know what to ask healthcare counsel.

When you are a business associate

The regulation defines a business associate, with respect to a covered entity, as a person who on the covered entity's behalf creates, receives, maintains or transmits PHI for a function or activity the HIPAA rules regulate, such as claims processing, data analysis, billing or practice management, or who provides certain services, such as consulting, management or administrative services, where doing so involves disclosure of PHI to them. A subcontractor that creates, receives, maintains or transmits PHI on behalf of a business associate is a business associate too (45 CFR 160.103). HHS explains the term on its business associates page.

For a SaaS company the practical test is about your customer data, not your intentions: does PHI from a provider, health plan or clearinghouse reach your systems, even if only to be stored or passed through your support tools? If it does, you are probably one. If your product is built so PHI never reaches you, you may not be, which is why some startups design it out. Either way, the call belongs to counsel who has seen your architecture.

Encryption does not take you out of scope

A common assumption is that a company that holds only encrypted data, and not the keys, cannot be a business associate. HHS's guidance on HIPAA and cloud computing addresses this directly for cloud providers that maintain ePHI: it treats them as business associates even when the provider cannot view the data. Read that page before you rely on a no-key argument for your own product or for a vendor of yours.

What a BAA commits you to

The regulation lists what a business associate contract must contain (45 CFR 164.504(e)). In summary, it must:

  • Set out the uses and disclosures of PHI you are permitted or required to make, and not allow uses the covered entity could not make itself, with narrow exceptions.
  • Bar you from using or disclosing PHI beyond what the contract or the law allows.
  • Require appropriate safeguards, and that you follow the Security Rule for electronic PHI.
  • Require you to report uses or disclosures the contract does not allow, including breaches of unsecured PHI.
  • Require you to hold your subcontractors to the same restrictions.
  • Require you to help the covered entity meet its obligations on individuals' access, amendment and accounting of disclosures requests.
  • Require you to make your internal practices, books and records available to the HHS Secretary.
  • Require you to return or destroy PHI at termination if feasible, or extend the contract's protections if not.
  • Let the covered entity terminate the contract if you violate a material term.

The Security Rule adds its own contract requirements: you must comply with the Security Rule, ensure your subcontractors that handle ePHI agree to the same, and report any security incident you become aware of (45 CFR 164.314(a)). That summary is ours; read the regulation text for exact wording. A customer's BAA often goes beyond the required elements, with shorter notice deadlines, audit rights, insurance or indemnity terms. Those extra terms are the part to negotiate with counsel.

Your own vendors: the cloud host and anything that sees PHI

A business associate may let a subcontractor handle ePHI only after obtaining satisfactory assurances that it will safeguard the information (45 CFR 164.308(b)(2)). Those assurances take the form of a BAA between you and the subcontractor, with the same restrictions and conditions (45 CFR 164.504(e)(5)). List every service that can see PHI, not just the hosting provider: the database, backups, logging and monitoring, error tracking, email and support tools, and any AI service that receives text from your product.

  • Check the scope of each BAA. A cloud provider's BAA usually covers a listed set of services. A service outside the list is not covered by it.
  • Keep PHI out of tools without a BAA. The simplest control is to stop PHI from flowing into a vendor you cannot sign with: scrub logs, error reports and support tickets.
  • Keep a record per vendor. The vendor review template records contract terms, including whether a BAA is in place. The Vendor and Third-Party Risk Policy, when your answers include health data, requires a BAA before any vendor receives PHI. For reports from vendors that have them, see where to get vendor SOC 2 reports.

The Security Rule safeguards, and how far 22 policies go

The Security Rule (45 CFR Part 164, Subpart C) has administrative, physical and technical safeguards, plus organizational and documentation requirements. HHS summarizes it on its Security Rule page. It requires you to implement reasonable and appropriate policies and procedures (45 CFR 164.316), and to keep that documentation for 6 years (45 CFR 164.316(b)(2)).

Policyseed mapped its 22 policies to all 65 of the Security Rule's standards and implementation specifications (21 Required and 22 Addressable specifications, plus 22 standards). In that mapping, 44 are addressed by the policies, 17 partly, and 4 not at all. The 4 not addressed are requirements for clearinghouses, group health plans and government agencies, which a SaaS vendor records as not applicable. The 17 partly addressed are the ones where a policy can require something it cannot be. The full table, with the policy sections behind each line and a CSV, is on the HIPAA policy templates page. It is Policyseed's own mapping, not a determination by HHS.

To get the PHI statements in your own policies, pick Health data (PHI) under Sensitive data handled in the free generator. The healthtech page covers how the same policies serve a SOC 2 request from the same customers.

The risk analysis requirement

The Security Rule requires a risk analysis, which it describes as an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity and availability of the ePHI you hold, and risk management, which means implementing security measures sufficient to reduce those risks to a reasonable and appropriate level (45 CFR 164.308(a)(1)(ii)). It also requires you to identify a security official responsible for the policies and procedures (45 CFR 164.308(a)(2)) and to train your whole workforce (45 CFR 164.308(a)(5)).

The regulation does not prescribe a format, so a documented analysis is, at minimum, a record of where ePHI lives and moves, the threats and vulnerabilities you found, how likely and how serious each one is, what you decided to do about it, and the date and who approved it. Keep it current as the product changes. The risk assessment tool builds that kind of record from your generator answers, but it is built on the SOC 2 Risk Assessment and Management Policy and is not a Security Rule risk analysis scoped to ePHI on its own; scope it to the systems that hold PHI and add what your counsel or security advisor asks for. The risk register template is a blank starting point.

Breach notification

A business associate must notify the covered entity of a breach of unsecured PHI without unreasonable delay, and in no case later than 60 calendar days after discovery (45 CFR 164.410). Notice identifies each affected individual to the extent possible and gives the covered entity other available information it needs for its own notices. HHS describes the rule on its Breach Notification Rule page. Your BAA may set a shorter deadline, and state law may add requirements. Put the shortest deadline you have agreed to into your incident response plan, with an owner for each step and a way to tell which customers a given incident touches.

What policies do not cover

  • The contracts themselves. The BAA you sign with each covered entity and the BAAs you sign with your vendors are legal documents. Policies can require them; they are not substitutes.
  • Breach notification law and the Privacy Rule. Policyseed's mapping covers the Security Rule only. A business associate's Privacy Rule obligations come mostly through the BAA, and state laws and other federal rules, such as the FTC Health Breach Notification Rule, may apply to your facts.
  • Evidence that you did the work. A risk analysis performed, training records, dated log reviews and tested recovery plans are what a customer or HHS would ask to see.
  • HHS's sample provisions. HHS publishes sample business associate agreement provisions. Use them to compare against a customer's draft, not as a replacement for a lawyer's review.

There is no official HIPAA certification

No standard in the Security Rule requires you to "certify" compliance, and HHS says it does not endorse or otherwise recognize private organizations' certifications regarding the Security Rule (HHS FAQ). If a vendor offers a seal or a badge, ask what was checked and by whom. What you can show is the documentation the rule asks for and the records that you followed it. A SOC 2 report is a CPA firm's opinion on controls against the Trust Services Criteria; many health customers ask for one alongside the BAA, and it is not a HIPAA determination. See what to send when a customer asks for a SOC 2 report.

Questions to take to healthcare counsel

  1. On our architecture and the data we receive, are we a business associate, and for which customers?
  2. Which clauses in this BAA go beyond the required elements, and which can we negotiate (notice deadlines, audit rights, insurance, indemnity, termination)?
  3. How does the BAA define a security incident and a breach, and what does it ask us to report and when?
  4. Which of our vendors and subprocessors can see PHI, and does each BAA cover the services we actually use?
  5. What must we do with PHI when a customer leaves, given the BAA's return or destroy terms and our backups?
  6. Which state laws apply to us in addition to HIPAA?
  7. Does our risk analysis scope and format meet what the customer will ask to see?

Where Policyseed fits

The generator and its 22 policies are free and run in your browser. The Audit Kit ($59, one time) adds editable Word policies in your company's name and, when your answers include health data, a HIPAA Security Rule sheet in its crosswalk.xlsx. Neither is legal advice, neither signs or reviews a BAA, and neither replaces the risk analysis or the training you have to carry out.

Frequently asked questions

What does HIPAA mean for SaaS startups?
It depends on whether your product touches protected health information (PHI) for a covered entity such as a provider or health plan. If it does, you are a business associate, and the Security Rule applies to you directly, on top of whatever the business associate agreement (BAA) says. If you never create, receive, maintain or transmit PHI for a covered entity, you are not a business associate on that account, and designing the product so PHI never reaches you is a legitimate option. Whether your facts fit is a question for healthcare counsel.
Do we have to sign a BAA?
If you are a business associate, the regulation requires a written contract or arrangement with the covered entity that contains the elements in 45 CFR 164.504(e), so in practice the customer will not give you PHI without one. What the contract says beyond those elements is negotiated. Have counsel read it before you sign, because it can add obligations the regulation does not require.
Do we need a BAA with our cloud provider?
If ePHI is stored or processed there, generally yes. HHS's cloud computing guidance treats a cloud provider that maintains ePHI as a business associate even when the data is encrypted and the provider holds no key. Many cloud providers offer a BAA that covers a published list of services, so check that every service you put PHI in is on that list. The same question applies to your database host, logging tool, support desk and any other subcontractor that can see PHI.
Is there an official HIPAA certification?
No. HHS says it does not endorse or otherwise recognize private organizations' certifications regarding the Security Rule. A badge or a certificate from a private company shows what that company checked, not a determination by HHS. What a customer can ask to see is your evidence: the risk analysis, policies, agreements, training records and logs. A SOC 2 report is a CPA firm's opinion on your controls against the Trust Services Criteria, not a HIPAA determination either.
How quickly must we tell the customer about a breach?
The Breach Notification Rule requires a business associate to notify the covered entity without unreasonable delay and in no case later than 60 calendar days after discovery of a breach of unsecured PHI (45 CFR 164.410). Your BAA can set a shorter deadline, and many do, so write the contract deadline into your incident response process and read how the BAA defines an incident. State law may add its own requirements.
Are our SOC 2 policies enough for HIPAA?
No, but they carry a lot of the weight. Policyseed's own mapping of its 22 policies to the 65 Security Rule standards and implementation specifications finds 44 addressed, 17 partly addressed and 4 not addressed, each with the reason. The partly addressed items ask for something a policy can require but cannot be: a risk analysis performed, training completed, an agreement signed. That is Policyseed's mapping, not a determination by HHS.
Is this legal advice?
No. This guide explains the regulation's structure and points to the text so you know what to ask. HHS and its Office for Civil Rights administer and enforce HIPAA; Policyseed is not affiliated with either. Take the BAA, your facts and your state's rules to a lawyer who works with healthcare companies.

HIPAA is the Health Insurance Portability and Accountability Act of 1996. Citations are to the Code of Federal Regulations on eCFR, which was read on October 25, 2026; the summaries are ours, not the regulation text. Policyseed is not affiliated with HHS or its Office for Civil Rights.

Policyseed provides governance policy templates and AI tailoring. It is not legal advice and not a compliance guarantee. Management adopts the policies; the CPA firm performs the SOC 2 examination.