Les prin­ci­paux enjeux qu’une banque doit consi­dé­rer dans le choix d’un cloud service provi­der (« CSP »), la revue des proces­sus internes et la négo­cia­tion contrac­tuelle avec le CSP, sont les suivants :

1. Droit règle­men­taire : Circulaire FINMA Outsourcing 2018/​03 (« Circulaire Outsourcing ») et Annexe 3 de la Circulaire FINMA Risques opéra­tion­nels 2008/​21 (« Circulaire Risques Opérationnels »);
2. Droit de la protec­tion des données : Loi fédé­rale sur la protec­tion des données (« LPD », cf. égale­ment la nouvelle version adop­tée en septembre 2020 : « nLPD ») et Règlement géné­ral de l’UE sur la protec­tion des données (« RGPD ») si applicable ;
3. Secret bancaire et dispo­si­tions analogues : Article 47 de la loi fédé­rale sur les banques (« LB »), article 69 de la loi sur les établis­se­ments finan­ciers (« LEFin »), article 162 du code pénal (« CP ») et autres dispo­si­tions légales proté­geant la confi­den­tia­lité de certaines informations.

Le Guide « Cloud » de l’Association suisse des banquiers (« ASB ») illustre de manière didac­tique comment ces normes géné­rales et abstraites doivent être trans­po­sées dans le cadre de projets impli­quant le recours à un cloud.

A.           Droit règlementaire

La Circulaire Outsourcing s’ap­plique aux banques et maisons de titres suisses, ainsi qu’aux succur­sales suisses de banques et maisons de titres étran­gères. A comp­ter du 1er janvier 2021, le champ d’ap­pli­ca­tion de la Circulaire Outsourcing sera élargi aux direc­tions de fonds (et aux SICAV auto­gé­rées qui sont trai­tées par analo­gie aux direc­tions de fonds), ainsi qu’aux gestion­naires de fortune collective.

Dans une pers­pec­tive maté­rielle, la Circulaire Outsourcing règle­mente l’ex­ter­na­li­sa­tion d’une fonc­tion essen­tielle, à savoir une « fonc­tion dont dépend de manière signi­fi­ca­tive le respect des objec­tifs et des pres­crip­tions de la légis­la­tion sur la surveillance des marchés finan­ciers » (Circulaire Outsourcing, N 4). Selon la pratique de la FINMA, toute exter­na­li­sa­tion impli­quant la trans­mis­sion à un pres­ta­taire de services d’une grande quan­tité de client-iden­ti­fying data (CID) tombe ipso facto sous le coup de la Circulaire Outsourcing.

L’application de la Circulaire Outsourcing déclenche une série d’obli­ga­tions, dont les prin­ci­pales sont résu­mées ci-après :

• Choix, instruc­tion et contrôle du CSP (y compris due dili­gence documentée);
• Tenue d’un inven­taire des exter­na­li­sa­tions de fonc­tions essentielles ;
• Extension du système de contrôle interne à la fonc­tion externalisée ;
• Conclusion d’un contrat avec le CSP qui contient notam­ment les dispo­si­tions suivantes : 
  • Droit pour la banque de donner des instruc­tions au CSP et d’en contrô­ler l’exécution ;
  • Exigences en matière de sécu­rité de l’in­for­ma­tion, y compris un dispo­si­tif propre à assu­rer la conti­nuité de la fonc­tion exter­na­li­sée en cas d’urgence ;
  • Droit d’ac­cès et d’au­dit inté­gral, perma­nent et sans entraves au béné­fice (i) de la banque, (ii) de son audi­teur pruden­tiel et (iii) de la FINMA sur la fonc­tion exter­na­li­sée, à la fois auprès du CSP et de ses sous-trai­tants ; en cas de trans­fert à l’étran­ger (ce qui est souvent le cas lors du recours à un cloud), le CSP doit garan­tir que ces droits puissent s’exer­cer dans le pays de destination ;
  • Lorsque le CSP fait appel à des sous-trai­tants pour exécu­ter tout ou partie d’une fonc­tion essen­tielle, le contrat doit permettre à la banque (i) d’être infor­mée suffi­sam­ment tôt du recours, respec­ti­ve­ment du chan­ge­ment de sous-trai­tants et (ii) d’avoir la possi­bi­lité de mettre un terme au contrat d’ex­ter­na­li­sa­tion si elle refuse le recours au sous-trai­tant. Ces sous-trai­tants doivent par ailleurs sous­crire aux mêmes obli­ga­tions que le CSP.

Les exigences de l’Annexe 3 de la Circulaire Risques Opérationnels doivent égale­ment être prises en compte lorsque le recours au CSP implique la trans­mis­sion de client-iden­ti­fying data à ce dernier.

B.           Droit de la protec­tion des données

Si des données person­nelles (y compris des client-iden­ti­fying data) sont rendues acces­sibles au CSP, le projet d’ex­ter­na­li­sa­tion doit égale­ment être revu à la lumière de la LPD (et poten­tiel­le­ment du RGPD), ce qui implique la prise en compte notam­ment des points suivants :

• Devoir d’in­for­ma­tion à l’égard des personnes concer­nées (e.g., clients, employés);
• Conclusion d’un contrat de sous-trai­tance (data proces­sing agree­ment) avec le contenu mini­mal prévu par les articles 28 RGPD, 10a LPD et 9 nLPD ;

Lorsque des données person­nelles sont acces­sibles dans un Etat ne dispo­sant pas d’une légis­la­tion assu­rant un niveau « adéquat » de protec­tion des données person­nelles (e.g., les Etats-Unis), des mesures de protec­tion supplé­men­taires doivent être mises en œuvre, la plus utili­sée étant les « Clauses-Modèles » de la Commission euro­péenne. La vali­dité de ces clauses est toute­fois incer­taine depuis l’ar­rêt Schrems II de la Cour de Justice de l’UE du 16 juillet 2020 (cf. swiss​pri​vacy​.law/​17/), de sorte que d’autres garan­ties doivent être envisagées.

Les contraintes liées à la protec­tion des données peuvent être signi­fi­ca­ti­ve­ment réduites si seules des données pseu­do­ny­mi­sées ou cryp­tées sont remises au CSP, en prêtant toute­fois atten­tion au risque de reverse engi­nee­ring et donc de divul­ga­tion indi­recte de données personnelles.

C.           Secret bancaire et secret commercial

La compa­ti­bi­lité avec le secret bancaire doit être analy­sée pour chaque projet qui implique la mise à dispo­si­tion de client-iden­ti­fying data au CSP, typi­que­ment lorsque les spéci­fi­ci­tés de la pres­ta­tion ne permettent pas la pseu­do­ny­mi­sa­tion ou le cryptage.

Si la trans­mis­sion est limi­tée à un CSP situé en Suisse (hypo­thèse peu réaliste compte tenu du busi­ness model des CSP), l’ob­ten­tion d’une levée du secret bancaire par le client ne sera en prin­cipe pas néces­saire vu que le CSP est lui-même soumis au secret bancaire en vertu de l’art. 47 al. 1 let. a LB. Le Guide « Cloud » de l’ASB adopte le même raison­ne­ment en cas de trans­mis­sion de client-iden­ti­fying data à un CSP loca­lisé en-dehors de Suisse, alors même que la protec­tion pénale du secret bancaire est limi­tée par le prin­cipe de terri­to­ria­lité. En pratique, nombreuses sont les banques qui demandent une levée du secret bancaire dans cette dernière hypo­thèse, l’un des éléments-clés étant de s’as­su­rer que cette renon­cia­tion au secret bancaire est octroyée sur une base dûment informée.

D.           Conclusions

D’un point de vue juri­dique, le lance­ment d’un projet de cloud banking doit être revu dans la pers­pec­tive de la rela­tion contrac­tuelle avec le CSP, tout en gardant à l’es­prit les droits des personnes dont les données seront confiées au CSP (e.g., respect du devoir d’in­for­ma­tion prévu en droit de la protec­tion des données, obten­tion éven­tuelle d’une levée du secret bancaire). D’un point de vue règle­men­taire, les exigences supplé­men­taires décou­lant des circu­laires de la FINMA doivent être prises en compte, notam­ment lors de la négo­cia­tion du contrat conclu avec le CSP.