The first healthcare deal usually arrives before the HIPAA program does. A clinic, a health plan, or a digital health company wants your product, and their procurement team sends a business associate agreement and a security questionnaire. Someone on your side asks whether you are "HIPAA compliant," and nobody is sure what the honest answer is.
This article is the overview for that moment. It covers how to tell whether HIPAA applies to you, what it requires once it does, what buyers accept as evidence, and a sensible order of work. Each topic has a deeper treatment elsewhere on this blog, linked where it comes up.
Are you a business associate?
HIPAA applies directly to two kinds of organization. Covered entities are health plans, health care clearinghouses, and health care providers that conduct standard transactions electronically. Business associates create, receive, maintain, or transmit protected health information on behalf of a covered entity, or on behalf of another business associate.
Most SaaS companies selling to healthcare are business associates, or not regulated by HIPAA at all. Four questions sort it out:
Is your customer a covered entity or a business associate? If your customer is a consumer wellness company that is neither, HIPAA may not apply to the data, though other laws might.
Does PHI enter your systems? A staff scheduling tool for a clinic that holds only employee data may never touch PHI. A patient messaging tool always does.
Do you handle it on the customer's behalf? Hosting, processing, analyzing, or transmitting PHI for a customer's purposes is the core of the definition.
Are you storing it, even without access? HHS guidance treats a cloud service that stores ePHI as a business associate even if the data is encrypted and the provider holds no key.
If your customer is itself a business associate, such as a billing company or another software vendor, you are a subcontractor. The obligations are the same, and the agreement runs to your customer rather than to the provider.
Write the conclusion down, product by product. Some vendors decide that only certain products or configurations may hold PHI, and say so in their terms. That is a legitimate way to limit scope, provided the restriction is enforced.
What the role obligates you to do
Since the HITECH Act and the 2013 Omnibus Rule, business associates have been directly liable for parts of HIPAA, not only through contract. HHS has published a fact sheet listing those provisions. They include:
Complying with the Security Rule in full
Not using or disclosing PHI except as your agreement permits or the law requires
Notifying the covered entity of breaches of unsecured PHI
Making reasonable efforts to limit PHI to the minimum necessary
Entering business associate agreements with your own subcontractors
Providing records to HHS when it investigates
The Security Rule is the bulk of the work. It means a risk analysis, a named security official, written policies, workforce training, access controls, audit logging, a contingency plan, and documentation kept for six years. The HIPAA risk analysis requirement is the place to start, because the rest of the program is meant to follow from it.
The Privacy Rule applies to you more narrowly. You must follow the uses and disclosures your agreement permits, and help the covered entity meet patients' rights, such as access to their records. Most of the Privacy Rule's administrative requirements fall on the covered entity.
There is no HIPAA certification
HHS does not certify or endorse any organization or product as HIPAA compliant. Private companies sell HIPAA "certifications," but no regulator recognizes them. A healthcare buyer's security team knows this, and a badge on your website that implies otherwise costs credibility.
What buyers accept instead is a combination of documents:
A signed business associate agreement. This is the one they cannot do without. Business associate agreements: what to check before signing covers the terms.
Evidence of a risk analysis. Usually a summary of scope, method, and date, not the full register.
Your policies. At least the index, and often the security policy in full.
A third-party report. A SOC 2 report is common. Some buyers, especially larger health systems and payers, ask for HITRUST. HITRUST vs SOC 2 for healthcare buyers compares the two.
A completed security questionnaire. Often the buyer's own, sometimes a standard one with healthcare additions.
A penetration test summary. Recent, with remediation status.
Neither SOC 2 nor HITRUST is a HIPAA assessment, though both can cover much of the Security Rule's ground. Some auditors offer SOC 2 reports that include additional HIPAA criteria. If you take that route, agree the scope with your auditor early.
Your own subcontractor chain
Every vendor that handles PHI for you needs a business associate agreement with you, on terms at least as strict as the ones you accept from customers. The list is usually longer than the hosting provider, which is why it is easy to get wrong.
Start from the data flow. Common subcontractors that end up handling PHI:
Your cloud provider. Most large providers offer a business associate agreement, but it typically covers only a listed set of services. Check each service you use against that list.
Email and SMS delivery, if notifications contain patient details
Customer support and help desk tools, where tickets and screenshots land
Logging, monitoring, and error tracking services that capture request data
Data warehouses and analytics tools that receive production data
AI and search APIs that process PHI in prompts or documents
For each one, either sign an agreement or keep PHI out. Keeping it out is often the better option for logging and analytics. It is rarely possible for hosting.
A sensible order of work
For a company starting from a first healthcare deal, this order front-loads what buyers check and what everything else depends on:
Map PHI. List every system, product, and vendor that PHI reaches. Decide which products will hold PHI.
Fix the subcontractor chain. Sign agreements where PHI flows, and remove it from places it should not be.
Assign ownership. Name the security official in writing.
Run the risk analysis against the PHI map, and start the risk register.
Write the core policies the Security Rule's administrative safeguards require, and train the workforce on them.
Close the highest-rated gaps. For most SaaS teams these are encryption, MFA, audit logging, and backup restore testing.
Prepare your own agreement template and an incident procedure with a customer-notification step.
Assemble the buyer package: the documents listed above, ready to send.
Steps 1 and 2 are usually the quickest, and they shape everything after. A company that knows where its PHI is can answer most buyer questions accurately, even before the full program is in place.
What to say in a sales conversation
Accuracy here protects you twice: once with the buyer's security team, and once if the statement is ever examined after an incident. Phrases that hold up:
"We sign business associate agreements and are subject to the Security Rule as a business associate."
"We completed a risk analysis on a stated date, and we can share a summary."
"Our SOC 2 report covers these controls, and here is how they map to the Security Rule."
Phrases to avoid: "HIPAA certified," "fully HIPAA compliant," and "HIPAA compliant hosting" used as if it settles the question. Compliance with HIPAA is an ongoing obligation of your organization, not a property of a product. The HIPAA framework page summarizes the rules in more detail.
How TrustLynce helps
A Trust Center lets you share your policies, report, and penetration test summary with buyers through gated access, with a log of who accessed what. Questionnaire automation drafts answers to healthcare security questionnaires from a library your team has reviewed.