The EU Cloud Code of Conduct and what a bank reads from it

Article 40 GDPR lets associations draw up codes of conduct that apply the regulation to a particular sector, and a supervisory authority approves the code. Where a code covers processing in several member states, the European Data Protection Board gives an opinion and the Commission can confirm general validity. The code then operates with a monitoring body accredited under Article 41 GDPR, which is the part that separates a code of conduct from a self-declaration: the body assesses whether a declared service really meets the requirements and can suspend or exclude a provider.

For the EU Cloud Code of Conduct that body is SCOPE Europe, based in Brussels. Its assessment is what stands behind an entry in the public register, and a bank that reads an entry is reading the result of a third-party check and not the provider's own word.

The code sets out requirements for implementing Article 28 GDPR and the articles around it: the processor's duties on instructions, sub-processors, security of processing, assistance with data subject rights, breach notification, audit and deletion or return at the end of the contract. It covers all cloud service layers, so infrastructure, platform and software services are all in scope, each with the same requirement set applied to what that layer actually does.

Two points matter to a bank reading the detail. The code requires the provider to disclose the countries in which the data is processed, which gives the bank a documented basis for its transfer analysis. And it requires the provider to state the conditions under which it would disclose data to a public authority, which is the question a residency clause alone leaves open. The page on sovereign cloud for banks goes through how that reads against the CLOUD Act.

Adherence is declared per service, so one provider can hold entries for some services and none for others. The declaration names the service, the version of the code it was assessed against and the countries of processing, and the monitoring body maintains the public register where a buyer verifies it. The code defines three compliance levels, and the point a buyer usually gets wrong is what separates them: all three require full compliance with every requirement of the code, and they differ only in the type of evidence the provider submits to the monitoring body. A higher level therefore means stronger documentation of the same compliance and not a stricter standard. SCOPE Europe runs an initial assessment and annual re-assessments, and can open a further assessment after a complaint, a media report, a change in legislation or new guidance from a data protection authority.

The practical procedure for a bank is short. Find the exact service name in the contract, look it up in the register, treat a logo on a marketing page as no evidence, check that the entry is current, and read the countries of processing against the bank's own transfer documentation. An entry for a different service of the same provider proves nothing about the one being bought.

Adherence is evidence of GDPR processor compliance for a named service. It is not evidence of operational resilience, it does not deliver the contractual clauses DORA requires for ICT third-party arrangements, and it does not perform the transfer impact assessment a controller owes where data or access leaves the EU. A bank that treats an adherence entry as a substitute for its own DORA documentation has a gap the supervisor will find in the register of information, which the page on DORA in Germany covers.

Nor does adherence say anything about the provider's exit obligations or about the bank's ability to move the workload. Those sit in the contract, and the page on digital operational resilience in Europe covers what the regulation expects of them.

Search results for the term mix in the European Code of Conduct for Data Centre Energy Efficiency, which is a different instrument entirely. That code is a voluntary scheme coordinated by the Commission's Joint Research Centre, it addresses power usage and cooling practice in data centers, and it has no connection to GDPR or to processor duties. A data center can participate in it and have no bearing whatsoever on the data protection question. The data centers for finance in Frankfurt page covers the energy and cooling rules that apply to a German site.

No, and the distinction is legal. A code of conduct under Article 40 GDPR and a certification under Article 42 GDPR are two separate instruments with separate approval routes. The code works through a declaration of adherence verified by a monitoring body, while a certification is issued by an accredited certification body against approved criteria. Providers sometimes describe their adherence as a certification in marketing material; the register entry is what a buyer should cite.

It proves one part. A bank's suitability assessment has to cover ICT risk, concentration, resilience testing, audit rights, sub-outsourcing, exit and the supervisory reporting duties on top of the data protection question. Adherence settles the data protection question for the named service and leaves the rest to the contract and to the bank's own assessment. The useful way to use it is as one documented input, cited by register entry, inside a wider file.

This is the gap that matters most to a bank with a non-EU provider. The code approved in 2021 is not an Article 46 GDPR transfer safeguard, so adherence does not legitimize a transfer to a third country on its own. After the Schrems II judgment a separate module for third-country transfers was begun, and a bank planning on it has to check its status before relying on it.

Until that module is in force, a transfer still needs its own legal basis and its own transfer impact assessment, with standard contractual clauses and supplementary measures where they apply. The useful way to read an adherence entry is as evidence about the processing, with the transfer question handled separately, which is the same split the sovereign cloud page makes between residency and jurisdiction.

Article 83(2)(j) GDPR requires a supervisory authority to take adherence to an approved code of conduct into account when it sets an administrative fine, and the European Data Protection Board has indicated it can work as a mitigating factor. It does not change the tiers of the fine structure, and it does not make adherence a defense, so a bank should not present it as one.

Where it does help is in the controller's own file. A controller has to be able to show it chose a processor that offers sufficient guarantees, and an entry assessed by an accredited monitoring body is documented evidence for that choice, which is worth more at the point of selection than after an incident.

The work started in 2012 under the European Commission's cloud strategy, ran first against the Data Protection Directive and was assessed by the Article 29 Working Party in January 2015. The Commission handed the project to industry in 2017, when Alibaba Cloud, Fabasoft, IBM, Oracle, Salesforce and SAP set up the General Assembly and designated SCOPE Europe as the monitoring body. The Belgian data protection authority approved the code on May 20, 2021, after a positive opinion from the European Data Protection Board. The code is governed by a General Assembly, a Steering Board and a Secretariat, and runs in five sections: scope, data protection, security requirements, monitoring and compliance, and internal governance.

A second code exists for the same sector. The CISPE Data Protection Code of Conduct was approved on June 3, 2021 and is a separate instrument with its own monitoring body, so a provider can adhere to one, the other or neither. A bank comparing two providers should check which code an entry belongs to before treating two claims as equivalent.