Published on 08 Mar, 2013
In early 2013, Shelston IP released a study entitled “Cloud Cover”. Commissioned by IT News the study follows on from the IT News 2011 research.
The study comprises a review of over 53 contracts from 18 providers. It points out what clauses to avoid, and what clauses represent best practice for cloud computing contracts in Australia.
A summary of the study was published by IT News.
A recent VMWare and Forrester Research annual survey published in November 20121 indicated that cloud computing adoption had increased for Australian business to about 58 per cent, up from 42 percent the previous year. A further 20% of businesses planned to implement cloud solutions within the next 18 months. Cloud adoption was seen as a strategic move with competitive advantage being cited as a major factor by a majority of organisations. In addition to cost savings being a driver for adoption, users are increasingly adopting cloud technologies for the flexibility offered by being able to scale up and down without committing permanently to the underlying infrastructure and applications.
While adoption of cloud increases, concerns around privacy, security and availability remain significant for Australian businesses.
The purpose of this paper is to consider the extent to which there has been an associated maturation in the terms of provision of cloud services, to take account of these continued concerns.
We have done so by reviewing a number of the terms and conditions for cloud providers (“the cloud contracts”)2 . A primary focus has been privacy and security together with various other commercial issues which can have a significant practical impact on a business’ adoption of a cloud solution. In conducting our survey we have also reviewed the similar White Paper co-authored by Mark Vincent in 2011: Cloud Computing Contracts White Paper, A Survey of Terms and Conditions3(“the 2011 White Paper”) and comment on developments or lack thereof since that time.
The cloud contracts comprise some 53 individual contracts and documents from 19 providers. The contracts relate to paid business grade services available in Australia.
2. Issues Considered
In reviewing the cloud contracts, we focussed on the issues which may create significant legal and practical risk in a cloud environment. In particular we have considered:
- Privacy issues, location of data and foreign government access;
- Security measures and notification of security breaches;
- Service availability and service credits;
- Assistance with/ability to transition out on termination or expiry of services;
- Ability of a provider to vary terms;
- Choice of law and jurisdiction clauses.
3.1 Privacy issues and location of data and foreign government access
The VMWare survey indicated that data privacy, residency and control are the top cloud concerns amongst Australian businesses. There are some very real issues as to how cloud solutions overcome privacy concerns and provide sufficient certainty as to data location to satisfy ever increasing regulation of data.
As well as commercial considerations as to the privacy of their own information, many Australian businesses are under numerous obligations to protect the privacy of personal information in their possession belonging to other individuals. The Privacy Act 1988 governs privacy in Australia and imposes obligations on businesses with a turnover of more than $3 million4. Governmental agencies and businesses providing services to governmental agencies are also subject to privacy obligations.
These obligations include duties not to use or disclose the information unless certain criteria are met5, to take reasonable steps to protect such information from misuse or loss6, and only to allow transfer of the data out of Australia under certain conditions7.
Furthermore the Privacy Amendment (Enhancing Privacy Protection) Act 2012 (“Privacy Amendment Act”) was passed on 29 November 2012 and when it comes into effect in March 2014, will place both public sector organisations and private businesses under significantly more stringent requirements in relation to cross border data flow, and allow for the prospect of stronger sanctions if they do not comply.
The Privacy Amendment Act containing the new Australian Privacy Principles (“APPs”) will come into force in March 2014. Under new APP5, if a company collects personal information and it is likely to disclose the personal information to overseas recipients it must provide notice at the time of collection of the countries in which such recipients are likely to be located. This is difficult where cloud providers are unwilling to nominate the location of their data centres.
Under the new APP8, before a company discloses personal information about an individual to a person who is not in Australia, it will be required to take reasonable steps to ensure that the overseas recipient does not breach the APPs, unless informed consent, with very specific requirements as to the information to be provided in order to obtain such consent, is obtained. Such a company will also remain liable in some circumstances for any breaches of the relevant APPs by the overseas recipient.
Since the Privacy Amendment Act refers to disclosure to overseas recipients (rather than being limited to actual datatransfer overseas) these rules would appear to apply whenever the information becomes available to an overseas recipient (for example, to a remotely located user or member of a support team), even if storage of the data remains in Australia. An arguably “reasonable” step to ensure compliance with privacy law by a data recipient is to seek to place it under a contractual obligation to comply with such law. It also seems arguable that by placing data in an encrypted state or even by locking down data through access controls and password protection it may be possible to store data overseas but to not “disclose” it to an overseas recipient. This new principle may arguably be better suited to the needs of cloud users than the current NPP9 which is triggered by a “transfer” of information overseas not a “disclosure” of information. Any judicially tested construction of the APPs will take some time to emerge after the March 2014 introduction.
In order to satisfy Australian businesses of the commitment of the cloud providers to comply with Australian privacy law, we looked for provisions in the cloud contracts surveyed providing a commitment to compliance with Australian privacy law, together with more specific provisions relating to location of data and foreign government access.
The picture revealed is very similar to that of the 2011 White Paper. While the specific privacy compliance needs of Australian companies are clearly taken seriously by some providers, others base their contracts on privacy laws of other jurisdictions, in particular the US and Europe. As a consequence many of the provisions fail to take account of specific obligations under Australian privacy law.
i. Privacy obligations in general
Many of the United States based providers referred to the US/EU Safe Harbour Privacy Framework as the privacy standard to which they would comply.
Oracle provides, as part of its contractual documentation, a data processing agreement, which provides good coverage in relation to privacy rights in a number of respects, several of which are discussed further below.
Several of the contracts sought to define the customer as the ‘data controller’ and the provider as a ‘data processor’ in terms of those concepts as provided for under the EU Data Protection Directive 95/64/EC. Under the EU Directive, data processors have more limited obligations than data controllers with respect to data in their possession. Those concepts do not exist in Australian privacy law, under which any organisation (within the relevant definition) has the same obligations with respect to information held by it. This could potentially lead to an underestimation of the obligations of the cloud provider under Australian privacy law. Such clauses did however also include provision that as data processor, the cloud provider would act on the customer’s instructions with respect to any personal data, which may provide customers with an ability to lay down any necessary requirements in that regard. This may however create additional expenses, with at least one cloud contract requiring that the customer pay for any
ii. Offshore transfer of data
It is in the very nature of public cloud services, and indeed one of the advantages in terms of scale and capacity, that the services may be provided from anywhere in the world, and potentially many places in the world. However this can create significant difficulties for a customer from a privacy perspective, and is an issue which will need to be considered carefully before entering a cloud environment.
It is perhaps unsurprising that many of the cloud contracts surveyed expressly permit the provider to transfer data globally, or at least to all countries in which the provider has facilities.
Given the significant concerns of Australian businesses in relation to such data transfer, particularly in light of the upcoming requirements of the Privacy Amendment Act, it is unsurprising that several of the Australian providers (for example Cloud Central and Ninefold) commit to maintaining data in Australian data centres, and market themselves on that basis.
However at least one Australian provider specifically maintained the ability to transfer data outside of Australia to deliver relevant products, and included consent by the customer to this in their terms.
Several of the overseas providers also limit the regions to which data will be transferred, at least in some respects. One provides that the customer may specify the regions in which its content will be stored and accessible and agrees that the content will not be moved without notification unless required by law or governmental request. Another provides that the order will specify the data centre region in which the services environment will reside. Other services may be provided from elsewhere, for example, service administration and support, professional services and disaster recovery services.
In light of the increased obligations with respect to trans-border data flow contained in the Privacy Amendment Act, customers would appear to need to seek either stronger commitments from cloud providers as to the location of their data or stronger commitments to comply with Australian privacy law. A difficulty arises as to how the level of informed consent from the data owner required to displace other cross border transfer requirements could be obtained if the location of the personal data is not known. These issues will have an increasing focus for Australian companies particularly in light of the increased powers of the regulator to accept enforceable undertakings and to seek civil penalties of up to $1.1 million in the case of serious or repeated cases of breaches of privacy. These increased powers are to come into effect in March 2014.
iii. Foreign government access
Much has been written about the ability of the United States government to access data under the USA PATRIOT Act 2001 as it is commonly known8. Under this legislation, brought in as a response to the events of September 11, 2001, United States governmental agencies have a range of powers to access data held by US corporations and their subsidiaries, wherever they may be based, or data held in the US by non-US corporations. This could include data held by US cloud providers in data centres around the world. Commentators have different views as to the consequence of a conflict between a US law requiring the provision of data for law enforcement purposes and a foreign national law preventing disclosure off-shore.
However despite the publicity surrounding the USA PATRIOT Act, a study conducted last year indicated that the ability of governments to access foreign data is by no means unique to the United States. A Hogan Lovells study, released by the think tank, the Open Forum Academy, surveyed the laws in ten countries, and found that all ten allow the government access to data held by a cloud provider to assist with the course of an investigation. In eight of the ten countries, cloud providers may voluntarily provide data to the relevant government in response to an informal request9. However the fact that many global cloud providers are US based and the perception that the United States government is far more likely to use the powers given to it, has driven commentators to continue to focus on the risks posed to data in the cloud subject to US jurisdiction10.
Most of the cloud contracts we surveyed contained a provision which is generally standard in most privacy policies, allowing the provider to disclose data to meet an enforceable governmental request or any legal obligation. With very few exceptions, the contracts did not commit to notifying the customer if data had been disclosed in this manner, something which in any event might well be prohibited under legislation such as the USA PATRIOT Act. Some contracts went even further to provide for the ability of the provider to choose to disclose information in response to governmental requests.
One contract which did appear to go some way to attempt to alleviate customer concerns in this regard was that of Microsoft. Its Office 365 Privacy Statement provides:
“We will not disclose Customer Data to law enforcement unless required by law. Should law enforcement contact us with a demand for Customer Data, we will attempt to redirect the law enforcement agency to request it directly from you. As part of this effort we may provide your basic contact information to the agency. If compelled to disclose Customer Data to law enforcement, we will use commercially reasonable efforts to notify you in advance of a disclosure unless legally prohibited.”
The commitment to at least attempt to redirect the relevant law enforcement agency directly to the customer and to notify the customer in advance of any disclosure (if permitted by law) goes at least some way (to the extent possible) to mitigating the risks around foreign government access.
Oracle also deals with this topic in its data processing agreement as follows:
“Except as otherwise required by law, Oracle will promptly notify Customer of any subpoena, judicial, administrative or arbitral order of an executive or administrative agency or other governmental authority (“demand”) that it receives and which relates to the Personal Data Oracle is processing on Customer’s behalf. At Customer’s request, Oracle will provide Customer with reasonable information in its possession that may be responsive to the demand and any assistance reasonably required for Customer to respond to the demand in a timely manner. Customer acknowledges that Oracle has no responsibility to interact directly with the entity making the demand.”
The vast majority of Australian companies will not have any commercial issue with compliance with requests from law enforcement bodies. Nevertheless the potential for access to data persists as a discussion point in the negotiation of cloud contracts. At the time of this review some providers have a more nuanced answer for this customer concern.
3.2 Security measures
Security remains an important concern for cloud consumers. Public cloud, in particular, presents additional risks arising from the co-tenanting of multiple customers within the cloud infrastructure and a lesser ability to contractually specify any specific security measures on an enterprise by enterprise basis. As well as a practical business risk, security also presents legal issues, in particular around privacy, bearing in mind in particular the obligation in the Privacy Act 1988 to take reasonable steps to keep personal information secure11.
A number of providers continue to disclaim responsibility for security measures with terms which place the onus on the client to ensure security of its data12. The following are typical of these clauses:
“[We are] not responsible for any unauthorised access to, alteration of, or the deletion, destruction, damage loss or failure to store any Content or other data which you submit in connection with your account.”
“The Customer is responsible for:
(d) ensuring the security of any communications made using the Services or any Customer Equipment connected to the Services”
However more than half of the providers surveyed in this 2013 review provide some assurances as to security. The level of assurance varies. Some clauses promise “reasonable” or “appropriate” security measures, such as the following:
“We shall maintain appropriate administrative, physical, and technical safeguards for protection of the security, confidentiality and integrity of Your Data.”
“[We] agree to maintain reasonable and appropriate measures related to physical security to protect Customer Content.”
“[We] will use commercially reasonable security technologies (such as encryption, password protection and firewall protection) in providing the Service…”
Other contracts define the security measures to be provided by reference to specific measures contained elsewhere. For example:
“[Provider] agrees to follow security procedures at least as stringent, in [provider’s] reasonable judgment, as those described at [web site].”
In this example the relevant web site describes the following in relation to operational security:
• ISO 27001/2 based policies, reviewed at least annually
• Documented infrastructure change management procedures
• Secure document and media destruction
• Incident management function
• Business continuity plan focused on availability of infrastructure
• Independent reviews performed by third parties
• Continuous monitoring and improvement of security program
Another provider promises:
“We will implement reasonable and appropriate technical and organizational measures, as described in the security overview applicable to the online service to help secure your customer data processed or accessed by the online service against accidental or unlawful loss, access, or disclosure.”
The relevant security overview confirms that the provider has established and agrees to maintain a data security policy that complies with the ISO/IEC 27000 series of standards, the ISO/IEC 27002 code of best practices for information security management, and ISO 27001 standards for the establishment, implementation, control, and improvement of the Information Security Management System.
One provider measures the security in place by reference to security measures used for its own data:
“All facilities used to store and process the Application and Customer Data will adhere to reasonable security standards no less protective than the security standards at facilities where [provider] processes and stores its own information of a similar type. ‘Provider” has implemented at least industry standard systems and procedures to ensure the security and confidentiality of an Application and Customer Data, protect against anticipated threats or hazards to the security or integrity of an Application and Customer Data, and protect against unauthorised access to or use of an Application and Customer Data.”
The willingness of some cloud providers to contractually bind themselves to meet the standards referred to in promotional material, such as that provided on their web sites, is a welcome step. At least several of the providers who offer more general assurances as to security in their contracts, refer to specific certifications or accreditations on their web sites or other material. Arguably the adoption of such standards in their marketing material should set the benchmark for what would be considered “reasonable” or “appropriate” in terms of the cloud contracts which offer contractual assurances of that nature. However a firm contractual commitment to meet the standards which the provider advertises that it meets, and to have ongoing independent audit reports available to provide continuing assurance, would be preferable for customers.
It is probably the case that where a cloud provider makes representations about its security practices and accreditations on its website or in marketing material it could be in breach of the Australian Consumer Law if these representations are untrue or misleading13.
Notably the Oracle data processing agreement referred to above provides the customer with substantive contractual rights in relation to ongoing assurance that security standards are maintained. This is achieved in part through the right to audit in relation to security. In particular:
“Customer may audit Oracle’s compliance with the terms of the Agreement and this Data Processing Agreement up to once per year. If a third party is to conduct the audit, the third party must be mutually agreed to by Customer and Oracle and must execute a written confidentiality agreement acceptable to Oracle before conducting the audit.
To request an audit, Customer must submit a detailed audit plan at least two weeks in advance of the proposed audit date to Oracle Corporation’s Global Information Security organization (“GIS”) describing the proposed scope, duration, and start date of the audit. Oracle will review the audit plan and provide Customer with any concerns or questions (for example, any request for information that could compromise Oracle security, privacy, or employment policies).Oracle will work cooperatively with Customer to agree on a final audit plan.
The audit must be conducted during regular business hours at the applicable facility, subject to Oracle policies, and may not unreasonably interfere with Oracle business activities. If the information required for such an audit is not contained in a SSAE 16/ISAE 3402 Type 2 or similar report, Oracle will make reasonable efforts to provide requested information to the auditor.”
ii. Governmental agency security requirements
Cloud providers offering services to government agencies are likely in any event to be required to adhere to certain standards and obtain certification in that regard. In the United Kingdom the G-Cloud procurement framework has been developed to assist government departments in procuring cloud services. Security accreditation is required for all services which will hold information assessed at Business Impact Level 1/2 or above14. Very few services are likely to fall below this level, so the accreditation requirements for BIL1/2 can be seen as a baseline for security requirements. BIL1/2 accreditation is largely based on the use of ISO 27001 certification.
A similar approach is evidenced in the Draft Report on Cloud Service Provider Certification Requirements for the Australian Government (“the Draft Cloud Certification Report”) issued in December 2012 by the Department of Finance and Deregulation. The Report responds to the Australian Government Cloud Computing Strategic Direction (“the Cloud Strategy”)15 which called for an investigation into the need for a risk-based cloud service provider certification program.
The Draft Cloud Certification Report refers to two existing initiatives:
(a) the Data Centre as a Service Multi-User List (DCaaS MUL)16 which was established in October 2012 and provides governmental agencies with a list of cloud providers for low risk, low cost and short duration projects; and
(b) The Australian Government Commercial Service Providers Assurance Framework17 (AGSCPAF) which is being developed in relation to digital mail boxes, data vault and authentication services.
In light of the existence of these two programmes underway, the Draft Cloud Certification Report recommends that in the medium term, the DCaaS MUL be expanded to include certification of cloud and cloud-like services. In the long term, expansion of the AGSCPAF to include cloud provision is recommended. In either case, the Draft Cloud Certification Report recommended that certain requirements would need to be satisfied, and these include security accreditation based on similar business impact levels to those used in the G-Cloud, which would incorporate ISO/IEC 27001 certification at the BIL 1 and 2 level.
iii. Notification of security breaches
There is no requirement under current Australian privacy law or the amendments to be introduced by the Privacy Amendment Act to notify data subjects of any known or suspected breach of security which might affect the integrity and/or privacy of their data.
However there is an ongoing and sustained debate as to whether notification should become mandatory.
The 2008 Australian Law Reform Commission (ALRC) Report on Privacy recommended such a requirement18 noting that data breach notification can serve to protect personal information from any further exposure or misuse, and encourages agencies and organisations to be transparent about their information-handling practices. Data breach notification requirements are not reliant on establishing that an organisation has not complied with its data security obligations, or designed as a form of punishment. Rather, by arming individuals with the necessary information, they have the opportunity to take preventative action against damage.
On the other hand, opponents argue that such a statutory requirement is unnecessary and places an undue burden on business19. Notably several cloud providers were among those who argued against the adoption of such a requirement in submissions made to the ALRC on this topic.
The ALRC recommendation was not adopted in the Privacy Amendment Act. The Attorney General’s Department released a discussion paper late last year calling for public submissions both on the question of whether such an obligation should be entrenched in law, and how it would work in practice.
In the meantime, the Office of the Australian Information Commissioner (OAIC) has adopted Guidance recommending that if there is a real risk of serious harm as a result of a data breach, the affected individuals and the OAIC should be notified20. Although the Guidance is voluntary, the OAIC “highly recommends” that the procedures are followed.
It is also worth noting that many overseas jurisdictions do have mandatory data breach notification requirements, including nearly every state in the United States and the European Union’s e-data Directive covering the telecoms sector22. The New Zealand Privacy Commissioner has also issued voluntary guidance advocating data breach notification once certain threshold criteria are met .
Of the cloud contracts surveyed, a minority contained any reference to data breach notification. This mirrors the results of the 2011 White Paper which found that very few contracts specified what would happen in the event of a data breach.
There were some examples of providers willing to agree to notify in the case of data breach. For example, the Rackspace Cloud Terms of Service contain an obligation to follow security procedures at least as stringent as those contained in its website security practices document. This document provides that Rackspace will immediately report any unauthorised access or release of information of which it becomes aware.
Oracle’s data processing agreement takes a comprehensive approach to security breaches in respect of personal information. Its provisions on the subject include the following:
“Oracle shall promptly investigate any security breach and take reasonable measures to identify its root cause(s) and prevent a recurrence. As information is collected or otherwise becomes available, unless prohibited by law, Oracle will provide Customer with a description of the security breach, the type of data that was the subject of the breach, and other information Customer may reasonably request concerning the affected persons. The parties agree to coordinate in good faith on developing the content of any related public statements or any required notices for the affected persons.”
Several other providers take a middle ground. One example of this is the following provision:
“In the event that PII [personal information] is acquired, or is reasonably believed to have been acquired, by an unauthorized person and applicable law requires notification [emphasis added], [provider] will notify the affected individual of the breach by email or ticket on the Customer Portal …. Notice will be given promptly, consistent with the legitimate needs of law enforcement and any measures necessary for [provider] or law enforcement to determine the scope of the breach and to ensure or restore the integrity of the data system.”
The provision further provides that notification may be delayed if it would impede a criminal investigation. Given the limitation of the clause to circumstances in which data breach notification is required under applicable law, the provider would not have any obligation to notify Australian customers of a data breach.
A further provider states in its contract that:
“[Provider] may notify Customer of leaks or exposure of private data, but except to the extent required by law, [provider] is not required to provide such notification.”
3.3 Service availability and service credits
Service availability is a key concern for cloud consumers and rightly so. A 2012 report by The International Working Group on Cloud Computing Resiliency estimated, based on press releases reporting on outages of 13 cloud providers, that the average downtime between 2007 and 2012 was 7.5 hours per year25. An outage for even a relatively modest period of time can have significant consequences for customers, particularly where ‘mission critical’ systems are operated from the cloud.
Targets for cloud service availability are most commonly governed by service level agreements (“SLAs”) which often provide a “guarantee” of the percentage of time for which the service will be operational. The remedy for failure to meet the guarantee is typically a service credit provided to the customer to offset fees for the month in question. Service level guarantees and representations are another area where representations about remedies, availability and past performance may come under increasing scrutiny by regulators if there are found to be any misleading representations26.
Among the providers surveyed, in all but one case, we found reference to SLAs or guarantees within the body of the relevant cloud contract as to service level availabilities. In some cases we were unable to locate an SLA agreement, but reference was made on the relevant web site to guaranteed availability levels. Availability levels varied from 99% to 100%, with most having a target of at least 99.9% availability. Many providers target 100% availability. In some cases, a range of options are available depending on the plan selected.
All SLAs we have seen referred to outage time which would not be included for the purposes of service credit calculation. Some of the most common of these were:
• Scheduled maintenance;
• Force majeure events;
• Outage resulting from misuse of the service; and
• Outages elsewhere on the Internet.
Some contracts contained an even more aggressive list of exceptions to outage time, one including circumstances such as “unavailability of management, auxiliary or administration services, including administration tools reporting services, utilities, or other services supporting core transaction processing” and “hacker or virus attack” and “denial of service attacks”.
Service levels were calculated by a variety of methods. In most cases, the availability percentage relates to the percentage of time during a month during which the service is accessible. However in several cases, the availability percentage is calculated by reference to the proportion of service request failures from the total service requests made. For example:
“[Provider] measures service availability by tracking fulfilled requests or successful requests. The [provider] service is considered unavailable starting when valid web service requests that are received by [provider] controlled server fail unintentionally three consecutive times, ending when valid request are serviced … Service availability is calculated by subtracting from 100% the total number of Failures divided by the total number of requests received in a billing cycle.”
Service level credits vary both in method of calculation and level of credit. In a minority of cases there is no evidence that service credits are available at all, rendering the service target rather meaningless. In one such case there is also a prohibition on the customer monitoring or seeking to measure the availability or performance of the service, subject to limited exceptions, due to “potential adverse impact on service performance and availability”.
Many credits are calculated as a percentage of the monthly fees for the given month, the percentage varying depending on the extent to which the downtime exceeds the guarantee. For example, in the following case with a 99.999% uptime guarantee, the following table sets out the credits available if this target is not met:
|Percentage of uptime||Credit Applied|
|99.999% or higher||No credit|
|Between 99.99% and 99.999% uptime||10% credit|
|Between 99.9% and 99.99% uptime||20% credit|
|Between 99% and 99.9% credit||30% credit|
In other cases a credit is available for each session of downtime of a particular length:
“…you are entitled to a credit in the amount of 5% of your monthly recurring fee for the affected hosted system per half hour of power outage or network downtime, up to 100% of the monthly recurring fee for the affected components for any calendar month.”
Notably, in several cases employing this type of formula, the contract specified that no credit was available at all for a downtime period of less than the specified length. In terms of system downtime, 30 minutes is a significant period, for which no credit would be available under such formulation. In other cases, it was not clearly specified whether the reference to a credit for a particular period of time would include a portion thereof.
Care must also be taken in analysing the extent of the credits available, to pay attention to any triggering events required to allow ‘downtime’, for which credit was available, to commence. In the above example a further provision entitled“Measurement of Time Periods” states:
“For the purpose of determining whether a credit is due, time periods will be measured from the time stamp generated by our ticket system, or the time an interruption is recorded in our monitoring system, as applicable. You may open a support ticket to document the start time for a support request or other incident, or if you contact us by telephone to request support, we will open a ticket. If you contact us by phone, there may be a delay between the time of the call and the time we open a ticket.”
Many of the contracts included a cap on the available credit, in most cases at 100% of the monthly fees, but in one case at 50%, a significant limitation. The contracts also generally included requirements as to how the credit was to be claimed. In most cases the customer was required to make a claim for the credit within a specified time period. These time periods ranged from 48 hours from the beginning of the downtime to 30 days from the end of the month in which the downtime occurred. Several contracts also required that supporting information be provided and in one case the customer was required show that their use of the service had been “adversely affected”. Such a myriad of requirements would appear to make it difficult for customers to actually claim service credits. In particular the requirement to provide supporting documentation showing the downtime may well mean that many actual downtimes are not credited for.
It is important for cloud customers to consider SLAs in their entirety bearing in mind all the provisions and exceptions. In one case, the provider offers a “10,000% guarantee”, that is a credit equivalent to 100 times the customer’s fees for the impacted service for the duration of the failure. However on closer inspection a number of limitations are revealed:
- No credit can exceed 100% of the customer’s fees for the month; and
- The downtime will only be measured from the time the customer or a support representative files a case; and
- The minimum period of failure eligible for a credit is 15 minutes and shorter periods will not be aggregated and in the event that multiple periods of failure overlap in time credits will not be aggregated and the customer will receive credit only for the longest such period of failure; and
- The maximum credit during a single calendar year, for all service features combined, is two months’ service fees, regardless of the length of failure or number of occurrences; and
- In the event that credits for any calendar month exceed 25% of the provider’s revenues for such period, it may reduce and pro-rate the value of the credits given to all customer for such period so that the aggregate credit given to all customers does not exceed 25% of revenues; and
- Credits must be requested within 48 hours of the start of the failure.
It appears to us that SLAs must be scrutinised carefully to determine their overall effect and so that customers are aware of the requirements to be met in order to seek service credits.
3.4 Assistance with/ability to transition out on termination or expiry of services/deletion of data
The ability of a customer to retrieve its data on termination or expiry of cloud services is not only critical to the ongoing performance of its business, but may also affect compliance with legal obligations such as those in privacy law to protect personal data from misuse or loss , corporate record keeping requirements and other duties such as those encountered in discovery in legal proceedings. For example, the Corporations Act 200128 requires that financial records of a company are to be retained for 7 years after the completion of the transactions to which they relate. The Australian Tax Office also requires that records be kept for 5 years. Governmental agencies are also subject to a range of additional obligations requiring them to keep records for various purposes.
In cases where a very large amount of data is stored in the relevant cloud facility, the retrieval of data may not be simple. It may not be practicably possible to download the data remotely and arrangements may be necessary for physical retrieval of the data. These arrangements should be made in advance.
In the event that a cloud contract is terminated and the data held in the system cannot be effectively extracted, the ability of a business/agency to comply with such legal obligations is put at risk.
Equally, the ability to ensure that personal data is deleted from a cloud provider’s system is a key requirement to ensure compliance with privacy law, in particular National Privacy Principle 4.2.
Few of the contracts surveyed contained strong provisions requiring the provider to assist with transition out and/or the recovery of data, even at an additional cost. Many simply specified that the customer’s right to use the service terminates immediately on cancellation of the service and that data could or would be deleted immediately thereafter.
Some terms provided a period of time after termination in which a customer could migrate data out of the relevant cloud environment. The time periods provided ranged from 15 days to 90 days.
In other cases some post-termination assistance was offered in accordance with whatever assistance might generally be made available to customers. These clauses typically did not specify what type of service was generally made available to customers and were generally framed in such a manner as to place them entirely at the discretion of the provider. They also often exclude circumstances where the contract is terminated for cause, and allow the provider to specify fees and additional terms in relation to such assistance. As such many of the deficiencies commented on in the 2011 White Paper remain. An example of such a clause is as follows:
“Following the suspension or termination of the right to use the Services for any reason other than a for cause termination … Customer shall be entitled to take advantage of any post-termination assistance [provider] may generally make available with respect to the Services, such as data retrieval arrangements [provider] may elect to make available. [Provider] may also endeavour to provide you unique post-suspension or post-termination assistance, but [provider] shall be under no obligation to do so. Customer’s right to take advantage of any such assistance, whether generally made available with respect to the Services or made available uniquely to Customer, shall be conditioned upon Customer’s acceptance of and compliance with any fees and term [provider] may specify for such assistance.”
A good example of a provision designed to ensure that the parties to engage cooperatively in the transition out process comes from Macquarie Telecom:
“If Services are cancelled for any reason:
(a) where prior notice of the cancellation is given, the Customer and Macquarie Telecom must co-operate to agree a schedule for the orderly transfer or shutdown of each of the cancelled Services on or before the effective date of the cancellation;
(b) where no prior notice of cancellation is given, or where no agreement is reached under paragraph (a) by the earlier of:
(i) the date thirty days before the effective date of the cancellation; and
(ii) 30 days after the notice of cancellation is given,
Macquarie Telecom may notify the Customer of a schedule for the shutdown of the cancelled Services which Macquarie Telecom consider meets as nearly as practicable those requirements of the Customer which have been made known to Macquarie Telecom.”
Even in circumstances where the parties are unable to agree on a schedule, Macquarie is obliged to seek to meet the requirements of the customer which have been made known to it.
Salesforce also includes a specific provision to provide data in a specific format, providing certainty to customers, although it is unclear what is to happen in cases where the data is so large that it may not be convenient to download it in the specified fashion:
“Upon request by You made within 30 days after the effective date of termination of Purchase Services subscription, we will make available to You for download a file of Your Data in comma separated value (.csv) format along with attachments in their native format.”
As to the deletion of data, many contracts specify that data will be deleted within a certain timeframe (albeit without any provision as to how the customer will retrieve such data before deletion). In some cases the obligation is limited to personal information. For example:
“Upon Customer’s written request, following termination or expiry of [relevant agreements] [provider] will destroy or return to Customer all Content that Customer identifies as personal information.”
However other providers do not have any specific obligation to delete data at the end of the relationship, although retaining the discretion to do so. In several such cases the relevant privacy policies also make no reference to deletion of personal data on termination of the service. This presents a significant difficulty to customers in ensuring that they are able to comply with their own privacy obligations.
We mention in passing the UK Government’s data extraction/removal provisions from the G-Cloud Services II Framework Agreement. Some 458 cloud suppliers have signed up to offer cloud based services to the UK Government based upon the Framework Agreement. In February 2013 a media report was made that Microsoft Office 365 had secured G-Cloud accreditation29.
The requirements of the Framework Agreement substantially exceed the level of attention to “transition out” issues we observed in our study of cloud contracts. On one view the UK G-Cloud represents no more than the increased bargaining power of a substantial government IT budget but it also represents a list of commercial/technical and legal issues which will arise for all enterprise customers for cloud products. The relevant clause from the Framework Agreement reads:
“Suppliers will provide a “simple” and “quick” exit process to enable consumers to move to a different supplier for each of their G-Cloud Services and/or retrieve their data. Suppliers will commit to providing details of this, clearly and unambiguously in the Service Definition for each service. This will include, but not be limited to:
- The data standards that will be in use (within the service).
- A commitment to returning all consumer generated data (e.g. content, metadata, structure, configuration etc.) and a list of the data that will be available for extraction. Where there is a risk of confusion, data that will not be available for later extraction will also be published.
- The formats/standards into which data will be able to be extracted and preferably a list other common services/technologies to which an export/import mechanism is available.
- A price for the extraction of consumer generated data (or the migration to another service provider’s service).
- Confirmation that the Supplier will purge and destroy (as defined in security accreditation for different ILs) consumer data from any computers, storage devices and storage media that are to be retained by the Supplier after the end of the subscription period and the subsequent extraction of consumer data (if requested by the consumer).”30
3.5 Ability of provider to unilaterally vary terms
The ability to unilaterally vary a contract is a powerful right, which undermines the ability of a customer to negotiate appropriate safeguards in the contract and ensure they remain in place for the life of the service provision.
Many of the contracts we reviewed allow the cloud provider to unilaterally vary the terms of the contract by giving notice of the revised version, usually on its web site. Most contracts containing this type of clause also provide that continued use of the service amounts to acceptance of the modified terms. In one case, the provider purports to reserve the right to update and change the terms from time to time without notice. In such circumstances the consumer has very little ability to avoid any modification to the contract, and in many cases is unlikely to even become aware of the change, short of regularly checking the relevant website, until and unless s/he seeks to rely on it at a later stage.
In some cases the ability to modify in this manner is limited to changes which will not have a material adverse impact on the customer, or similar restriction. Such a restriction may mean that the clause will not cause detriment to the customer.
However other providers reserve only much more limited rights of modification. The Salesforce contract, for example, provides that no modification will be effective unless in writing and either signed or accepted electronically by the party against whom the modification is to be asserted.
In some cases terms may be amended by the provider, but will only come into effect on renewal of the contract. This at least affords an opportunity for any changes to be renegotiated before the contract is renewed.
3.6 Choice of law/jurisdiction and dispute resolution clauses
The choice of law provision of a contract is often viewed as a ‘boilerplate’ clause, however it can have significant implications, particularly in cases where the parties to a contract are located in different jurisdictions.
For an Australian business, the right to take legal action in the United States, for example, may in practice provide it with very little real ability to vindicate its legal rights. On one view, a cloud provider offering services in another jurisdiction might be better placed to take on the burden of determining the effect of the law in a jurisdiction in which it provides its services and litigating its rights in that jurisdiction, rather than requiring its customers to accept the law of, and take action in, its home jurisdiction. On the other hand, a Court order obtained in Australia presents the need to take the additional step of enforcing the order in the cloud provider’s home jurisdiction.
As might be expected, the choice of law and jurisdiction clauses surveyed tend to follow the home jurisdiction of the provider. Thus, the Australian providers designate the law of one of the Australian states as applying to the contract and provide for the Courts of such state to have exclusive jurisdiction over any disputes.
Most of the United States based providers also designate their home state in this manner. Notable exceptions are:
(a) Salesforce, which provides for the governing law and courts having jurisdiction to vary depending on the domicile of the user by reference to region. In the case of customers based in countries in the Asia-Pacific region, the governing law and Courts having jurisdiction are those of Singapore; and
(b) Oracle, which adopts the governing law and exclusive jurisdiction of New South Wales.
In general, the trends in respect of the topics we have reviewed in the cloud contracts remain similar to those discussed in the 2011 White Paper. In a number of respects there are questions as to whether the cloud contracts available allow customers to meet applicable regulatory obligations. In some cases there are exceptions which may be held up as best practice and provide a useful benchmark for negotiation of cloud contracts.
Changes in the Australian privacy laws together with the increased focus on Government use of the cloud and the necessary certification of cloud providers for that purpose are likely to provide a focus point for Australian consumers of cloud services to seek greater commitments, particularly in relation to privacy and security concerns. This may also provide an even greater opportunity for Australian cloud providers to differentiate themselves within the Australian market with a firm commitment to meet Australian requirements and satisfy customers that the cloud can deal with the inherent privacy and security concerns which remain at the forefront of customers’ minds.
1VMWare and Forrester Research, 3rd Annual VMware Cloud Index 2012:http://info.vmware.com/content/APAC_ANZ_Enterprise_Cloud_Index?src=CloudIndexVanityWM
2A full list of the contracts surveyed is contained at Appendix 1
3Truman Hoyle Lawyers, 5 April 2011
4See sections 6C and 6D, Privacy Act 1988
5National Privacy Principle 2, Privacy Act 1988
6National Privacy Principle 4, Privacy Act 1988
7National Privacy Principle 9, Privacy Act 1988
8The full name is the Uniting (and) Strengthening America (by) Providing Appropriate Tools Required (to) Intercept (and) Obstruct Terrorism Act of 2001.9http://www.computerworld.com/s/article/9227403/Study_Patriot_Act_doesn_t_give_feds_special_access_to_cloud_data?taxonomyId=158&pageNumber=1
10See, for example, the Google “Transparency Report” for the 6 months to December 2012 accessed in February 2013 at: http://www.google.com/transparencyreport/userdatarequests/countries/?t=table. This records that in the period July to December 2012 there were 21,389 government requests for user data access, 8,438 or close to 40% of all requests were from the US Government, next highest was the Indian Government with 2,431 requests or 11%, whilst Australian Government law enforcement requests numbered 584 (relating to 711 individual user accounts), the 7th highest number of requests of any government globally.
11National Privacy Principle 4.1
12See the 2011 White Paper for similar conclusions: section 3.4, pages 10-11.
13Section 18 of the Australian Consumer Law contains a general prohibition on conduct which is misleading or deceptive or is likely to mislead or deceive. Section 29 also contains a specific prohibition on misleading representations that services are of a particular standard or grade when they are not. Litigation involving pre-contractual representations in an IT project in RACV v Unisys  VSC 300 makes clear that entire agreement clauses will not exclude liability for misleading and deceptive conduct under the Australian Consumer Law.
14For further information on accreditation see G-Cloud Information Assurance Requirements and Guidance, 10/05/12:http://gcloud.civilservice.gov.uk/files/2012/05/G-Cloud-Services-IA-Requirements-and-Guidance-version-1-0-_for-publication_1-2.pdf.
18Australian Law Reform Commission Report 108, section 51
19See, for example, the submissions made to the Australian Law Reform Commission in preparation of Report 108 recorded, in particular, at paragraphs 51.50 to 51.56.
20Data breach notification: a guide to handling personal information security breaches – April 2012:http://www.oaic.gov.au/publications/guidelines/privacy_guidance/Data_breach_notification_guide_April2012FINAL.pdf
212009/136/EC  OJ L337/11
22See the summary contained in the New Zealand Law Commission’s 2011 Report: Review of the Privacy Act 1993:http://www.lawcom.govt.nz/sites/default/files/publications/2011/08/web_pdf2_review-of-the-privacy-act-1993-webpdf-72dpi-chapter-7-appendix_1.pdf.
23Key Steps for Agencies in Responding to Privacy Breaches and Privacy Breach Checklist, New Zealand Privacy Commissioner, 2008
24See section 3.4, page 11.
25Downtime statistics of current cloud solutions: http://iwgcr.org/wp-content/uploads/2012/06/IWGCR-Paris.Ranking-002-en.pdf
26See for example the March 2012 adjudication by the UK Advertising Standards Authority scrutinising an advertising claim of “100% network uptime in 2011” which was found to be misleading in light of network failures:http://www.asa.org.uk/Rulings/Adjudications/2012/3/UK2-Group/SHP_ADJ_179995.aspx).
27In particular, National Privacy Principle 4.1
|OpSource Cloud Terms
OpSource Cloud Hosting Service Level Agreement
Downloaded 22/01/13 Downloaded 04/02/13
|Nirvanix Cloud Terms and Conditions31
Nirvanix Service Level Agreement
|Oracle Cloud Services Agreement
Oracle Cloud – SaaS Hosting and Delivery Policies
Oracle Data Processing Agreement for Cloud
|VM Vault Secure Hosted Virtualisation Service Agreement
VM Vault Secure Private Cloud Service Level Agreement
|Softlayer Master Services Agreement32
Softlayer Privacy Agreement
|Salesforce Master Subscription Agreement
Salesforce Privacy Statement
|Macquarie Telecom Services Agreement Trading Terms
Macquarie Telecom Privacy Statement
|Joyent Terms of Service
Joyent Cloud Hosting Service Level Agreement
IBM Online Privacy Statement Information on IBM
Cloud management service level agreements
|GoGrid Terms of Service
GoGrid Service Level Agreement
|Cloud Central Terms & Conditions
|Melbourne IT – Hosting Terms and Conditions33
|Jun 2011 Aug 2012|
|Ninefold Customer Agreement
Ninefold Service Level Agreement
|Rackspace Cloud Terms of Service
Rackspace Cloud Servers SLA
Rackspace Privacy Statement
|Google Cloud Storage Terms of Service
Google Cloud Storage, Google Prediction API, and Google BigQuery
|SAP Terms and Conditions for SAP
Cloud Services SAP NetWeaver
Cloud Supplemental Terms and Conditions SAP Privacy Statement
Aug 2012Downloaded 05/02/13
|Telstra Cloud Services Customer Terms
Telstra General Terms for Corporate Customers
Telstra Privacy Statement
|Microsoft Online Subscription Agreement
Microsoft Exchange Online SLA – Office 365 Dedicated Plans
Microsoft Privacy Statement: Office 365 Privacy and Security Supplement
|Amazon Web Services Customer Agreement
Amazon S3 Service Level Agreement
Amazon.com Privacy Notice
32No Service Level Agreement found
33No Service Level Agreement found