Applied Legal
Contract Playbooks11 min read

NDA, MSA, DPA: What Actually Gets Negotiated

Most of a commercial agreement never moves. These are the clauses that do, on NDAs, MSAs, and DPAs, with sensible default positions and the fallbacks worth having ready.

NDAMSADPANegotiationLimitation of LiabilityData Protection
Illustration for “NDA, MSA, DPA: What Actually Gets Negotiated”
On this page→

Every commercial agreement looks long, and most of it never changes. Notices clauses, counterparts, headings, severability: these are rarely the reason a deal stalls. The time goes into a short list of terms that allocate money and risk, and that list is remarkably consistent from one deal to the next.

This piece walks through that short list for the three documents growing companies see most: the NDA (non-disclosure agreement), the MSA (master services agreement, the framework that governs an ongoing customer or vendor relationship), and the DPA (data processing agreement, which governs how one party handles personal data on the other's behalf). For each clause you will find a sensible default position and a fallback. Think of it as the first draft of a playbook.

How to read the defaults

Every position below assumes you are a reasonably sized company negotiating with a peer, not a startup signing a large enterprise's paper with no leverage, and not a large company dictating terms to a small vendor. Adjust for leverage.

Also note which side you are on. Many positions flip depending on whether you are the provider (you deliver the service and receive payment) or the customer (you buy the service). Where that matters, it is called out.

NDAs: four clauses that move

NDAs are the highest-volume agreement most companies sign and the easiest to over-lawyer. Mutual NDAs on balanced terms should take minutes, not days. These four clauses are where the real differences are.

1. Definition of confidential information

What moves: whether information must be marked confidential to be protected, and how broad the catch-all is.

  • Default: information is confidential if it is marked, or if a reasonable person would understand it to be confidential given its nature and the circumstances of disclosure.
  • Fallback: marking required for written information; oral disclosures protected if identified as confidential at the time and summarized in writing within a set period (thirty days is common).
  • Watch for: a definition so broad it covers anything you ever learn about the other party, with no standard exclusions. The standard exclusions (already known, publicly available, independently developed, received from a third party without restriction) should always be there.

2. Term and survival

What moves: how long the NDA lasts and how long the confidentiality obligation survives after it ends.

  • Default: a disclosure period of one to two years, with confidentiality obligations surviving two to five years after disclosure.
  • Fallback: a longer survival period is usually easy to accept.
  • Watch for: trade secrets. A fixed survival period can be a problem for information that is valuable precisely because it stays secret. The common fix is to protect trade secrets for as long as they remain trade secrets under applicable law.

3. Residuals

What moves: a residuals clause lets the receiving party use ideas and know-how retained in the unaided memory of its people. It is common in NDAs written by large technology companies.

  • Default (as discloser): delete it.
  • Fallback: accept it only if it excludes trade secrets and the disclosing party's patents and copyrights, and only covers information retained without intentionally memorizing it for later use.
  • Watch for: residuals in an NDA with a potential competitor or acquirer. That is where it matters most.

4. Non-solicitation

What moves: whether either party may recruit the other's people during and after the relationship.

  • Default: no non-solicit in an NDA. It is not what the agreement is for.
  • Fallback: a mutual, short (twelve months is typical) restriction on actively soliciting employees the party worked with, with carve-outs for general job postings and for people who approach you on their own.
  • Texas note: Texas courts generally analyze restrictions like this under the state's covenant-not-to-compete statute in the Business and Commerce Code, which requires a restriction to be ancillary to an otherwise enforceable agreement and reasonable in time, geography, and scope of activity. A narrow, mutual, time-limited restriction is far more likely to hold up than a broad one.

MSAs: five clauses that move

An MSA usually runs ten to thirty pages. Most of the negotiation lands on five clauses. If your team knows its position on these, the rest of the document is usually clean-up.

1. Limitation of liability

The single most negotiated clause in commercial contracts. It has two parts: the cap (the maximum either party pays) and the exclusions (types of damages, usually indirect and consequential, that neither party pays at all), plus the carve-outs from both.

  • Default: mutual cap at the fees paid or payable in the twelve months before the claim. Mutual exclusion of indirect, consequential, special, and punitive damages and lost profits.
  • Common carve-outs (uncapped or separately capped): indemnification obligations, breach of confidentiality, a party's gross negligence or willful misconduct, and the customer's payment obligations.
  • Fallback: a "super cap" for data and confidentiality breaches (often a multiple of the general cap) rather than unlimited liability. This is frequently where large customers and small providers meet.
  • Watch for: a cap that is mutual on paper but one-sided in practice, for example a cap tied to "fees paid" when only one side pays fees.

2. Indemnity

An indemnity is a promise to cover the other party's losses from specific third-party claims. It is a risk transfer, so it should track risks each party actually controls.

  • Default (provider): you indemnify the customer against third-party claims that your service infringes intellectual property, with the usual remedies (modify, replace, or refund) and exclusions (customer modifications, combinations you did not provide).
  • Default (customer): the customer indemnifies you against claims arising from its data or its use of the service in violation of the agreement.
  • Fallback: add mutual indemnities for third-party claims of death, bodily harm, or property damage caused by a party's negligence.
  • Texas note: Texas courts apply "fair notice" requirements to indemnities that cover the indemnified party's own negligence. The agreement must say so expressly, and the language must be conspicuous. If an indemnity is meant to reach that far, draft it deliberately.

3. Intellectual property ownership

  • Default (provider): you own your platform, pre-existing materials, and improvements; the customer owns its data and the deliverables created specifically for it, if any; the customer grants you a license to use its data to provide the service.
  • Fallback: if the customer insists on owning custom deliverables, carve out your underlying tools and general know-how, and take back a license to reuse non-customer-specific components.
  • Watch for: feedback clauses, aggregated or de-identified data rights, and any language that assigns you "all work product." Each one should be a deliberate choice.

4. Term and termination

  • Default: an initial term with renewal for successive one-year periods unless either party gives notice (thirty to sixty days is common); termination for material breach after a cure period (thirty days); termination for insolvency.
  • Fallback (customer side): termination for convenience on notice, often with a refund of prepaid unused fees.
  • Watch for: long non-renewal windows (ninety days or more) that are easy to miss, and termination rights that do not address what happens to data and transition assistance.

5. Payment

  • Default (provider): annual in advance or monthly, net thirty, late fees at a stated rate, the right to suspend service after notice for undisputed overdue amounts.
  • Fallback: net forty-five or net sixty for large customers with a reliable payment history; a good-faith dispute process that pauses late fees on disputed amounts.
  • Watch for: price increase caps on renewal, most-favored-customer clauses, and set-off rights that let the customer withhold payment against unrelated claims.

DPAs: six clauses that move

DPAs are often presented as non-negotiable forms. Many terms are dictated by law, but the commercial parts move, and they deserve attention because a data incident is one of the most expensive things that can happen under any agreement.

1. Roles

Data protection laws distinguish between the party that decides why and how personal data is processed (the controller, or "business" under some U.S. state laws) and the party that processes it on that party's instructions (the processor, or "service provider").

  • Default: the customer is the controller; the provider is the processor and processes only on documented instructions.
  • Watch for: any use of customer personal data for the provider's own purposes, such as product improvement or analytics. That may make the provider a controller for that processing and should be addressed expressly.
  • Texas note: the Texas Data Privacy and Security Act requires a contract between a controller and a processor that covers specific points, including processing instructions, confidentiality, deletion or return of data, and conditions for engaging subcontractors. Check that a DPA covering Texas residents' data addresses each of them.

2. Subprocessors

  • Default (provider): a published list of subprocessors, advance notice of new ones, and a right for the customer to object on reasonable data-protection grounds.
  • Fallback: if the customer objects and no workaround exists, the customer may terminate the affected service with a refund of prepaid unused fees.
  • Watch for: a requirement that the customer approve every new subprocessor in advance. For most providers that is unworkable.

3. Security

  • Default: an annex describing technical and organizational measures in reasonable detail, with a commitment not to materially reduce overall security during the term.
  • Fallback: reference to a recognized framework or an independent audit report the provider already maintains.
  • Watch for: promises of specific controls the provider does not actually run. A DPA is a contract, not a marketing page.

4. Breach notice

  • Default: notice to the customer "without undue delay" after the provider becomes aware of a personal data breach, with the information the customer needs to meet its own obligations.
  • Fallback: a fixed outer limit, commonly between twenty-four and seventy-two hours. The European Union's General Data Protection Regulation (GDPR) gives controllers seventy-two hours to notify regulators in many cases, so customers subject to it often ask for a shorter window from their processors.
  • Texas note: Texas's breach-notification statute sets its own deadlines for notifying affected individuals and, above a threshold number of residents, the Texas Attorney General. Make sure the contractual window leaves the controller enough time to meet them.

5. Audit

  • Default: the provider makes available its current independent audit reports and responds to reasonable security questionnaires; on-site audits only where required by law or after a breach, at the customer's cost, on reasonable notice, and no more than once a year.
  • Fallback: a remote audit or a call with the security team in place of an on-site visit.

6. International transfers

  • Default: where personal data from the European Economic Area, the United Kingdom, or Switzerland is transferred to a country without an adequacy decision, the parties rely on an approved mechanism, typically the European Commission's Standard Contractual Clauses (with the UK addendum where relevant) or a certification under the EU–U.S. Data Privacy Framework.
  • Watch for: the wrong module of the Standard Contractual Clauses for the relationship (controller-to-processor and processor-to-processor transfers use different modules), and an annex that does not actually describe the data, purposes, and recipients.

Turning this into a playbook

Read back through the defaults and fallbacks above and you have the skeleton of a playbook: for each clause, a preferred position, an acceptable fallback, and the point at which a decision-maker gets involved. The work of a playbook is to make those choices once, write them down, and apply them every time.

That is how a contract review can be both fast and consistent. The reviewer is not rediscovering your risk appetite on every agreement; they are applying it. Our piece on what a contract review actually includes shows how those positions turn into an issues table, and Contract Systems is the service where we write the playbook with you.

If you would rather hand off the agreements entirely, talk to a lawyer and we will start with the agreements that matter most to you.

EA
EJ Archuleta

Founder of Applied Legal. Former General Counsel at technology companies, software engineer, and Texas-licensed attorney who builds and runs contract pipelines. Read the full bio →

This article is general information, not legal advice, and reading it does not create an attorney-client relationship. Applied Legal is a trade name of Archuleta Partners PLLC. Responsible attorney: EJ Archuleta.

Next step

Send the contract. Get back finished work.

Tell us which agreements you handle and roughly how many arrive each month. The next step is a short scoping call, and you see the fixed fee before any work starts.