Cloud computing is a misnomer of arcane origin. Originally the “cloud” was literally just a technology doodle (beyond the then-available lexicon or the plastic templates of systems architects 40 years ago).1 The billowing shape was used in system schematics to represent something beyond the computationally and conversationally stunted devices of the time (reminiscent of the ancient cartographers’ “terra incognita”). But over time, and especially with the dawning of the gigabyte era, the image/term has been co-opted to visually/linguistically represent what NIST has defined as “a model for enabling ubiquitous access to shared pools of configurable resources (such as computer networks, servers, storage, applications, and services).”2
Rather than the cloud being a thing, it is actually a process.
So how do you cloud
Part of the risk concerns come from most cloud vendors’ perspective that since they are providing a standardized suite of services to all customers, the contract for such services should also be standardized (i.e., a form contract). These form contracts always seem to disproportionately favor the vendor (and if the cloud vendor has market power, it can force such unfavorable terms across its customer base). What this form-based contracting ignores is that risk is most efficiently allocated in an open marketplace to the party that has control. In the cloud environment, the vendor by definition has control (of the activity), but the form contract avoids and minimizes shifting the risks related to this control, thereby negating the actual monetary consequence of whatever choices the vendor may have made in architecting or operating its cloud. This can be done in the form agreement via:
- limitations of liability and/or caps on liability (that, while proportionate to the value to the vendor of the contract-for-service, have no relationship to the absolute risk of and costs to the cloud customer);
- limited indemnification provisions (leaving the principle exposed to disproportionate third-party risks, even if covered for the customer’s own first-party risks); and/or
- disclaimers of the true equitable and/or monetary damages the customer may experience from a vendor’s activities in favor of service credits (that represent only a fractional or variable cost to the vendor, with little proportionality to the actual customer risks and damages).
However, even when contracts for cloud services are negotiated, attorneys sometimes forget that these negotiations must be mapped against their client’s enterprise vulnerability, which must account for both the probability of disruption or liability and the severity of the consequences.3
Intentional risks grab headlines (and disproportionate mindshare in cloud contracts).
But cyberterrorism and cyberwarfare are now equally an issue of risk allocation.4 Similarly, the intentional acts of the vendor in architecting, implementing, and/or operating its cloud infrastructure based around appropriate standards (and certification and residual auditing around such standards) need to be addressed in negotiations (and run the gamut from the esoteric to the more mundane aspects of cloud operation, such as employee background checks and the physical security of locked doors and drawers).
Negligent risks are more familiar territory for attorneys. Such risks begin with a duty, such that the first issues in cloud contracting are to properly and adequately define the vendor’s duty in the agreement (and make such duty both legally and practically enforceable). Once such duty is articulated in the contract, then the task turns to not only allocating the risks of loss from failure to adhere to that defined
Trust is the extent to which one party relinquishes control to another party on the belief that it will fulfill tasks and responsibilities the grantor values. In the cloud, our clients relinquish control. Unfortunately, the cloud was never architected for trust; it is completely agnostic, in that each bit is valued the same as every other bit. So much of what attorneys must do in the cloud environment is architect such trust between the client and a cloud vendor. And this must be done with the sole tool available: appropriate contract language that requires an alignment between the cloud vendor’s values and the client’s values (as set out in the tasks and responsibilities a vendor must assume, by contract, to implement such client values).
1 See www.retroist.com/2009/01/11/ibm-flowcharting-template/ for example of an early plastic template used for system analysis.
2 SP 800-145, The NIST Definition of Cloud Computing, at http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf.
3 See generally, Sheffi, The Resilient Enterprise, MIT Press, 2005.
4 See Frey, Cyber-warfare, cyber-terrorism, and cyber-crime, Financier Worldwide,