Tests d’intrusion finance au Japon : FSA, FISC et DORA

Tests d’intrusion bancaires au Japon : FSA, normes FISC et DORA

Votre groupe bancaire, votre assureur ou votre société de gestion a une filiale ou une succursale au Japon ? Ses systèmes doivent être testés selon les attentes de l’Agence des services financiers (FSA), le superviseur financier japonais. Depuis octobre 2024, ces attentes figurent dans une ligne directrice dédiée à la cybersécurité, qui fait des audits de vulnérabilités et des tests d’intrusion réguliers une mesure de base.

Côté européen, DORA impose depuis le 17 janvier 2025 un programme de tests de résilience opérationnelle numérique. Les deux cadres se recoupent largement, mais pas entièrement : la nature juridique, la fréquence, le périmètre minimal et la qualification des prestataires diffèrent. Un programme de tests conçu pour l’ACPR ne répond donc pas forcément, tel quel, à ce que la FSA vérifiera au Japon.

Cet article porte sur les audits de vulnérabilités et les tests d’intrusion « classiques ». Les tests d’intrusion fondés sur la menace (TLPT) sont traités dans notre article consacré au TLPT au Japon.

L’essentiel en trois points

Au Japon, ce n’est pas une option : la ligne directrice de la FSA range les audits de vulnérabilités et les tests d’intrusion réguliers parmi les « mesures fondamentales » attendues de tous les établissements supervisés, avec un périmètre minimal précis (équipements exposés comme les VPN, sites et API publics, applications mobiles).
DORA est plus précis sur le rythme : au moins un test par an pour tous les systèmes qui soutiennent des fonctions critiques ou importantes, et des scans automatisés au moins hebdomadaires. Le texte japonais laisse chaque établissement fixer la fréquence selon les risques.
Le prestataire n’est pas interchangeable : la qualification PASSI de l’ANSSI suppose un prestataire soumis au droit d’un État membre de l’UE. Pour tester au Japon, vous combinerez souvent le programme de votre groupe avec l’intervention d’un prestataire local, et les rapports devront être utilisables par les deux superviseurs.

Ce qu’attend la FSA : la ligne directrice de 2024

Deux niveaux d’exigence et une approche fondée sur les risques

La ligne directrice sur la cybersécurité du secteur financier (Guidelines on Cybersecurity for the Financial Sector) a été publiée par la FSA le 4 octobre 2024. Elle précise ce que les lignes directrices de supervision ne faisaient qu’esquisser, et ces dernières y renvoient désormais dans leur section sur le risque informatique. Une modification technique a suivi en juillet 2025, liée à la réorganisation de l’agence gouvernementale japonaise de cybersécurité ; elle ne change pas le fond.

Chaque thème distingue deux niveaux :

les mesures fondamentales (« fundamental response measures »), c’est-à-dire l’hygiène informatique que tout établissement doit appliquer ;
les mesures recommandées (« recommended measures »), qui sont les bonnes pratiques attendues des grands établissements et des principales infrastructures de marché.

La FSA précise qu’aucun des deux niveaux n’est appliqué de manière uniforme : chaque établissement doit évaluer ses risques et adopter des mesures proportionnées. Ses inspections et sa surveillance suivent la même logique.

Les mesures fondamentales sur les tests (section 2.2.4)

Tout établissement doit réaliser régulièrement des audits de vulnérabilités et des tests d’intrusion, en tenant compte du niveau de risque et de l’importance des systèmes. Il doit aussi formaliser une procédure, qui précise notamment :

le périmètre, en incluant les équipements directement connectés à l’extérieur, comme les VPN ;
la fréquence, le calendrier (y compris avant la mise en production) et le déroulement des tests ;
pour les sites web publics (site institutionnel, banque en ligne, API publiques), un audit de la plateforme (mots de passe faibles, configuration du système et du middleware) et un audit de l’application web (injection SQL, CSRF…) ;
un audit des applications mobiles ;
lorsque l’architecture est à risque, par exemple si le réseau métier n’est pas séparé du réseau connecté à Internet, un audit des équipements internes clés comme les serveurs Active Directory et les serveurs de fichiers ;
la priorisation des problèmes, avec une méthode et un délai de traitement pour chacun, et le suivi de leur correction ;
la remontée rapide des résultats importants à la direction.

Les mesures recommandées

Pour les grands établissements, la FSA attend en plus :

l’extension des audits et tests aux réseaux VPN non connectés à Internet et aux environnements internes ;
des tests TLPT réguliers ;
des tests d’intrusion menés par des équipes internes qui connaissent bien le système d’information, y compris une red team ;
une revue périodique des méthodes et des résultats, et l’éventualité d’un changement de prestataire pour obtenir un regard neuf et indépendant.

La ligne directrice recommande aussi, dans sa partie sur la sécurité dès la conception, de tester les applications avant leur mise en production puis régulièrement après. Dans sa partie sur les prestataires, elle cite la réalisation et la communication des audits de vulnérabilités parmi les points à prévoir dans les contrats.

Votre entité japonaise est-elle concernée ?

La ligne directrice vise les établissements soumis aux lignes directrices de supervision de la FSA : banques, assureurs, entreprises d’investissement, prestataires de paiement, plateformes de crypto-actifs, bourses, etc. Une filiale japonaise agréée entre donc directement dans son champ. Les succursales de banques étrangères relèvent des lignes directrices de supervision des grandes banques, qui leur consacrent une section et prévoient d’appliquer le reste du texte selon l’activité de la succursale. En pratique, partez du principe que la FSA attendra le même socle.

Les normes FISC : la référence technique du secteur

Le Center for Financial Industry Information Systems (FISC), fondation créée en 1984 avec l’agrément du ministre des Finances de l’époque, publie les « FISC Security Guidelines on Computer Systems for Financial Institutions ». Il les élabore avec ses membres, la FSA et la Banque du Japon. Ce ne sont pas des obligations légales, mais la plupart des établissements financiers japonais les appliquent volontairement, et les lignes directrices de supervision de la FSA les citent comme document de référence sur le risque informatique.

Ces normes sont révisées presque chaque année. La 14e édition, publiée en mars 2026, ajoute notamment des mesures sur l’IA et l’IA générative, sur la cybersécurité et sur la migration vers la cryptographie post-quantique. La dernière traduction anglaise disponible est celle de la 13e édition (novembre 2025).

Trois points pratiques pour une entreprise française :

le texte est payant et n’est pas public : demandez à votre entité japonaise l’édition qu’elle applique et la correspondance entre ses contrôles et les normes FISC ;
le FISC ne se prononce pas sur la conformité d’un établissement : il n’existe ni certification ni label FISC, et un prestataire « conforme FISC » ne veut rien dire ;
la version anglaise a souvent une édition de retard sur la version japonaise : vérifiez quelle édition votre siège utilise pour ses analyses des écarts.

DORA et Japon : ce qui diffère

Les articles 24 et 25 de DORA (règlement (UE) 2022/2554) imposent à chaque entité financière, hors microentreprises, un programme de tests intégré à son cadre de gestion du risque lié aux TIC. Le tableau ci-dessous compare ce programme aux attentes de la FSA.

Point	Union européenne (DORA)	Japon (FSA)
Nature du texte	Règlement directement applicable depuis le 17 janvier 2025, complété par des normes techniques de réglementation	Ligne directrice de supervision (octobre 2024), utilisée par la FSA lors des inspections et de la surveillance
Fréquence	Au moins une fois par an pour tous les systèmes et applications qui soutiennent des fonctions critiques ou importantes	« Régulièrement » : la fréquence est fixée par la procédure de l’établissement, selon les risques
Types de tests	Liste ouverte : analyses de vulnérabilités, revues de code source, tests fondés sur des scénarios, tests de bout en bout, tests d’intrusion, etc.	Périmètre minimal nommé : équipements exposés (VPN), plateforme et application des sites et API publics, applications mobiles, Active Directory si le réseau n’est pas cloisonné
Scans automatisés	Au moins hebdomadaires pour les actifs qui soutiennent des fonctions critiques ou importantes (règlement délégué (UE) 2024/1774, article 10, hors régime simplifié)	Pas de fréquence chiffrée dans la ligne directrice
Indépendance des testeurs	Tests réalisés par des parties indépendantes, internes ou externes, sans conflit d’intérêts	Pas d’exigence explicite parmi les mesures fondamentales ; recommandation d’envisager un changement de prestataire
Suite des tests	Procédures pour hiérarchiser et corriger les problèmes, et méthodes de validation interne de leur correction	Priorisation, délais de traitement, suivi, et remontée rapide des résultats importants à la direction
Tests avancés	TLPT au moins tous les trois ans pour les entités désignées (article 26)	TLPT parmi les mesures recommandées aux grands établissements

Deux conséquences pratiques.

D’abord, le Japon nomme des cibles précises. DORA vous laisse choisir les types de tests selon les risques. La FSA, elle, cite des éléments que l’inspecteur cherchera : les équipements VPN, les deux niveaux d’audit des sites publics, les applications mobiles. Un programme de groupe qui ne couvre pas explicitement ces éléments pour l’entité japonaise laissera un écart visible.

Ensuite, votre périmètre DORA peut inclure des systèmes situés au Japon. DORA s’applique à vos entités européennes, pas à la filiale japonaise. Mais si des systèmes exploités au Japon soutiennent des fonctions critiques ou importantes du groupe (applications partagées, centre informatique, services de l’entité japonaise utilisés par le siège), ils relèvent du programme annuel de l’entité européenne. Et si l’entité japonaise fournit elle-même des services TIC aux entités européennes, elle entre dans la définition du prestataire tiers de services TIC (« une entreprise qui fournit des services TIC »), même au sein du groupe.

PASSI, prestataires japonais : qui peut tester ?

En France : la qualification PASSI

L’ANSSI qualifie les prestataires d’audit de la sécurité des systèmes d’information (PASSI) selon un référentiel dont la version 2.2 date du 1er août 2024. La qualification couvre l’audit d’architecture, de configuration, de code source, les tests d’intrusion et l’audit organisationnel et physique, à deux niveaux : substantiel et élevé.

DORA n’impose pas le recours à un PASSI. La qualification devient obligatoire dans certains cadres, notamment pour les audits d’homologation des systèmes d’information d’importance vitale des opérateurs d’importance vitale (OIV), lorsqu’ils ne sont pas réalisés par une équipe interne. Hors de ces cadres, l’ANSSI indique que le référentiel peut servir de bonnes pratiques, et la qualification reste un critère de choix.

Deux exigences du référentiel comptent pour un test au Japon : le prestataire doit être soumis au droit d’un État membre de l’UE, et la convention de service doit être régie par ce même droit. Un prestataire japonais ne peut donc pas être qualifié PASSI. Votre PASSI habituel peut intervenir à distance ou sur place au Japon, mais il devra composer avec les contraintes locales : langue, horaires, interlocuteurs, prestataires japonais de l’entité.

Au Japon : pas de qualification obligatoire, une liste publique

Le Japon n’impose pas de qualification aux prestataires de tests. Le ministère de l’Économie, du Commerce et de l’Industrie (METI) a toutefois créé un dispositif d’enregistrement des services de sécurité conformes à une norme de qualité, dont l’IPA, agence publique placée sous la tutelle du METI, publie la liste. En avril 2024, le METI y a ajouté une catégorie « tests d’intrusion », comme option de la catégorie « audits de vulnérabilités ». Son usage est recommandé pour les achats de l’État et des collectivités ; pour une entreprise privée, c’est un premier filtre utile.

Côté personnes, la qualification nationale japonaise est celle de Registered Information Security Specialist (RISS), un titre enregistré auprès de l’IPA qui impose une formation continue. Les certifications internationales (OSCP, CREST, GPEN…) restent des repères utiles, au Japon comme en France. Aucune ne remplace l’examen d’un rapport-type et un échange technique avec les testeurs qui interviendront réellement.

Pour le TLPT, la FSA demande de vérifier l’expérience et les compétences du prestataire, y compris les qualifications et le parcours des testeurs. Appliquez la même rigueur à vos tests classiques.

Organiser les tests de votre entité japonaise

1. Cartographier ce qui relève de qui

Classez les systèmes de l’entité japonaise en trois groupes : ceux qui soutiennent des fonctions critiques ou importantes du groupe (programme DORA), ceux qui ne relèvent que de l’activité locale (attentes de la FSA), et ceux qui relèvent des deux. Ajoutez les systèmes opérés par des prestataires japonais. Cette cartographie évite de tester deux fois le même système, ou de n’en tester aucun.

2. Construire un plan unique, avec une table de correspondance

Un même test peut servir les deux cadres si son périmètre et sa date le permettent. Tenez une table qui relie chaque test aux exigences correspondantes : articles 24 et 25 de DORA d’un côté, section 2.2.4 de la ligne directrice de la FSA de l’autre, et normes FISC si l’entité les applique. Vérifiez en particulier que les éléments nommés par la FSA (VPN, audit plateforme et application des sites publics, applications mobiles) figurent explicitement dans le plan.

3. Préparer l’exécution en production

Les établissements japonais encadrent strictement les tests sur les systèmes en production. Prévoyez :

des créneaux hors activité définis à l’heure japonaise, souvent la nuit ou le week-end, en tenant compte du décalage de sept ou huit heures avec la France ;
l’exclusion ou la limitation des techniques qui peuvent perturber le service (déni de service, tests de charge) ;
une validation avant chaque action risquée et une procédure d’arrêt immédiat, avec des contacts joignables des deux côtés ;
les autorisations de vos fournisseurs cloud et de vos prestataires, dont les systèmes entrent dans le périmètre ;
des délais pour les validations internes, souvent nombreuses au Japon (informatique, sécurité, conformité, juridique, risques, direction).

4. Fixer la langue et la forme des rapports dès le contrat

La ligne directrice de la FSA est rédigée en japonais ; sa traduction anglaise est présentée comme provisoire, et seul le texte japonais fait foi. Les équipes locales et les échanges avec la FSA fonctionnent le plus souvent en japonais, alors que votre siège a besoin d’un rapport exploitable en anglais ou en français.

Exigez un rapport bilingue ou une synthèse dans la langue du siège avec des constats détaillés en japonais, et précisez quelle version fait foi.
Prévoyez une synthèse pour la direction, compréhensible par des non-spécialistes. Le référentiel PASSI l’impose déjà, et la FSA attend que les résultats importants remontent rapidement à la direction.
Utilisez une échelle de gravité commune au groupe, pour que les constats japonais entrent dans le suivi des vulnérabilités du groupe.
Ajoutez au rapport la correspondance avec les exigences de la FSA, de DORA et, le cas échéant, des normes FISC.

5. Encadrer la confidentialité

Les résultats d’un test d’intrusion bancaire sont des informations très sensibles. Prévoyez dans le contrat la liste des personnes qui y auront accès, le chiffrement des données, le lieu de stockage, la durée de conservation et la destruction ou la restitution en fin de mission, avec une attestation. Le référentiel PASSI fournit une bonne base pour ces clauses, que vous pouvez reprendre avec un prestataire japonais.

6. Revoir les contrats avec les prestataires japonais

Si l’entité japonaise externalise une partie de son informatique, vérifiez que les contrats prévoient la réalisation et la communication des audits de vulnérabilités, comme le recommande la FSA, ainsi qu’un droit d’audit et la participation aux tests du groupe.

Questions fréquentes

Q1. La FSA rend-elle les tests d’intrusion obligatoires ?

Il n’y a pas d’obligation légale chiffrée. Mais la ligne directrice range les audits de vulnérabilités et les tests d’intrusion réguliers parmi les mesures fondamentales attendues de tous les établissements, et la FSA examine les dispositifs de cybersécurité lors de ses inspections. En pratique, une entité supervisée qui ne teste pas ses systèmes aura du mal à le justifier.

Q2. Nos tests DORA réalisés en Europe couvrent-ils notre entité japonaise ?

Seulement pour les systèmes qui étaient dans leur périmètre. Les systèmes propres à l’activité japonaise, les applications mobiles locales ou les équipements VPN du site japonais n’y figurent souvent pas. Comparez le périmètre de vos tests à la liste de la section 2.2.4 de la ligne directrice de la FSA.

Q3. Pouvons-nous faire réaliser les tests au Japon par notre PASSI habituel ?

Oui, rien ne l’interdit, et cela facilite la cohérence avec le programme du groupe. Prévoyez toutefois un appui local pour la langue, la coordination avec les équipes et les prestataires japonais et les créneaux horaires. Un prestataire japonais, de son côté, ne peut pas être qualifié PASSI.

Q4. Les rapports doivent-ils être rédigés en japonais ?

La ligne directrice n’impose pas de langue pour les rapports de tests. Mais les équipes locales et la FSA travaillent en japonais, et votre siège dans sa propre langue. Un rapport bilingue, ou une synthèse dans la langue du siège avec des constats détaillés en japonais, évite les traductions de dernière minute.

Q5. Et le TLPT ?

Le TLPT est un exercice distinct : scénarios fondés sur le renseignement sur la menace, tests en production sans prévenir les équipes de défense, évaluation de leur capacité de réaction. Au Japon, il fait partie des mesures recommandées aux grands établissements ; dans l’UE, il est imposé aux entités désignées au moins tous les trois ans. Nous le détaillons dans notre article sur le TLPT au Japon.

Parler à AEVUS

AEVUS est une entreprise de cybersécurité basée au Japon. Nous réalisons des audits de vulnérabilités et des tests d’intrusion sur les applications web, les API, les applications mobiles et les réseaux internes, en tenant compte des contraintes propres aux établissements financiers : tests en production, confidentialité, rapports exploitables pour la supervision. Si vous devez organiser les tests de votre entité japonaise ou rapprocher votre programme DORA des attentes de la FSA, contactez-nous.

En résumé

Au Japon, la ligne directrice de la FSA (octobre 2024) range les audits de vulnérabilités et les tests d’intrusion réguliers parmi les mesures fondamentales de tous les établissements supervisés.
Elle nomme un périmètre minimal : équipements VPN, plateforme et application des sites et API publics, applications mobiles, Active Directory si le réseau n’est pas cloisonné.
Les normes FISC, dont la 14e édition date de mars 2026, servent de référence technique, sans certification.
DORA est plus précis sur le rythme (test annuel des systèmes critiques, scans hebdomadaires) et sur l’indépendance des testeurs.
Un prestataire japonais ne peut pas être qualifié PASSI : prévoyez un plan unique, une table de correspondance entre les cadres et des rapports bilingues.

Sources

Articles connexes

← Retour au blog