Editor: Tell our readers about your practice.
Ryan: I am a transactional lawyer, and I have been working in the technology field since 1992. I have spent a good deal of my time working on large-scale outsourcing deals. In the '90s there were many large-scale application maintenance or data-processing deals taking advantage of labor cost arbitrage. In the present decade I have done many application service provider deals and a lot of systems integration work, so I've been involved with many different types of technology and professional services deals over the last 15 years or so. The firm has technology expertise, particularly in the data privacy and security areas where we have one of the leading groups in the field. Many of the lawyers in our DC office are former FTC lawyers who keep a close eye on all the privacy regulations. We have an office in Brussels, which is helpful from the EU perspective. We also have a closely affiliated office in India so we're able to draw on that expertise.
Editor: Many of our readers are technologically advanced, but this is a field that has moved at warp speed in the time you've been practicing, so remind us, what is cloud computing ?
Ryan: The Commerce Department's National Institute of Standards and Technology (NIST) defines it as: "A pay-per-use model for enabling available, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, services) that can be rapidly provisioned and released with minimal management effort or service provider interaction."
Editor: That sounds like government computer geekese. In English?
Ryan: The basic idea is to allow computer technology to be accessed as a service over the Internet from any location, so that computer technology, programs and data can be available when and where the user needs them. I think flexible pricing on a pay-for-use basis is a big piece of the value proposition. Rather than buying and maintaining server capacity and operating systems, an enterprise can acquire that same capability from a cloud provider that it accesses over the Internet. It only pays for as much data processing as it needs, avoiding the capital expenditure and the ongoing expense of maintaining it. The same concept applies to the software application, thereby avoiding the upfront license fee.
The NIST defines three basic types of cloud services: Infrastructure as a Service (IaaS, or data storage at so-called server farms); Software as a Service (SaaS, or the application programs that manipulate the data) and Platform as a Service (PaaS, or software development services). NIST categorizes different ways of deploying those three service types. Private clouds are where all the technology components, servers and software, as well as software development, are kept in-house. This way an enterprise makes better use of its current assets, e.g., not every laptop has to be loaded with the software and have the data stored on it.
Editor: That's the private cloud. What are the other two?
Ryan: A public cloud - such as salesforce.com, amazon or gmail - is available to anyone. The third is community cloud computing, which NIST defines as multiple organizations that have shared concerns around things like security, privacy, or regulatory compliance. An example could be the healthcare industry, or even more narrowly, hospitals.
Editor: What are the major issues that an enterprise or its counsel must be aware of when acquiring public or private cloud computing capacity? One of the fears might be that data could be compromised, altered, sold or misused. What is the general state of the law now?
Ryan: It varies by industry. A financial institution has the requirements of Gramm-Leach-Bliley and cannot move to public cloud until it is comfortable that privacy and security standards are compliant and that its regulators would agree. Each regulated industry has different standards, but even if it is not a regulated enterprise, the FTC is going to be very concerned about how it is protecting personal information. As you move to the public cloud, you're not going to know on what machine your data is residing, so you must have the contractual controls in place with that service provider to assure that it is going to maintain security, maintain privacy, and so that you know exactly what it is doing with the data and not data mining or aggregating.
There are jurisdictional issues of where the server is located. Crossing borders presents problems in many industries. A data breach requires notification in many jurisdictions, so counsel must be wary.
Enterprises must have a recovery plan when disaster strikes. Turning over much of the IT function to a third-party provider brings cost savings that are significant, but if service stops, you need a way to get back up and running. Editor: What about e-discovery when data is residing on servers at various locations?
Ryan: First, you've got retention issues. I don't think any court would expect a system to be perfect, whether it's in-house or in a cloud. However, you can't outsource your responsibility; you have to put in place a reasonable process for data to be retained, preserved and protected. If a rogue employee of a service provider has destroyed information, you're going to be relying on those reasonable processes. If you've simply signed a form agreement of the service provider, you will be challenged as to whether what you did was reasonable. Most companies would look to the service provider and say you can't do anything with the data other than process it and securely store it per the agreement.
Editor: Has litigation developed between enterprise customers and providers?
Ryan: Not much yet. It's fairly early days.
Editor: What about auditing of charges by service providers?
Ryan: These service agreements can be complex in terms of the pricing. It is analogous to the banking industry, where service providers are doing a lot of the processing for smaller banks. The enterprise customer needs to understand what the parameters are and what the cost of exceeding them is.
Editor: Is this a subset of the net neutrality argument in terms of how you draft the contract and what you pay for?
Ryan: You must address all of these concerns in the contracts with the service provider, but the customers need to monitor performance closely and be ready to switch providers, if necessary. Transitioning from a provider is a very significant undertaking. You need to have detailed termination assistance clauses and be able to enforce that contractual commitment in a reliable jurisdiction. A lot of the issues that have to be dealt with in outsourcing contracts are the same as those that have to be dealt with in the cloud service agreements. Eventually, there may be some standardization of contract language, so that the highly customized negotiating arrangements don't become the norm in cloud agreements.
Editor: To complicate it further, what happens when the cloud provider goes bankrupt?
Ryan: Hopefully, your data is sitting here in the U.S., and you've got U.S. bankruptcy laws, but if your data is dispersed in various jurisdictions, it does become a problem. Your contract must be clear that you own the data, that the service provider is only storing and processing it at your direction.
Editor: What in fact is the res , what's the property? Is it the bytes that you've sent to the service provider?
Ryan: Good question. You own the bytes and should have the ability under your contract to have all of the bytes, if you direct it, returned to you or destroyed at your election with a certification of destruction. It needs to be very clear under the contract that you own all rights associated with that machine and human readable data.
Editor: Another argument for standard contract language - otherwise you're probably looking at a very lengthy and arduous negotiation.
Ryan: Unfortunately, service providers will be proposing contracts that they will have spent time writing that are favorable to them. The enterprise customer is unlikely to have spent time developing language until the actual negotiation. There are some benefits to engaging external counsel and advisors who have been involved on multiple occasions on the customer side. It would be helpful if there were more involvement of both customers and service providers to develop contracts that are more down the middle of the road, similar to what has happened in venture capital where there are many robust form documents that are available.
Editor: Switching to U.S. national policy, the Cyberspace Policy Review and the denial of service attacks on Twitter raise again the tension between security, both national and personal, and privacy issues.
Ryan: If payroll checks or direct deposits were made for your employees via the cloud and a cyber attack brought the system down, suddenly you're got a whole bunch of really unhappy employees. Or, if you couldn't get invoices out to your customers, you might be in a real bind to continue operating. Enterprise customers are really going to need to get comfortable that the provider they're using has the capability to address a particular attack and not have loss of service for a long period of time. That basic reliability of the service aspect is an impediment now for larger enterprises moving to the cloud.
Editor: Is anyone writing insurance against these kinds of events?
Ryan: There is insurance that is available for loss of data associated with a cyber attack, but it is quite expensive. More commonly insurance against the loss of data is found in business continuity insurance. My guess is there are opportunities for the insurance companies as more enterprises move to cloud.
Editor: Final observations?
Ryan: We've covered quite a lot of ground, but another piece I find interesting is quasi-legal. It will be fascinating to see if some of the consulting firms decide to develop a practice model where they offer to manage, monitor and even guarantee the relationship between the enterprise client and the public service providers. Let's see what happens over the next year or two as the various companies participating in this growth develop their value propositions.
Published September 1, 2009.
