White Paper · Business & Contracts · Privacy & Security

The Data Terms Stack: DPA, BAA, and Security Exhibits

A master agreement rarely answers the data-risk questions by itself. The DPA, BAA, security exhibit, order form, and product documentation must allocate the same data, security, incident, subcontractor, deletion, and liability obligations without contradicting one another.

By Lincoln Square Law · 8-minute read

Map the documents before negotiating any one of them

A data-heavy transaction often arrives as a stack: master services agreement, order form, data processing addendum, business associate agreement, security exhibit, service-level terms, AI terms, and online policies incorporated by reference. Each document may have been drafted by a different team. The first legal task is therefore architectural: identify which document governs which subject and what happens when two documents conflict.

Create a one-page precedence map. Record whether the BAA controls for protected health information, whether the DPA controls for personal information generally, whether the security exhibit overrides weaker security language in the MSA, and whether the order form can change liability. If the agreement uses “notwithstanding anything to the contrary” language in several places, compare those provisions directly. Multiple purported trump clauses are a signal that the stack has not been reconciled.

Define the data before assigning obligations

The contract should distinguish customer data, personal information, protected health information, confidential information, de-identified data, usage data, telemetry, and model or product-improvement data where relevant.

Definitions determine which obligations apply. A provider may agree to delete “Customer Data” while defining that term narrowly enough to exclude logs or derived records that still matter to the customer.

For healthcare arrangements, determine whether the vendor is a HIPAA business associate for any service. HHS explains that BAAs must contain the elements specified by 45 CFR 164.504(e), including permitted and required uses and disclosures, safeguards, reporting, subcontractor flow-down, access to records, and return or destruction at termination where feasible. A generic DPA is not a substitute for those HIPAA-specific terms when a BAA is required.

Make the BAA operational, not ornamental

A BAA should match the actual service. Identify which systems receive PHI, which functions require it, which subcontractors touch it, and who handles individual-rights requests, amendments, accountings, or breach coordination.

HHS’s sample provisions are a useful baseline but expressly do not replace transaction-specific terms or state-law analysis. A BAA that says the right things abstractly can still fail if the vendor’s product team cannot perform the obligations.

Incident reporting is a common example. The HIPAA rules establish outside deadlines for breach notification, but a covered entity may need contractual notice much sooner to investigate, preserve evidence, make its own legal determination, and coordinate other laws. Define what the vendor must report, when the clock begins, required initial information, update cadence, cooperation, and responsibility for notices. Do not use “security incident” and “breach” interchangeably without explaining the different response paths.

Use the security exhibit to convert promises into controls

The HIPAA Security Rule requires appropriate administrative, physical, and technical safeguards for electronic PHI. A security exhibit can translate that standard into contractually testable commitments: access control, multifactor authentication, encryption, logging, vulnerability management, backups, incident response, workforce security, secure development, and independent assessments. The exact controls should reflect the service, data sensitivity, and deployment model rather than a copied questionnaire.

Avoid vague commitments such as “industry standard security” when the parties already know which controls matter. At the same time, do not freeze obsolete technical details unnecessarily. Use outcome-based requirements where technology changes quickly and specific controls where failure would be material. If a provider proposes exceptions, record them and decide whether compensating controls are sufficient before signature.

Control subcontractors through both diligence and contract

A vendor may rely on cloud hosting, support providers, analytics tools, AI services, and offshore teams. The data terms should say when subcontractors can be used, what obligations flow down, whether a current list is available, what notice is required for changes, and what rights the customer has if a new subcontractor creates unacceptable risk. For HIPAA business associates, subcontractors that create, receive, maintain, or transmit PHI on the business associate’s behalf must be subject to the same applicable restrictions and conditions.

Do not treat a subprocessor list as the whole control. Review where data is hosted, whether the subcontractor can use data for its own purposes, whether cross-border transfers are implicated, and whether deletion propagates through the chain. If the vendor cannot identify material subprocessors for a critical service, the customer does not yet have a complete data-flow picture.

Align retention, return, and deletion across the stack

Termination language frequently conflicts. The MSA may say the provider can delete data immediately after termination, the DPA may promise return on request, the BAA may require return or destruction where feasible, and product documentation may describe a thirty-day recovery window. Reconcile these provisions so the business knows how to export data, how long access remains available, when deletion begins, what backups retain, and what certification is available.

Also address retention during the relationship. A provider should not retain sensitive data indefinitely merely because the contract is active. Tie retention to service need, legal requirements, and documented customer instructions. For systems that create logs, analytics, or AI-derived records, state whether those artifacts are customer data, whether they can be de-identified, and what happens to them when the underlying account closes.

Put audit rights on a realistic evidence ladder

Unlimited onsite audit rights are often impractical, while a promise to provide “information upon request” may be too weak. Build an evidence ladder: current independent assessment or certification, penetration-test summary, security questionnaire, remediation information, and then targeted audit rights if those materials reveal a significant gap or a material incident occurs. The customer should be able to verify commitments without turning routine diligence into a full forensic examination.

For regulated customers, preserve rights needed to respond to regulators and auditors. The BAA already requires making certain internal practices, books, and records available to HHS for HIPAA compliance review. Contractual cooperation should also address customer examinations, evidence preservation, and reasonable regulator inquiries. Keep the clauses specific enough that the vendor knows what cooperation means before an urgent request arrives.

Reconcile liability with the data obligations

A carefully drafted security exhibit can be economically hollow if the MSA subjects every claim to a small general liability cap and excludes the very response costs most likely to occur. Map privacy, confidentiality, security, and BAA obligations to the limitation-of-liability and indemnity sections. Decide whether those risks sit inside the general cap, a higher super-cap, or a specific indemnity, and whether defense costs consume the cap.

The answer should reflect control, insurance, deal size, data sensitivity, and realistic loss. It should also be consistent across documents. If the DPA says data breaches are subject to a special cap but the BAA says the business associate will indemnify “notwithstanding any limitation,” the stack contains a dispute waiting to happen. Resolve the economics before signature, not after an incident.

Treat AI and product-improvement rights as a separate decision

Modern vendor forms increasingly reserve rights to use customer interactions, prompts, outputs, telemetry, or de-identified information to train models or improve products. Do not let those rights hide inside broad “service improvement” language. Identify exactly what information can be used, whether personal information or PHI is excluded, what de-identification standard applies, whether opt-out is available, and whether subcontracted AI providers receive the same restrictions.

For regulated information, the correct answer may be no secondary use at all unless separately authorized. For lower-risk telemetry, a limited improvement right may be reasonable. The key is intentionality. A DPA focused on statutory processor terms does not automatically resolve model-training, intellectual-property, confidentiality, or product-development questions.

Close with a document-to-control matrix

Before signature, create a matrix with rows for data categories, permitted use, security, incident response, subprocessors, audit, retention, deletion, individual rights, regulator cooperation, AI use, indemnity, and liability. Put the controlling document and section in each row. Any blank or conflicting row requires resolution. The matrix becomes a practical reference for procurement, security, privacy, and operations after the negotiation ends.

A coherent data stack should let the company answer basic questions without rereading six documents during an incident: what data the vendor has, what it may do with the data, what security it promised, how fast it must report an event, who its subprocessors are, what happens at termination, and what remedies apply if the promises fail. That is the difference between contract volume and contract architecture.