Financial institutions Energy
Infrastructure, mining and commodities Transport
Technology and innovation Life sciences and healthcare
Cloud computing
A Norton Rose Fulbright guide
Cloud computing
Executive summary 07
What is cloud computing? 08
Why is the cloud being used more and more? 12
What service levels should the customer expect? 14
What are the inherent risks of a public cloud? 19
What about being locked in to a particular 24
vendor or technology?
Security and privacy – what are the specific legal 27
and regulatory issues around the world?
What are the practical deployment and 68
operational issues?
What are the taxation issues? 70
Cloud computing and the USA PATRIOT Act 72
Cloud computing and government take-up 74
Cloud computing and the financial services industry 79
Contacts 82
Executive summary
Businesses can derive many benefits from public cloud computing – it saves them
money, keeps them agile, and connects their employees. But a public cloud solution doesn’t come without risk. A public cloud essentially involves the commoditisation of IT infrastructure and services, a process which introduces new risks that sit alongside all the usual ones inherent in any IT deployment. Of course, with foresight and planning, the customer can mitigate these extra risks.
The infrastructure behind a public cloud is typically rather opaque. This lack of
transparency, together with limited flexibility, can pose security challenges and
complicate disaster planning and recovery.
Businesses may face issues if they want or need to change cloud services provider, or move back to a traditional IT infrastructure. Even with “open” standards for cloud computing platforms emerging, the “transition out” process can be a troublesome one. And the use of encryption or proprietary storage formats, together with network bandwidth limitations, can cause data access and migration headaches.
A business that stores personal information about itself in a public cloud needs to make sure it doesn’t breach any relevant data privacy legislation by transferring this personal
information across borders. In addition, financial services companies usually have their
own extra legal and regulatory obligations to meet.
There are also practical deployment and operational issues to think about: increasing the scope of the deployment can quickly push up costs; getting extra resources to cope with higher demand won’t necessarily happen automatically; and having a high-performing, “always available” platform isn’t guaranteed.
To get the real commercial benefits from public cloud computing, businesses need to understand all these issues and mitigate the risks properly in the first place. This
can be achieved by carrying out thorough due diligence before taking on a provider, and putting in place a solid contract as they would with any “bricks and mortar” outsourcing, with provisions on service levels, legal and regulatory compliance, audits and transition planning.
What is cloud computing?
Cloud computing at its simplest is any IT service made available over the internet. While the concepts it covers have been around for some time, the term “cloud computing” itself is relatively new. Launched back in July 1996, Hotmail (or Outlook.com as it’s now called) is an example of a classic cloud computing application. Since then, application service providers (ASPs) have delivered many more services over the internet and become the pioneers of the cloud.
Today, virtually any application can be run in the cloud and accessed from anywhere in the world. The results below, from our recent survey Outsourcing in a brave new world1,
show that more and more companies are beginning to use the cloud.
1 http://www.nortonrosefulbright.com/files/outsourcing-in-a-brave-new-world-57727.pdf 70% 30% Use Don’t use 45% 55% Use Don’t use
Since technology is their business, it makes sense that suppliers use cloud computing
more than their customers. But a large percentage (45 per cent) of customers are now
also using the cloud.
Cloud computing services can be categorised in two different ways:
• as service models – looking at what is being provided; and • as deployment models – looking at how it is deployed.
With different service models available, almost any IT service can be provided in the
cloud. The three main service models are:
Infrastructure as a service (IAAS)
This is cloud computing at its most basic. An IAAS provider simply sells raw computing power, like processing or storage. The user is left to choose what to run on the system, and is responsible for installing everything, including basic operating systems. It’s like installing your own server in your own data room, but having extra computing power available if you need it.
Platform as a service (PAAS)
This is a mid-level service, where a PAAS provider delivers a platform consisting of an operating system, programming language execution environment, database and web server. The user can develop and run systems using the underlying software and
hardware layers without having to invest a significant amount up front.
Software as a service (SAAS)
This is what most people think of as typical cloud computing. An SAAS provider installs and operates applications in the cloud, and the user then pays to access these applications (or in some cases accesses them for free). It’s cheaper for the user than purchasing the application, environment and related hardware.
Different deployment models are available depending on the particular application and
industry sector.
The three main deployment models are:
Public cloud
This is the traditional cloud model, where many different users share the same infrastructure. It’s the cheapest service, and also tends to be the most flexible as users
can buy extra services as needed. However, it does carry the greatest risk because all user data is stored and processed on the same machines.
Private cloud
This is at the other end of the spectrum. A provider allocates infrastructure and applications to one particular user for its own exclusive use, as if the user had bought
the hardware and software itself. The user benefits from being able to have their say
on the design of the cloud and the redundancy arrangements, and from having their data kept apart from others’. But this is the most expensive cloud model (it’s often more
expensive than in-house hosting) and it’s generally not flexible on short notice.
Hybrid cloud
As the name suggests, this is a combination of the public and private models and offers the benefits of both. The user has a private cloud for their high-risk applications and a
public cloud for their lower risk ones. For example, a bank’s unlikely to allow its core banking solution or even email onto a public cloud, but might use one for its marketing materials.
Increased client control Inc reased a bstr ac tion Hybrid service Hybrid platform Hybrid infrastructure Public service Public platform Public infrastructure Private infrastructure Private platform Ar chit ec tur al la yer Configuration model
And why is it called “cloud” computing? Opinions vary, but the general consensus
is that it’s because it’s usually difficult to know exactly where your data is – spread over many different machines, in many different data centres, often in many different
countries. And what’s more, you probably don’t really need to know.
Why is the cloud being used more and more?
There are three main reasons why organisations are looking at cloud computing.
To save money and become more efficient
Cloud computing’s pay-per-use model means that an organisation only has to pay for the resources it needs. It doesn’t have to worry about infrastructure maintenance or upgrade costs. Lower capital expenditure and recurring IT costs are tempting reasons to move to cloud computing. Because it’s scalable, users can increase or decrease resources based on actual demand, and pay accordingly. Almost all users of cloud computing made peak cost savings of between 10 per cent and 20 per cent (International Data Corporation, Research In Future Cloud Computing Workshop, May 2012).
Cloud computing is highly cost effective because the cloud can be accessed from any
computer with an internet connection and is independent of any machine, device or geographical location. This works well for organisations that have representatives who travel regularly.
Interestingly, however, the CSC Cloud Usage Index Survey (2011) (CSC Survey) found that relatively few organisations (14 per cent) reduced the size of their IT department
after moving to the cloud. In fact, 20 per cent of organisations hired more IT staff to
help with developing and managing cloud environments.
64 per cent of organisations indicated that adopting cloud computing has helped to reduce waste and lower energy consumption.
To stay agile and move quickly
IT organisations see cloud computing as an effective way to implement new
applications quickly in order to keep pace with application backlogs and business demands (North Bridge Venture Partners, Future of Cloud Computing Survey, June 2011). It’s quicker to meet a demand for higher computing capacity because fewer approvals are needed, there’s less paperwork and there’s no need to rely on hard-to-deploy physical servers. The arrival of cloud computing gives organisations a greater
ability to easily and cost effectively expand and reduce computing resources to meet fluctuating demands.
To connect employees
Significantly, the CSC Survey found that connecting employees across today’s multitude
of computing devices was even more important than cutting costs and staying agile.
33 per cent of 3,645 responses to the CSC Survey put this forward as the number one
reason for choosing cloud computing. This trend among small businesses is especially pronounced in the United States, with almost half (46 per cent) citing information access as most important, compared with just 10 per cent citing cost reduction.
What service levels should the customer
expect?
The idea of unlimited and cheap IT resources is becoming increasingly popular, with more and more business systems and data being moved to the cloud. This is even the case for business critical processes.
But the 100 per cent reliability of these services is an illusion, as the outage of Amazon’s Elastic Compute Cloud (EC2) services, in April 2011, clearly brought home. Cloud outages may not only result in a temporary unavailability of services, but also in the non-recoverable loss of data. This raises questions about the liability of the provider if services fail.
This section looks at how off-the-shelf service level agreements (SLAs) rarely meet
the customer’s expectations and how, as a result, the negotiation of an individual SLA is needed. It also highlights the most important points to be considered when negotiating SLAs.
Standard service levels for the cloud
Although service levels are very important to most customers, many cloud services providers sell services “as they are”, with no, or only very basic, service levels. According to a standard SLA used by one of the world’s largest providers, the provider
“will use commercially reasonable efforts to make [the service] available with an Annual Uptime Percentage (defined below) of at least 99.95 per cent during the
Service Year”. The provider doesn’t promise a certain level of availability, and doesn’t
even commit to use “best efforts”. Its obligations are limited to what is “commercially reasonable”, suggesting the amount of effort it will make depends on the outcome of
business decisions.
When it comes to working out the “Annual Uptime Percentage”, the service level states that the only relevant downtime is a situation where “more than one Availability Zone in which you are running an instance, within the same Region, is “Unavailable” to you. “Unavailable” means that all of your running instances have no external connectivity”.
So the only relevant downtime in the context of this service level is nothing less than the complete outage of the entire cloud service in a minimum of two locations in a
region. If the service fails in a single location, several locations in different regions, or
regarding certain functionalities, the provider wouldn’t be in breach of the SLA. Monitoring the availability of cloud services is the customer’s burden. To make a claim under the SLA, the customer has to provide “the dates and times of each incident of Region Unavailable that you claim to have experienced including instance ids of the
instances that were running and affected during the time of each incident [and…] server
request logs that document the errors and corroborate your claimed outage”. Assuming the customer can actually prove an outage the provider is liable for and that the minimum availability hasn’t been met, the “customer is eligible to receive a
Service Credit equal to 10 per cent of their bill […] for the Eligible Credit Period”. This is the “sole and exclusive remedy for any unavailability or non-performance of [the service] or other failure by [the provider] to provide [the service]”. So the customer’s only compensation under the standard SLA would be 10 per cent off their next bill. The provider isn’t liable for any damages resulting from the outage, for example profits lost
because of a damage to reputation or the costs of recovering lost data.
The need to negotiate an individual SLA
The service level arrangements described above are unlikely to meet most customers’ expectations, particularly where business critical processes are concerned. After all, they amount to a limitation of liability rather than, as you’d want, a warranty. Although it may be questionable whether a limitation like this would be enforceable in the jurisdiction where the customer is based, they won’t want to rely on court proceedings to determine this. Proceedings may take years, and the outcome would be uncertain. The case might even threaten the customer’s very existence, particularly when high damages are in question.
So, in most cases, the customer should negotiate an individual SLA with the provider. The contents of it will depend on the nature of the cloud services, the particular customer’s needs, and whether the SLA is a standalone document or part of another agreement.
The SLA should always clearly define the cloud services to be provided. Although this
point might seem obvious, standard SLAs don’t necessarily set out the services at all, or only very loosely, and might allow the provider to change or stop the services at its discretion.
The other areas to cover are:
• availability and other service levels • error correction
• monitoring and reporting • sanctions.
Availability and other service levels
As 100 per cent reliability of cloud services isn’t feasible in practice, the SLA will have
to define the level of service the provider should maintain.
The agreement will usually set out a minimum availability for each cloud service. Apart
from defining “availability” and an “availability percentage”, this also means agreeing
on a reasonable assessment period. As a rule of thumb, “the shorter, the better” for the
customer. For example, 98 per cent availability in a 365 day assessment period means
that, in the worst case, an outage of up to 7.3 consecutive days would still be allowed under the SLA. However, with the same percentage agreed, an outage of more than 14.4 hours would breach the SLA in a 30 day period.
It’s also important to clearly describe what “availability” actually means and where it is measured. In traditional outsourcing agreements, customers normally strive for an “end-to-end” availability, meaning that the service is available only when it can be used by the end user. A cloud services SLA can’t adopt this model because cloud services providers are normally only responsible for certain components and resources – they are not usually responsible for the internet connection, for example.
It is therefore even more essential for the customer to have a clear idea of which components the SLA covers and at which point the availability is actually measured. This will also depend on the particular nature of the service, for example, whether
it’s an infrastructure or an application service. To make it easy for the customer, the provider should have to measure availability and send reports to the customer. What’s more, the provider and the customer should agree the rules on scheduled downtimes. Scheduled downtimes, for taking care of things like maintenance and upgrades, should be kept to a minimum and only allowed at certain times, for example, outside the customer’s business hours. The provider should be required to give the
customer sufficient prior notice of a scheduled downtime, if possible. Scheduled
downtimes should be taken into account when calculating the availability of services. Depending on the cloud services in question, the particular requirements of the customer, and on what is practically feasible for the provider, other service levels
should be defined to guarantee the quality of the cloud services provided.
Error correction
The provider and the customer should also agree the rules on correcting possible errors.
The agreement should state how long the provider has to start and finish correcting any
error. It should also specify when the time limits start, for example, at the point the customer
reports the error to the provider. It might also set out specific service hours during which
mistakes will be corrected.
The obligations of the provider may depend on certain defined error classes. Ultimately,
error correction will be a matter of negotiation. It will largely depend on what is feasible for the provider considering the types of error in question. For example, it might be easier for a provider to commit to a maximum time limit where it just has to replace a piece of
hardware rather than fix a software problem or sort out a third party issue.
Monitoring and reporting
Evidence is needed to prove breaches of an agreement and to enforce sanctions. Standard SLAs may require the customer to measure how the provider performs the services, but usually the customer won’t be able to do this accurately, if at all. So instead the agreement should require the provider to continuously monitor the performance of its services and send regular reports to the customer on the achievement of the agreed service levels.
Sanctions
If the provider doesn’t meet service levels or correct errors as agreed, it breaches their contractual obligations. Customer claims resulting from these breaches will depend on the law that applies to the SLA. Depending on the jurisdiction in question, it might
be unclear what claims exist and existing claims might be difficult to enforce – for example, it’s often difficult to prove specific economic damage where an outage harmed
the customer’s reputation.
So the SLA should include a regime of sanctions triggered if the agreement is breached. What the actual sanctions are is a matter of negotiation between the customer and the provider, but a fee reduction or a penalty payment would be typical.
The amount of the reduction or payment will depend on the extent and duration of the SLA infringement. So the amount might go up in cases of severe or repeated breaches of the SLA. In the most extreme cases, the customer might have the right to end the agreement.
From a customer’s point of view, the sanction regime should not be exhaustive – they
should be free to claim for any higher damages they might have suffered because of the
contract breach.
Having a sanction regime in place not only protects the customer in cases where statutory damage claims are unclear or hard to enforce, but also encourages the
What are the inherent risks of a public cloud?
By the very nature of cloud computing, the customer cannot typically see how everything is implemented. A cloud services provider simply agrees to provide a
specified functionality, like data storage, software hosting or raw computing power, and
to meet certain service levels.
While this lack of transparency can help simplify the deployment of a cloud solution
and allow efficiency gains to be made, it can also bring up issues. It is particularly a problem for highly regulated industries, like financial services.
Things are made more difficult in the case of a public cloud, where providers are often
reluctant to negotiate standard terms and conditions. Some providers will refuse all requests made by customers to amend terms and conditions, making it very hard indeed for customers to negotiate better terms to protect their interests and mitigate perceived risks. Some providers simply display their standard public cloud terms and conditions on their website, and update them from time to time.
This section looks at several inherent risks that arise from the lack of transparency and ways to address them.
The risks
Security breaches
Research we conducted for our survey, Outsourcing in a brave new world2 revealed
that both suppliers and customers thought the greatest risk associated with cloud computing was a security breach. A security breach can take the form of a physical breach of security at a data centre, or a remote attack over the internet.
Security breaches pose a particular problem for cloud computing. Depending on the nature of the breach, the customer might not even be aware a breach has taken place because either there’s no apparent loss of data, or the data lost has been recovered from the provider’s backups unknown to the customer. And if the provider isn’t contractually
2 http://www.nortonrosefulbright.com/files/outsourcing-in-a-brave-new-world-57727.pdf
obliged to tell the customer about a security breach, this could cause the customer a major problem if they’ve got a legal or regulatory obligation to report this kind of breach.
Providers of public cloud services often buy services from third parties, like data centre operators or providers of data processing services. As the customer’s only contractual relationship is with the cloud services provider, they won’t normally have any right to impose security requirements on third parties and they might not have any legal remedies against them in relation to any security breaches either.
Disaster recovery and other technical issues
One of the inherent benefits of cloud computing is that the provider might be able to
recover from disasters or rectify technical issues in a transparent manner. For example, the provider might be able to bring a backup online in another location – this is especially common for cloud solutions where data is stored in several locations, both physically and virtually.
But this could also mean that the underlying configuration of the cloud infrastructure might change without the customer’s knowledge. This might affect the reliability of the
cloud itself, especially regarding its use as a redundant solution. In these circumstances, the problem could be made worse by the fact that the customer can’t impose business continuity planning or disaster recovery requirements on the provider’s suppliers. This issue might have legal or regulatory consequences for the customer.
A cloud services provider’s disaster recovery plans can also create particular issues. If litigation arises in relation to data that is stored in a public cloud, a customer might need to take control of their data and to preserve their communications and documents for discovery, in order to avoid court-imposed sanctions. There’s also a danger that legally privileged communications could lose their privilege if they are disclosed because of the nature of the data lifecycle in the cloud, or if backups are archived and
stored at off-site locations in another jurisdiction.
Insolvency of the provider
There is clearly an issue if the cloud services provider stops trading. However, even insolvency and the appointment of a receiver, administrator or controller in relation to
If the provider becomes insolvent, telecommunications services between the provider’s data centre and the customer might very well be stopped, resulting in an immediate loss of access for the customer. The customer is unlikely to be able to get physical access to the data centre, and might not even know which data centre or centres to visit. To
make matters worse, there’s also a risk that a financier, liquidator or administrator
might seize the provider’s hardware before the customer can retrieve their data. Even if the customer does get hold of the relevant hardware, there’s no guarantee they’ll be able to fully recreate the complete dataset – particularly if the provider has stored their data in a proprietary or non-standard format, or has used encryption or other security systems the customer can’t break through.
How to address these risks
Carry out due diligence
One of the best ways for the customer to manage risk is to carry out thorough due diligence on the cloud services provider before engaging them. It is crucial to know what data format and storage systems the provider will use to store data, because any proprietary or unusual ones might make it very hard to move to another provider if the customer needs to do so in the future.
The customer should also ask about the technical and security controls the provider uses, and maybe even about the security plans, governance, escalation processes,
breach detection procedures and notification process the provider has in place.
Finally, if the customer is concerned about particular legal or regulatory risks, they should query the potential jurisdictional issues, such as the location of the provider’s data centres and how the provider will communicate the customer’s data back to them. For example, some providers promote the fact that their infrastructure is located in the European Union, because of the perceived risk that the USA PATRIOT Act might potentially give the US government access to their data. We look at this issue in more detail in chapter 10.
Get ongoing disclosures
As well as getting information on the provider’s cloud computing infrastructure at the due diligence stage, the customer might also require that the provider complies
with any industry standards relating to data storage, or make sure the infrastructure continues to meet certain requirements, after the contract has started. Depending on how important it is to them, the customer might want to carry out an audit themselves
or simply ask the provider for proof. This extra burden might affect the price of the
service, of course.
The customer might want to consider asking to see the provider’s business continuity and disaster recovery plans, so they can understand how the provider will deal with
issues that affect more than one customer. And, if the provider is prepared to make
them available, the results of any disaster or security breach simulations the provider has carried out.
Keep some control
The customer might look to contractually control the underlying implementation of the cloud and restrict the provider’s ability to change that implementation. A common condition is to restrict the physical location of the data centres used. This is particularly relevant when there are legal or regulatory restrictions, for example, on the transfer of personal information across borders.
The customer might require their data to be segregated from the data of other
customers. The provider can do this either physically, by dedicating one or more servers
that make up the cloud to a specific customer, or virtually, by using virtual servers that
are transparent to the underlying physical infrastructure.
The customer might also require their data to be encrypted when stored. Encryption gives the customer extra peace of mind, but the need to continually encrypt and decrypt data can slow performance, and losing the encryption keys obviously brings its own problems. The customer will decide at what point their data is encrypted, either before it is sent to the provider or when it arrives. Encrypting data before it is sent to the provider adds an additional layer of security – useful for particularly sensitive data. The customer might also consider imposing other security requirements, like ISO 27001
security certification.
Finally, the customer might decide to abandon a public cloud altogether and opt for the more secure but more expensive private cloud, or a combination of the two. Depending on the degree of control and customisation the customer wants, a private cloud can eventually resemble little more than a dedicated data centre-type arrangement.
Make arrangements with the provider’s own suppliers
The customer could enter into agreements directly with their cloud services provider’s own suppliers, ensuring continuity of service should their provider fail to perform. For example, the customer might make an arrangement with a data centre operator so that they can access their provider’s servers and retrieve their data in the event of a breach or termination.
Although dealing directly with multiple third parties can be a useful risk reduction exercise, it can also become troublesome and add an extra layer of complexity. As a result, cloud services providers might be reluctant to agree to their customers having relationships with their own suppliers, especially as it goes against the “one-stop-shop” nature of a public cloud.
Put the cloud into escrow
Escrow of the relevant software and source code is often used as a risk management tool in the IT industry. However, a traditional software escrow arrangement will not work in a cloud computing environment. The software needed for the cloud to function
may be distributed across a range of different systems or may require external resources
from third party providers. Depending on the nature and type of the cloud deployment, some physical hardware or other platform element may also be required for the cloud to function.
Escrow of a cloud would essentially require the creation of a “mini cloud”, consisting of a number of virtual machines under the control of the customer, or provided by another cloud services provider, which would emulate the existing cloud platform. This mini cloud could then be subject to a form of escrow where, when an escrow release event is triggered, data would be moved from the main cloud to the mini cloud, which would then start operating. In practice, this arrangement is quite similar to normal disaster
recovery procedures. The difference is that it is the customer that implements the
fail-over change to their infrastructure, by using an escrowed version of their provider’s own systems, to allow operation to continue.
Setting up and maintaining this kind of arrangement is potentially complex, and the cost of doing so may well wipe out the cost savings made from using a cloud solution in
the first place.
What about being locked in to a particular
vendor or technology?
Using cloud computing comes with another risk – the potential for vendor or
technology “lock-in”. While it’s relatively straightforward to move your IT infrastructure to the cloud, it can be much harder to go back to a traditional infrastructure, or even just change cloud services providers.
As previously discussed, carrying out thorough due diligence is vital for the customer to understand the potential complications that could arise if they ever need to move away from their provider. The customer should be particularly wary if a provider simply says their public cloud infrastructure complies with “open” standards – this doesn’t necessarily mean the customer’s cloud solution could be easily transferred to another provider. Depending on the particular cloud deployment used, the customer might face a range of issues if they decide to end the arrangement with their provider. There is the question
of how to access their data in the first place, how to extract it, and how to move it to
the new system – and then there’s the cost of doing so. The extraction and migration process can be complicated, especially if the provider uses multiple software platforms and third party suppliers.
Getting access to data
The nature of a public cloud inherently means that the customer will lose some level of control over the storage and retention of their own data. This is a problem if the cloud services agreement ends or expires because the customer will need to extract their data so they can carry on their normal business operations.
The main question is whether the customer can access their data over the internet or not – if the amount of data is too much, they will need physical access to the servers themselves. If this is the case, they will need to know the location or locations of the relevant servers, and get permission from the data centre operator to access those
servers. The provider might also have to retrieve archived or backed-up data from off-site or offline storage systems.
Extracting and migrating data
The process of extracting and migrating data will be determined by the nature of the provider’s systems – a well-designed cloud platform should make extracting the data relatively easy. The main issues here will be how long it takes to extract the data and how much downtime the customer will face. If the data transfer process is done over the internet, the customer is likely to encounter bandwidth bottlenecks, which might
affect the rest of the business.
Whether the data is going back in-house or to another cloud services provider,
transferring it is likely to be a costly and time-consuming process – especially if there’s a lot of it, or it needs to be decrypted or re-formatted before it can be used.
How to address the risks
The customer should begin to think about potential data extraction and migration issues at an early stage in the cloud deployment process, and certainly during the due diligence process. They should agree a “transition out” plan with their provider before, or at least soon after, the initial deployment of the cloud platform.
The best time for the customer to negotiate a suitable transition out plan is before the deployment period, when the parties are on good terms and the provider remains keen to win the customer’s business. The worst time is when the contract is about to expire or has been terminated, and the provider has little incentive to help the customer. Putting a transition out plan in place early also means the customer can ask their provider to test the plan, even on a limited scale. This will help the customer
understand the viability and ease of the transition out process, and could even result in improvements being made to it.
The customer might also ask the provider to restrict the data centres used to specified
locations or jurisdictions. We’ve already seen how this course of action can address some of the risks that arise from the lack of transparency in public cloud deployments, and it could also help bring down the time and cost of moving data. It is worth bearing in mind though that restricting the data centres used could reduce the resilience of the cloud computing platform.
Finally, the customer could seek to hold back a fixed percentage of the fees payable
to their provider to fund the transition out process in the event that the contract is terminated. However, cloud services providers are generally reluctant to agree to this kind of arrangement, except in cases involving more complex bespoke cloud solutions.
Security and privacy – what are the specific
legal and regulatory issues around the world?
The use of public cloud computing can give rise to a range of legal and regulatory issues, especially concerning security and privacy. This section looks at some of the
issues in different countries.
Australia
While there is no specific or targeted legislation that would apply to the use of a cloud
computing platform by Australian entities, regulations exist that apply to certain activities or to certain types of customers.
Personal information and privacy issues
The National Privacy Principles (NPPs) contained in the Privacy Act 1988 (Cth) apply
to the use, collection, storage and disclosure of personally identifiable information
by Australian companies with an annual turnover of AU$3,000,000 or more, and to federal government agencies. State and territory agencies are also subject to similar legislation in their home jurisdiction.
In the context of cloud computing, National Privacy Principle 9 prohibits the transfer of
personally identifiable information to foreign countries except in limited circumstances.
Accordingly, companies that use a public cloud to store or process their customers’ personal details might be in breach of the National Privacy Principles if the cloud services provider’s servers are located outside Australia. The main exceptions available under the Privacy Act that permit the flow of personal information across borders
include: where consent has been given for that transfer; where the recipient is subject to a similar law or binding scheme in the jurisdiction where the personal information is being transferred to; or where the customer has taken reasonable steps to ensure the personal information will be treated in a manner consistent with the Privacy Act. Amendments to the Privacy Act 1988 (Cth) will come into force in March 2014. Among these amendments are the new Australian Privacy Principles (APPs) which replace the NPPs and apply to any organisation or government agency that must currently comply with the NPPs.
APP 8, which replaces NPP 9, tightens the rules on cross-border data flows. APP
8 requires an organisation or government agency to ensure that, before disclosing personal information to an overseas recipient, it takes such steps as are reasonable to ensure that the recipient does not breach the APPs in relation to that information. An organisation or government agency can be held liable for a breach of the APPs by an overseas recipient of personal information.
Accordingly, the main issue arising from the use of a public cloud to store or process customer information is determining the location of the cloud services provider’s servers and backup infrastructure. This can be done as part of the due diligence process and reinforced by appropriate provisions in the contract.
Material outsourcing of activities by financial institutions and insurers
Insurers, banks and certain other regulated financial institutions are subject to extraregulation administered by the Australian Prudential Regulation Authority (APRA). Under the prudential standards enforced by APRA, certain steps have to be taken relating to any material outsourcing of a business activity, which can potentially
include significant IT outsourcing. For example, if an APRA-regulated financial
institution proposes to use a cloud computing platform and that use constitutes a material outsourcing, the customer would need to comply with APRA’s Prudential Standard CPS 231 and APRA’s Prudential Practice Guide PPG231. APRA has also provided extra guidance in the form of Prudential Practice Guide PPG234 for the management of security risk in information and IT, which can apply in a cloud computing context.
For customers covered by these regulations, the issues that will concern APRA here relate to: the scope of the outsourcing; any service levels and performance requirements
that are implemented; any provisions relating to the confidentiality, security and
privacy of information; the visibility of any subcontracts; whether services will be provided from a foreign jurisdiction; and whether an exit plan or migration strategy can be put in place in the event of default or termination.
Business continuity management by financial institutions and insurers
APRA also has certain requirements for insurers, banks and certain other regulated
financial institutions relating to business continuity management. For example, an APRA-regulated financial institution has to comply with business continuity
management obligations in APRA Prudential Standard CPS 232 and APRA Prudential Practice Guide PPG233 – Pandemic Planning and Risk Management.
Accordingly, any use of cloud computing by APRA-regulated entities will have to comply with the regulations above. The main things APRA will look for in the context of business continuity management includes the carrying out of risk assessments, the development of a business continuity plan, and the regular testing of business continuity processes.
How to structure the cloud platform
The entities covered by the laws and regulations mentioned above will have to take particular care to understand the nature of the cloud deployment and to avoid breaching these obligations. For sensitive data or a minor outsourcing of non-material business activities, the use of a public or hybrid cloud platform might be
possible. For personal or sensitive information, or a more significant outsourcing, a
bespoke private cloud that complies with all of the relevant legal obligations might be a better alternative from the customer’s perspective.
The cost effectiveness of a customised private cloud solution needs to be considered
in the context of the customer’s business requirements. However, there may be opportunities for cloud services providers to work with customers and APRA to come up with bespoke cloud solutions for APRA-regulated entities that are more commercially viable.
Canada
Privacy concerns arise when companies located in Canada use the cloud to process or store the personal data of their Canadian employees and customers, or the personal data they hold on the employees and customers of their subsidiaries located in other jurisdictions. All of this data becomes subject to both federal and provincial privacy legislation3, regardless of where in the world the data was obtained.
Canadian privacy law doesn’t distinguish between data controllers and data processors. Canadian companies collecting, using or disclosing personal data, at home or abroad,
3 In addition to federal privacy legislation of general application, the provinces of Alberta, British Columbia and Québec have their own general privacy legislation. Certain provinces, like Ontario and New Brunswick, have their own privacy legislation, but it extends only to health information.
have to make sure both the cloud services provider and any subsidiaries accessing personal data stored in the cloud respect Canadian privacy legislation.
This is typically done by putting in place contractual measures that mirror the rights of the individuals concerned and the obligations of the collecting organisation under Canadian legislation. This means ensuring contractually that the cloud services provider won’t use the personal data for its own purposes and that it will put in place appropriate backups that enable the retrieval of data should a malfunction cause its loss.
Both the provider and any subsidiaries accessing personal data in the cloud have to
also agree to restrict access to that data to only those identified in the contract (those
whose jobs require it), notify the Canadian organisation of any data breaches promptly, and institute appropriate measures to contain and eliminate the source of the breach4.
The right to require destruction of personal data, once it has outlived the purpose it was
collected for, should also be foreseen. European Union model clauses will often suffice
for these purposes. Unlike many
European countries, Canada doesn’t require these contractual measures to be approved by any of its privacy commissioners. The onus is on the Canadian organisation to make sure the contractual measures comply with all applicable legislation.
Some organisations have raised concerns about using cloud services providers with servers located in the United States, given the provisions of the USA PATRIOT Act. In this regard, Canadian privacy legislation generally requires, as a condition of export of personal data to another country, the exporting organisation to make sure
a comparable level of security and confidentiality exists around the data once it’s
exported. Canada, like many other Western countries, has legislation that enables law enforcement authorities to require disclosure of personal data in national security and anti-terrorism contexts. As Canada’s Assistant Privacy Commissioner has pointed out on more than one occasion5, the risk of a US-based provider being ordered to
disclose personal data to US authorities isn’t a risk unique to US organisations. Not only are Canadian organisations subject to these requests as well, but there are several bilateral agreements in place between the two countries allowing their respective law
4 At the moment, only the province of Alberta has general legislation requiring security breaches to be notified to its privacy commissioner and, in some cases, to the individuals concerned. However, federal privacy legislation has been tabled that foresees similar obligations, and the provinces of Ontario and New Brunswick have mandatory reporting of breaches relating to health information.
enforcement agencies to exchange personal information. As a result, the USA PATRIOT Act doesn’t mean that a comparable level of security and confidentiality exists around
personal data exported to the US. Canadian organisations need to tell individuals that their information will be processed or held in the US, but they don’t need to get their consent.
While this is the opinion of Canada’s federal privacy commissioner, the same reasoning would likely apply under any provincial privacy legislation with two exceptions; both British Columbia and Nova Scotia have legislation prohibiting the transfer to the US of personal data held by their respective Crown corporations, except in certain limited exceptions.
Federally regulated financial institutions
Cloud computing solutions used by federally regulated financial institutions are subject to guidelines imposed by the Office of the Superintendent of Financial Institutions
(OSFI), Canada’s federal regulator of “federally regulated entities” (FREs). FREs can be banks, federally incorporated or registered trusts, loan companies, insurance companies,
cooperative credit associations, fraternal benefit societies, pension plans, bank holding
companies, or Canadian branches of foreign banks or insurance companies. In 2001, OSFI issued guideline B-10, entitled Outsourcing of Business Activities, Functions and Processes (the B-10 Guideline), a persuasive, though non-compulsory, code of conduct for FREs that outsource business activities. Based on the premise that FREs retain ultimate accountability for outsourced activities and that OSFI’s supervisory powers should apply regardless of whether an activity is kept in-house or outsourced, the B-10 Guideline sets out OSFI’s expectations regarding the management of outsourcing risks.
Under the B-10 Guideline, OSFI expects FREs to:
(a) develop a due diligence process for determining the materiality of outsourcing arrangements
(b) evaluate risks with all existing and proposed outsourcing arrangements
(c) implement a programme for managing and monitoring risks, commensurate with
the materiality of these arrangements.
The minimum requirements of the B-10 Guideline vary, depending on whether the activity in question is outsourced to:
(a) an FRE’s subsidiary or a controlling entity (if it’s an FRE itself) or a subsidiary of the same
(b) the Canadian branch, head office or any other branch or agency of a foreign bank,
insurance company or entity that controls the FRE, if the entity is regulated by a foreign or provincial regulatory body
(c) external auditors or other third parties.
The risk management expectations are heightened when an FRE outsources to a third party – for example, the B-10 Guideline requires FREs to refrain from outsourcing certain principal business activities to third parties.
An FRE’s material outsourcing arrangements should be documented in a written contract that includes certain provisions set out in the B-10 Guideline. The FRE should make sure, for example, that its cloud services provider has got appropriate measures in place to guarantee the continuation of the outsourced activity in the event of system breakdowns, natural disasters and other reasonably foreseeable events. The FRE should also require the provider to test its contingency plans on a regular basis, notify the FRE of the results,
and address any material deficiencies. OSFI might, with reasonable notice, ask the FRE
for a summary of these results. Ownership and access rights should be clearly delineated.
Data security and confidentiality policies should be commensurate with those of the FRE
and should apply to the provider’s subcontracting arrangements.
Because the number of cloud deployments in the Canadian financial services
marketplace was growing and there was some uncertainty about how to apply the B-10
Guideline to cloud solutions, in February 2012, OSFI confirmed that the B-10 Guideline
does apply to all technology-based outsourcing services, including cloud computing. In its memorandum to FREs, OSFI reminded them of their B-10 Guideline obligations,
including those regarding: confidentiality, security and separation of property;
contingency planning; location of records; access and audit rights; subcontracting; and monitoring material outsourcing arrangements.
FREs and cloud services providers need to be aware of the challenges created by the application of the B-10 Guideline to the deployment of cloud solutions by FREs. For example, as noted previously, the B-10 Guideline requires an FRE to carry out due diligence on an outsourcing arrangement. The nature of a cloud solution can greatly complicate, or even frustrate, the due diligence process in many respects. Cloud
solutions will often use multiple data centre locations in different jurisdictions and
a myriad of third party subcontractors and partners – conducting even minimal due diligence can be time consuming and expensive, as well as complex. Complying with other requirements of the B-10 Guideline will often mean having to deviate from many providers’ standard terms and conditions dealing with prohibitions and other controls over subcontracting, audit and access requirements, and reporting obligations. So a cloud services provider that wishes to take on an FRE will need to anticipate the challenges raised by the B-10 Guideline, and be prepared to negotiate a cloud solution that balances the FRE’s obligations with the characteristics and limitations often inherent in many cloud solution models.
Asia
Singapore
Legal landscape
OverviewThe Singapore government has chosen to adopt a “cloud friendly” policy, and has itself decided to use cloud computing. Singapore has also taken a light touch approach when it comes to legislating the collection, use and transfer of personal data in the cloud. At the moment, there are no laws in Singapore that prohibit the transfer of an
organisation’s data, including its customers’ personal details, to the cloud or through outsourcing. Any legislation covering the collection, use and transfer of an organisation’s
data tends to be specific to a sector, with an emphasis on the financial services sector and
protection of government information. A new PersonalData Protection Act (the PDPA), which is broadly based on established data privacy principles, is expected to come
into force by the end of 2012, and will most likely complement existing sector specific legislation. The first reading of the Personal Data Protection Bill (the Bill) took place in early September 2012.
Privacy
Singapore doesn’t currently have an over-arching data protection law. Personal data
is protected by the common law of confidence and by sector specific legislation. The
proposed PDPA aims to curb excessive and unnecessary collection of personal data by organisations and prohibits the unauthorised use and disclosure of this data. Although the PDPA hasn’t been enacted yet, it is expected that it will take a light touch, pro-business approach.
The Bill defines personal data very broadly to be:
“data whether true or not, about an individual who can be identified (a) from that
data, or (b) from that data and other information to which the organization is likely to have access”6.
This definition of personal data means that the PDPA, when in force, will apply to most
organisations in Singapore. A key provision of the Bill is the new section 26, which requires an organisation to not transfer data outside Singapore “except in accordance with requirements prescribed under this Act to ensure that organizations provide a standard of protection to personal data”. Section 26 doesn’t appear to require an organisation to carry out a detailed assessment of the laws in the foreign jurisdiction receiving the data. However, the organisation will have to make sure the recipient maintains a level of protection comparable to that in the PDPA. In short, the PDPA, when in force, is unlikely to impede the use of cloud computing services, even those hosted outside Singapore. The Bill also has requirements for letting individuals access and correct personal data7.
Organisations will have to:
• help an individual obtain their personal data;
• tell the individual how their personal data has been used; and
• supply the names of other individuals or organisations that have been given their personal data.
Organisations will have to correct any inaccurate personal data at the request of the individual, if the data is under the organisation’s control. They will also have to send the correct personal data to any other organisation that has been given it, within a year from the date on which the correction was made. In light of this requirement, it is essential that an organisation chooses a cloud services provider that can cope with this.
Until the new PDPA comes into force, any private sector organisation that collects personal data is free to adopt the voluntary Model Data Protection Code (the Model Code). The Model Code imposes practices broadly consistent with the EU Data Protection Principles.
Sector specific legislation
Both the Banking Act8 and the Securities and Futures Act9 require financial institutions
to maintain the confidentiality of customers’ personal details. Both laws allow the
7 Part V of the Personal Data Protection Bill 2012.
8 Banking Act (Cap. 19), Section 47 – to be read together with MAS Notice 634.
9 Securities and Futures Act (Cap. 289), Section 21.
disclosure of data for outsourcing purposes, including for cloud computing, provided
that the relevant authorities are notified, the confidentiality of customers’ personal
details is maintained, and there are adequate contractual terms in place with the cloud services provider.
The Statistics Act10, the Official Secrets Act11 and the Statutory Bodies and Government
Companies (Protection of Secrecy) Act12 have extra regulations covering the collection,
processing and transfer of personal data, but these are only relevant to private sector organisations when they are dealing with government information.
Mutual assistance in criminal matters
The Mutual Assistance in Criminal Matters Act13 allows Singapore to co-operate with
foreign governments in criminal investigations and prosecutions. Singapore aims to
make sure criminals can’t evade investigation, prosecution and asset confiscation on the basis that the evidence or proceeds of their crimes are in different countries. Singapore offers foreign governments a wide range of “mutual assistance”, including
the execution of search warrants to obtain evidence from holders of information contained in databases. There are several exceptions that apply to the provision of mutual assistance, but, in general, if a crime in one country is also a crime in
Singapore, Singapore will offer assistance to that country.
The main security and regulatory issues
Overview
The regulations that govern the use of cloud computing in Singapore are largely
directed at the financial services sector and take the form of guidelines issued by the
Monetary Authority of Singapore (MAS).
Regulators like the MAS will often view cloud computing as a form of outsourcing, depending on the type of cloud computing used, the extent to which it’s used, and the impact it has if it’s unavailable. Financial institutions should be aware that if their use of cloud computing is deemed to be a “material outsourcing”, they need to tell the
10 Statistics Act (Cap. 317).
11 Official Secrets Act (Cap. 213).
12 Statutory Bodies and Government Companies (Protection of Secrecy) Act (Cap. 319).
MAS. Before they go ahead and outsource, they also have to complete a Technology Questionnaire for Outsourcing and send it to the MAS.
In general, the regulations in Singapore require organisations to be aware of the unique attributes and risks associated with cloud computing, especially in the
areas of data integrity, multi-tenancy, recoverability and confidentiality. As most
cloud services providers and their data centres aren’t located in Singapore, the legal issues organisations should be aware of include sovereignty and jurisdictional ones. Organisations shouldn’t view the use of cloud computing as an outsourcing of their regulatory and audit obligations and the authorities will still expect them to comply with these obligations.
Data security and storage
As cloud services providers use data pooling systems to process data for multiple customers, an organisation should make sure its own provider can isolate and clearly identify the data, and other information system assets, of each of its customers. From the start, the organisation should also have a plan in place to get its data back should it stop using the cloud computing service in the future.
Data security
The organisation should check its provider has stringent security policies, procedures
and controls in place to protect the confidentiality and security of its sensitive information, like personal data, computer files, records, object programs and source
codes. It should also regularly monitor and review these policies, procedures and controls. Organisations should only partner with providers that comply with industry standards and have data centres with an acceptable data centre tier rating.
Threat and vulnerability
Where possible, the MAS recommends that the organisation carries out a threat and vulnerability risk assessment of its provider’s data centre on a regular basis14. The
purpose of this risk assessment is to identify the data centre’s security and operational weaknesses so that the level and type of protection needed to safeguard it can be determined. The provider should also have a remediation plan to address all the issues
identified within a reasonable timeframe.
14 Section 5.1.9, MAS Consultation Paper on Technology Risk Management Guidelines.
Maintaining control
The organisation has an obligation to make sure its use of cloud computing or outsourcing, regardless of location, doesn’t result in the weakening of its control over its data. The organisation should carry out regular reviews and audits to make sure the cloud computing services or outsourced functions adhere to its risk management policies.
The organisation should set up a technology risk management framework to manage
technology risks in a systematic and consistent way, and to give specified people risk management responsibilities. The organisation needs to put effective risk management
practices and internal controls in place to protect and maintain the integrity of personal data and to guarantee availability of cloud computing services 15.
Contracts
The terms and conditions governing the roles, relationships, obligations and scope
of cloud computing services should be carefully and properly defined in a written
contract. The requirements and conditions covered in the contract would usually include performance targets, service levels, availability, reliability, scalability, compliance, audit, security, contingency planning, disaster recovery capability and
backup processing facility. The organisation should make sure its provider offers their
service with a high standard of care, as if the activity were not outsourced but carried out in the organisation itself16.
The contract should take into account the need to protect the confidentiality of personal
data and the need to comply with all applicable laws and regulations. It should also document the provider’s ability to get their service up and running again within a
specified time after a disaster or period of unavailability.
Finally, the contract should give the organisation the right to have its data promptly returned or destroyed when the contract is terminated or expires.
15 Extract from sections 4.0.1 to 4.0.3, MAS Consultation Paper on Technology Risk Management Guidelines; section 6.7, MAS Guidelines on Outsourcing.
Service levels
The organisation should set up management control groups to monitor the outsourced service on a regular basis. These groups should make sure the provider’s service delivery, performance reliability and processing capacity are in line with the agreed services levels.
Internal IT policies and processes
IT policies, standards and procedures are critical components of a framework to manage the technology risks associated with cloud computing. They should specify the people in the organisation who are responsible for maintaining the policies, as well as the processes for safeguarding data in the organisation. Because of the speed of change in IT operating environments and cloud computing, the organisation should regularly review and update its policies, standards and procedures so that they stay up to date and relevant. The organisation should be able to address any compliance issues as quickly as possible 17.
The organisation should set up a comprehensive IT security awareness training programme to improve the overall level of awareness in the organisation, especially if the use of cloud computing is new. The organisation should make sure the programme’s content keeps up to date with developments in cloud computing 18.
Audit rights
A cloud services provider should be required to give all those who need it access to their systems, operations, documentation and facilities so they can carry out any review or assessment for regulatory, audit or compliance purposes. The contract with the provider should allow the regulatory authorities to carry out inspections, supervisions or examinations of the provider’s roles, responsibilities, obligations, functions, systems and facilities19. Organisations, especially financial institutions,
shouldn’t use cloud computing services based in jurisdictions where regulators can’t access their data quickly20.
17 Extract from section 3.2, MAS Consultation Paper on Technology Risk Management Guidelines.
18 Extract from section 3.4, MAS Consultation Paper on Technology Risk Management Guidelines.
19 Section 6.8, MAS Guidelines on Outsourcing.
20 Section 6.9.2, MAS Guidelines on Outsourcing.
Risk assessment and management
Board supervision and responsibilityBoard responsibility and accountability is a basic principle of good corporate governance that also extends to the use of cloud computing. The MAS has expressly
stated that the board of directors and the senior management of financial institutions
are fully responsible and accountable for managing technology risks. This also includes making sure the use of any new technology, like cloud computing, complies with the relevant laws and regulations in Singapore21.
The board and senior management should regularly review and appraise the cost and
benefit of investing in controls and security measures in connection with using cloud computing. Some of the things they should look at are reputation, customer confidence,
consequential impact, legal implications and cost considerations22. They need to fully
understand the risks associated with outsourcing and using cloud computing23.
Due diligence
Before an organisation appoints a cloud services provider, it should carry out due
diligence on the provider’s viability, capability, reliability, track record and financial
position24. As part of the due diligence process, the organisation might want to ask if
it can visit the provider’s data centres to assess the quality of operation and security
controls. This might not always be possible if the data centres are located offshore. Contingency plan
The organisation should have a contingency plan in place, based on credible worst case scenarios, in case its cloud computing services fail or stop working for whatever reason. The plan should identify viable alternatives for resuming operations elsewhere,
define the roles and responsibilities of the parties, and involve the regular testing of the
recovery procedure25.
21 Extract from section 3.1.2, MAS Consultation Paper on Technology Risk Management Guidelines; section 4.1, MAS Guidelines on Outsourcing.
22 Section 6.1, MAS Guidelines on Outsourcing.
23 Extract from section 5.1, MAS Consultation Paper on Technology Risk Management Guidelines; section 4.1, MAS Guidelines on Outsourcing.
24 Section 6.2, MAS Guidelines on Outsourcing.
Hong Kong
Legal landscape
OverviewHong Kong encourages the use of cloud computing as long as there are safeguards
surrounding the use of personal data. For the financial services sector, there’s also specific regulation relating to risk management. Within these limitations, the Hong
Kong regulations generally allow users and cloud services providers to establish contractual terms that suit their business needs.
Privacy
Personal data is protected in Hong Kong by the Personal Data (Privacy) Ordinance (the PDPO). Personal data protection has been controversial in Hong Kong ever since a Hong Kong provider of stored value cards sold personal data in 2010. This incident resulted in a series of public consultations on data protection laws, recommendations from the
Office of the Privacy Commissioner for Personal Data, Hong Kong and the Hong Kong
Monetary Authority (HKMA) relating to direct marketing activities, and amendments to the PDPO.
The PDPO defines personal data as any data:
• relating directly or indirectly to a living individual
• from which you can directly or indirectly work out the identity of the individual • in a form you can access or process26.
The PDPO requires personal data to be collected and used in accordance with six data privacy principles, which are broadly in line with data privacy principles adopted in other jurisdictions. In Hong Kong, these principles are27:
• why and how personal data is collected
• accuracy of personal data and how long it is kept for
26 Section 2(1), Personal Data (Privacy) Ordinance (Cap. 486).
27 Schedule 1, Personal Data (Privacy) Ordinance (Cap. 486).
• proper and legitimate use of personal data • security of personal data
• data handling policies and other information generally available to the individuals concerned
• the individuals’ access to personal data and their ability to correct it
The PDPO applies to “data users”, defined as “a person who, either alone or jointly or
in common with other persons, controls the collection, holding, processing or use of personal data”28. Under this definition, an outsourcing agent that holds, processes or
uses personal data for someone else’s purposes and not for their own isn’t considered to be a data user. Therefore, a data user that engages a data processor as their agent won’t be responsible for the actions of that data processor.
From a cloud computing perspective, this means that the customer is responsible for their cloud services provider’s handling of their data. If a data user engages a cloud services provider, whether in or outside Hong Kong, to process personal data on their behalf, they have to use contractual or other means to prevent the data from being kept longer than necessary and prevent unauthorised or accidental access to the data, or processing, erasure, use or loss of the data.
Transfer of data outside Hong Kong
Section 33 of the PDPO prohibits the transfer of personal data to places outside Hong
Kong, except in specified circumstances, although this restriction isn’t in force yet.
Nevertheless, since the provision could be brought into operation at any time, data users with a cloud services provider located outside Hong Kong, or that uses servers located outside Hong Kong, should think about the potential impact of section 33 on their business.
Sector specific regulation
Schedule 7 of the Banking Ordinance sets out the minimum authorisation criteria that “authorised institutions” (AIs) should be aware of when outsourcing functions, like data processing, to a third party. For instance, AIs are required to put adequate
