[We updated this post in November of 2022. Click here for the new version.]

Here are ten issues to consider when addressing data in IT contracts. This issue-spotter serves both customers and providers, though generally the former benefit more from data protection.

1. Type of Deal: If your contract involves cloud services (SaaS, PaaS, etc.), the provider will hold customer data. So data terms become important for the customer. On the other hand, in on-premise software and professional services contracts, the data sits on the customer’s own computers. So the customer faces less risk related to data, at least from provider actions. However, some on-premise and professional services deals give the provider behind-the-firewall access to customer data — as part of maintenance, implementation, or other services. So data concerns climb back up the priority ladder. The terms discussed below mostly relate to cloud services deals. But customers should think through the issues raised when they work on other IT deals — and assess whether to add these provisions. In many cases, providers should too.
2. NDAs: Don’t use a nondisclosure agreement (NDA) or confidentiality terms to protect data. Those clauses are designed for confidential documents and other trade secrets, not for the data at issue in IT deals.
3. Ownership of Data: Contrary to common belief, you can’t own data — at least, not in any meaningful way. Data is information, and there is no IP in information — except to the limited extent that it’s covered by trade secrets law. And while parts of a dataset might qualify for trade secret protection, probably most of it doesn’t. So customer “ownership” of data doesn’t necessarily keep the provider from exploiting the data for its own purposes. In other words, contract terms saying the customer owns the data might not do much good. That doesn’t mean contracts should say nothing about data ownership. The customer should still confirm that it owns the data (assuming it does). The customer should also add some magic language about IP: “Provider recognizes and agrees that: (a) Customer Data is valuable property of Customer; (b) Customer Data includes Customer’s trade secrets; (c) Customer Data is an original compilation pursuant to the copyright law of the United States and other jurisdictions; and (d) Customer has dedicated substantial resources to collecting, managing, and compiling Customer Data.” Once that’s all done, the customer should focus on contract terms about data rights, like those described below. (Click here for language on ownership and related issues.)
4. Data License/Use: The contract should specify how the provider can use the data — a.k.a. the “data license.” Most cloud services contracts simply say: “Provider shall not access or use Customer Data other than as necessary to provide the Services to Customer.” In some cases, however, the provider gets broader rights. For instance, the contract might give the provider the right to analyze the data to improve its own products and services. (If so, the customer should make sure that doesn’t including sharing the data with third parties — or mining it.) And many contracts give the provider rights to “de-identified” or “aggregate data.” The former refers to data with all personal information (PI) removed. The latter refers to a collection of all the provider’s customers’ data — aggregated — again with PI removed. Providers should try to get de-identified/aggregate data whenever possible, since it’s often valuable. And customers should be aware of industry terms surrounding PI removal. The term “truly anonymized” generally means the PI has been removed — with no mechanism left that could be used to reconstruct or reinsert PI. Garden-variety de-identified data could include such a mechanism. For instance, the provider could replace all personal names with code numbers — and keep a ledger of those numbers and the names they replaced. That ledger could be used later to reconstruct the data: to reinsert PI. Obviously, customers face left risk if no such reconstruction mechanism survives. (Don’t rely on industry terms like “truly anonymized.” Define them in your contract. And click here for sample terms.)[*]
5. Access and E-Discovery: Customers often need access to data hosted by the provider, outside the provider’s SaaS or other system. They need a data download. The customer might also need “deconversion” of the data, translating it into a format the customer’s computers can use. Often, providers charge for deconversion and other data transfer services, since they eat up provider resources. Either way, getting the data into the customer’s hands has an advantage related to e-discovery. Imagine the customer gets into a lawsuit with a third party, and customer data on provider computers is discoverable. If only the provider has the data, the customer’s opponent might subpoena the provider to hand it over. That’s bad for the customer, since it wants to control discovery. It wants to make its own choices about what to hand over — what’s relevant, privileged, etc. And it’s bad for the provider, since it’s forced to spend time and money addressing the suit. But if the customer has a copy of the data or can get one, the court probably won’t issue a subpoena. There’s no reason to bring a third party into discovery if the customer has all the discoverable information. Finally, e-discovery raises a separate issue. If the provider erases discoverable customer data after the customer knows about the suit, the court might fine the customer — even if the provider erased as part of routine data deletion. So customers should seek contractual authority to put a “litigation hold” on data deletion. (Click here for sample language.)
6. Data Security: Security terms address steps the vendor takes to ensure protection of the data. The heart of the clause addresses technical security measures: encryption and the like. Lawyers and contract managers generally don’t write those terms, but we certainly can and should edit them for clarity and breadth. Data security terms also address employee and subcontractor access (e.g., “need to know”). And they address any requirements for background checks. (Click here for sample language.)
7. Audits: Third party audits give customers some of their best data-related protections. The provider hires a security expert to review its systems and provide a report card on data protection. For cloud services, the U.S. gold standard is the “SOC 2, Type II” report. “SOC” refers to the Service Organization Control standard put out by the American Institute of Certified Public Accountants (AICPA). And the Type 2 report — another AICPA term — covers performance during some period, like a year.[†] AICPA puts out other standards, and there are alternative certifying organizations. So the IT team should assess which report fits best. (Click here for sample language.)
8. Terms Required by Privacy & Security Laws: Some laws on privacy require specific contract terms between the customer and any provider holding or accessing data. Providers should consider putting those terms in a separate attachment. I call that a “special terms addendum.” That way, you can more easily limit those terms’ role. You can limit the required obligations to the data covered by the statute. For instance: “The provisions of Attachment B (GDPR DPA) apply solely to Personal Data governed by the GDPR, and not to any other Customer Data.”
9. Privacy & Security Compliance in General: Most cloud services contracts include privacy-related terms not specifically required by law. Those terms can cover any number of topics, including rules for handling consumer demands (e.g., “right to know,” “right to be forgotten”), restrictions on moving data, and provider promises to comply with applicable law. Providers for their part should try to limit these promises. Note in particular that few laws require that anyone promise to obey the law — in a contract or otherwise. The provider will already be in trouble if it violates a law. Adding contract terms on the subject just adds breach of contract claims to those troubles. So providers should avoid promising compliance if they can.
10. Data Breach Response: Data breach terms address notice and cooperation in case of an incident. They usually put a deadline on informing the customer of a data breach. They also generally require that the provider, or each party, cooperate with law enforcement. And some govern who takes responsibility for informing injured consumers: a time-consuming and expensive process in a big breach. Finally, data breach terms sometime require that the provider compensate injured consumers — e.g., by providing each with a year of credit monitoring. (Click here for sample terms.)

You can learn more from The Tech Contracts Handbook: Software Licenses, Cloud Computing Agreements, and Other IT Contracts for Lawyers and Businesspeople, 3^rd ed., by David W. Tollen (ABA Publishing 2021).

Want to do tech contracts better, faster, and with more confidence? Check out our training offerings here: https://www.techcontracts.com/training/. Tech Contracts Academy® has  options to fit every need and schedule: Comprehensive Tech Contracts Master Classes™ (four on-line classes, two hours each), topical webinars (typically about an hour), customized in-house training (for just your team). David Tollen is the founder of Tech Contracts Academy and our primary trainer. An attorney and also the founder of Sycamore Legal®, P.C., a boutique IT, IP, and privacy law firm in the San Francisco Bay Area, he also serves as an expert witness in litigation about software licenses, cloud computing agreements, and other IT contracts.

[*] The California Consumer Privacy Act (CCPA) muddies the water by using “de-identified” the way the industry generally uses “truly anonymized.” That’s all the more reason to define your terms in the contract.

[†] “SSAE-18” stands for Statement of Standards for Attestation Engagements number 18. That’s an AICAP standard for conducting SOC audits.

© 2021, 2022 by Tech Contracts Academy, LLC. All rights reserved.

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