Covered entity, business associate, subcontractor
HIPAA sorts organizations into roles, and the role decides which obligations apply. The definitions sit in 45 CFR 160.103, and three of them matter most to a software company.
The chain can run several links deep. If a clinic uses your scheduling platform and your platform stores that data with a cloud provider, the clinic is the covered entity, your company is its business associate, and the cloud provider is generally treated as your subcontractor, because it maintains protected health information on your behalf.
A few details are easy to miss. A covered entity can itself be a business associate of another covered entity. The definition also has exceptions, such as a health care provider that receives information from a covered entity to treat the individual. A covered entity's own workforce members, such as employees, volunteers, and trainees, are not its business associates.
- Covered entity: a health plan, a health care clearinghouse, or a health care provider that transmits health information electronically in connection with a transaction covered by the HIPAA rules.
- Business associate: a person or organization that, on behalf of a covered entity and outside its workforce, creates, receives, maintains, or transmits protected health information for a regulated function or activity, or provides services such as legal, accounting, consulting, data aggregation, management, or administrative services where the service involves disclosing protected health information to it.
- Subcontractor: a person or organization to whom a business associate delegates a function, activity, or service. A subcontractor that creates, receives, maintains, or transmits protected health information for the business associate is itself a business associate.
Signs your product is a business associate
Whether a particular arrangement makes you a business associate is a legal question, and the answer turns on the facts: who the customer is, what the product does, and what data it touches. For a SaaS or health tech company, the questions below show where you stand before you talk to counsel.
A yes to any of them is a reason to map your data flows and get a legal opinion. If a customer has already sent you a business associate agreement, treat it as a prompt to answer these questions, not as the answer itself.
- Do your customers include health plans, health care providers, or clearinghouses, or companies that serve them?
- Does the product store, process, or transmit patient or member information for those customers, even briefly, for example appointment details, claims, lab results, clinical notes, or billing records?
- Does the product perform a function the definition names, such as claims processing, data analysis, utilization review, quality assurance, billing, benefit management, or practice management?
- Can your engineers or support staff see customer data that includes health information, for example while troubleshooting?
- Does health information flow into your logs, backups, analytics, error tracking, or email systems?
- Is a customer asking you to sign a business associate agreement?
What the HIPAA Security Rule asks of a business associate
Business associates follow the same Security Rule standards as covered entities, and these standards are the core HIPAA business associate requirements. Since the 2013 amendments, 45 CFR 164.302 applies the rule's standards, implementation specifications, and requirements to both, for the electronic protected health information (ePHI) involved.
The rule is flexible about how, not whether. Under 45 CFR 164.306(b), you choose security measures that fit your size, complexity, and capabilities, your technical infrastructure, the costs involved, and the probability and criticality of the risks. Some implementation specifications are required. Others are addressable, which means you assess each one, implement it if it is reasonable and appropriate, or document why not and implement an equivalent alternative if that is reasonable and appropriate.
Everything starts with the risk analysis, a required specification in 45 CFR 164.308(a)(1)(ii)(A): an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability of the ePHI you hold. Risk management, the security measures that bring those risks down to a reasonable and appropriate level, is required too.
| Safeguard area | Where in the rule | Standards named in the rule (examples) | How it often shows up in a SaaS product |
|---|---|---|---|
| Administrative | 45 CFR 164.308 | Security management process, assigned security responsibility, workforce security, security awareness and training, security incident procedures, contingency plan, evaluation | A named security official, a documented risk analysis, onboarding and offboarding steps, training records, an incident response plan, tested backups |
| Physical | 45 CFR 164.310 | Facility access controls, workstation use, workstation security, device and media controls | Reliance on your cloud provider's data center controls, plus rules for laptops, removable media, and disposal |
| Technical | 45 CFR 164.312 | Access control, audit controls, integrity, person or entity authentication, transmission security | Unique accounts, least-privilege roles, audit logs of access to ePHI, strong authentication, encryption in transit and at rest where reasonable and appropriate |
| Organizational | 45 CFR 164.314 | Business associate contracts or other arrangements | Agreements with each healthcare customer and with every subcontractor that handles ePHI |
| Documentation | 45 CFR 164.316 | Policies and procedures, and written records of required actions, kept six years | Versioned policies, risk analysis reports, decisions on addressable specifications, evidence of reviews |
What a business associate agreement must cover
A covered entity may let a business associate handle ePHI only after obtaining satisfactory assurances, documented in a written contract or other arrangement (45 CFR 164.308(b)). A business associate must get the same assurances from its own subcontractors. That contract is the business associate agreement, often shortened to BAA.
The Privacy Rule adds its own contract terms in 45 CFR 164.504(e). Among them: the permitted uses and disclosures of protected health information, a promise not to use or disclose it beyond the contract or the law, support for individuals' rights of access, amendment, and accounting, access to books and records for HHS, and return or destruction of the information at the end of the contract where feasible.
Counsel writes and negotiates the agreement. The practical job for a SaaS team is to make sure the business can deliver what it signs: incident reporting it can meet, subcontractor agreements already in place, and a register of every agreement and what it promises.
- Comply with the applicable requirements of the Security Rule (45 CFR 164.314(a)(2)(i)(A)).
- Ensure that any subcontractor that creates, receives, maintains, or transmits ePHI on the business associate's behalf agrees to the same requirements through a compliant contract (164.314(a)(2)(i)(B)).
- Report to the covered entity any security incident it becomes aware of, including breaches of unsecured protected health information as required by 45 CFR 164.410 (164.314(a)(2)(i)(C)).
When HIPAA may not apply: consumer health apps
Does HIPAA apply to your app? Not necessarily. An app that people download and use on their own, without acting on behalf of a health plan, provider, or clearinghouse, is usually outside the business associate definition. Handling health data doesn't by itself bring a company under HIPAA; being a covered entity, or working on behalf of one, does.
Such apps may fall under the FTC Health Breach Notification Rule, 16 CFR Part 318, which applies to vendors of personal health records, PHR related entities, and their third party service providers. The rule's definitions reach online services, including mobile apps and connected devices, that track things such as health conditions, medications, fitness, sleep, or mental health. It does not apply to HIPAA-covered entities, or to any other entity to the extent it acts as a business associate of one (16 CFR 318.1).
One company can sit on both sides of that line: a business associate for its clinic customers and a personal health record vendor for its direct-to-consumer product. The FTC's Mobile Health Apps Interactive Tool helps developers see which federal laws may apply, including HIPAA, the FTC Act, the Health Breach Notification Rule, the Federal Food, Drug, and Cosmetic Act, and COPPA.
What healthcare customers usually ask vendors for
Healthcare customers review vendors before and after they sign. Requests vary with the customer's size and the sensitivity of the data, but the same items come up again and again, and having them ready saves rework in each review.
- A signed business associate agreement, or comments on theirs.
- A summary of your most recent risk analysis and your risk management plan.
- Security policies and procedures, and the name of your security official.
- Answers to a security questionnaire, backed by evidence rather than assertions.
- Evidence that safeguards operate: access reviews, training records, an incident response plan and its last test, and backup restore tests.
- A summary of a recent penetration test, and how findings were fixed.
- An independent report such as a SOC 2 report, if you have one.
HIPAA and SOC 2 together
HIPAA vs SOC 2 is a comparison of different things. HIPAA is a federal law, and the Security Rule is a regulation you must meet if it applies to you. A SOC 2 report is an attestation report from a licensed CPA firm, acting as the service auditor, on controls relevant to the trust services categories in scope, such as security and availability. SOC 2 is not a certification.
A SOC 2 report doesn't assess whether you meet the HIPAA Security Rule, and HHS says it does not endorse or recognize private organizations' certifications regarding the rule. The two still fit together well. One mapped set of controls can support both your HIPAA risk analysis and safeguards and a SOC 2 examination, and some healthcare customers accept a SOC 2 report as part of their vendor review.
First steps toward HIPAA compliance for a SaaS team
HIPAA for startups is mostly about sequence. You don't need every policy on day one, but you do need to know where ePHI lives and what could go wrong with it before you promise anything to a customer.
HHS proposed changes to the Security Rule in January 2025. As of September 27, 2026, the proposal has not been finalized or withdrawn, so build on the rule as it stands and track the proposal separately.
- Map where health information enters, lives, and leaves the product, including logs, backups, analytics, support tools, and staging environments.
- Decide with counsel which customers and product lines make you a business associate.
- Name the security official responsible for your Security Rule policies and procedures (45 CFR 164.308(a)(2)).
- Complete and document a risk analysis, then a risk management plan with owners and dates.
- Review each safeguard in Subpart C and record your decision on every addressable specification.
- List the vendors that touch ePHI and put subcontractor agreements in place before data flows.
- Adopt policies you actually follow, and keep required documentation for six years.
- Train your workforce, then test your incident response and contingency plans.
- Keep the evidence organized so customer reviews draw on it instead of starting from scratch.