By David W. Tollen, attorney and trainer\/founder at Tech Contracts Academy\nTech buyers often misunderstand contract terms about data. So they don\u2019t 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: \u201cAsk better questions.\u201d This article offers questions you should ask about your data\u2014questions for your lawyer, contract manager, vendor, or for yourself.\n1. Does the contract say we own our data? How useful is that?\nMost cloud contracts confirm your ownership of data in loud and clear language: \u201cCustomer owns all right, title, and interest in the Data.\u201d That\u2019s great, and you do want those terms. But when it comes to data, ownership isn\u2019t all it\u2019s cracked up to be.\nModern industry has a bad habit of calling information \u201cintellectual property\u201d\u2014as if someone could own it. The truth is, you can\u2019t really own information. IP law is complex, and it\u2019s 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\u2014no data \u201cownership\u201d\u2014will empower you to keep other companies from using the bulk of your data. So once you\u2019ve confirmed ownership, focus on control\u2014addressed in questions 2 and 3 below.\n2. What rights does the contract give us to access and manage our data? What does it say about third-party lawsuits\u2014about e-discovery?\nIdeally, 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\u2019ll enjoy far greater control if you can copy the data and put it on your own computers\u2014whenever you want. (Among other issues, you\u2019ll already have the data if the vendor goes bankrupt and can\u2019t be forced to provide it.) That\u2019s not always technically possible, but get it where you can.\nControl 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.\nFirst, if you don\u2019t have a copy of the data, the other party could subpoena the vendor. That means the vendor decides what to give your opponent: what\u2019s relevant, what\u2019s protected by a privilege, and so on. You want your lawyers making those choices.\nSecond, if your vendor deletes relevant data (as part of a data cleanup process, for instance), the court might fine you\u2014a lot.\nAll that means you want control over e-discovery. \u201cIn 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\u2019s E-Discovery Policy. Except as permitted in such policy, Vendor shall not erase Data, or any copy thereof, without Customer\u2019s prior written consent.\u201d Terms like these won\u2019t fit all cloud deals, and you might have to pay extra. But again, get them if you can.\nAre you asking the right questions about cloud computing contracts? Register for a live webinar with David Tollen and Rimini Street on June 14th. \n3. How does the contract restrict the vendor\u2019s use of our data? What does it say, if anything, about anonymized and aggregate data?\nThe simplest, most customer-friendly restriction lets the vendor use the data for one purpose: \u201cVendor shall not access or use the Data other than as necessary to provide the Services to Customer.\u201d Many cloud vendors offer exactly that.\nSome vendors want to use your data for their own purposes. Some even resell it. These vendors usually request \u201canonymized data.\u201d Here\u2019s a typical definition: \u201c\u2018Anonymized Data\u2019 refers to the Data with the following removed: all personally identifiable information and all information that can be used to distinguish or trace Customer\u2019s or another company\u2019s identity, such its name, tax identification number, telephone numbers, credit card numbers, or addresses (\u2018Company Information\u2019).\u201d\nBut that definition doesn\u2019t say whether the data gets fully anonymized or just \u201cde-identified.\u201d 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. \u201c\u2018Anonymized Data\u2019 refers to the Data with personally identifiable information and Company Information removed so that it cannot be recovered.\u201d Or, \u201c\u2018Anonymized Data\u2019 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.\u201d If you give your vendor continuing rights to data, you\u2019re safest with true anonymization.\nMany vendors also ask for \u201caggregate\u201d or \u201cderived\u201d 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\u2019re safest if the aggregate\/derived data qualifies as fully anonymized\u2014if it has no personally identifiable information from the original data set.\nFinally, consider trying to regulate where your data can be stored. \u201cVendor shall not transfer the Data or any copy or part thereof outside the United States [or European Union, Australia, etc.].\u201d 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.\n4. What does the vendor promise about keeping our data safe and keeping us on the right side of privacy law?\nData 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.\nWhat 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.\nDoes the vendor promise criminal background checks on staff who get data access? And does that include employees of the vendor\u2019s subcontractors?\u00a0\nDoes 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\u2019s performance over a defined period, like the whole year, as opposed to a snapshot in time (which you get in a Type 1).\nDoes 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.\nDoes the vendor promise to comply with privacy laws, particularly GDPR? The EU\u2019s General Data Protection Regulation impacts most companies that handle European consumers\u2019 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\u2019re liable for your vendor\u2019s failure to comply, particularly if you had only weak contract terms.\n5. Is the vendor responsible\u2014and liable\u2014for data management by its vendors?\nMany 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\u2019s not good for you\u2014particularly since you probably have no contract with the third-party vendor.\nYou\u2019ll 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\u2019t visible to you: for companies that provide tech support, maintenance, or other services to the vendor. But if you chose the third party\u2014if you asked for services on Salesforce\u2019s platform, for instance\u2014your vendor will probably argue that you accepted the risk of third-party-vendor errors.\nIn 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.\n6. Does the vendor indemnify us for data breach?\nCloud 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?\nYou can\u2019t 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\u2019s at fault, or they might disagree. (Contrast that with IP indemnities, where the vendor defends claims regardless of fault. It\u2019s the vendor\u2019s product, and customer wrongdoing generally can\u2019t trigger an IP claim, so fault doesn\u2019t matter\u2014though that rule has some exceptions.)\nVendors also resist data breach indemnities because the liability could be huge.\nMy 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.\nKeep in mind that \u201cno indemnity\u201d does not mean \u201cno liability.\u201d If the contract has good data security terms, a data breach might count as a contract breach. The vendor is liable; you just don\u2019t get a defense against third-party claims.\nEven if you can\u2019t get a full data breach indemnity, you might get an indemnity about anonymized data. \u201cVendor shall defend, indemnify, and hold harmless Customer against any third-party claim arising out of or related to Vendor\u2019s use or misuse of the Anonymized Data, including without limitation any claim that personally identifiable information was discovered using Anonymized Data.\u201d\n7. Aside from signing a contract, what are we doing to make sure our data is safe in the vendor\u2019s hands?\nContracts are no substitute for due diligence. Have we really vetted this vendor\u2019s data security systems? Have we researched other customers\u2019 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\u2019t protect you much if the vendor goes bankrupt at the first sign of trouble.\nFor more on big data deals, see The Big Data Licensing Issue-Spotter. And for data security clauses, see the sample terms here, in part II-H.\nAre you asking the right questions about cloud computing contracts? Tune in for the on-demand webinar with tech contracts attorney David Tollen, hosted by Rimini Street.\n_____________________________________\nAbout David W. Tollen\n\nDavid W. Tollen is the author of the American Bar Association\u2019s bestseller, The Tech Contracts Handbook, Cloud Computing Agreements, Software Licenses, and Other IT Contracts for Lawyers and Businesspeople (ABA Publishing 2015). He is an attorney and expert witness and also the founder of Tech Contracts Academy, where he trains businesspeople and lawyers to draft and negotiate IT contracts. David practices law with Sycamore Legal, P.C. in San Francisco, representing buyers and sellers of information technology.\nNo 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.