by David W. Tollen and Nathan Leong

You’re a lawyer looking for online software and other tools to run your firm—tools like email, word processing, calendaring, timenotes, legal research, and particularly document management. You stumble across a great suite of tools from a reputable company and sign up. You love your new powers; now you’re in the 21^st Century. But one day you glance at your provider’s terms of service. Most of it’s pretty innocuous, but then you read the following:

“When you upload … content to or through our Services, you give us (and those we work with) a worldwide license to use, host, store, reproduce, modify, create derivative works …, communicate, publish, publicly perform, publicly display and distribute such content. The rights you grant in this license are for the limited purpose of operating, promoting, and improving our Services, and to develop new ones. This license continues even if you stop using our Services ….”

Uh, oh. You’ve granted a permanent license to distribute and publicly display your content, and your clients’ content, in order to market or improve the provider’s services or to develop new ones. The provider can even share client documents with its partners. And the license is perpetual. Uh, oh.

These terms cited above come from a well-known tech company, and they’re current as of this writing.[1] We wonder how many lawyers have signed onto them without thinking it through, or even reading them. The lesson is that T’s & C’s from data hosts and other cloud services providers involve some traps for the unwary. This paper helps you avoid those traps. It explains eight clauses found in contracts from providers of online tools for lawyers. It also offers some pointers on due diligence: on vetting and picking the right provider in the first place. Your authors (and speakers) are attorneys whose work includes drafting the types of terms you’ll see from your technology providers. David Tollen is the author of the ABA’s manual on IT contracts, The Tech Contracts Handbook: Cloud Computing Agreements, Software Licenses, and Other IT Contracts for Lawyers and Businesspeople, Second Edition (ABA Publishing 2015). He’s in private practice and represents both technology providers and their customers, and he also provides training on drafting IT agreements, for lawyer and businesspeople. Nathan Leong is corporate counsel at Microsoft, one of the world’s leading hyperscale cloud providers. His work involves shaping complex cloud deals with Fortune 100 U.S. and multinational companies, and he regularly speaks, writes, and advises on privacy, data protection, information security, cross-border data transfer, healthcare and financial privacy, and export issues in the cloud.[2]

You can find additional resources on cloud contracts in David’s book, of course and for free at its website, www.TechContracts.com.

EIGHT KEY TERMS OF CLOUD SERVICES CONTRACTS

Many law firms can’t negotiate terms with their IT providers. Sometimes it’s because they’re not buying enough services. And in some cases, the provider has limited room to negotiate with individual customers, since it offers a shared infrastructure using the same systems, controls, and resources to support all customers. In any case, even if you’re looking at “take it or leave it” terms, you need to understand what they say. If the terms are too slanted, the answer may be “leave it.”

Data Licenses

The sample clause at the top of this article is a data license. It goes without saying that lawyers shouldn’t give their providers a license like that, with extremely broad, perpetual rights to client documents and other materials. In fact, you might hesitate before granting such a license to your own materials, like firm logos, manuals, and financial records.

Here’s a better data license, for most purposes, from a public cloud provider:

You hereby grant [Cloud Provider] and its contractors the right to transmit, use and disclose Content posted on the Service solely to the extent necessary to provide the Service, as otherwise permitted by these Terms, or to comply with any request of a governmental or regulatory body (including subpoenas or court orders), as otherwise required by law, or to respond to an emergency which [Cloud Provider] believes in good faith requires [Cloud Provider] to disclose information to assist in preventing the death or serious bodily injury of any person.[3]

The above license restricts the provider’s rights to pretty narrow data use, particularly to use as necessary to provide the service. That’s not bad. Ideally, you’d restrict data use and disclosure even more: “Provider shall not transmit, use, disclose, or otherwise exploit the Content other than as strictly necessary to provide the Service unless it receives Customer’s written permission, except as required by law.” If you have the leverage (and aren’t dealing with a provider so large that scale prevents individualized “written permission”), try for term like those. But if not, in most cases a law firm can work with a narrow license like the one cited above.

Providers of cloud-based systems don’t need extremely broad content licenses like the one at the start of this article—at least, not if they provide typical services for businesses, like law firms. They don’t need rights to use your data to market their service, and they certainly don’t need permanent rights. If the contract does demand those rights, it’s probably the result of overzealous lawyering, rather than an informed policy. So if you’re in a position to negotiate, there’s a good chance you can talk the provider out of it. If not, you might consider another provider.

The next section addresses some concerns that go hand-in-hand with data licenses, particularly regarding ownership of data and the details surrounding how the provider can use, secure, and manage it.

Data Security, Management, and Privacy

In the digital age, data is king. And, in the cloud, protecting that data is the empire. When you load traditional software on premises (e.g. on your laptop or firm’s server), you retain all responsibility and control over your data. But, once you move from desktop to cloud and from software to service, you’ve got to assure yourself that your data will be secure and managed in a way that supports your privacy obligations.

Let’s turn to data security first because, with cybercrime and data breaches at an all-time high, it’s no wonder that data and information security are top of mind for many of us. Tech providers should recognize and address this real concern about security,[4] so if you find your cloud contract absolutely void of any data security commitments, the ethical lawyer managing client data should walk away.[5] As a floor, you should look for something like this:

[Cloud Provider] has implemented and will maintain and follow appropriate technical and organizational measures intended to protect Customer Data against accidental, unauthorized or unlawful access, disclosure, alteration, loss, or destruction. Until Customer Data is deleted as set forth in the [Contract], such measures shall remain in full force and effect.

The better terms will build from there and add greater detail surrounding operational security, encryption, access control, identity management, threat management, logging, and network security. Of course, your service’s place on the spectrum of cloud services, from software-as-a-service through platform- and infrastructure-as-a-service, will mandate how far up the IT stack the cloud provider’s control rises—along with its information security responsibility—and where shared responsibility or your sole responsibility begins.

A fair question at this point is, to what extent should you expect to dictate a cloud provider’s security practices? Traditional outsourcing with customized (read: $$$) operations might allow for you to define the security policy, but it is highly difficult if not impossible for cloud providers to comply with varied and often conflicting security policies for each subscriber of a high volume, shared cloud service. Thankfully, over the years, the demand for verifiable security on cloud services has given rise to several global standards for articulating and auditing cloud security controls. The most sophisticated cloud providers will make their information security policy available for your review, and the best will accord their security controls with international standards like ISO 27001, ISO 27002, and ISO 27018 and prove their performance with regular, independent audits against the latest industry respected attestations like SSAE 16 SOC 1 and SOC 2, and HITRUST, among others.[6]

Now, let’s talk data privacy. Keep in mind that security, while critical to privacy, is not the same as privacy. When reading the tech contract with an eye toward data privacy, you are looking for those commitments that govern the access, use, and disclosure of your data in ways that comport with applicable privacy law. Who you are and what data you have (and who your clients are and what data of theirs you have) will bear significantly on which commitments are “must have” and “nice to have” for you, but what follows are a few guideposts:

• Clear data ownership. This one is pretty easy, but it’s unfortunately not pretty common. As a companion to an appropriately scoped data license like what we discussed earlier, look for a clear contractual commitment that you retain ownership of your data. Here’s an example: “As between the parties, Customer retains all right, title and interest in and to Customer Data. [Cloud Provider] acquires no rights in Customer Data, other than the rights Customer grants to [Cloud Provider] to provide the Online Services to Customer.”
• Data mining. Following on clear ownership, be on the lookout for tech contracts that permit data mining by your provider. This one requires some careful reading on your part because some unscrupulous providers will “fail to state the negative” and/or will incorporate consumer-grade privacy policies that expressly permit data mining. Even more, look for an affirmative statement barring all repurposing of your data for the commercial benefit of your provider or any third party, such as: “[Cloud Provider] will not use Customer Data or derive information from it for any advertising or similar commercial purposes.” Pay attention to how order of precedence governs the interplay of these concepts with your data license.
• Location of data processing and data at rest. You’ll want to get a handle on location, namely, the geographic locations where the provider will process your data and the locations where your data will be at rest. The cloud is not a foggy soup in the sky,[7] but it’s a network of countrywide or worldwide data centers. Have a baseline expectation about transparency into data center locations where your data will be processed and where it will sleep at night. Pull up a map if it helps. Privacy-conscious providers will give you comparatively greater control over data location, including the capability to keep certain data within certain countries or regions at rest (e.g. within the European Economic Area or the United States).
• It’s not uncommon for a cloud provider to leverage subcontractors, but if they do, it ought to be done transparently. Just like you limit the provider’s use of your data with the data license, subcontractors’ access to and use of your data should be limited to delivering solely those services that the provider has retained them to provide and should be prohibited from using your data for any other purpose. The tech provider should remain responsible for its subcontractors’ compliance with the terms of your agreement. The most sophisticated cloud platforms will give you a list of all subcontractors used, including their geographic location, and will require subcontractors to sign written agreements no less protective than its contract with you (including the privacy, security, and compliance terms).
• Data transfer strategies/mechanisms, like EU Model Clauses and Binding Corporate Rules. Consuming cloud services today requires that you both (1) understand the patchwork of privacy regulations which may be implicated by how your data will flow on a particular provider’s cloud service and (2) ensure proper coverage by effective data transfer methodologies. Just as effective security is not the same a security, you need effective data transfer mechanisms—and this area of regulation is rapidly evolving. More and more countries around the world are proscribing the international transfer of their citizens’ personal data absent certain legally prescribed exceptions, and the recent Court of Justice of the European Union invalidation of the EU-US Safe Harbor Framework, one method of legitimizing data transfer, exemplifies our destabilized global privacy environment. Legitimate transfer options as of the date of this writing include EU Model Clauses and Binding Corporate Rules, but the world may (will) change by the time we meet at TechShow. Study this carefully and err toward a cloud provider who has proven leadership in this area.

These privacy and other compliance commitments could be located in a “Privacy” section, or they may be found in a separate data processing agreement, data protection agreement, data management and security addendum, or other similarly named document.

Beyond the guideposts above, you may need to dig deeper into the privacy “alphabet soup” as determined by your clients’ industries, including, but not limited to, HIPAA (the Health Insurance Portability and Accountability Act, governing the use, disclosure, and safeguarding of protected health information), CJIS (Criminal Justice Information Services Division of the U.S. Federal Bureau of Investigation, which promulgated policy for minimum security requirements and controls to access federal criminal justice information), FDA (Food and Drug Administration regulations setting guidelines for tech systems that manage information used by FDA-regulated organizations), FedRAMP (U.S. Federal Risk and Authorization Management Program, which programmatized the assessment, authorization, and monitoring of cloud services under the Federal Information Security Management Act (FISMA)), FERPA (Family Educational Rights and Privacy Act, which protects the privacy of student education records), IRS 1075 (IRS Publication 1075, which prescribes security and privacy controls for cloud services to protect the confidentiality of federal tax information), and more.

Finally, we reach data management. As with security and privacy, these concepts are related because they all bear on the data itself. At the outset, nota bene: unilateral amendment as discussed later can deeply unsettle the commitments a provider makes to you regarding data privacy, security, and management.

You can think about data management as your test of how well a provider keeps you in control of your data. Look for specifics about data retention and how, when, and under what circumstances, your data will be deleted. Look for a commitment that your data won’t commingle with data from a provider’s consumer services. If it’s a shared, multitenant service, look for terms that commit to logical separation between your data and another customer’s data. Look for committed procedures, compliance with law, and redirection to you (if permitted) of third party and government requests for your data. As discussed previously, look for commitments about where your data will be located at rest. Look for an explicit notice obligation for security incidents involving your data. Look for defined parameters on extracting your data at the end of the relationship. If your provider can’t articulate its data management strategies and confirm them in writing, you might reasonably wonder if it’s worthy of your trust—and data.

Performance Warranties & Service Level Agreements

Here’s the warranty you want: “Provider represents and warrants that the Service will perform materially according to its published specifications throughout the Term.” If you can get that, do.

Most cloud services providers, however, limit their service promises. First and foremost, where you do get a warranty, it will likely cover only a limited set of functions, rather than performance of all functions listed in the service’s specifications. In other words, the provider warrants that “the Service will be accessible to the Internet during 99% of each calendar month,” or that “Time Entries will be retained in the Service’s memory during the 2-year period following submission.” And whatever your warranty, the contract will often limit your remedies quite severely. If the provider (or rather its service) breaches the warranty, your only remedy will likely be termination with no refund, or at best with a partial refund. Or you may not get a termination right but rather a right to a partial refund of that month’s fees. Broader warranty rights would serve you better, obviously, but you may have to live with limited remedies like these.

In fact, if you can get a performance warranty at all, you’re doing well. Many cloud services providers offer no warranty regarding system performance. Instead, they provide a service level agreement, or “SLA.” Despite the name, an SLA usually isn’t a separate contract. Rather, it’s a clause or attachment to the main contract. Usually, the SLA says what the service will not do—promises of minimum standards for performance—and often it offers credits as the remedy for performance failures. In that way, an SLA resembles the limited performance warranties discussed in the preceding paragraph, but without use of the legally potent term “warrant,” and often with very constrained remedies.

The most typical SLA promise for a cloud services provider is accessibility. The usual promise is that the system will be accessible X% of the time, excluding scheduled maintenance and emergencies. You should know that cloud contracts rarely define “accessible” to mean anything more than access. If the customer can log into the system, it’s “accessible,” even if some or most functions don’t actually work. So you’re better off with an SLA that lists actual functions, like the ability to revise or download documents. But many cloud services providers stop at access.

Most providers limit your SLA remedies to credits. If the service fails its promised metrics (and if you go through the trouble-ticket process), you get a little money, often limited to some percent of that month’s fees. It’s not money back; you can only deduct it against future service fees. If you terminate, it’s gone. (That’s one way providers keep unhappy customers.) Most SLA’s, in other words, offer nothing remotely resembling breach of contract remedies, or even the broader remedies customers sometimes get for breach of warranty.

Most SLA’s are designed to protect the provider. They look like a promise of good service, but they often promise relatively little and limit your remedies even further. If you can get better terms, you should. But if you can’t, recognize that terms like these help keep prices low, and they’re typical.

IP Warranty

If you have any experience with technology contracts, one of the first things you look for is the IP warranty. Don’t be surprised if you don’t find it.

Ideally, every tech customer gets a warranty like the following: “Provider represents and warrants that the Service does not and will not infringe upon the intellectual property rights of any third party.” With a warranty like that, you have the right to compensation if you lose access to the service because of an IP suit. But IT providers have been dialing back on IP warranties in recent years, arguing that the IP indemnity covers the customer’s needs. That’s not really right. The indemnity addresses the provider’s obligations to defend third party suits and to pay judgments or settlements, while the warranty addresses the customer’s losses if the suit disrupts use of the system, including if the provider loses the indemnified case. So a smart customer tries to get both. But while that’s an option if you have a lot of leverage, law firms probably don’t often get both clauses, and if you had to choose, the indemnity would in most cases be more valuable. (Unfortunately, the indemnity isn’t always available either, as discussed in the next section.)

Indemnities

In negotiated tech contracts, the indemnity is often the most fought-over clause (and the least understood). Each side knows it’s got a lot at stake—particularly since, in many cases, the contract’s limit of liability clause does not apply to indemnity obligations. In the sort of standard contracts most law firms see from IT their providers, provider indemnities are quite limited. And in many cases, it’s the customer who indemnifies the provider.

Typical tech contract indemnities cover intellectual property and, in rare cases, data security. (Personal injury indemnities crop up in some tech contracts, but not often with cloud-based services lacking in-person services.) As noted above, providers often grant IP indemnities more willingly than IP warranties. “Provider shall indemnify, defend, and hold harmless Customer against any third party claim, suit, or proceeding arising out of, related to, or alleging infringement by the Service of third party intellectual property rights.” In most cases, the provider limits that promise in a variety of ways, including refusing to cover claims resulting from the customer’s breach or use of the service in combination with third party systems. (The latter exclusion isn’t as sensible as it sounds. It could mean you’re not covered for an IP suit resulting from the service’s interface with a system you had to use, like a standard browser or operating system. But few providers will give up this exclusion, particularly for smaller customers.[8])

Some IT providers simply don’t give IP indemnities; at least, not in their standard contracts and not to customers without substantial leverage. As the customer, you definitely want the indemnity (or an obligation to defend, hire attorneys, and pay settlements/judgments, as it’s phrased on some contracts). But if you have to do without it, you’re in good company. Lots of customers get none. The provider’s logic—aside from “It’s against our policy”—is that the service would cost more with an indemnity.

Whether or not the provider offers an IP indemnity, it may ask you for one. Generally, cloud services providers want an indemnity covering copyright, trade secret, and other IP claims related to the documents and other content you upload. That’s not unreasonable in most cases, though you’re certainly better off avoiding it if you can. By accepting your content on their computers, cloud services providers take the risk of lawsuits by third parties who claim rights to that content.

What may astonish you (and even offend you) is the cloud services provider who demands an indemnity for third party claims related to data breaches. In other words, if a breach of the provider’s systems exposes third party data—like your employees’ health records or your clients’ documents—and the third party sues the provider, you defend the case and pay judgments and settlements. That sounds totally backward, but there is a method to the provider’s madness. It’s probably letting you upload whatever you want to its computers, without checking whether your content is worth the risk. You could upload nuclear secrets, names and addresses for ten thousand minors, or a thousand social security numbers—information the provider would rather not hold. In exchange for that open door, the provider wants a data breach indemnity. Avoid giving one if you possibly can, but recognize that it may be the price for doing business with this provider.

Of course, you might also want to receive a data breach indemnity. Very large customers often have to fight for rights like that. If you can get them, do, but recognize that it’s rare.

Whatever indemnity ends up in the agreement, if it’s limited by the limit of liability clause, it may be of little use (illusory use) to the indemnified party. As explained below, the typical limit clause caps liability at a year’s fees, or something like that, which for most services is a drop in the bucket compared to the cost of defending a lawsuit.

Limitation of Liability

It’s axiomatic that lawyers love to talk liability. The liability caps and exclusions, as well as the insurance commitments (if any), in your technology contract round out your liability profile, when considered together with SLA credits and any indemnities.

What you’ll want to avoid is no liability whatsoever for your use and consumption of a cloud service where your most critical data, your clients’ confidential information, is at stake. So too, watch out for exclusions that bar liability coverage for data processing, privacy, and security obligations, and carefully assess how categories of damages—like costs related to security incidents and post-breach remediation—are characterized and defined.

Here’s what you’ll see in the market. Most major tech providers will cap liability, and the cap is commonly a multiple of fees paid. Twelve months of fees paid is fairly typical, but in any case, you’ll often see a rational relationship between the cap and the revenue associated with the business transaction. What you should not expect is uncapped liability for the other party, which is a losing business proposition for providers. If you do see unlimited liability, heed your “buyer beware” alarms, double check for tricky contract loopholes, and assess the provider’s financial wherewithal and/or insurance coverage. Whether or not the cap is mutual may matter to some, but in practical terms, a cap on liability largely benefits the provider as it holds the majority of the risk of breach. Also, most cloud contracts will be quite abundantly clear about the liability arrangement as it relates to your data. While it is reasonable for the processor of your data retain some level of financial accountability, few legitimate businesses can sustain unlimited liability in exchange for a low-cost monthly fee, like $10/user/month.

Here is the liability provision from a cloud contract out in the wild:

Limitations of Liability.  We and our affiliates or licensors will not be liable to you for any direct, indirect, incidental, special, consequential, or exemplary damages (including damages for loss of profits, goodwill, use, or data), even if a party has been advised of the possibility of such damages. Further, neither we nor any of our affiliates or licensors will be responsible for any compensation, reimbursement, or damages arising in connection with: …  (d) any unauthorized access to, alteration of, or the deletion, destruction, damage, loss or failure to store any of Your Content or other data. In any case, our and our affiliates’ and licensors’ aggregate liability under this Agreement will be limited to the amount you actually pay us under this Agreement for the Service that gave rise to the claim during the 12 months preceding the claim.

Here we see an aggregate, 12-month cap on damages based on actual fees paid, and we have in subpart (d) a very clear disclaimer of any damages related to a customer’s data. That’s at least problematic, but this clause also has an exclusion of all “direct” damages, as well as consequential damages. That probably leaves the cloud service provider with zero liability, the 12-month cap notwithstanding. Few tech providers go this far, and in fact, one has to wonder whether the drafter understood the clause. In any case, an exclusion of punitive and consequential damages (including indirect, incidental, and special) is typical and hard to avoid, but you shouldn’t have to exclude direct damages.

Now a note on insurance and the interplay with financial strength. Cyber risk and technology errors & omissions insurance are, at their core, about ensuring a party’s ability to meet a financial obligation, namely, an indemnification or liability commitment. Hand-in-hand with your review of any applicable insurance coverage and the market cost of underwriting the risk, whether on the part of your provider or for your own benefit, you should include a thorough assessment of the financial strength and stability of your cloud provider. Some highly capitalized cloud providers use programs of self-insurance. Other providers offer no insurance commitment, but, given their financial liability to you, really should. Take off your lawyer hat. Think like an investor. Engage your risk management team or advisor. Extravagant indemnities and sky-high liability caps from a fly-by-night provider are of little use during its bankruptcy.

IP Claims Waiver

We talked about overbroad data licenses above, but beware: sometimes they take the form of an intellectual property claims waiver, like this:

License Restrictions.  … During and after the Term, you will not assert, nor will you authorize, assist, or encourage any third party to assert, against us or any of our affiliates, customers, vendors, business partners, or licensors, any patent infringement or other intellectual property infringement claim regarding any Service Offerings you have used…

This IP claims waiver is an example of what’s known as a non-assertion of patent (NAP) clause or non-assertion clause. A non-assertion clause in favor of a tech provider is effectively a license to your IP rights in exchange for use of the provider’s technology. Non-assertion clauses generally may create efficiencies not unlike patent licenses or cross licenses, but the nature of the cloud space intensifies the potential pitfalls of a non-assertion clause that you’ll want to avoid (or accept with eyes wide open and appropriate mitigation).

Here’s how the cloud context can amplify risk from non-assertion clauses for you as a cloud customer. You’ll witness a special ballooning of the waiver/license scope with a cloud provider on the beneficiary end of your non-assertion clause. Global cloud operations require massive scale, which means incredible and growing numbers of vendors, business partners, and affiliates, not to mention acquisitions. The expansion of scope multiplies to several orders of magnitude beyond a traditional IP license if other customers of the cloud provider are beneficiaries of the non-assertion clause. You could be waiving your IP assertion rights against a competing law firm, who unbeknownst to you, is also using that cloud provider’s platform—assuming, of course, your firm has valuable IP. Finally, consider the implication to you as a lawyer. What if the non-assertion clause prohibits you from assisting or encouraging your client to assert its IP rights?

The bottom line is that as a cloud customer, you should avoid IP non-assertion clauses that extend to other customers and their data. A cloud provider with a sufficient data license and reasonable protection from your hosted IP (each as discussed above) probably can do without a non-assertion clause.

Unilateral Amendment

Some contracts let the provider change terms at will. “We may amend this Agreement at any time by posting a new version on this Webpage. You agree to check this Webpage regularly for such amended terms, and you agree that your continued use of the Service after the effective date of such amended terms constitutes your acceptance thereof.” That’s an awful clause, since it essentially means that whatever terms you’re relying on could change at any time. And the provider’s dreaming if it imagines that any customer will regularly check the online terms.

There is a silver lining to these unilateral amendment terms, and you’ll have to decide whether to rely on it. They’re probably not enforceable. In fact, one court has suggested that a clause like the one above renders the whole agreement unenforceable, at least against you: an “illusory” contract.[9] That could work in your favor, since most of the contract’s terms protect the provider.

Sophisticated providers protect themselves through more limited amendment terms. They limit their unilateral rights to immaterial changes, for instance. Some will agree to lock the agreement’s terms in place for your subscription term, which is even better. Or they give you real notice of amendments, as well as a chance to terminate, or at least to reject the amendment.

DUE DILIGENCE ON YOUR CLOUD SERVICES PROVIDER

We have no doubt that you’re here and reading this paper because you want to maximize the value of technology. But, it’s also increasingly clear that we all expect to preserve certain timeless values while unlocking the potential of technology—and trust is one of those core values. So, how do you find technology and a provider that you can trust, one that’s worth diving into the Terms and Conditions with? We have the following due diligence recommendations.

An initial note: Some of these suggestions apply most directly to very large or global cloud service providers. Your provider might be smaller and so can’t be expected to do things like running cyber wargames or fostering relationships with regulators around the world—both discussed below. But, it’s still worth asking the questions below about them—and also looking into which larger providers, if any, provide them with cloud platform or infrastructure services.

Understand who your provider is. Yes, take a look at a provider’s business model. Take a look at their balance sheet. Assess the relationship between your tech and its core revenue and its future. But, go further. Understand the provider’s core identity, and understand how that identity is borne out in its technology investments. Identity—core values and the “why”—is endlessly informative in your due diligence. Here is why. If you anticipate change (and you should with a cloud service), it helps predict future decision-making: what might your provider do and will it be the right thing for you. If you anticipate waves and storms of new data and information security reforms (and you should, given the coming years’ privacy forecast), you’ll learn a ton from those core values. When storms are brewing, success will not come to those who shout into the wind; success will only come to those who figure out how to ride the wave.

Vet their security posture. In a day and age when many organizations don’t even know they’ve been hacked for over 6 months,[10] merely securing the cyber perimeter to prevent intrusion is archaic. It’s like trusting the hard candy coating to protect your soft gooey center. What you should prefer is a security posture that “assumes breach”—assuming an attacker is always in the system—and employs strategies that keep the attacker from getting out with anything of value. Running cyber war games to simulate real-world attacks helps a sophisticated provider stays ahead of emerging threats. Taking proactive action against cybercriminals helps your provider get smarter, constantly evolve its security capabilities, and harden its cloud services. Security should permeate from the core of the provider’s DNA, through to the design process, operations, administration, and incident management. If you don’t know how they operate in the cybersecurity landscape, you haven’t asked enough of the right questions to put your data there.

Consider working with a leader. Today’s privacy and compliance landscape requires that you use online solutions that protect the privacy of your data and your clients’ data. What is their reputation for privacy and compliance in the industry? What is their track record in cloud? Do they employ Privacy by Design, which bakes privacy into the core of products and services? Leadership means fostering meaningful relationships with top regulators around the world and supporting you with any necessary regulatory approval (or getting it on your behalf). It means focusing on highly regulated industry segments and those with the strictest data security requirements. It means a cloud provider who sees around the corner and sets the trends. It means a cloud provider who sees privacy not as a compliance cost, but as an asset.[11]

Assemble your team—even if you’re a solo or small firm, and your team is likewise very small and/or includes outside vendors. It’s often said that cybersecurity is a team sport. Equally accurate is that cloud due diligence requires that you assemble a team. Likewise, cloud computing requires a fair grasp of the legal and operational implications of data privacy and compliance, finance and risk management, technology, and information security. If you understand it all, then make sure you differentiate and wear all your different hats. If you don’t understand it all (like us), get help.

• • •

True, T’s & C’s from data hosting and other cloud services providers involve some traps for the unwary. But we hoped that, armed with due diligence and the considerations in this paper, you won’t be asking, “What did I just do?” We hope that, instead, the questions you ask your provider will launch a good relationship with a trusted partner.

—————

This paper was presented to the American Bar Association’s TechShow conference in March of 2016, under the title, Terms and Conditions: To What Did I Just Agree? (And why am I so unwilling to dangle a preposition?). This is its first publication.

—————

[1] We’ve substituted “us” for the company name. Also, note that the same paragraph goes on to say, “in some of our Services, there are terms or settings that narrow the scope of our use of the content ….” (We’ve had a hard time figuring out whether those narrowing terms or settings appear in the systems lawyers use.)

[2] We shared the drafting of this article, but David was the primary author for this introduction and for the following sections: Data Licenses, Performance Warranties & Service Level Agreements, IP Warranty, Indemnities, and Unilateral Amendment. And Nathan was the primary author for these sections: Data Security, Management, and Privacy, Limitation of Liability, IP Claims Waiver, and Due Diligence on Your Cloud Service Provider.

[3] Note that these terms do authorize the cloud provider to use your data “as otherwise permitted by these Terms ….” You’ve got to check the whole contract, including terms attached to any individual service.

[4] The good ones do. See, e.g., Chris DiMarco, “As Legal Awakens to Cyberthreats, Technology Must Respond,” Legaltech News, March 23, 2015, available at http://www.legaltechnews.com/id=1202721336393/As-Legal-Awakens-to-Cyberthreats-Technology-Must-Respond.

[5] See ABA Model Rules of Professional Conduct, Rule 1.1, Comment 8 (“To maintain the requisite knowledge and skill, a lawyer should keep abreast of changes in the law and its practice, including the benefits and risks associated with relevant technology…”) (emphasis added).

[6] Speaking of attestations, if you see any provider commitments and chest-pounding about SAS 70, run and run away quickly! The American Institute of Certified Public Accountants (AICPA), whose Auditing Standards Board publishes various auditing standards, published SSAE 16 as a superseding standard to SAS 70 a few years ago.

[7] https://youtu.be/i8rYQLGnWHQ?t=1m34s

[8] David Tollen’s book, The Tech Contracts Handbook, suggests compromise terms on this issue, for larger deals where the provider will negotiate. (See, Handbook 2d ed., Chap. II.J.3, “Exclusions from IP Indemnity”).

[9] Harris v. Blockbuster, 622 F.Supp.2d 396 (N.D. Tex. 2009).

[10] See Mandiant Consulting’s Annual Threat Report 2015. Median number of days that threat groups were present on a victim’s network before detection was 205 days, and the longest presence reported was 2,982 days. Id.

[11] Viviane Reding, Former EU Justice Commissioner, “A Data Protection Compact for Europe,” Speech on January 28, 2014, available at http://europa.eu/rapid/press-release_SPEECH-14-62_en.htm (“[S]ome companies…continue to see data protection as an obstacle rather than as a solution; privacy rights as compliance costs, and not as an asset”).

—————

© 2016 by David W. Tollen and Nathan Leong. All rights reserved.