Every CIO wants to deliver value to the business, with infrastructure and applications moving to the cloud, improved user experiences, and security that scales across their hybrid environments. Yet, limited resources, constrained budgets and risk of upsetting the status-quo can get in the way. These assets address why CIOs should think about risk differently, how to move IT funding around to make the greatest impact, and why 3rd party support is on the CIO’s agenda.
Protecting Your Data in Enterprise Cloud Computing Agreements
This is a guest post by David W. Tollen, attorney and trainer/founder at Tech Contracts Academy.
BrandPosts are written and edited by members of our sponsor community. BrandPosts create an opportunity for an individual sponsor to provide insight and commentary from their point-of-view directly to our audience. The editorial team does not participate in the writing or editing of BrandPosts.
Tech buyers often misunderstand contract terms about data. So they don’t protect themselves in agreements about software-as-a-service and other types of cloud computing. I see the resulting weak contracts in my work as a lawyer, and I teach businesspeople and lawyers to do better in my courses on tech contracts. One of the key lessons is: “Ask better questions.” This article offers questions you should ask about your data—questions for your lawyer, contract manager, vendor, or for yourself.
1. Does the contract say we own our data? How useful is that?
Most cloud contracts confirm your ownership of data in loud and clear language: “Customer owns all right, title, and interest in the Data.” That’s great, and you do want those terms. But when it comes to data, ownership isn’t all it’s cracked up to be.
Modern industry has a bad habit of calling information “intellectual property”—as if someone could own it. The truth is, you can’t really own information. IP law is complex, and it’s not worth going into the details here. Suffice it to say that trade secret and copyright law may give you limited protection for some of your data. But in most cases, no form of IP—no data “ownership”—will empower you to keep other companies from using the bulk of your data. So once you’ve confirmed ownership, focus on control—addressed in questions 2 and 3 below.
2. What rights does the contract give us to access and manage our data? What does it say about third-party lawsuits—about e-discovery?
Ideally, control of your data starts with the right to access it at any time and for any reason. Many cloud contracts grant exactly that right. But you’ll enjoy far greater control if you can copy the data and put it on your own computers—whenever you want. (Among other issues, you’ll already have the data if the vendor goes bankrupt and can’t be forced to provide it.) That’s not always technically possible, but get it where you can.
Control also involves e-discovery. In a lawsuit, your opponent usually has the right to see any data relevant to the case. That creates two problems when a cloud vendor holds your data.
First, if you don’t have a copy of the data, the other party could subpoena the vendor. That means the vendor decides what to give your opponent: what’s relevant, what’s protected by a privilege, and so on. You want your lawyers making those choices.
Second, if your vendor deletes relevant data (as part of a data cleanup process, for instance), the court might fine you—a lot.
All that means you want control over e-discovery. “In response to an e-discovery notice from Customer, Vendor shall promptly give Customer copies of the Data pursuant to Attachment B (Data Sharing Procedures). Further, Vendor shall observe Customer’s E-Discovery Policy. Except as permitted in such policy, Vendor shall not erase Data, or any copy thereof, without Customer’s prior written consent.” Terms like these won’t fit all cloud deals, and you might have to pay extra. But again, get them if you can.
Are you asking the right questions about cloud computing contracts? Register for a live webinar with David Tollen and Rimini Street on June 14th.
3. How does the contract restrict the vendor’s use of our data? What does it say, if anything, about anonymized and aggregate data?
The simplest, most customer-friendly restriction lets the vendor use the data for one purpose: “Vendor shall not access or use the Data other than as necessary to provide the Services to Customer.” Many cloud vendors offer exactly that.
Some vendors want to use your data for their own purposes. Some even resell it. These vendors usually request “anonymized data.” Here’s a typical definition: “‘Anonymized Data’ refers to the Data with the following removed: all personally identifiable information and all information that can be used to distinguish or trace Customer’s or another company’s identity, such its name, tax identification number, telephone numbers, credit card numbers, or addresses (‘Company Information’).”
But that definition doesn’t say whether the data gets fully anonymized or just “de-identified.” In de-identified data, names have been removed but can be reconstructed. For instance, de-identification might replace names with code numbers, so that anyone with a list of the numbers and names could figure out which data corresponds to which person or company. True anonymization makes reconstruction impossible. “‘Anonymized Data’ refers to the Data with personally identifiable information and Company Information removed so that it cannot be recovered.” Or, “‘Anonymized Data’ refers to the Data with personally identifiable information and Company Information removed and with no code, key, or other mechanism retained by any person or entity that could be used to recover such information.” If you give your vendor continuing rights to data, you’re safest with true anonymization.
Many vendors also ask for “aggregate” or “derived” data. The former refers to summaries of data, and the latter refers to information derived by studying the data. (They overlap.) In most deals, I see no harm in granting these rights. But you’re safest if the aggregate/derived data qualifies as fully anonymized—if it has no personally identifiable information from the original data set.
Finally, consider trying to regulate where your data can be stored. “Vendor shall not transfer the Data or any copy or part thereof outside the United States [or European Union, Australia, etc.].” Territory restrictions help keep your data in a jurisdiction you trust. And certain laws (including the GDPR, discussed below) restrict cross-border transfers of sensitive data.
4. What does the vendor promise about keeping our data safe and keeping us on the right side of privacy law?
Data security is a huge topic, and we can only scratch the surface. But a scratch helps, since what you need is an issue-spotter. So here are five issue-spotting sub-questions.
What technical procedures does the contract require for protecting our data? This is the big kahuna, and it deserves as much attention as any other question here.
Does the vendor promise criminal background checks on staff who get data access? And does that include employees of the vendor’s subcontractors?
Does the vendor promise annual SOC2 or ISO 27001 data security audits? Does it promise a Type 2 report? There is no substitute for a certified audit to find out whether the vendor is living up to its promises. SOC2 defines the gold standard, alongside ISO 27001, though there are alternatives. And a Type 2 report provides a view of the vendor’s performance over a defined period, like the whole year, as opposed to a snapshot in time (which you get in a Type 1).
Does the vendor promise written data breach procedures? Ideally, those procedure include prompt notice to you and to law enforcement, best efforts to contain the leak, and cooperation on notifying injured consumers.
Does the vendor promise to comply with privacy laws, particularly GDPR? The EU’s General Data Protection Regulation impacts most companies that handle European consumers’ data, including companies outside Europe. American law imposes an alphabet soup of privacy obligations too, as do the laws of most industrialized nations. Under many laws, you’re liable for your vendor’s failure to comply, particularly if you had only weak contract terms.
5. Is the vendor responsible—and liable—for data management by its vendors?
Many cloud vendors rely on services from further cloud vendors. SaaS vendors, for instance, often host their software with Amazon Web Services (AWS), Microsoft, Salesforce, or some other platform or infrastructure host. Very often, their contracts disclaim liability for those third parties. That’s not good for you—particularly since you probably have no contract with the third-party vendor.
You’ll have an easier time arguing for liability if you had no role in choosing the third-party vendor. Most vendors accept liability for subcontractors who aren’t visible to you: for companies that provide tech support, maintenance, or other services to the vendor. But if you chose the third party—if you asked for services on Salesforce’s platform, for instance—your vendor will probably argue that you accepted the risk of third-party-vendor errors.
In some of my deals, we split the baby: the vendor accepts some liability and the customer accepts some risk. But there is no easy solution.
6. Does the vendor indemnify us for data breach?
Cloud customers are often stunned to learn their vendor offers no data breach indemnity. But the vendor community has a legitimate concern about promises to defend you in a lawsuit and to pay judgments or settlements. What if you caused the breach?
You can’t reliably solve that problem by agreeing that the vendor defends if the breach was its fault. When those injured consumers sue you, the parties might not know who’s at fault, or they might disagree. (Contrast that with IP indemnities, where the vendor defends claims regardless of fault. It’s the vendor’s product, and customer wrongdoing generally can’t trigger an IP claim, so fault doesn’t matter—though that rule has some exceptions.)
Vendors also resist data breach indemnities because the liability could be huge.
My best advice is try hard for an indemnity but recognize that it might not be possible. And you might have to limit your rights. Some vendors, for instance, will only give a data breach indemnity with a limit of liability.
Keep in mind that “no indemnity” does not mean “no liability.” If the contract has good data security terms, a data breach might count as a contract breach. The vendor is liable; you just don’t get a defense against third-party claims.
Even if you can’t get a full data breach indemnity, you might get an indemnity about anonymized data. “Vendor shall defend, indemnify, and hold harmless Customer against any third-party claim arising out of or related to Vendor’s use or misuse of the Anonymized Data, including without limitation any claim that personally identifiable information was discovered using Anonymized Data.”
7. Aside from signing a contract, what are we doing to make sure our data is safe in the vendor’s hands?
Contracts are no substitute for due diligence. Have we really vetted this vendor’s data security systems? Have we researched other customers’ experiences? And do we know if the vendor has the money to handle expensive obligations, like securing data and defending lawsuits? A great contract won’t protect you much if the vendor goes bankrupt at the first sign of trouble.
No Legal Advice. None of the information provided in this article is, nor is intended to be, legal or professional advice or a substitute for advice of an attorney or any other professional, and is not intended to be, and should not be relied upon as, legal advice.