A healthcare customer's business associate agreement often arrives late in a deal, on the customer's paper, with a note that it is "standard." Part of it is. HIPAA sets a list of terms every agreement must contain, and those terms are not negotiable. The rest is commercial, and that is where a vendor takes on obligations it may not be able to meet.
This article separates the two. It lists what the regulation requires, the clauses that commonly go further, and the operational check worth doing before you sign. It is written for the business associate's side of the table, but a covered entity reviewing a vendor's paper can use the same list. Contract terms carry legal consequences, so confirm your reading with counsel before you sign.
When an agreement is required
A business associate is a person or organization that creates, receives, maintains, or transmits protected health information on behalf of a covered entity, for a function or activity HIPAA regulates. The definition also includes certain services, such as legal, accounting, consulting, and administrative work, where the service involves disclosing PHI. A subcontractor that handles PHI on behalf of a business associate is itself a business associate.
Before a covered entity discloses PHI to a business associate, or lets one create or handle it, the two must have a written agreement. The same rule runs down the chain: a business associate needs an agreement with each subcontractor that handles PHI for it.
Some disclosures need no agreement. A covered entity sharing PHI with another provider for a patient's treatment is one example. A narrow exception also exists for pure conduits, such as a carrier that transmits information without routine access to it. Do not stretch the conduit idea to cover storage. A service that stores PHI, encrypted or not, is generally a business associate under HHS guidance.
What the regulation requires the agreement to say
The required terms come from 45 CFR 164.504(e) under the Privacy Rule and 164.314(a) under the Security Rule. Check that the agreement in front of you covers each one. Under these provisions, the business associate must:
Use and disclose PHI only as the agreement permits or as required by law. The agreement cannot permit anything the covered entity itself could not do, with limited allowances for the business associate's own management and administration, and for data aggregation if the agreement provides for it.
Use appropriate safeguards, and comply with the Security Rule for ePHI.
Report any use or disclosure the agreement does not permit, including breaches of unsecured PHI as the Breach Notification Rule requires.
Report security incidents it becomes aware of.
Ensure subcontractors that handle PHI agree to the same restrictions and conditions.
Make PHI available so the covered entity can meet individuals' rights of access and amendment, and provide the information needed for an accounting of disclosures.
Where it carries out a covered entity's Privacy Rule obligation, comply with the requirements that apply to the covered entity for that obligation.
Make its internal practices, books, and records available to HHS for determining compliance.
At termination, return or destroy all PHI if feasible, keeping no copies. If that is not feasible, extend the agreement's protections to what remains and limit further use to the reasons return was infeasible.
The agreement must also let the covered entity terminate it if the business associate violates a material term. HHS has published sample business associate agreement provisions that track these requirements, and they are a useful baseline for comparing a customer's draft.
Clauses that go beyond the rule
Most negotiation happens here. None of these clauses is required by HIPAA, and each can be reasonable. The question is whether you can perform it.
| Clause | What HIPAA sets | What to check |
|---|---|---|
| Breach notice to the customer | No later than 60 calendar days after discovery, and without unreasonable delay | Shorter deadlines are common. Can you identify affected individuals within that window? |
| Security incident reporting | Report security incidents | Whether unsuccessful attempts, such as routine scans, are excluded or reported in aggregate |
| Indemnification and liability | Silent | Uncapped indemnity, and whether it sits outside the main contract's cap |
| Cost of breach response | Silent | Obligations to pay for notification, credit monitoring, or call centers |
| Insurance | Silent | Required cyber coverage amounts and named-insured terms |
| Audit rights | HHS access only | On-site audit rights, notice periods, frequency, and who pays |
| Offshore restrictions | Silent | Bans on storing or accessing PHI outside the United States, including by support staff |
| De-identification and aggregate use | Allowed only if the agreement permits | Whether you may de-identify PHI or use it to improve your product |
| Subcontractor approval | Flow-down required | Prior approval rights over new subcontractors, and notice periods |
The breach notice clause deserves the most care. The 60-day figure is an outer limit, not a target, and the customer has its own 60-day deadline to notify individuals. A customer asking for notice within a few days so it can meet that deadline is reasonable. A clause that requires full details of every affected individual within 24 hours of a suspected incident may not be achievable, and a deadline you miss is a breach of contract.
Can you actually perform it?
Read the agreement against how your systems and team work, not against your policies. For each obligation, name the person and the system that would carry it out.
Permitted uses. List every way you use customer data: hosting, support, debugging, analytics, model training, benchmarking. Anything not covered by the agreement's permitted uses has to stop or be added.
Return or destruction. At termination, can you delete one customer's PHI from primary storage, replicas, logs, and backups? If backups cannot be selectively purged, the infeasibility path applies. Say so in the agreement and describe how retained data stays protected until it ages out.
Individual rights. If a patient asks the customer for their records, can you produce that patient's data in a usable form within the customer's deadline? The Privacy Rule gives covered entities a fixed window to respond, and your agreement may commit you to a shorter one.
Flow-down. Every subcontractor that handles PHI for you needs its own agreement with terms at least as strict as the ones you accept. If your customer's draft bans offshore access, check your hosting, support, and monitoring vendors before agreeing.
Incident handling. Your incident procedure should include the customer-notification step, the contact address from each agreement, and each customer's deadline. Track these per customer, because they will differ.
Your own agreement, and the GDPR overlap
Many vendors draft their own business associate agreement and offer it first. That is usually the better position. It keeps the terms consistent across customers, which is what makes them performable at scale. Expect large health systems to insist on their own paper anyway.
If you also process personal data under the GDPR, the business associate agreement and the data processing agreement cover similar ground with different requirements. They are not interchangeable. What belongs in a GDPR data processing agreement covers the Article 28 terms. Some vendors combine both in one document. Others keep them separate so each regulator's language stays intact.
The agreement also shapes your security program. The Security Rule obligations it confirms are the ones described in HIPAA technical safeguards for SaaS teams and the rest of the rule. The HIPAA framework page summarizes them.
How TrustLynce helps
TrustLynce records commitments from each customer agreement, such as a notification deadline or an offshore restriction, and tracks them against the controls that meet them (customer commitments). For your own subcontractors, third-party risk keeps the vendor inventory, risk tier, and review dates in one place.