Contract Provisions That Should Be Considered In A Cloud Computing Arrangement
This is actually Chapter 4 in a rambling dissertation on why the "Cloud" is what it is.
In previous posts (see here, here and here), we have chronicled the evolution of the “Cloud”, Software as a Service and various permutations thereof and labels therefor. So, now that we think we know how we got here, what do we do now? If you are considering the procurement of cloud services and if you have the negotiating clout to request changes to the vendor’s standard contract, you need to consider some additional things to request.
In addition to the general considerations such as price, term, etc., the following are additional considerations to be discussed with the vendor and possibly included in the governing agreement:
1. In most cases, the vendor owns or licenses the software and the customer owns the data. The customer should always have the right to access and move its data, even in an alleged default situation. This is particularly true if the customer is in a regulated industry.
2. What happens if the vendor goes out of business, declares bankruptcy or is acquired? What happens if the acquirer is one of your competitors? The customer should have an exit strategy and the agreement should be compatible with such strategy.
3. How much responsibility or liability will the vendor assume if the systems are unavailable or if your data is lost? What are the backup procedures, business continuity plans and disaster recovery arrangements? Most vendors’ heads would explode if you requested that they be responsible for the value of your lost data but what are the procedures to recover the data, to back it up and protect it and who pays for that?
4. What kind of investment will the vendor make in software upgrades, enhancements and development? A company for which I once worked pledged 5% of its outsourcing revenue to software development and maintenance. Most companies won’t commit to a specified amount or percentage but a purchaser should review their plans and should have some input, through user groups or otherwise, into the direction of software development.
5. What will you use to determine if the software is functioning in the manner that you expected? What are the warranties surrounding such? Most software providers will warrant that the software will perform in accordance with its documentation but you should request that the basics of any functionality found in sales proposals, demos, RFPs or other material used to sell you on the software be part of the warranty.
6. A purchaser should consider whether the vendor routinely conducts a SAS 70 audit and makes the results available.
7. Since the purchaser has less control over the software used in a SaaS situation than in any on-site situation, a reputable vendor should be willing to provide an intellectual property indemnification that will pay for a legal defense (usually the biggest exposure for a user) and should provide an alternative if use of the subject system is enjoined or interrupted in any manner.
8. The escrow of source code, executables and other information necessary to carry on the processing if the vendor goes out of business or becomes unavailable should be considered. In most cases, this makes the user feel better but because of the long lead times involved, may be of marginal benefit.
9. Performance metrics, also called service level agreements (SLA) should be negotiated. Matters that are important to the user should be identified and reflected in the SLAs.
10. The foregoing are fairly standard components of most outsourcing contracts (which the delivery of cloud based software is, even if it is referred to as a software agreement). Perhaps the biggest divergence by Cloud based solutions from standard outsourcing situations is the question of security, the location of the data and the compliance of the system with Gramm Leach Bliley, HIPAA, Sarbanes Oxley and international data transfer restrictions. If the user is a financial institution or subject to HIPAA then the problem becomes particularly acute and addressing those issues in a manner that the benefit of Cloud computing can be realized by regulated entities is a difficult process.
Now that we've looked at the Cloud from both sides now, it may be the Cloud's illusions we recall and that we really don't know the Cloud at all. Or it may be just that we are out of cheesy cloud references.
