I Introduction

Owing to the spread of digitalisation within the world of banks and financial institutions, and coupled with the fact that a good number of back office functions in banks are now being outsourced and that both banks and third-parties are major customer of cloud services providers (CSPs), the legal requirements applicable to cloud computing induce an ambiguous tension between the cloud computing guidelines issued by the European Banking Authority (EBA) and the Standard Contractual Clauses (SCCs) that are expected to be replaced now that the General Data Protection Regulation 2016/679 (GDPR) is in force. This relationship is crystallising around three main stumbling points:

  1. information security requirements, also referred to as technical and organisational measures (TOMs);
  2. subcontracting, also now known as sub-processing when the subcontracting involves the processing of personal data; and
  3. audit rights.

Professionals are contemplating a hide-and-seek game between the EBA and the European Commission, or rather – if we dare to say – a love-hate relationship that is detrimental to business and IT efficiency.

Let us hope that the EU Commission and the EBA find a compromise to put an end to this game by putting a term to the discrepancies existing between the Second Payment Services Directive (PSD2) and the GDPR, and ensuring that the EBA's guidelines are realistic for CSPs by using adapted, standardised mechanisms including the Code of Conduct for Cloud Services Providers and updated SCCs that include TOMs based on the ISO 27001 standards. We hope that this chapter will contribute to the draft of a roadmap for an enlightened outcome.

II Topics specific to banks and other financial institutions

i Historical context

Banks and other financial institutions have been concerned by trust as early as the 15th century, when the letter of credit enabled globalised business. And as history repeats itself:

we are [today] living in the Renaissance era of banking and this transformation that we see is from disruptive changes across regulations, technology, and the very manner in which banking is consumed as a service. The opportunity to transform banking is now the top agenda for most nations globally, as they seek to make banking inclusive and accessible to billions.2

Privacy and infosec – as the basis for such trust – have been the core elements of banking regulations as early as 2006,3 when the Committee of European Banking Supervisors released its Guidelines on Outsourcing and disclosed a set of principles-based guidelines to provide national supervisors with an adequate degree of flexibility to take into account domestic rules and specific features of their local markets and to encourage developments in market practices.

The EBA's Guideline 8 provides that:

[a]ll outsourcing arrangements should be subject to a formal and comprehensive contract. The outsourcing contract should oblige the outsourcing service provider to protect confidential information.4

ii The French Ministerial Order of 3 November 2014 in relation to the internal control of credit institutions and investment firms subject to the supervision of the French Prudential Control Authority

These Guidelines have been translated into national regulations, specifically in France as the French Ministerial Order dated 3 November 2014 in relation to the internal control of credit institutions and investment firms subject to the supervision of the French Prudential Control Authority (the Order).5

The Order sets out obligations for French banks and financial institutions in relation to a bank's internal control and for the outsourcing of services qualified as 'essential' (essential outsourced services or EOSs).

These EOSs are defined as:

services or other operational tasks which are essential or important for the bank's activity and which are transferred to a third party (the 'Supplier') on a regular and lasting basis.

Essential services are defined in the Order as:

(i) banking activities; activities related to banking activities; activities directly linked to banking activities; and any other activities of such importance that any weakness or failure in the provision of these activities could have a significant effect on the bank's ability to meet its regulatory obligations and/or to continue its business; (ii) any other activities requiring a licence from the supervisory authority; (iii) any activities having a significant impact on its risk management; and (iv) the management of risks related to these activities.

If outsourced to a supplier, any services or tasks falling within the first three categories above are automatically considered as an EOS.

The fourth category requires French banks to assess for themselves whether a given high-risk activity, if outsourced, should be qualified as an EOS. If the analysis by the relevant internal compliance department of the bank concludes that a given outsourced activity falls within the fourth category, such activity will be considered an EOS and the contract with the supplier would be required to comply with specific contractual requirements. The supplier additionally would need to undertake to:

  1. abide by service levels (SLAs);
  2. protect the integrity and confidentiality of any information processed by it (confidentiality, security and data protection clauses need to be included in the contract);
  3. provide contingency mechanisms in case of any serious problem or force majeure event in order to ensure the service continuity of the bank (a business continuity plan (BCP) needs to be included in the contract);
  4. provide regular reports on the performance of the service and on any events that might have a significant impact on the supplier's capacity to perform the outsourced services in an efficient and compliant manner; and
  5. access on-site, whenever the bank deems it necessary, to audit all information and systems relating to the services, in compliance with applicable regulations governing disclosure, and allow the European Central Bank (or, in France, the Prudential Supervision and Resolution Authority, independent public supervisory authority for the banking and insurance sectors) to have access, including on-site, to information necessary to their mission in relation to understanding and inspecting the services provided under the contract.

The Order also provides for the requirement for the supplier to obtain the express written consent of the bank before making changes to the outsourced services, and before outsourcing any of such services to any third party (or fourth party) or concluding a service or subcontracting agreement with a third party concerning the outsourced services in order to ensure full compliance of said agreements to the Order.

Among other obligations are the requirement to insert a termination and an exit management clause to allow the outsourced services to be transferred to another supplier or to be reintegrated by the bank, and the more generic concern to consider the relationship as based on intuitu personae, namely, where the specific contracting party and its suppliers are material terms of the contract and cannot be changed without the customers' consent.

In July 2018, the EBA updated the 2006 Guidelines on Outsourcing 6

We may assume that a heated debate will ensue between CSPs and banks and financial institutions as to which software or services will be classified as 'material'. Each bank will, therefore, be required to notify competent authorities of the outsourcing on a case-by-case basis.

And where the CSP will strongly defend the fact that the Order provides that:

Without prejudice to the assessment of any other task, the following tasks shall not be considered as services or other essential or important operational tasks:
- the supply to the reporting enterprise of consultancy services and other services not included in the activities covered by its accreditation or authorisation, including the provision of legal advice, training of its personnel, billing services and the security of the premises and the personnel of the enterprise;
- the purchase of standard services, including services providing market information or price data feeds.7

Market data and other standard services that do not require the implementation of sophisticated integration services can be argued as being de facto out of scope. The same could apply to public clouds that are not specifically tailored to a particular customer when used for general purposes and for the purposes included in the bullets above.

It is common practice for banks and financial institutions to argue that where a bug or a failure of the service likely would lead to serious impacts on the ability of the institution to comply with its obligations relating to the exercise of its activity, its financial performance or the continuity of its services and activities, such software or service should be qualified as an EOS.

Therefore, if failure of the part of the computer system deployed in the cloud is likely to undermine the continuity of the services and activities of the financial and banking institution, the use of cloud computing is also likely to be qualified as an EOS, implying stronger obligations including requirements to:

  1. have an exit plan agreed to in the contract and a BCP;
  2. share the contract with the competent authority;
  3. have full access to the business premises (the head office as well as any operations centre) for providing outsourced services. This access right includes the following:
    • an unrestricted right of inspection and audit by bank or appointed third party as defined in the contract, unimpeded or limited by contractual arrangements;
    • the right to agree alternative assurance level if other clients' rights are affected;
    • third-party certification is possible; however, there is the right to request an expansion of the scope of the audit to certain systems or controls (based on reasonable and legitimate grounds);
    • the right for the customer to check that auditors have correct level of skill and knowledge to perform the audits;
    • an unrestricted contractual right for competent authority to inspect and audit services, subject to confidentiality;
    • notice of audit or access within a reasonable time period; and
    • full cooperation with onsite visit;
  4. set confidentiality and security standards for the protection of data (integrity and traceability of data and critical systems), with standards monitored on an ongoing basis;
  5. no prohibition on outsourcing outside the EEA, but noting issues arising for effective supervision;
  6. inform the bank of change to any subcontractors sufficiently in advance to allow the bank to make an assessment on new subcontractors;
  7. the right to terminate where a change of subcontractor results in an adverse effect on services; and
  8. review and monitor services on an ongoing basis – this means service levels must be included in a contractual agreement. There must be indicators that can trigger exit plan as part of ongoing monitoring.8

iii Existing discrepancies between the GDPR and the PSD2 Directive9 and other financial services regulations

PSD2 and GDPR: a different path to privacy

The PSD210 went live on 13 January 2018, a couple of months before the 25 May enforcement date for the GDPR (which is a regulation and not a directive). The difference may seem minor, but even though the GDPR provides for more than 60 exceptions that can be ruled by national laws, a directive (such as PSD2) is not immediately enforceable under local laws and needs to be transposed. Local laws will hence have a 100 per cent direct impact on the way the PSD2 will be applied throughout the European Union. On top of that, certain terms – and more specifically the regulatory technical standards (RTSs) – of the PSD2 relating to access to data (which is truly the heart of the battle between banks and suppliers) will only come into force in September 2019 – thus creating additional issues from a timing perspective, even without mentioning the fact that these will need to be integrated into local laws.

In addition to the above uncertainties, the GDPR and the PSD2 have a slightly different approach to personal data: while the PSD2 considers that banks and financial institutions should provide access to all of the customers' personal data in order to stimulate competition and fintech's innovations, the GDPR's goal is to empower people and give them back control over their personal data.

This does not mean that there are no legal tools to reconcile both pieces of legislation – such tools include consent and the obligations applicable to the know-your-customer (KYC) rules.

However, once one moves from the high-level principles to implementation, the challenges of reconciling the details of GDPR and PSD2 quickly become obvious.

Consent under the GDPR and the PSD2

A perfect example is obtaining a customer's consent. The PSD2 allows third-party providers (TPPs) to access the customer's payment data directly, provided they have obtained explicit consent and use the banks' infrastructure for the provision of their services. Both pieces of legislation provide for consent but the liability of the party that needs to obtain such consent remains unknown. Additionally, while Article 64 of the PSD2 provides that consent may be withdrawn by the payer at any time, but no later than at the moment of irrevocability as defined under Article 80 of the PSD2, Article 7.3 of the GDPR provides that the data subject shall have the right to withdraw his or her consent at any time, including, presumably, the second after it has been given or even before.

While banks are the data controllers and are responsible for implementing safeguards 'to ensure that they genuinely act on the data subject's behalf',11 TPPs are only permitted by the PSD2 to access data as 'explicitly requested by the customer' for the sole provision of the services. That means that while TPPs will probably initiate the process of securing customers' consent, banks will ultimately remain responsible for confirming with, or otherwise separately obtaining, the consent directly from their customers.12

The PSD2 seems, therefore, to ignore the controller-processor-data subject relationship set up in the GDPR.

Sensitive payment data

Another interesting example is the definition of the term 'sensitive payment data'. The RTS on strong customer authentication and common and secure communication under PSD2 states that banks will have to provide account information service providers with the same information available to the customer when directly accessing their account information, provided such information excludes sensitive payment data. However, the terminology has not been defined and is clearly different from the definition of sensitive personal data set out in Article 4 of the GDPR, very much in contrast to US laws where banking information is considered equal to medical data as being especially personal and sensitive. Without further guidance, banks may need to take a more risk-averse approach and redact all data that could possibly fall into the PSD2 definition of sensitive data category in order to avoid breaching rules around data protection, both under PSD2 and GDPR.

Delay for notifying a data breach

Article 96 of the PSD2 provides that, in the case of a major operational or security incident, payment service providers shall, without undue delay, notify the competent authority, and the EBA guidelines specify that such notification should be done within four hours. By comparison, the GDPR's Article 33 requires notification within 72 hours of becoming aware of the breach.


A very common example of the difficulties of implementing the GDPR in the financial industry environment is the processing of criminal data for the purposes of the KYC. Article 10 of the GDPR states that, in order to process criminal records, the data controller must:

  1. rely on an Article 6 legal ground (i.e., the legitimate interest); and
  2. be authorised under local Member State law.

The KYC is a regulatory obligation imposed on all banks and reinforced in the framework of the fight against money laundering and the financing of terrorism.

In this area, sanctions or the increased threat of sanctions from the authorities have led the banks to strengthen the collection, analysis, and storage of personal data concerning individual consumer customers and executives or shareholders of corporate clients, increasing the volume of data, staff access and exchange of information between entities and suppliers within banks.

The GDPR has several impacts on the KYC:

  1. Does the regulation require that the investigation process of the KYC be transparent to the customer, and if so, to what extent?
  2. Is there a right for the customer contest and how does the bank avoid liability?
  3. How can a bank ensure access to personal data by the data subjects?
  4. Will data subjects be able to recover not just all the data provided by themselves to the bank, but also all that generated in the context of the commercial relationship?
  5. What retention period shall be applicable?

Specific policies need to be implemented for the KYC by each bank or financial services institution.13

The many discrepancies between financial regulations and the GDPR force banks and financial institutions to go beyond the requirements of the GDPR, and these discrepancies are echoed on the relationship of the banks and financial institutions with their CSPs to whom they entrust essential IT systems, such as the KYC.

III The work left to be done by the EU Commission

With the globalisation of digitalisation, and the importance gained by cloud computing, the EU Commission may need to generalise banking and financial institutions' concerns, or at least harmonise the legal and infosec requirements in order to facilitate CSPs' compliance with the EBA's requirements.

At the same time, such generalisation should not be detrimental to small and medium enterprises unable to invest as much as the Big Four (i.e., Google, Amazon, Facebook and Apple). In order to achieve such goal, a possible solution would be to implement standardised TOMs that should remain neutral from a technical standpoint and regulate the scope of audits by giving a framework to audits. Auditing should be outsourced to independent companies paid for that, and should not be imposed on a company's workforce: as much money and time spent on audits cannot be expected out of a small or medium CSP without being seriously detrimental to a fair competition, and CSPs must be able to provide certificates in lieu of on-site audits. Once the issues related to TOMs and auditing are resolved and there is standardisation and harmonisation, subcontracting will probably be much less of a concern.

That being said, there are certain things the European authorities can do.

i The SCCs

Much has been said and written about the EU SCCs (also known as EU Model Clauses). In fact, there are over 4 million websites that discuss the SCCs in one form or another. However, notwithstanding the introduction of the GDPR, the SCCs in use date back to 2001, 2004 with revision in 2010 (the Controller to Controller SCCs) and 2010 (the Controller to Processor SCCs) and to date have not been updated – and there is no indication that the EU authorities are considering updating the SCCs. However, the SCCs are currently under review as part of a (second) court case brought by Max Schrems in his campaign against Facebook's data handling policies and procedures.14 What follows, therefore, is a consideration of possible changes and updates to the SCCs to bring them into line with GDPR.

Pursuant to Article 26 of Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 'on the protection of individuals with regard to the processing of personal data and on the free movement of such data' (the Data Protection Directive), the EU created a mechanism to allow for standard contractual clauses to transfer data to third countries that do not have an adequate level of data protection. Accordingly, by Decisions 2001/497/EC and 2004/915/EC, the EU Commission introduced two standard contractual clauses templates between an EU controller and a non-EU or non-EEA controller, and by Decision 2010/87/EU the EU Commission introduced a standard contractual clauses template between an EU controller and a non-EU or non-EEA processor. As has been widely reported and commentated, on 25 May 2018, the GDPR became enforceable after a two-year transition period, and pursuant to Article 46(2) reinforced the right of the EU Commission to adopt SCCs. Unfortunately, no new SCCs have, to date, been issued by the EU to update the existing templates to reflect the requirements of GDPR or the state of progress of technology. This has caused a frenzy of contractual activity, as controllers and processors have had to negotiate their own interpretations of the GDPR's requirements between them and to the data subject, and while some of the requirements are quite straightforward, others lend themselves to reasonable interpretations. This, along with the general difficulties in managing third-party vendors has resulted in tremendous compliance burdens that could have been alleviated with the issuance of GDPR-ready SCCs.

In addition, the advent of cloud computing has forced certain organisations to review their position on data processing in the cloud. For example, in December 2017 the European Banking Authority issued its Recommendations on Outsourcing to Cloud Service Providers.15 This sets out certain baseline requirements for financial service organisations when outsourcing services to cloud service providers.

The SCCs can therefore be considered under threat, and what seems to be an obvious solution is to update them to reflect not only the concerns raised by Schrems but also to reflect the new regulatory landscape as well as current and future technology.

What follows is an examination of some areas with the SCCs that could and should be updated.


The technical and organisational measures are a huge bone of contention, varying in depth and scope. Much time is spent negotiating these between controllers and processors, where each party insists on using their standard TOMs and eventually a compromise is found. Perhaps the solution is for the authorities to develop a set of TOMs that cover the main key elements minimum standards expected, covering access, input and change, roles, availability, etc.

Retention period maximum

A large derogation is the right to retain data. While the GDPR is clear that you should only keep data for as long as it is necessary for the purpose for which it was collected, there is something to be said for introducing a backstop and offering protections for companies that correctly delete the data but might need it to defend against claims, perhaps three years after the contract expires or terminates. The introduction of such a backstop would require a fine balance between the rights, duties and obligations under GDPR versus those imposed by other legal frameworks around statutory limitation periods. One of the conflicts within the GDPR is the right of the data subject to request deletion. If the deletion is granted, an organisation may have difficulty defending against a suit from that same data subject.


The audit right provided in the SCCs is wide and without definition or limitation (Does it refer to allowing access within data center or to company confidential security controls? Does it require a bank's hosting provider to allow the bank's customer to inspect all of its controls in person?) and does not provide any comfort to a processor of the ongoing security of its infrastructure.

Bear in mind, for instance, the technical issues surrounding the simple fact that the temperature of a data centre may be disrupted by the presence of one additional person, putting at risk the data of thousands of customers. How can a regulation grant unlimited on-site audit rights to these same thousands of customers?

The audit right applies regardless of whether the audit is a general one or one following a data incident. For this, perhaps, three streams need to be developed: one audit mechanism for supervisory authorities, and two for the controller (one annual mechanism and a mechanism to handle for auditing following a data breach).

The right to audit should vary depending on the circumstances that resulted in the audit in the first place in order to be meaningful and effective, as an audit is a limited point-in-time view of compliance and arguably less meaningful than contractual promises that are regularly reaffirmed via a questionnaire or a third-party certification. If the purpose of the audit is to evidence compliance, then things such as the requirement for an audit plan, sufficient reasonable advance notice, and the use of mutually agreed upon third-party auditors should be handled via one mechanism. The introduction of GDPR-compliant third-party certifications could go a long way to resolving this issue. An audit following a data breach, by contrast, will more than likely require an abbreviated process recognising the urgency around post-incident compliance, and as such should be done by a single independent auditor, and not all customers coming on-site.

ii EU Code of Conduct for CSP

Article 42 of the GDPR provides that:

Member States, the supervisory authorities, the Board and the Commission shall encourage, in particular at Union level, the establishment of data protection certification mechanisms and of data protection seals and marks, for the purpose of demonstrating compliance with this Regulation of processing operations by controllers and processors. The specific needs of micro, small and medium-sized enterprises shall be taken into account.

Adherence to a code is one of the compliance mechanism provided by the GDPR. An EU Cloud Code of Conduct covering the requirements for CSPs is currently being drafted. The Code is:

designed to be a voluntary instrument, allowing a CSP to evaluate and demonstrate its adherence to the Code's requirements, either through self-evaluation and self-declaration of compliance and/or through third-party certification. The Code is developed to cover GDPR requirements for a Code of Conduct under GDPR and is being submitted to the appropriate Data Protection Authority.16

While the intention of the EU Cloud Code of Conduct is supposed to make it easier for cloud customers (particularly small and medium enterprises and public entities) to determine whether certain cloud services are appropriate for their designated purpose, it is quite difficult to imagine that it fits the specific needs of micro, small and medium-sized CSPs.

For instance, several references are made to the ISO 27001 standards, but no references are made to projects such as the attempt by the French Agence Nationale de la Sécurité des Systèmes d'Information to ensure that cybersecurity be accessible to everyone, including the micro, small and medium-sized CSPs.

In order to be efficient, we need to make sure this code is not meant exclusively for the Big Four and other large giant tech companies.17

And if we want that to be true, TOMs based on the ISO 27001 standards should be standardised and realistic to put in place from a financial standpoint for all companies.18

Another major essential point taht remains unresolved by the EU Code is the ability to proceed to still-required on-site audits, even if the CSP has adhered to the EU Code. The EU Code could have provided that audits be entrusted to independent third parties, coupled with the ability to have certificates to resolve the issues.

It seems, however, that the draft version of the EU Code of Conduct for CSPs has taken a different approach and has left these core issues regarding a pacified relationship between CSPs and banks and other financial institutions unresolved.

For many banks and financial institutions, as well as for providers and companies subject to more than one of the above-mentioned laws, regulations, guidance and directives – and that would comprise a good bit of the ecosystem – the complexity of the legal frameworks coupled with the complexity of the technologies and the savings and efficiencies from outsourcing leave many practitioners struggling to make sense of the interplay. When discussing with small and medium players, their main preoccupation is that they feel they will never be able to fill the gap required by the regulations, and many give up before even trying to conform to the new standards. The IAPP Annual Privacy Governance Report 2018 highlights that 19 per cent of respondents feel full compliance is impossible; 46 per cent of respondents are concerned of the conflict with other national laws; and 25 per cent of respondents have changed vendors in response to the GDPR.

Time, regulatory actions and, hopefully, guidance will help resolve some of these uncertainties, but a good understanding of the technical issues and the complexity of the legal obligations would certainly be appreciated by most parties.19


1 Roy Kamp is a data protection officer and Noémie Weinbaum is an attorney at McAfee.

4 id. Guideline No.8.

6 Footnote 23.

7 Article 10 of the Order opt. cit. 3.

11 Guidelines on the right to data portability: https://ec.europa.eu/newsroom/article29/item-detail.cfm?item_id=611233.

12 This is aligned with the requirements of the UK Open Banking API Standards, available on: https://www.openbanking.org.uk/providers/standards/. For a full review of the various standards, refer to: http://blog.particeep.com/analyse-tout-ce-que-vous-devez-savoir-sur-la-dsp2-et-linfrastructure-api/.

17 'GAFA Approach to Digital Banking Transformation - Accenture'. www.accenture.com.

18 The ANSSI provides for instance a guide for small and medium companies at https://www.ssi.gouv.fr/guide/guide-des-bonnes-pratiques-de-linformatique/. Would the respect of such guide be considered as equivalent to the ISO 27001 standards?