When one party has to protect information belonging to the other, we tend to pull out a nondisclosure agreement: an NDA. Or if we don’t want a separate NDA, we add the NDA’s key provisions to our tech contract as a confidentiality or nondisclosure clause. That makes sense if we’re trying to protect trade secrets and the like: source code, customer lists, secret sauce, etc. Lawyers of the olden days designed NDA’s for exactly that purpose. But what if we’re protecting private information, like social security numbers, health records, or credit card numbers? The NDA’s creators didn’t have private information in mind, and NDA’s don’t protect them well. Nor do NDA’s work for data in electronic form — which is how most private information gets stored, along with a lot of other sensitive data. Large stores of electronic information call for a newer creature: the data security clause.

Like NDA’s, data security clauses generally prohibit intentional disclosure of sensitive information. But the similarities end there, and in fact three key differences create a chasm between the two:

1. Confidential Information vs. Electronic Data: A typical NDA or nondisclosure clause protects only a limited body of information. The “Confidential Information” definition might cover documents marked “confidential,” for instance, or defined types of information, like customer lists or source code. That makes sense for business secrets. But in a database holding mountains of information, you can’t separate the sensitive data from the rest. It’s not grouped into sensitive and non-sensitive documents. So the recipient has to protect everything: the whole database. That’s why information security clauses address broad swaths of data — like “all Company’s information in electronic form” — rather than well-defined “Confidential Information.” Also NDA’s generally exclude certain information from the “Confidential Information” definition. They don’t protect information already in the recipient’s hands at the start of the relationship, information received from third parties without an NDA, or information already exposed to the public. Again, that makes sense for business secrets, but it doesn’t work for private data. If you’re sitting on consumer social security numbers, you’ve got to protect them no matter where you got them and no matter what anyone else has done with them. That’s why data security clauses have no such exclusions.

2. Focus on Nondisclosure vs. Focus on Security: NDA’s and confidentiality clauses focus on nondisclosure. An NDA says, first and foremost: don’t (intentionally) disclose the information to third parties. It says nothing about efforts to prevent accidental disclosure or theft — except possibly, “Recipient will protect the Confidential Information with the same degree of care it uses to protect is own information of similar nature, but no less than reasonable care.” Data security clauses, on the other hand, focus on security. They require protections like encryption, locked cabinets, and passwords, and sometimes employee background checks, SAS-70 (or SSAE-16) audits, and reporting of leaks. Data security clauses also tend to require compliance with company privacy policies and with government regulations, like FTC, HIPPA, and GLBA rules.*

3. Duration of Obligations: Most tech-related NDA’s and nondisclosure clauses expire. After eighteen months or three years or whatever, the recipient can stop worrying about keeping the Confidential Information quiet. That’s because most business secrets lose their value over time in the IT world. But private data remains sensitive — not to mention legally protected — indefinitely. Plus, you often don’t know what’s on a corporate database, so even if you don’t think it includes private information, you may not now when it’ll lose its sensitive status. That’s why data security clauses generally have no end-dates (though in many cases the recipient can eventually reduce the burden by returning the data and deleting all copies).

Of course, you can address all of these issues by revising your NDA or nondisclosure clause: by adding data security provisions and removing inappropriate NDA provisions. But that’s a lot of work. Why not just start with a form that fits your needs? Also, by carving up your NDA, you’ll ruin it for its intended purpose: protection of business secrets. In many deals, you need to protect both business secrets and electronic data, and as we’ve seen, they call for different measures. One of the parties gets the other’s customer lists and source code, for instance, as well as access to its databases. In those deals, you need both clauses. You’ll draft clearer and more effective contracts if each clause serves its intended and separate purpose.

You may find it difficult to locate sample data security clauses because they’re newer and they vary more. Search on terms like “data security,” “information security,” and “privacy protection” in your favorite contracts database. And have a look at the “Data Management and Security” clause at the Tech Contracts Academy contracts forms page — as well as at the data security chapter in The Tech Contracts Handbook.

Notes:

• The Tech Contracts Handbook addresses NDA’s in Chapter II.G and data security clauses in Chapter II.H.
• FTC, HIPPA, and GLBA stand for Federal Trade Commission, Health Information Portability and Accountability Act, and Gramm-Leach-Bliley Act, respectively.

This article was updated in 2020 to refer and link to the 2nd (current) edition of The Tech Contracts Handbook.

Thank you to Pixabay.com for great, free stock images!

© 2011 by David W. Tollen. All rights reserved.