A little more than twenty years ago, the legal community began to recognize that nondisclosure terms don’t work for data protection. NDAs and nondisclosure provisions protect trade secrets, not the customer data in vendor cloud systems (SaaS, AI, etc.). The latter type of information demands a data management and security clause, not an NDA, possibly including a data protection agreement/attachment (DPA). That conclusion, however, still hasn’t reached everyone. And even among those who recognize the issue, confusion reigns over the edge cases. We’re often not sure which clause to use for information that arguably falls into both categories: trade secret and electronic data. I’ve given this a lot of thought, and this article shares my conclusions.

Why don’t nondisclosure terms work for data?
Nondisclosure terms don’t work for data because of the following.
- Loss of Protection: Under typical NDAs, confidential information loses protection if it’s (a) already in the recipient’s possession, (b) independently generated, (c) received from a third party without confidentiality obligations; or (d) known to the public. None of those should excuse protection of customer data in a deal for SaaS, artificial intelligence, or other cloud offerings, particularly if it includes personally identifiable information (PII).
- Expiration of Protection: Nondisclosure obligations expire in many agreements. Obligations to protect data never should – again, particularly PII. (Expiring NDAs have their own problems, by the way.)
- Inadequate Security Requirements: Nondisclosure terms generally include little detail about how to protect data. Most just say something like: “Recipient shall protect Confidential Information with the same degree of care it uses to protect its own information of similar sensitivity but in no event less than reasonable care.” That’s not enough for most data, particularly PII. Data clauses usually include technical and administrative requirements, sometimes quite detailed.
- No LoL for Nondisclosure: Limits of liability usually don’t apply to nondisclosure, but vendors almost never accept unlimited liability for data.
Of course, you could edit your NDA to address each of these issues, but then you’ve created a data management clause. Why not just start with a form intended drafted for that purpose?
Vague but useful general rule: use NDAs for trade secrets and data management/security for electronic data
In general, you should use nondisclosure terms for trade secrets and similar sensitive business information: source code, customer lists, secret recipes, strategy documents, etc. And you should use data management/security terms for information in electronic form – the “Customer Data” in most AI, SaaS, and other cloud deals – where the recipient processes the information or at least could access it.
That dividing line, however, isn’t perfectly clear.
Needs-based choice
Choosing NDA/nondisclosure
If in doubt, use nondisclosure terms when they provide the security you think the information needs, despite their lower levels of protection and their various exceptions. For example, should your recipient have the right to share an item of information if an uninvolved third party provided it? If so, nondisclosure works. Or should the recipient have the right to share the information if it becomes publicly known (through no fault of the recipient)? If yes, an NDA again should do the trick. In both cases, the answer should be “yes” for trade secrets. Trade secret protection does not demand that the recipient protect information from an uninvolved third party or information that’s already public.
A third example: would “reasonable care” to protect the information be enough? Are you legally free to accept reasonable care, for instance, because no law demands more? If so, you probably want an NDA. Of course, you could have trade secrets that demand higher levels of security. Even then, an NDA probably does the trick if you don’t need the other higher levels of protection in data management/security terms. You can just add extra information protection details to your NDA.
To put it another way, if issues 1 through 3 above don’t trouble you, an NDA should work.
Choosing data management/security
If leakage of information would impact privacy rights, you need a data management/security clause, probably including a DPA. That’s particularly important for the vendor, due to issue 4 above.
Slicing it another way, do you need the information protected even if it was provided or generated without discloser involvement – or even if it’s already public? Then you probably need data management/security terms.
Does the law requires special terms about protecting the information, for the benefit of third parties? Again, you need data management/security terms.
Information in both camps
Some deals define “Confidential Information” to include all Customer Data – so both the NDA and data terms cover that information. That’s usually a bad idea. The discloser doesn’t need NDA terms because data terms already say, “don’t disclose” (and more). And the recipient doesn’t want unlimited liability for data incidents, which usually comes along with nondisclosure. Also, the recipient needs traditional NDA exceptions for trade secrets, per items 1 through 3 above, but most data clauses lack those terms.
Double protection only makes sense for trade secrets included in customer data. The electronic data in a SaaS/cloud deal could include source code, customer lists, etc., in among the PII and other data on the vendor’s servers. In that case, yes, you could apply both nondisclosure and data terms to the same information.
Doing so, however, creates problems for each party. The clause below should solve most of them:
“Double-Protect Information” is Confidential Information that is also Customer Data. The following are governed by Section X (Nondisclosure) and not by Section Y (Data Management and Security): (1) Recipient’s liability for breach of this Agreement leading to exposure of Double-Protected Information; and (2) Recipient’s right to disclose Double-Protected Information as specifically authorized in Section X (Nondisclosure). The preceding sentence does not relieve Recipient of any obligation related to management or protection of Double-Protected Information pursuant to Section Y (Data Management and Security) or any obligation whatsoever related to other Customer Data.
What about employee NDAs?
Some tech vendors follow my rules above but still have employees sign NDAs protecting Customer Data. Among other reasons, NDAs are less intimidating than full-metal-jacket data management and security terms.
The fact that it’s an employee signing doesn’t make problems 1 through 3 above go away. So you should at least tweak the NDA to add extra protections for data. You could do that by attaching a data security policy to the NDA and having the employee promise to comply. Or you could laboriously edit the NDA to make it fit data better, e.g., by addressing all the problems listed in items 1 through 3 at the top of this article.
You can learn more from our course, Data Terms in AI and Cloud Services Contracts. It’s 1 hr. 25 min. on-demand – available on your schedule – and costs just $299.
THIS ARTICLE IS NOT LEGAL ADVICE. IT IS GENERAL IN NATURE AND MAY NOT BE SUFFICIENT FOR A SPECIFIC CONTRACTUAL, TECHNOLOGICAL, OR LEGAL PROBLEM OR DISPUTE, AND IT IS NOT PROVIDED WITH ANY GUARANTEE, WARRANTY, OR REPRESENTATION. LEGAL SITUATIONS VARY, SO BEFORE ACTING ON ANY SUGGESTION IN THIS ARTICLE, YOU SHOULD CONSULT A QUALIFIED ATTORNEY REGARDING YOUR SPECIFIC MATTER OR NEED.
© 2025 Tech Contracts Academy, LLC