Australia: Cloud Computing in 2013 - What legal commitments can you expect from your provider?

1. INTRODUCTION

A recent VMWare and Forrester Research annual survey published in November 2012¹ 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")² . 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 Conditions³ ("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:

1. Privacy issues, location of data and foreign government access;
2. Security measures and notification of security breaches;
3. Service availability and service credits;
4. Assistance with/ability to transition out on termination or expiry of services;
5. Ability of a provider to vary terms;
6. Choice of law and jurisdiction clauses.

3. RESULTS

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 million⁴. 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 met⁵, to take reasonable steps to protect such information from misuse or loss⁶, and only to allow transfer of the data out of Australia under certain conditions⁷.

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 APP9, 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 data transfer 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.

1. Privacy obligations in general

Almost all the providers had an available privacy policy applicable to cloud services, however the commitments in them, and the cloud contracts, varied. Several of the Australian providers made specific reference to compliance with the Privacy Act 1988. The privacy policies of others appeared generally compliant with Australian law, even if there was no specific reference to the relevant law. Cloud providers based outside of Australia generally did not provide any express commitment to comply with applicable data protection law, however some did promise more generally to comply with any applicable laws or regulations in the provision of the services, which arguably would include Australian privacy law, in the case of an Australian customer.

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

2. 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.

3. 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 known⁸. 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 request⁹. 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 jurisdiction¹⁰.

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:

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:

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

1. General

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 secure¹¹.

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 data¹². The following are typical of these clauses:

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:

Other contracts define the security measures to be provided by reference to specific measures contained elsewhere. For example:

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:

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:

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 misleading¹³.

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:

2. 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 above¹⁴. 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")¹⁵ 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:

1. the Data Centre as a Service Multi-User List (DCaaS MUL)¹⁶ 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
2. The Australian Government Commercial Service Providers Assurance Framework¹⁷ (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.

3. 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 requirement¹⁸ 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 business¹⁹. 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 notified²⁰. 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 sector²². 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.

The Microsoft Privacy Policy also contains a promise to notify of any unlawful access or unauthorised access to its equipment or facilities resulting in loss, disclosure, or alteration of Customer Data.

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:

Several other providers take a middle ground. One example of this is the following provision:

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:

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 year²⁵. 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 representations²⁶.

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:

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:

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:

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 2001²⁸ 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:

A good example of a provision designed to ensure that the parties to engage cooperatively in the transition out process comes from 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:

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:

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 accreditation²⁹.

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:

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:

1. 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
2. Oracle, which adopts the governing law and exclusive jurisdiction of New South Wales.

4. CONCLUSION

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.

Appendix 1

Document	Date
OpSource Cloud Terms OpSource Cloud Hosting Service Level Agreement OpSource Privacy Policy	Downloaded 21/01/13 Downloaded 22/01/13 Downloaded 04/02/13
Nirvanix Cloud Terms and Conditions31 Nirvanix Service Level Agreement	02/02/09 06/10/08
Oracle Cloud Services Agreement Oracle Cloud – SaaS Hosting and Delivery Policies Oracle Services Privacy Policy Oracle Data Processing Agreement for Cloud	Downloaded 08/02/13 01/12/12 05/05/10
VM Vault Secure Hosted Virtualisation Service Agreement VM Vault Secure Private Cloud Service Level Agreement VM Vault Secure Private Cloud Privacy Policy	Downloaded 21/01/13 Downloaded 04/02/13 Downloaded 04/02/13
Softlayer Master Services Agreement32 Softlayer Privacy Agreement	May 2012 Downloaded 05/02/13
Salesforce Master Subscription Agreement Salesforce Privacy Statement	07/01/13 08/06/12
Macquarie Telecom Services Agreement Trading Terms Macquarie Telecom Privacy Statement	10/08/10 12/01/11
Joyent Terms of Service Joyent Cloud Hosting Service Level Agreement Joyent Privacy Policy	Downloaded 21/01/13 Downloaded 04/02/13 Downloaded 04/02/13
IBM Terms of Use – IBM Commerce on Cloud IBM Online Privacy Statement Information on IBM Cloud management service level agreements	Sep 2012 01/10/11 Downloaded 05/02/13
GoGrid Terms of Service GoGrid Service Level Agreement GoGrid Privacy Policy	25/08/10 30/01/12 31/10/08
Cloud Central Terms & Conditions Cloud Central Privacy Policy Cloud Central FAQs	Downloaded 21/01/13 Downloaded 04/02/13 Downloaded 05/02/13
Melbourne IT – Hosting Terms and Conditions33 Melbourne IT – WebCentral Privacy Policy	Jun 2011 Aug 2012
Ninefold Customer Agreement Ninefold Service Level Agreement Ninefold Privacy Policy	30/08/12 Downloaded 05/02/13 Downloaded 05/02/13
Rackspace Cloud Terms of Service Rackspace Cloud Servers SLA Rackspace Privacy Statement	26/09/12 Downloaded 05/02/13 22/02/10
Google Cloud Storage Terms of Service Google Cloud Storage, Google Prediction API, and Google BigQuery SLA Google Privacy Policy	28/09/12 Downloaded 05/02/13 27/07/12
SAP Terms and Conditions for SAP Cloud Services SAP NetWeaver Cloud Supplemental Terms and Conditions SAP Privacy Statement	Aug 2012 Aug 2012 Downloaded 05/02/13
Telstra Cloud Services Customer Terms Telstra General Terms for Corporate Customers Telstra Privacy Statement	13/12/12 05/10/12 Downloaded 05/02/13
Microsoft Online Subscription Agreement Microsoft Exchange Online SLA - Office 365 Dedicated Plans Microsoft Privacy Statement: Office 365 Privacy and Security Supplement	Downloaded 21/01/13 Oct 2012 Dec 2011
Amazon Web Services Customer Agreement Amazon S3 Service Level Agreement Amazon.com Privacy Notice	15/03/12 01/10/07 06/04/12

Footnotes

¹VMWare and Forrester Research, 3rd Annual VMware Cloud Index 2012: http://info.vmware.com/content/APAC_ANZ_Enterprise_Cloud_Index?src=CloudIndexVanityWM
²A full list of the contracts surveyed is contained at Appendix 1
³Truman Hoyle Lawyers, 5 April 2011
⁴See sections 6C and 6D, Privacy Act 1988
⁵National Privacy Principle 2, Privacy Act 1988
⁶National Privacy Principle 4, Privacy Act 1988
⁷National Privacy Principle 9, Privacy Act 1988
⁸The full name is the Uniting (and) Strengthening America (by) Providing Appropriate Tools Required (to) Intercept (and) Obstruct Terrorism Act of 2001.
⁹http://www.computerworld.com/s/article/9227403/Study_Patriot_Act_doesn_t_give_feds_special_access_to_cloud_data?taxonomyId=158&pageNumber=1
¹⁰See, 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.
¹¹National Privacy Principle 4.1
¹²See the 2011 White Paper for similar conclusions: section 3.4, pages 10-11.
¹³Section 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 [2001] VSC 300 makes clear that entire agreement clauses will not exclude liability for misleading and deceptive conduct under the Australian Consumer Law.
¹⁴For 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.
¹⁵http://agimo.gov.au/policy-guides-procurement/cloud/
¹⁶http://agimo.gov.au/policy-guides-procurement/data-centres/
¹⁷http://agimo.gov.au/files/2012/04/ CommercialServiceProvidersAssuranceFrameworkdraft.pdf
¹⁸Australian Law Reform Commission Report 108, section 51
¹⁹See, 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.
²⁰Data 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
²¹2009/136/EC [2009] OJ L337/11
²²See 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.
²³Key Steps for Agencies in Responding to Privacy Breaches and Privacy Breach Checklist, New Zealand Privacy Commissioner, 2008
²⁴See section 3.4, page 11.
²⁵Downtime statistics of current cloud solutions: http://iwgcr.org/wp-content/uploads/2012/06/IWGCR-Paris.Ranking-002-en.pdf
²⁶See 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).
²⁷In particular, National Privacy Principle 4.1
²⁸Section 286
²⁹http://computerworld.co.nz/news.nsf/security/microsoft-365-latest-to-secure-g-cloud-accreditation
³⁰http://gps.cabinetoffice.gov.uk/node/2752
³¹No privacy policy found other than for general web site use
³²No Service Level Agreement found
³³No Service Level Agreement found

The content of this article is intended to provide a general guide to the subject matter. Specialist advice should be sought about your specific circumstances.