When you sell a technology service to a healthcare customer, your master services agreement (MSA) and business associate agreement (BAA) can answer the same questions differently: when to report an incident, what your liability cap covers, how you may use the data and what happens when the contract ends. Ask counsel to review them together with the statement of work and a checked account of how your service handles data.
Ask for coordinated redlines and a short decision list: what needs to change, what your team must confirm and who decides. This guide helps scope that assignment; counsel must determine the relevant business-associate relationships and requirements for your service.
Start with what happens to the data
Describe what the customer buys, then trace the data through the service: who sends it to you, who on your team and among your own vendors can access it, where it is stored and what happens to it when the contract ends. Name the technical owner who can confirm each point. Use information categories rather than patient records.
If the service runs in the customer’s cloud account or the customer holds the encryption keys, explain any access your team retains for support or monitoring. HHS says a cloud provider storing electronic protected health information for a covered entity or another business associate is a business associate even if it lacks the key to decrypt it. HHS cloud guidance
Gather the MSA, BAA, statement of work, prior redlines, security exhibits and terms incorporated by link. Note whose form each document started from and which documents are already signed.
Put the potential conflicts on one page
HHS’s sample BAA provisions can sit within a services agreement or in a separate contract. Their drafting notes address points that need coordination: permitted uses tied to a services agreement, reporting timeframes, responsibility for breach notices and permission to de-identify information. HHS BAA provisions
Notification
Compare: What triggers a report, when the clock starts, who receives it, what it must contain and who handles any notices to affected people or regulators.
Bring: The process your security team can run, including how reports from your own vendors reach it.
Liability and indemnity
Compare: Whether the MSA’s limits and exclusions reach BAA obligations, and whether the BAA adds indemnities or reimbursement of breach costs.
Bring: Relevant insurance documents, your broker’s contact and the business owner’s risk questions.
Your vendors and access
Compare: Whether subcontractor terms match the hosting, support and other vendors you use, including where data is stored and accessed.
Bring: A checked diagram showing each organization’s role, access and relevant agreements.
Your use of the data
Compare: Rights in the MSA over usage, aggregated or de-identified data against the BAA’s permitted uses and any permission to de-identify information.
Bring: Product and engineering’s account of uses beyond delivering the service, such as analytics, product improvement or model training.
Ending the service
Compare: Whether ending the BAA ends the MSA, how cure periods compare, and how suspension, customer access, return and deletion terms fit together.
Bring: The technical owner’s description of exports, retained copies and backups, with unknowns marked.
Document priority
Compare: Which document controls each topic, including conflicting precedence clauses and incorporated terms.
Bring: The complete versioned package and signature status; do not assume the last attachment wins.
A worked example: two different notification promises
Fictional example: a vendor’s draft MSA says to notify the customer after confirming an incident. Its draft BAA describes notice after discovery of a suspected event. The statement of work routes customer reports to a support inbox, while the BAA names a separate security contact. No one has checked who monitors the inbox outside normal working hours.
The decision list should make the mismatch visible and assign it:
- Counsel: compare the triggers and recipients, assess applicable requirements, and propose coordinated language across the documents.
- Security lead: confirm how an event reaches the team, who evaluates it and how the customer is contacted. Record gaps rather than promise a process that does not exist.
- Business owner: decide what operational commitments the team can support and approve the negotiated position with counsel.
Do not settle this by copying one document’s timing into the other. Counsel must check the legal requirements alongside the contract promises, and the team must confirm it can run the agreed process.
Ask for a usable output
Tell counsel your target signing date and whether the assignment includes negotiation or review of the customer’s counterproposal. Agree which requirements the review covers and identify any separate work needed to assess the service’s actual compliance.
Here is an illustrative request to adapt:
“We sell a technology service to healthcare customers and need vendor-side counsel to review the MSA, BAA and related statement of work as one package. Please identify conflicting obligations, propose coordinated revisions and return a prioritized decision list, including whether the BAA fits what the service does. We will explain who our customer is, provide a checked account of our service and data handling, mark current documents as signed or proposed, and name technical and business contacts. Flag missing facts and confirm the review scope and target date with us. Separately scope any negotiation support or broader compliance assessment.”
Find counsel for the package
Use Lawtrades to describe the assignment and find a lawyer with relevant experience. Agree scope, fees and deliverables with counsel before work begins. Your first message needs only a description of the deal, the documents involved and your deadline. Leave out patient information and arrange document sharing with your chosen counsel.