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, most or all customer data sits on the customer’s own computers. So the customer faces less risk related to data, at least from the provider’s 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. And applicable privacy laws may apply to those deals, even though the provider never puts the data on its own computers. (See bullet 2 below.) 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. Terms Required by Privacy & Security Laws: Some laws on privacy require specific contract terms between the customer and any provider holding or accessing data (any “processor” under typical language). 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’ impact to the data covered by the statute. For instance: “The provisions of Attachment B (GDPR DPA) apply solely to data from subjects in the member-nations of the European Union, governed by GDPR, and not to any other Customer Data.“
3. NDAs: Don’t use a nondisclosure agreement (NDA) or confidentiality terms to protect data. Those clauses are designed for confidential documents and trade secrets, not for the data at issue in IT deals.
4. 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 doesn’t. So customer “ownership” of may not keep the provider from exploiting the data for its own purposes, including by mining it. 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 confirm that the data could include trade secrets. And it should try to establish “compilation copyright” ownership: a weak IP right that might protect the compilation of data, though not any piece of information. The following magic language tries to achieve both: “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. Those sorts of terms provide far better protection than “ownership.” (For language on ownership and related issues, see our clause library’s data definition and rights terms.)
5. Data License/Use: The contract should specify how the provider can use the data—sometimes called the “data license.” Many 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 include 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 see our clause library’s sample terms on use and disclosure.)[*]
6. 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 becomes 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 quickly, 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 ask for contract terms giving the the right to put a “litigation hold” on data deletion. (See our clause library’s sample terms on access and deletion.)
7. Data Security: Security terms address steps the vendor takes to ensure protection of the data. The heart of the clause covers technical security: 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. (See our clause library’s sample tersm on data security.)
8. 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. 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. (See our clause library’s audit and testing terms.)
9. Data Breach Response: Data breach terms address notice and cooperation in case of an incident. They usually put a deadline on telling the customer about 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: sometimes a time-consuming and expensive process. Finally, data breach terms may require that the provider, if responsible for the breach, compensate injured consumers—e.g., by giving each a year of credit monitoring. (See our clause library’s sample terms on data incidents.)
10. Incorporating Privacy Policies: Each party should try not to incorporate its privacy policy into the contract. In other words, avoid terms like, “Party X shall comply with its Privacy Policy.” A privacy policy is not a contract document; it’s an announcement to the public. By incorporating the policy into your contract, you add breach of contract to the many legal troubles you could face for violating the policy. (And keep in mind, you could violate the policy without meaning to.) Plus, incorporating the privacy policy into your contract could limit your ability to modify the policy. Yet changes in law or in your data management practices could demand a modification. Why restrict that right? Often, it’s the customer who asks for terms incorporating the provider’s privacy policy into the contract. But if the contract includes reasonable terms protecting customer data, like those above, that shouldn’t be necessary. Plus, the provider’s privacy policy doesn’t need help from the customer or its contract. It doesn’t need a contract to give it teeth. The law already imposes consequences on companies that violate their privacy policies.

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).

You can also learn more by attending one of our trainings. Please visit our Training Page. Options include the Tech Contracts Master Classes™ (January 2023 series here: https://www.techcontracts.com/product/tech-contracts-master-class-jan-2023/. 2 hours CA CLE available per class, 8 hours for the series], webinars, and customized in-house training.

[*] 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.

~   ~   ~

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

This post updates an earlier version, dated Nov. 3, 2021.

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