Ten years ago, software was purchased, as was the hardware with sufficient capacity to run it and store user’s data. Today, most software suppliers have moved to a subscription-based model, and hardware is mainly purchased as an end-user device.
Many companies in Switzerland have already moved to the cloud or are in the process of doing so, including for their most precious and sensitive data. It may appear to be a “no brainer” at first sight, but there are pitfalls. Here’s what we experience with our clients in the Swiss market – and how to deal with it from a legal point of view.
Some say there is no alternative to the “cloud”. Others successfully rely on open source and locally hosted solutions, including for new technologies such as artificial intelligence. In our view, there is not one size fits all. Whereas some years ago many had doubts whether and to which extent cloud-based solutions would be permitted in industries with particularly sensitive data such as banks, hospitals and public authorities, the question today is rather how and not whether the cloud may be used from a legal point of view. This is where we stand today: Many of our clients in these sectors now want us to help them getting their cloud projects right and to show them how to assess and mitigate their risks on their path to the cloud.
We do however see recurring themes in this work. This is why we have compiled a list of the seven “pitfalls” when moving to the cloud. Not all of them appear to be of legal nature at first sight, but this is not as clear-cut as it seems. Gone are the days when it was possible to conclude that an IT project and related provider contract fulfilled all legal requirements. Today we as TMT lawyers are expected by our clients to help them take “risk-based” decisions because the contracts and technical solutions on the table are far from perfect – even though we have been able to get all three hyperscalers to significantly improve their contracts for our Swiss clients. However, as our seven pitfalls show, there is still work ahead:
1. Getting the contracts right
Standardisation in cloud computing is not just about technology. It also extends to provider contracts. The disadvantage is that we, as clients, to a certain extent need to live with the contractual terms that providers, in particular hyperscalers, are willing to offer. Unfortunately, some of the language — including from big names such as Microsoft — is atrociously worded. An in some cases, clients are simply misled. Countless times we have been forced to insist on providers updating their standard terms simply because they did not comply with the law. For example, it took hyperscalers more than a year to provide contractual amendments that satisfied the Swiss Financial Market Supervisory Authority’s operational risk requirements, and even then some of them heavily resisted. That said, there are still many Swiss banks that have not yet updated their contracts accordingly. Hence, our recommendation is not to accept insufficient standard terms, but to push back. We are doing so for all our clients and have been able to achieve significant improvements. But standardisation also has a benefit: Where we finally manage to improve a contract, chances are that all other clients — even those with less bargaining power — can also get the improved wording. The problem that remains is that many clients (and even many resellers) in Switzerland do not know which amendments exist and which ones are necessary for them to be sufficiently covered. Moreover, the contracts of providers such as Microsoft are so complicated, unclear and non-transparent that only experts have a chance of assessing what they really mean and what the bigger picture is.
2. Ever changing contracts
Even if you manage to get the contract and amendments you need for your business and compliance, you have to expect that this will not work for long. While some of the base agreements are “evergreen”, many cloud contracts are limited in time — usually for a maximum of three years — or can even change at any time (sometimes even if you do not have a pay-as-you-go-model). As a consequence, companies must constantly keep track of the legal terms under which they are using the services of a provider. If a new service is obtained, new terms apply and existing assurances may have automatically vanished without companies even noticing. To a certain extent this is even justified by the fact that the portfolio of services of a hyperscaler is a moving target: The provider is forced to constantly amend its terms to keep up with developments. But for clients, this is burdensome — and many are simply not geared up to cope with this. Also, providers reserve the right to change non-product terms, as well, unless you manage to improve the contract language for your specific case.
3. Changing services and configuration
The same is true for the actual services and configuration of a cloud service. We see providers silently turning on features within their services that directly impact the client’s compliance without even informing the client. Clients have no choice but to implement procedures that will allow them to keep track of such changes on an ongoing basis — something again many organisations are not really prepared for. Hence, compliance is not fire-and-forget when entering into cloud contracts.
4. Shared responsibility misunderstood.
When thinking of cloud solutions, many believe that they operate “plug & play”. The opposite is true: When relying on cloud services, clients often have a much larger share of the responsibilities that need to be fulfilled for properly running the solution. We sometimes compare a cloud platform to a nuclear powerplant in your own back yard: You can do crazy stuff with it, but if you fail to manage it properly, it will blow up. Especially platform-as-a-service and infrastructure-as-a-service setups offer a wealth of functions and features, but the contracts make it more than clear that it is the client who is in charge of setting them up and using them correctly, including with regard to compliance parameter such as the location of a service or provider operator access. What we see, however, is that many organisations do not have the necessary know-how to take care of their share of responsibility, for instance properly securing their cloud application. One of the three big hyperscalers actually had the audacity to state in its base contract that its own obligation to maintain security was essentially limited to its own hardware and network, but not the applications offered. Many do not realize such tricks to limit liability. They become a compliance issue where a client is required to contractually ensure information security.
5. Foreign lawful access not considered.
This topic is traditionally relevant “only” for organisations that are subject to professional or official secrecy obligations, such as law firms, hospitals, banks, certain insurance companies, or public authorities. The underlying issue is that when using cloud offerings, Swiss companies usually engage with a provider that has its seat in another country. This way, a provider could be compelled to grant foreign authorities access to client data otherwise unavailable to them. In Switzerland, any such “lawful access” may result in criminal prosecution of company officials. Since 2019, we have been developing solutions to assess (and manage) this risk, which are now well established. Initially, only US providers were considered to represent such a risk, mainly due to the US CLOUD Act. Meanwhile, however, more and more clients realise that similar threats may exist in Europe, should they decide to use cloud solutions that are no longer limited to Switzerland. We are being asked to deal with an increasing number of projects that involve other European jurisdictions, requiring us to understand the risks of lawful access by authorities in such other countries. What makes it more difficult is that many lawfirms do not have the necessary knowledge to assess these questions.
6. Subcontractors not under control.
In recent years, we mainly helped our clients to set up their contracts with the hyperscalers. Now we see an increasing shift to onboarding smaller providers with their Software-as-a-Service (SaaS) solutions. These SaaS-providers themselves procure cloud service from hyperscalers, which therefore become their subcontractors. The issue we see in practice is that these SaaS-providers are often even less experienced than our (more experienced) clients in adequately managing their relationship with the hyperscalers, let alone getting the contracts right. In several cases we had to actually “help” our clients’ providers of our clients to achieve a satisfactory outcome. After all, our clients can be held responsible if their providers mismanage their subcontractors, be it contractually or operationally. For our clients in the financial industry, we have developed a tool that lets them assess the compliance and risk of their cloud projects (it is referred to as “CCRA”), and what we see today is that an increasing number of institutions are now starting to require that their suppliers use these tools too. This complements similar practices in the field of information security.
7. No plan B for the unexpected.
One of the biggest issues we usually encounter when conducting compliance and risk assessments for critical cloud projects with our clients is a lack of business continuity measures should the cloud provider no longer be able or willing to maintain its service. While all hyperscalers themselves have business continuity measures to protect their data centres against outages due to catastrophic events, this only covers a small portion of the business continuity risks their clients will usually face. For example, most hyperscalers do not even offer to ensure a proper backup of the data they process for their clients. Even if they were to provide a backup service, it would be useless in cases where the provider itself becomes unable or unwilling to continue its services. This is by no means impossible or unrealistic: Many providers usually reserve the right to suspend and terminate their services when they believe this is necessary to preserve their interests or at least where law requires. The “law” that requires them to do so is not necessarily the law of the client but could be any applicable law.
We have even seen a client who was wrongfully considered a sanctioned entity by one of the big players and faced the threat of being left without any computing resources within only weeks – fortunately the situation could be resolved, but it took substantial efforts and time. Should, for instance, US law require a hyperscaler to cut off service to certain companies abroad, even for questionable reasons, it will be difficult for them to ensure continued service. This is why we believe organisations should have a “plan B” in place in case they become no longer able to rely on their cloud provider being able or ready to provide them with its service. This includes maintaining separated data backups, having a reasonable exit plan ready and have the remaining dependency and business continuity risks discussed and accepted.
For sure, not all organisations in Switzerland will live up to these standards, and some will not even care. A few years ago, we developed our CCRA tool for both the financial and public sector. Initially, we believed its main benefit would be to remind these organisations of what questions they should be asking for their compliance and risk assessments and allow them to document their answers. Experience has shown, though, that already the process of having an organisation’s stakeholders all discuss these questions was of great value because people became aware of the bigger picture of their projects. Even if they often did not have a real solution to solve, for example, the dependency risks that come with a cloud solution, they gain a much better understanding of them. In the end, this is also what data protection, financial markets regulations and other laws expect — a risk-based approach.
By David Rosenthal
[email protected]