Swiss Banks In The Cloud - This Is How It Works (And How Not) - Financial Services

Can a Swiss bank put its client identifying data (CID) in the cloud, even if access to it from outside Switzerland is not ruled out? While this was unthinkable a few years ago, the answer today is a resounding yes. Many Swiss banks do want to move into the cloud. We are currently involved in more than half a dozen such projects, some of them with well-known institutions, and the question is not "if", but "how".

Many requirements, but they can be solved (checklist)
Documented risk assessment required
Microsoft, AWS: contracts must be adapted

Microsoft is the current leader

It often begins with the replacement of Skype for Business as an "on-premise" solution with Teams. This is followed by M365 with the various Office applications, Exchange Online, Sharepoint Online and OneDrive for Business and, in a third step, bank-owned applications on Azure. These are all applications from Microsoft, which we perceive as currently dominating the market for such products among professions subject to professional secrecy; their early decision for data centres in Switzerland has undoubtedly paid off.

We see few applications from Swiss banks with CID based on AWS, which is currently also building a data centre in Switzerland, and we encounter solutions based on other foreign cloud providers even more rarely in this environment (we do not address purely Swiss solutions such as those from Swisscom here). AWS is likely to gain ground when banks will start moving bank-specific applications to the cloud and not "just" run their mail server or file shares online. Swiss insurance companies are somewhat ahead of Swiss banks, as they are often not subject to professional secrecy like banks and could therefore migrate to the cloud more quickly. The use of M365 is already more widespread in this industry sector.

Trailblazers emerged 2019

The path to the cloud was paved for the banks in 2019. That spring, the Swiss Bankers Association published its Cloud Guidelines, which, based on two legal opinions, came to the conclusion that, with appropriate risk assessments and security measures, the use of the cloud is possible - even with the involvement of foreign service providers. This "marketing" initiative made the cloud acceptable in the Swiss banking world.

The question remained unanswered as to which security measures would suffice so that offers such as those from Microsoft could also be used if access from abroad to CID, in plain text, could not be completely ruled out. If such access were to be gained by a foreign authority, this would generally constitute a breach of banking secrecy due to customers not having waived their right to banking secrecy. The solution came in autumn 2019 with a method developed by the author of this article for a major Swiss bank to statistically calculate the probability of access by foreign authorities, taking into account the specific technical and organisational security measures taken.

The method made it possible for the first time to objectify the risk, which was previously incomprehensible to many and only assessed subjectively. It was refined in various projects over nearly a year and finally published in August 2020 in Excel format as "open source". Since then, it has been regularly used by banks, insurance companies and other professions subject to professional secrecy as well as their advisors and lawyers to assess and document the lawful access risk in cloud projects. Since September 2021, the International Association of Privacy Professionals (IAPP), the largest global information privacy community and resource, is offering it as one of its tools.

Legal requirements - a checklist

If a bank (or another regulated financial institution) wants to use a cloud-based solution, a whole series of requirements must still be met. On the one hand, they result from data protection and banking secrecy (or other professional secrecy), but also from regulatory requirements such as the FINMA Outsourcing Circular. For those who are not well acquainted with such projects, the situation becomes confusing. We have therefore compiled these requirements in the form of a freely available Checklist for cloud solutions for Swiss banks. Like this blog post, it is available in German and in English.

In practice, we have noticed in projects that some of the FINMA and other requirements are not being applied correctly by cloud providers, financial institutions and their advisors. Also, some Swiss audit firms repeatedly do not check compliance in enough detail or do not comply with the requirements. This is critical insofar as FINMA relies on audits by audit firms in the area of bank outsourcing. In the insurance sector, FINMA itself validates whether the conditions are met. In a recent case, it even revoked an already granted authorisation when it became aware of a significant "defect" in the contractual arrangements of a well-known cloud provider. Even though the defect has been remedied in the meantime, it is likely to still exist in a number of contracts. To our knowledge, no one else had identified it before.

The five most common defects

In our experience, three of the five most common stumbling blocks in cloud projects relate to the requirements of FINMA, including its Outsourcing Circular. Some of the Circular's requirements may appear questionable, but the Circular reflects FINMA's current view of the specific requirements for material outsourcings and are therefore de facto binding:

Enforcement of audit and access rights: It is generally known that not only the client of the cloud provider must have a right to audit the outsourced function, but also FINMA and the external audit firm. What is less well known is that FINMA expects that this right to audit the provider can be contractually enforced not only by the client, but also by FINMA, the external audit firm and furthermore by all other financial institutions in the client's group that also use the cloud services. This means that a contract providing third-party beneficiary rights must exist. Many contracts, however, exclude such third-party beneficiary rights (the providers provide that enquiries, audits and access are possible only via the client itself), or applicable law (such as Irish law) does not permit them, even if they are agreed.
Data storage in Switzerland: The Outsourcing Circular requires that access to the information necessary for the institution's ability to be restructured and wound up must be possible in Switzerland at all times. Many still understand this to mean that online access to their data in the cloud must be guaranteed, which is sometimes promised in the contracts. FINMA understands it differently: The data at issue must be stored on Swiss soil, together with everything necessary for its use. Mere online access to a data centre abroad is not sufficient. At least the requirements can be met by regularly making and storing copies in Switzerland; the "master copy" may remain abroad. FINMA's reasoning: In the event of a global crisis, it does not want to have to rely on foreign authorities to organise access to the data in an emergency.
Reporting cyber attacks: All providers commit themselves to report data breaches, as this is required by the GDPR. However, they also rely on the GDPR's notification deadline, according to which the customer must report within 72 hours. FINMA's requirements are stricter: Under Art. 29 para. 2 FINMASA, it requires notification not only of (personal) data breaches, but of cyber attacks in general, and it requires a first report within 24 hours. In a public statement in March 2021, a representative of FINMA made it clear that they would like to know about such attacks within 24 hours of the time of the attack, and not within 24 hours of the time the bank learns about it. At the moment, though, this can't be fulfilled in connection with cloud service providers, which FINMA is aware of.
Insufficient protection of CID: In our opinion, it is possible to outsource CID to the cloud of a foreign provider in a legally compliant manner. However, in addition to certain technical measures, it also requires appropriate contracts. Some of the contracts we have seen unfortunately do not meet these requirements, even taking into account their supplementary agreements for financial institutions and a data processing agreement pursuant to the GDPR. For example, it is overlooked that the concept of personal data is narrower than that of CID and the regulations applicable to the GDPR simply do not apply. Cloud providers such as Microsoft also reserve the right to process customer data for their own purposes; in these cases, they are not processors but controllers. The data processing agreement (and the protection it provides) does not apply in these cases; hence, the processing of CID in plain text has to be excluded in these cases or strictly limited and regulated.
Insufficient liability: The provisions of a contract are not worth much if there is no need to comply with them because there are no real consequences for a failure to do so. This means that any contract for a Swiss bank that wants to move to the cloud needs to provide adequate liability. This is sometimes an issue. Microsoft's standard contracts are under Irish law, and what most people do not know is that Irish law does not prohibit excluding liability for gross negligence or even wilful intent. Microsoft's standard "MBSA" contract has been drafted in a way that it will likely benefit from this aspect: Even a deliberate breach of contract that leads to a loss of data will likely not lead to liability of Microsoft. Hence, the contract lacks an important measure of enforcement and one of the incentives for Microsoft to comply. While a customer can – of course – take its own measures to protect itself, the Swiss Federal Court has made it clear in 2019 in a case concerning professional secrecy of attorneys-at-law (DFC 145 II 229) that it is not even permitted to restrict liability to gross negligence and wilful intent. This case focused on the professional secrecy of attorneys-at-law, but we doubt that FINMA, the Federal Data Protection and Information Commissioner (FDPIC) and courts in other cases will have a less strict view, once they become aware of this pitfall under Irish law (it so far has been largely unknown in Switzerland, even among specialists). Hence, on top of all other risk mitigating measures (such as cloud backups with another provider) contracts should be amended to that end if they do not already provide appropriate carve-outs from their liability limitations and exclusions. Even if they have such carve-outs for liability limitations, specific care is necessary because some liability exclusion clauses try to exclude damages for loss of business information altogether, including for gross negligence and wilful intent. Another solution is to change applicable law, for instance to the law of a civil law country instead of common law. We have seen all these approaches.

One side-note concerning the provider's use of data: Provisions that permit the provider to use the customer's personal data for its own business purposes – Microsoft refers to "Legitimate Business Operations" (LBOs) – are not at all inappropriate in the right "dose". It is normal for a provider to process personal data of the customer also as a controller and not only as a processor. The invoicing of its services, the provision of support services, but also the administration of the users of an online service are such cases. The provider's interest in evaluating the use of its service for non-personal purposes is also legitimate, provided it takes place within certain limits. The fact is, however, that many providers do not even mention this kind processing in their contracts – often because it just does not come to their mind from a data protection point of view. The customer, in turn, must consider under which conditions set forth by data protection law it can permit such use (e.g. by informing employees).

Essential Outsourcing?

The question of whether there is an essential outsourcing is also a recurring topic of discussion, because only then does the outsourcing circular apply. Most of the insurers whose projects we are aware of and who have already taken the step have assumed that the outsourcing of mere office application services (e.g. M365 including Exchange Online and Sharepoint Online) does not constitute an essential outsourcing because it does not affect the core business applications. It appears that FINMA has accepted this so far, but probably rather subconsciously. As a rule, in this sector, an outsourcing becomes essential when insurers move into the cloud with insurance-specific applications, which the first institutions are now doing in Switzerland. However, we would not be surprised if FINMA will take a stricter view and in the future also classifies the outsourcing of office applications as being an essential outsourcing with the argument that these systems are also becoming increasingly business-critical. In any case, there are already signs of a tightening of the practice.

Banks must expect a stricter standard to apply to them anyway, because in their case CID is also involved. It was already the case that where the processing of a larger amount of CID is outsourced, this generally speaks in favour of an outsourcing being essential. If a bank outsources the operation of its mail server to a hyperscaler through which it regularly exchanges e-mails with bank clients or with CID, which will often be the case, one will often consider this an essential outsourcing. Here, however, we have also gained the impression that audit firms tend not to be strict in their assumption of an essential outsourcing. In any case, we recommend assuming an essential outsourcing for the contract either way. This avoids "emergency" exercises in adjusting the contract at a later date, and the additional effort is typically low on the part of the contract.

Microsoft and AWS: need for improvement

How should the contracts of the successful hyperscalers be assessed from the perspective of a Swiss bank?

Microsoft's contracts, for example, even with the standard extensions for financial institutions (M453), Swiss data protection law (M329) and Swiss professional secrecy (M744) are not sufficient for a Swiss bank with CID. So far, however, we have been able to find solutions in all cases with corresponding contract negotiations through customer-specific contract adjustments, so that the Swiss banks in question can also use the Microsoft cloud with CID. However, this again presupposes that the banks use certain forms of contract (e.g. Enterprise Agreement), as Microsoft is very inflexible with certain other forms of contract. Customers who buy through resellers such as SoftwareOne, the industry leader, are therefore in part incomprehensibly worse served by Microsoft today. Due to the lack of standard amendments, they have only been able to obtain the necessary contract adjustments through workarounds, if at all. Hence, if a Swiss bank (or other professional secrecy organization) is too small, there so far may be no solution at the contractual level. Such customers would have to take a risk-based decision or wait until Microsoft – hopefully – provides a standard "professional secrecy" amendment that really lives up the promise; the current such standard amendment M744 is clearly insufficient, despite some outside counsel (with close ties to Microsoft) pretending otherwise. Further changes are ahead when Microsoft will present its new Data Protection Addendum (DPA), to be introduced in September to reflect the revised EU Standard Contractual Clauses (EU SCC); the customer will no longer enter into the EU SCC directly with Microsoft Corporation, as in the past. Hopefully Microsoft will use the opportunity of the revised DPA to improve it and correct some of the aspects that are not yet in compliance with Swiss data protection law.

In our experience, AWS's standard agreement, including the addendum for financial institutions, has also not yet met the requirements and in particular the Outsourcing Circular. AWS will have to significantly improve for Swiss banks.

In this context, the hyperscalers often point to the confirmations and reports from auditing companies. However, these reports have to be examined closely: They sometimes give the impression that the requirements of FINMA or the Outsourcing Circular are fulfilled when a hyperscaler's solution is used, but a closer look reveals that the review does not address the contract, but only the structure of the service itself (e.g. whether it allows the client to make backups or establish encrypted connections to the cloud) and the internal organisation of the hyperscaler (i.e. whether it provides for audit reports to be made accessible to the client, for example). This is, of course, not sufficient.

Contracts continue to evolve

This highlights a fundamental problem for Swiss banks, for regulated financial institutions in general and also for other professions subject to professional secrecy in dealing with international cloud providers. The latter often offer a high level of data security, a high quality of service and it may be assumed that they basically behave as required in their day-to-day business but their contracts still too often do not reflect this. On the contrary, their contracts are often unclear, inconsistent, ambiguous, too open or simply poorly drafted.

This makes corresponding improvements necessary, which in turn are very time-consuming and laborious to achieve, because the providers try to defend their contractual standard to the extent possible, often simply claiming that the demands of the customers (or even the regulator) are not justified. This is a pity, but it is a problem that should be solved over time. The contracts of large cloud providers such as Microsoft have become better and better in recent years under constant pressure from numerous clients and regulators. For Swiss banks, too, the time will come when we will no longer have to press for customer-specific amendments of the contracts for our clients, but will be able to use the right standard amendments to the contracts to cover sector-specific requirements.

Is there a need for "Bring-your-own-key"?

Our checklist of requirements can also help a bank to prepare the risk assessment that FINMA expects from supervised institutions in documented form. After all, moving to the cloud, like any other IT project, is fraught with risks that a bank's management must not only be aware of but also assume before the project can be given the green light. Our experience in numerous cloud projects shows that such a risk assessment rarely results in high risks and in many cases the management even actively pushes the move to the cloud because they see no alternative in the medium and especially in the long term. Interestingly, they are now being supported in this by data security specialists: While some were still sceptical a few years ago, in our experience the majority are now convinced that their data is better protected in the hands of the large hyperscalers than in their own data centres. This is a remarkable development.

That leaves one question that we come across again and again in our consultations: Does a Swiss bank necessarily have to use "bring-your-own-key" (BYOK)? At Microsoft, this refers to the service option of the "customer managed key", which describes the situation much better: The key is stored in the hardware or software key vault at Microsoft, but the key management is the responsibility of the customer – and the customer may also generate the "private key" to its data itself on its own systems and import it into the provider's key vault. Those who do the key management themselves have the option of revoking the key (or triggering the revocation – this is carried out by the hardware or software at Microsoft). Revocation renders all stored data unusable. However, this also applies to the bank's ability to use the data. Hence, BYOK provides the customers with the "red self-destruct button" for their data in the cloud. This can be useful when leaving the cloud, but also in the case of threatened access by foreign authorities. Whether the latter can really be prevented is, of course, doubtful if, contrary to expectations, a foreign lawful access should actually happen.

Not legally required, but it is common practice

We believe that the BYOK option is not required from a legal point of view – incidentally, not even according to the specifications of the Cloud Guidelines of the Swiss Bankers Association. They allow the key to be stored with the provider, but require that access to the key remains under the "control" of the bank. Without going into details here, we are of the opinion that this is sufficiently ensured in Microsoft's classical setup via the interaction between the master copy of the Active Directory maintained at the customer and the Azure Active Directory, which determines which user or which resource can access the key. After all, if Microsoft cannot be trusted to comply with Azure Active Directory access control, then it is hard to see why it can be trusted that the key vault it provides (and the software running it) has not been tampered with, is operated without intervention by Microsoft, and has no backdoor for Microsoft. Without a basic trust that the provider will abide by the contracts and not manipulate its own systems to the detriment of its clients, outsourcing is not possible in the first place.

In our opinion, the risk assessment ultimately requires a consideration of the entire package, consisting of technical measures (such as Active Directory at Microsoft), organisational measures (such as contracts and audits) and legal barriers (such as the fact that not everything is permitted under the US CLOUD Act). Nevertheless, we assume that most Swiss banks will use the BYOK option, that it will be subjectively considered at least necessary as an additional security measure, and that it will thus become the industry standard. For the question about the need of BYOK, too, it must be understood that the answer can be relied on many different factors.

Originally published 9 September, 2021

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.

Switzerland: Swiss Banks In The Cloud - This Is How It Works (And How Not)