ISO 27001 pour les FinTech suisses : le guide expert face à FINMA (2026)

Pourquoi ISO 27001 se lit-elle différemment dans une FinTech suisse ?

Une CTO de FinTech m'a fait visiter son SMSI le trimestre dernier. Documentation propre, périmètre bien cadré, certification obtenue six mois plus tôt par un organisme reconnu. Puis sa banque partenaire lui a transmis la revue annuelle d'externalisation au titre de la Circulaire FINMA 18/3. Trois des contrôles qu'elle avait clos lors de son audit ISO 27001 sont revenus avec des questions complémentaires. Pas parce que le SMSI était mauvais. Parce que FINMA lit la conformité ISO sous un angle différent de celui d'un auditeur ISO.

C'est le paradoxe du SMSI FinTech en Suisse. ISO 27001 est l'ancrage international auquel chaque régulateur renvoie, mais dans une FinTech suisse, elle ne reste jamais seule sur la page. Elle se lit en parallèle des circulaires FINMA sur le risque opérationnel et l'externalisation, de la Loi fédérale sur la sécurité de l'information (ISG), de la nouvelle Loi sur la protection des données (nLPD), et, pour toute FinTech exposée à l'UE, de DORA et de l'AI Act. Six choses concrètes changent quand ces lectures se superposent à votre SMSI.

ISO 27001:2022 est la norme. Les contrôles de l'Annexe A, les chapitres SMSI (4 à 10), le cycle d'audit, tout ce qu'un Lead Implementer apprend à concevoir et qu'un Lead Auditor apprend à évaluer. Cette couche-là ne change pas en Suisse. L'Annexe A se lit de la même façon à Zurich qu'à Singapour.

Ce qui change, c'est la couche qui se superpose. Pour une FinTech suisse, l'overlay réglementaire lit chaque contrôle ISO sous un angle opérationnel précis, lui pose une question précise, et traite les constats d'audit comme des entrées d'inspection prudentielle, pas comme la fin de l'histoire.

La lecture à deux couches, c'est le sujet que les programmes Lead Implementer génériques n'abordent pas par défaut. La formation conduite par des praticiens comble cet écart. Les six changements ci-dessous, c'est là que cet écart se manifeste en pratique.

Qu'est-ce qui change pour le périmètre du SMSI quand FINMA entre dans la pièce ?

Dans un environnement non régulé, le périmètre du SMSI est une décision interne : quels services, processus et données vous voulez certifier. Dans une FinTech suisse, le périmètre devient une question de procurement et de surveillance prudentielle.

En phase pré-licence, les équipes de due diligence de vos banques ou assureurs partenaires dictent de fait le périmètre : tout ce qui touche à leurs services régulés doit être inclus. Une fois la licence obtenue, FINMA s'attend à ce que le périmètre couvre tous les services matériels, et les superviseurs lisent les déclarations de périmètre avec un œil aiguisé sur les exclusions. Le mode d'échec le plus fréquent consiste à traiter les rails de paiement orientés client ou les pipelines KYC comme « externalisés et donc hors périmètre ». Dans la pratique prudentielle de FINMA et la lecture de due diligence des partenaires, ils sont traités comme inclus dans le périmètre : c'est votre service à une contrepartie régulée, et la déclaration de périmètre de l'organisme certificateur est l'artefact qu'un examinateur FINMA, et le responsable d'externalisation de votre partenaire, liront en premier.

Ce qui fonctionne en pratique : définir le périmètre comme le service livré, et non comme l'entité juridique qui fournit chaque composant. Une FinTech d'orchestration de paiements qui vend à une banque régulée ne peut pas définir son périmètre SMSI comme « la couche d'orchestration » tout en excluant le workflow d'onboarding marchand qui déclenche le KYC. Toute la surface du service est dans le périmètre, et la Déclaration d'Applicabilité doit le refléter. Tout autre arrangement échoue à la lecture procurement avant d'échouer à la lecture prudentielle.

Comment les contrôles de l'Annexe A se lisent-ils face à la Circulaire 23/01 ?

Un audit ISO propre n'équivaut pas à une inspection FINMA propre. Le même contrôle peut passer l'un et échouer à l'autre.

La gestion des changements TIC (Annexe A.5.37) se lit face aux attentes de la Circulaire 23/01 sur le risque de changement pour les fonctions critiques. La continuité d'activité (A.5.30) se lit face au pilier résilience opérationnelle, pas seulement « avez-vous un plan » mais « quelle est votre tolérance à la perturbation, par service, et comment cette tolérance a-t-elle été dérivée ». La gestion des incidents cyber (A.5.24) se lit par-dessus les attentes de notification d'incidents de FINMA et l'obligation de notification des cyberattaques au titre de l'ISG. La sécurité des fournisseurs (A.5.19 à A.5.23) se lit conjointement avec la Circulaire 18/3 sur l'externalisation.

L'erreur consiste à documenter les contrôles de l'Annexe A en silo et à découvrir la couche réglementaire à la première inspection FINMA. La discipline consiste à mapper chaque contrôle matériel à sa clause ISO et à sa circulaire suisse applicable, dans le même document de contrôle.

C'est un endroit où l'outillage gagne sa place. Certaines FinTech suisses construisent la vue multi-référentiel en interne sur des plateformes GRC existantes. D'autres utilisent des outils dédiés tels qu'Acuna GRC, qui peut modéliser ISO 27001, les attentes FINMA, la nLPD, DORA et les overlays AI Act comme une bibliothèque de contrôles unique, plutôt que cinq documents en parallèle. Le choix de l'outil compte moins que la discipline d'éviter les bibliothèques de contrôles parallèles ; cette discipline compte plus que n'importe quel outil spécifique.

Pour les praticiens, la combinaison de la formation Lead Implementer et de la formation ISO 27005 Risk Manager est nettement plus solide que l'une ou l'autre prise séparément dans un contexte de FinTech régulée, parce que la densité de risque est la dimension où la lecture FINMA mord le plus fort.

Que demande la Circulaire 18/3 à votre registre des risques fournisseurs ?

Le registre des risques fournisseurs du SMSI n'est pas un artefact de back-office dans une FinTech suisse. C'est le document que les examinateurs FINMA lisent pour évaluer le risque de concentration, la stratégie de sortie, les droits d'audit et les chaînes de sous-externalisation. Les plateformes TPRM comme Supplier Shield permettent de structurer ce registre pour exprimer les quatre dimensions prudentielles de la Circulaire 18/3, pas seulement la lecture sécurité d'ISO 27001.

La Circulaire 18/3 (Externalisation, banques et assurances) pose quatre questions prudentielles sur chaque relation d'externalisation matérielle : le risque de concentration est-il compris et borné ; existe-t-il une stratégie de sortie crédible ; les droits d'audit sont-ils exécutables de bout en bout ; la sous-externalisation est-elle maîtrisée. Les contrôles fournisseurs d'ISO 27001 répondent à la dimension sécurité. La Circulaire 18/3 pose les dimensions résilience et gouvernance par-dessus.

Le mode d'échec le plus courant pour les FinTech, c'est la concentration cloud. Une relation unique avec un hyperscaler, sans stratégie de sortie documentée, passe la sécurité fournisseurs ISO 27001 si la configuration de sécurité est saine. Elle ne passe pas la Circulaire 18/3.

Pour la FinTech qui est elle-même le tiers, c'est-à-dire qui vend à une banque, la même lecture s'inverse : vous serez auditée au titre du cadre d'externalisation de votre client, et votre certification ISO 27001 est le ticket d'entrée, pas la conclusion. Les clauses de cascade des droits d'audit, la notification de sous-externalisation et le support à la stratégie de sortie deviennent des obligations contractuelles que le SMSI doit opérationnaliser, pas seulement décrire.

Comment le reporting des incidents cyber se cumule-t-il en triple en FinTech suisse ?

ISO 27001 attend un processus de gestion des incidents. La régulation FinTech suisse en attend trois, qui tournent en parallèle.

Le processus ISO interne existe pour le SMSI : détection, classification, réponse, retour d'expérience, et amélioration continue. Les attentes FINMA s'y superposent : les incidents matériels chez les institutions régulées et leurs partenaires d'externalisation matériels sont reportables sur la base du risque opérationnel, avec des délais et des contenus pilotés par la guidance FINMA et le dialogue prudentiel. L'obligation de reporting sous 24 heures de l'ISG, en vigueur depuis avril 2025, fixe une horloge stricte pour les cyberattaques sur les infrastructures critiques, et les institutions financières suisses sont systématiquement classées comme telles. Depuis octobre 2025, le cadre de sanctions fédéral au titre de l'ISG prévoit des amendes pouvant atteindre 100 000 CHF contre les opérateurs d'infrastructures critiques qui ne respectent pas l'obligation de notification des cyberattaques sous 24 heures. Le montant est inscrit dans la loi elle-même ; les modalités d'application continuent d'être développées par le NCSC et le Conseil fédéral.

Ce qui survit à un incident réel, c'est un processus d'incidents unique qui produit les trois sorties à partir d'une seule timeline, pas trois processus d'incidents qui tournent sur des rails parallèles.

Que fait la nLPD aux décisions de périmètre ISO 27001 ?

La nouvelle Loi sur la protection des données (nLPD), en vigueur depuis le 1er septembre 2023, n'exige pas ISO 27701, mais elle façonne chaque décision de périmètre du SMSI qui touche aux données personnelles.

Le mode d'échec le plus courant en FinTech consiste à intégrer la base de données clients dans le périmètre comme « la responsabilité de la banque » alors que la FinTech est en fait sous-traitant au sens de la LPD. ISO 27001 ne détectera pas cette erreur ; l'Annexe A traite les données personnelles comme une catégorie d'actifs informationnels parmi d'autres. La LPD, elle, la détecte. L'effet en aval, c'est que les contrôles SMSI sur la conservation, la base légale, les droits des personnes concernées et le transfert transfrontalier deviennent pertinents pour la LPD, et l'autorité de surveillance (le PFPDT) les lit sous un angle différent de celui de votre auditeur ISO.

Pour les FinTech suisses qui traitent des données personnelles matérielles, soit la plupart d'entre elles, ISO 27701 (l'extension Système de management de la confidentialité de l'information) devient de plus en plus le bon complément. Elle se superpose à ISO 27001 et aligne le programme de protection des données sur la même discipline de management. Elle n'est pas légalement requise. Elle devient souvent commercialement requise par les partenaires qui font eux-mêmes face à la LPD et au RGPD.

Jusqu'où la régulation UE atteint-elle un SMSI de FinTech suisse ?

Une FinTech suisse est une entité suisse. Son exposition réglementaire est rarement uniquement suisse.

DORA est entré en application le 17 janvier 2025, avec des standards techniques détaillés (RTS et ITS) qui se déploient par phases jusqu'en 2026. Il s'applique directement aux entités formellement désignées comme prestataires tiers critiques de services TIC (CTPP) auprès des entités financières de l'UE. Les prestataires non critiques, ce qui inclut la plupart des FinTech suisses qui servent des contreparties UE, prennent typiquement des obligations alignées sur DORA via des clauses de cascade contractuelle imposées par leurs clients entités financières UE au titre des exigences DORA de gestion du risque tiers.

Le RGPD attrape les FinTech suisses qui ont des clients UE, peu importe le pays d'incorporation. L'AI Act se déploie par phases sur 2025 à 2027 : les dispositions sur les pratiques interdites s'appliquent depuis le 2 février 2025, les obligations sur l'IA à usage général et la gouvernance s'appliquent depuis le 2 août 2025, et le gros des obligations sur les systèmes d'IA à haut risque entre en vigueur le 2 août 2026, avec des transitions étendues pour les systèmes à haut risque embarqués qui courent jusqu'en 2027. Les FinTech suisses qui utilisent l'IA pour des décisions de crédit, la détection de fraude, le KYC ou l'authentification biométrique sont concernées dès lors que leurs systèmes relèvent de la classification haut risque, ou qu'elles placent des systèmes d'IA sur le marché de l'UE.

Un SMSI uniquement suisse est une fiction pour la plupart des FinTech à l'échelle. La discipline consiste à cadrer le SMSI une fois, à identifier les lectures réglementaires qui s'appliquent, et à documenter chacune face aux mêmes contrôles, plutôt qu'à construire des systèmes de management séparés par régulateur. Notre guide complet sur la conformité DORA pour les institutions financières suisses et européennes couvre le côté UE en détail ; ce guide-ci se concentre sur la lecture suisse.

Quelle est la différence entre les entités sous surveillance FINMA, le sandbox FinTech et les entités régies par la Loi DLT ?

Toutes les FinTech suisses ne sont pas dans le même bucket réglementaire, et les attentes SMSI suivent le bucket.

Les entités sous surveillance FINMA, à savoir les banques au titre de la Loi sur les banques, les assurances, les titulaires d'une licence FinTech au titre de l'art. 1b de la Loi sur les banques, les maisons de titres, les directions de fonds, les gestionnaires de fortune et trustees au titre de la LEFin, sont directement surveillées. Tout l'arsenal FINMA s'applique : la Circulaire 23/01 pour les banques et les FinTech licenciées dans le périmètre résilience opérationnelle, la Circulaire 18/3 sur l'externalisation, le dialogue prudentiel, les inspections sur place.

Les entités du sandbox FinTech opèrent au titre de l'exemption de minimis (dépôts publics jusqu'à 1 million de CHF) qui autorise certaines activités sous le seuil sans licence bancaire complète. Le sandbox n'est pas une catégorie de licence formelle FINMA ; c'est un traitement de périmètre prudentiel. Les entités sandbox ne sont pas directement surveillées par FINMA comme l'est une banque licenciée, mais elles sont à l'intérieur d'un périmètre qui surveille le seuil, et les banques partenaires appliquent systématiquement les attentes de la Circulaire 18/3 par voie contractuelle. Le sandbox n'isole pas le SMSI d'une lecture de type prudentiel ; il change juste qui fait la lecture.

Les entités régies par la Loi DLT, c'est-à-dire les systèmes de négociation fondés sur la TRD licenciés au titre de la Loi DLT de 2021, se trouvent dans une catégorie de surveillance distincte avec une supervision FINMA spécifique aux infrastructures de marché de la technologie des registres distribués. Le périmètre SMSI doit ici absorber des risques opérationnels propres à la TRD (gestion des changements de smart contracts, conservation des tokens, résilience du réseau) qui ne s'inscrivent pas confortablement dans les descriptions standards des contrôles de l'Annexe A, et l'organisme certificateur doit être à l'aise pour les auditer.

L'erreur consiste à supposer qu'un seul gabarit de SMSI convient aux trois buckets. La discipline consiste à cartographier votre périmètre réglementaire tôt, idéalement avant que le périmètre du SMSI ne soit verrouillé, et à laisser le bucket piloter les décisions de périmètre et de DA.

Comment la posture du SMSI change-t-elle avant et après la licence ?

Le SMSI joue deux rôles différents selon l'endroit où la FinTech se situe dans son parcours réglementaire.

En phase pré-licence, le SMSI est un actif procurement. Les banques partenaires conduisent leur due diligence au titre de leur propre cadre d'externalisation. SOC 2 Type II est souvent le ticket d'entrée pour les partenaires ancrés aux États-Unis ; ISO 27001 différencie de plus en plus sur les engagements européens et internationaux. À ce stade, le SMSI existe pour gagner et conserver l'activité partenaire.

Une fois la licence obtenue, le SMSI devient un artefact réglementaire. FINMA inspecte directement. Le reporting cyberattaque ISG s'applique. La surveillance d'externalisation circule en remontant la chaîne, pas seulement en descendant. À ce stade, le SMSI existe pour satisfaire un superviseur, en plus de satisfaire les partenaires.

L'erreur courante consiste à reconstruire le SMSI à la transition de licence. La bonne approche consiste à le construire en pré-licence avec l'overlay post-licence déjà cartographié, pour que la transition soit une maturation documentaire plutôt qu'une re-architecture.

Quels contrôles de l'Annexe A sont les plus durement audités en FinTech suisse ?

Sur 100+ implémentations ISO 27001 et 200+ audits, les contrôles qui attirent le plus de scrutin dans les services financiers suisses ne sont pas une surprise ; mais les raisons pour lesquelles ils l'attirent sont plus tranchées que ce que la norme suggère.

A.5.19 à A.5.23 (Sécurité de l'information dans les relations fournisseurs). L'ensemble du jeu de contrôles fournisseurs se lit face à la Circulaire 18/3. Les droits d'audit, la sous-externalisation et la concentration cloud pilotent les questions. Documenter la revue de sécurité fournisseurs est nécessaire ; le superviseur veut voir les dimensions résilience et stratégie de sortie traitées également.

A.5.24 à A.5.28 (Gestion des incidents de sécurité de l'information). Les cinq contrôles d'incidents pris ensemble sont inspectés comme un processus à triple sortie : processus ISO, notification FINMA, rapport ISG sous 24 heures. Le constat le plus fréquent, c'est que le playbook produit l'une des trois mais pas les trois.

A.5.30 (Préparation TIC à la continuité d'activité). Se lit face au pilier résilience de la Circulaire 23/01. Le contrôle passe ISO si un plan testé existe. Il ne passe la Circulaire 23/01 que si la tolérance à la perturbation est définie par service critique, que les scénarios sont testés, et que les objectifs de reprise sont dérivés de la tolérance opérationnelle, plutôt que l'inverse.

A.5.34 (Confidentialité et protection des informations personnelles identifiables). Se lit face à la nLPD. Les constats se concentrent autour du cadrage de la responsabilité du traitement (qui est responsable du traitement pour quel jeu de données) et des mécanismes de transfert transfrontalier après les décisions d'adéquation LPD-RGPD.

A.8.34 (Protection des systèmes d'information pendant les audits et les tests). Se lit face aux attentes FINMA sur l'accès prudentiel. Le contrôle doit supporter à la fois les scénarios d'audit interne et d'inspection prudentielle ; le second est souvent oublié dans les implémentations non régulées.

Un schéma qui fonctionne sur ces contrôles : maintenir la documentation des contrôles dans un système qui peut exprimer la lecture multi-référentiel nativement, qu'il s'agisse d'un build GRC interne ou d'un outil dédié. La discipline qui compte, c'est le principe de source unique de vérité : un contrôle, un enregistrement, plusieurs vues réglementaires. Cinq documents en parallèle finissent par échouer à l'audit.

Comment choisir un organisme certificateur en tant que FinTech suisse ?

Le choix de l'organisme certificateur pour une FinTech suisse est une décision plus conséquente que ce que l'exercice standard de comparaison de fournisseurs suggère, parce que la compréhension de l'overlay réglementaire suisse par l'organisme certificateur façonne la manière dont le SMSI est audité, cadré et certifié.

Trois facteurs comptent plus qu'ils ne comptent dans des contextes non régulés.

Une accréditation que les contreparties financières suisses reconnaissent. Les organismes accrédités SAS et ceux qui ont une forte reconnaissance dans le secteur financier suisse retirent une question procurement que les autres accréditations laissent ouverte. Les équipes de due diligence des banques partenaires ont des listes préférentielles.

La familiarité de l'auditeur avec la régulation financière suisse. Un Lead Auditor ISO 27001 qui lit l'Annexe A.5.30 en silo n'est pas le même que celui qui la lit sous l'angle de la Circulaire 23/01. Les questions sont différentes ; les constats sont différents ; les recommandations de remédiation sont différentes. Demandez explicitement, lors du choix de l'organisme certificateur, si leurs Lead Auditors ont déjà audité des entités sous surveillance FINMA.

L'alignement de l'expression du périmètre avec les lectures réglementaires. Le gabarit de déclaration de périmètre standard de l'organisme certificateur compte. Une déclaration qui se lit proprement pour un examinateur FINMA n'est pas toujours celle qu'un organisme certificateur générique produirait par défaut.

Pour les FinTech qui naviguent ce choix en parallèle de l'implémentation elle-même, Abilene Advisors, le cabinet de conseil GRC du groupe Abilene, intervient sur tout le cycle d'implémentation ISO 27001 dans les services financiers suisses régulés, y compris l'engagement avec l'organisme certificateur, la rédaction du périmètre et la revue de readiness pré-audit. Cela complète le côté formation d'Abilene Academy : la formation Lead Implementer construit la capacité du praticien ; l'engagement conseil porte le projet.

Quelles sont les 10 étapes pratiques pour ISO 27001 dans une FinTech suisse ?

Une séquence d'implémentation pragmatique qui tient face à la due diligence partenaire et à la lecture FINMA. Les durées ci-dessous supposent une FinTech à un stade intermédiaire avec des pratiques d'ingénierie établies ; les FinTech à un stade plus précoce raccourcissent la durée mais pas la séquence.

1. Cartographier le périmètre réglementaire

Avant de cadrer le SMSI, décidez dans quel bucket réglementaire vous êtes : licence FINMA, sandbox FinTech, entité Loi DLT, ou non régulée avec partenaires régulés. Identifiez parmi la Circulaire FINMA 23/01, la Circulaire 18/3, l'ISG, la nLPD, DORA, le RGPD et l'AI Act ce qui s'applique. Le livrable, c'est une carte réglementaire d'une page qui pilote chaque décision suivante.

2. Définir le périmètre du SMSI comme un service, pas une entité juridique

Cadrez par la surface de service orientée client, pas par l'organigramme. Si vous servez des contreparties régulées, la surface qu'elles consomment définit le plancher de votre périmètre. Les exclusions qui paraissent défendables en termes ISO peuvent échouer à la lecture Circulaire 18/3 dès l'étape procurement.

3. Conduire l'analyse de risque avec l'overlay réglementaire

Lancez une analyse de risque alignée sur ISO 27005, mais enrichissez le catalogue de menaces avec des scénarios pertinents pour FINMA (perturbation opérationnelle des services critiques, concentration tiers, timing de notification d'incident) et des scénarios pertinents pour la LPD (ambiguïté sur la responsabilité du traitement, litiges sur le transfert transfrontalier). Les analyses de risque génériques les manquent.

4. Construire une bibliothèque de contrôles multi-référentiel

Documentez les contrôles de l'Annexe A une fois, avec une colonne d'overlay réglementaire pour chaque contrôle qui montre la lecture FINMA, LPD, DORA et (le cas échéant) AI Act. Maintenez-la dans un outil qui peut exprimer cela nativement, soit une plateforme GRC existante configurée pour le contexte suisse, soit un outil dédié comme Acuna GRC. La discipline de source unique de vérité, c'est ce qui survit à l'audit.

5. Opérationnaliser le processus d'incidents à triple sortie

Concevez le processus d'incidents pour produire trois sorties à partir d'une seule timeline : enregistrement d'incident ISO, notification FINMA (le cas échéant), et rapport ISG sous 24 heures. Testez le timing en exercices de table. L'échec du triple stack, c'est le constat SMSI le plus coûteux en FinTech suisse régulée.

6. Trancher la question SOC 2 vs ISO 27001 tôt

Décidez si la FinTech tourne sur SOC 2 seul, ISO 27001 seule, ou les deux, en fonction de la géographie partenaire. Les écosystèmes partenaires ancrés aux États-Unis attendent souvent SOC 2 Type II. Les partenaires européens et les contreparties sous surveillance FINMA attendent ISO 27001. Beaucoup de FinTech suisses régulées maintiennent les deux, avec un jeu de contrôles ingénierié pour qu'un cycle d'audit en évidence les deux.

7. Engager l'organisme certificateur avant la revue de direction

Discutez de la déclaration de périmètre et de l'approche d'audit avec l'organisme certificateur choisi avant de verrouiller le SMSI pour la certification. Apportez des questions sur la lecture de la régulation financière suisse. L'organisme certificateur qui s'engage substantiellement, c'est le bon ; celui qui ne le fait pas, c'est un problème d'audit futur.

8. Conduire une revue de readiness pré-audit

Une revue de readiness structurée face à la fois à la conformité ISO 27001 et à l'overlay réglementaire attrape l'écart entre « conforme ISO » et « défendable face à FINMA » avant l'audit de certification. C'est là que l'engagement conseil externe gagne ses honoraires ; Abilene Advisors mène des revues de readiness FinTech-spécifiques dans le cadre de la mission d'implémentation.

9. Construire le registre fournisseurs comme un artefact réglementaire

Traitez le registre fournisseurs comme un artefact Circulaire 18/3, pas seulement un enregistrement Annexe A.5.19. Documentez la concentration, la stratégie de sortie, la cascade des droits d'audit et la notification de sous-externalisation pour chaque relation matérielle. Le registre doit pouvoir répondre aux quatre questions prudentielles de FINMA à la demande.

10. Planifier le dialogue prudentiel continu, pas les audits annuels

Une fois la licence obtenue, le SMSI vit dans un dialogue prudentiel continu. Construisez une cadence de revue trimestrielle qui met à jour l'overlay réglementaire, rafraîchit le registre fournisseurs, teste le triple stack incidents, et aligne la DA sur les éventuelles évolutions des circulaires FINMA. Le SMSI qui survit, c'est celui qui est conçu pour la continuité, pas pour la date de renouvellement du certificat.

Quelle formation et quel accompagnement pour un SMSI de FinTech suisse ?

La formation ISO 27001 Lead Implementer prépare à concevoir et à implémenter un SMSI au standard international. C'est le socle, et il est nécessaire. Pour un contexte de FinTech suisse, deux éléments précis méritent plus de poids qu'un curriculum générique ne leur en donne.

Le premier, c'est la profondeur en gestion du risque. Les FinTech sont denses en risques par nature, avec des transactions à haute vélocité, des dépendances tiers et un paysage de menaces qui évolue. La formation ISO 27005 Risk Manager étend ce que Lead Implementer couvre en analyse de risque vers une méthodologie complète de gestion du risque. Pour les praticiens qui travaillent dans des FinTech régulées, la combinaison Lead Implementer plus ISO 27005 Risk Manager est nettement plus solide que l'une ou l'autre prise séparément.

Le second, c'est l'overlay réglementaire suisse lui-même. Un trainer avec une expérience d'implémentation dans les services financiers suisses régulés apporte le contexte FINMA, ISG et LPD dans la méthodologie par défaut. Les supports Lead Implementer décrivent comment construire un SMSI. La conversation en classe détermine si vous repartez en sachant comment construire un SMSI qui tient face à la surveillance suisse.

Au-delà de la formation, le travail SMSI en FinTech demande couramment un engagement d'implémentation hands-on : rédaction du périmètre face à l'overlay réglementaire, choix de l'organisme certificateur, mapping multi-référentiel des contrôles, readiness pré-audit, et accompagnement du dialogue prudentiel continu. Abilene Advisors, le cabinet de conseil GRC du groupe Abilene, intervient sur tout ce cycle dans les services financiers suisses régulés, en complément de la formation Lead Implementer délivrée par Abilene Academy.

Sources et références

Circulaire FINMA 2023/1, Risques opérationnels et résilience, banques · finma.ch (officiel)

Circulaire FINMA 2018/3, Externalisation, banques et assurances · finma.ch (officiel)

Loi fédérale sur la sécurité de l'information (LSI/ISG), obligation de notification des cyberattaques · fedlex.admin.ch (officiel)

Nouvelle Loi sur la protection des données (nLPD), en vigueur depuis le 1er septembre 2023 · edoeb.admin.ch / PFPDT (officiel)

Loi fédérale sur l'adaptation du droit fédéral aux développements de la technologie des registres électroniques distribués (Loi DLT) · fedlex.admin.ch (officiel)

Règlement (UE) 2022/2554, Digital Operational Resilience Act (DORA) · eur-lex.europa.eu (officiel)

Règlement (UE) 2024/1689, AI Act de l'Union européenne · eur-lex.europa.eu (officiel)

ISO/IEC 27001:2022, Systèmes de management de la sécurité de l'information, Exigences · iso.org (officiel)