B-13 de l'OSFI : testez votre application bancaire mobile avant et après chaque version.
La ligne directrice B-13 demande aux institutions financières fédérales d'adopter des pratiques de sécurité dès la conception pour les applications et les API qu'elles développent, de scanner et de tester les systèmes avant leur mise en production, de classer et de corriger les vulnérabilités selon des délais fondés sur le risque, et de mettre en œuvre l'authentification multifacteur. La ligne directrice B-10 étend ces attentes aux SDK, aux services cloud et aux fournisseurs derrière votre application. Ostorlab teste votre application et les API qui la sous-tendent, derrière la connexion, à chaque version.
- Évalue l'application mobile et les API qu'elle appelle, sur le build que téléchargent vos clients
- Teste la connexion, les codes à usage unique, les vérifications d'authentification renforcée et la gestion des sessions avec vos comptes de test
- Recense les SDK et bibliothèques natives de chaque version et les rapproche des vulnérabilités connues
- Prouve chaque résultat par un exploit rejouable ou par les requêtes et réponses à l'appui
- Qui est concerné
- Les institutions financières fédérales (FRFI) : banques, sociétés de fiducie et de prêt, assureurs et succursales de banques étrangères au Canada
- Dates clés
- B-13 applicable depuis le 1er janvier 2024 ; B-10 depuis le 1er mai 2024 ; conformité complète à E-21 attendue pour le 1er septembre 2026
- Objet
- Développement sécurisé et tests avant la mise en production, correction des vulnérabilités, MFA, risque lié aux SDK et aux tiers, et signalement des incidents sous 24 heures
- Texte de référence
- Ligne directrice B-13 de l'OSFI, Technology and Cyber Risk Management
Les textes canadiens qui encadrent votre canal mobile
La réglementation fédérale des institutions financières et le droit fédéral et québécois de la protection des renseignements personnels s'appliquent à la même application. Les dates ci-dessous concernent les textes cités sur cette page.
- 1er novembre 2018
Signalement des atteintes selon la LPRPDE
Le signalement obligatoire des atteintes entre en vigueur au titre de la LPRPDE : signaler au Commissariat à la protection de la vie privée et aviser les personnes concernées lorsqu'une atteinte aux mesures de sécurité crée un risque réel de préjudice grave, et tenir un registre de toutes les atteintes.
- 13 août 2021
Avis sur le signalement des incidents
L'avis actualisé de l'OSFI sur le signalement des incidents de technologie et de cybersécurité entre en vigueur : signaler un incident à la Division du risque technologique de l'OSFI et à votre superviseur principal dans les 24 heures, ou plus tôt si possible.
- Juillet 2022
Ligne directrice B-13
L'OSFI publie la version finale de la ligne directrice sur la gestion des risques technologiques et cyber. Elle s'applique depuis le 1er janvier 2024 et couvre la gouvernance et la gestion des risques, les opérations technologiques et la résilience, et la cybersécurité.
- 21 avril 2023
Cadre I-CRT
L'OSFI publie le cadre Intelligence-led Cyber Resilience Testing. L'OSFI recommande aux banques d'importance systémique et aux groupes d'assurance actifs à l'international de réaliser une évaluation I-CRT au moins une fois par cycle de supervision de trois ans, à compter de 2023.
- 1er mai 2024
Entrée en vigueur de B-10
La ligne directrice sur la gestion du risque lié aux tiers, datée du 30 avril 2023, entre en vigueur. Elle couvre la diligence raisonnable, la contractualisation, la sécurité des données, les droits d'audit et le risque technologique et cyber dans les arrangements avec des tiers.
- 22 août 2024
Ligne directrice E-21
L'OSFI publie la version finale de la ligne directrice sur la gestion du risque opérationnel et la résilience. Les sections 1 et 2 s'appliquent immédiatement ; la section 4 est attendue pour le 1er septembre 2025 et la conformité complète pour le 1er septembre 2026.
- 22 septembre 2024
Loi 25 du Québec, dernière phase
Le droit à la portabilité des données entre en vigueur. Le régime des incidents de confidentialité, dont l'avis à la Commission et aux personnes concernées et le registre des incidents, ainsi que la désignation d'un responsable de la protection des renseignements personnels, s'appliquent depuis le 22 septembre 2022 ; la plupart des autres obligations, dont les évaluations des facteurs relatifs à la vie privée et les règles de consentement, depuis le 22 septembre 2023 (texte français).
- Avril 2026
Bulletin sur l'IA de pointe
Le Technology Risk Bulletin de l'OSFI sur l'intelligence artificielle de pointe indique que le délai pour identifier et exploiter les vulnérabilités s'est compressé et renvoie les institutions à B-13, B-10 et E-21 pour l'application des correctifs, la réponse aux incidents et la surveillance des tiers.
Les attentes de l'OSFI, appliquées à votre application mobile
Pour chaque règle : ce que dit le texte, ce que cela implique pour une application bancaire mobile, comment Ostorlab vous aide et ce qui reste du ressort de votre équipe.
- Ligne directrice B-13 de l'OSFI, 3.2.1 et 2.4.2
Intégrer la sécurité dans l'application et ses API
Ce que dit le texte
Adoptez des pratiques de sécurité dès la conception pour protéger les actifs technologiques. Les contrôles de défense devraient être préventifs lorsque c'est possible, et des contrôles de sécurité standard devraient être appliqués de bout en bout, dès la phase de conception, aux applications, micro-services et interfaces de programmation d'applications développés par l'institution. Les exigences de sécurité devraient être intégrées à chaque phase du cycle de vie du développement des systèmes, y compris dans les méthodes de développement Agile.
Ce que cela implique pour votre application mobile
L'application mobile est à la fois une application que vous développez et un canal exposé à l'extérieur. La conception sécurisée, la revue et les tests doivent faire partie de la fabrication de chaque version, et non d'une étape ajoutée à la fin.
Comment Ostorlab vous aide
Mobile SAST analyse directement l'APK, l'AAB ou l'IPA, sans code source, avec une analyse de propagation (taint) sur les SDK intégrés, et s'exécute depuis votre pipeline CI/CD à chaque build.
Ce qui reste de votre ressort
Les normes de développement sécurisé, les points de contrôle du SDLC, les revues de conception et l'approbation des mises en production.
- Ligne directrice B-13 de l'OSFI, 3.2.9
Scanner et tester les applications avant la mise en production
Ce que dit le texte
Lorsque c'est possible, utilisez des capacités d'analyse et de test statiques et/ou dynamiques pour vérifier que les nouveaux systèmes et applications, ainsi que les modifications des systèmes existants, font l'objet d'une évaluation des vulnérabilités avant leur mise en production. Lorsque les pratiques de développement et d'exploitation sont combinées dans un pipeline continu et automatisé, mettez en place des contrôles de sécurité qui maintiennent le niveau de sécurité.
Ce que cela implique pour votre application mobile
Chaque version publiée sur les stores est une modification d'un système de production. L'évaluation doit avoir lieu avant que le build n'atteigne les clients, idéalement à chaque build du pipeline.
Comment Ostorlab vous aide
Mobile SAST et Mobile DAST lancent des scans automatisés depuis votre pipeline CI/CD à chaque build, et Ostorlab surveille les versions publiées sur les stores sans déclenchement manuel. Les deux fonctionnent sur le binaire, sans code source.
Ce qui reste de votre ressort
Le choix des points de contrôle du pipeline, la définition de ce qui bloque une publication et l'approbation de ce qui est livré.
- Ligne directrice B-13 de l'OSFI, 3.1.3
Évaluer et classer les vulnérabilités régulièrement
Ce que dit le texte
Établissez des processus pour réaliser régulièrement des évaluations de vulnérabilité des actifs technologiques, y compris, sans s'y limiter, les équipements réseau, les systèmes et les applications. Les processus devraient préciser la fréquence des scans et des évaluations, et classer les vulnérabilités et les menaces selon la gravité de la menace et l'exposition au risque de l'actif, à l'aide d'une méthodologie standard, en tenant compte de l'impact cumulé des vulnérabilités qui, combinées, pourraient présenter un risque élevé.
Ce que cela implique pour votre application mobile
L'application mobile et les API qu'elle appelle font partie de cette évaluation, avec une fréquence nommée, une note de gravité par résultat et une vue de la façon dont les résultats se combinent.
Comment Ostorlab vous aide
Un pentest par agents IA teste l'application et ses API derrière la connexion, sur la version que vous livrez, avec un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA et une heatmap de couverture pour la version.
Ce qui reste de votre ressort
La méthodologie d'évaluation, la notation du risque que vous utilisez et le traitement des résultats hors application.
- Ligne directrice B-13 de l'OSFI, 3.1.2 ; cadre I-CRT de l'OSFI, avril 2023
Réaliser des tests d'intrusion et préparer l'I-CRT
Ce que dit le texte
Fixez des déclencheurs définis et des fréquences minimales pour les évaluations de menaces fondées sur le renseignement, et réalisez régulièrement des tests et des exercices pour identifier les vulnérabilités ou les lacunes de contrôle du programme de cybersécurité, comme les tests d'intrusion et le red teaming, selon une approche fondée sur le renseignement, avec un périmètre et des impacts potentiels clairement définis et des mesures d'atténuation appliquées. Par ailleurs, le cadre I-CRT de l'OSFI est une évaluation menée par le régulateur pour les banques d'importance systémique et les groupes d'assurance actifs à l'international, qui imite un acteur de menace sophistiqué à partir de renseignements ciblés, recommandée au moins une fois par cycle de supervision de trois ans.
Source :Ligne directrice B-13 de l'OSFI, 3.1.2 ; cadre I-CRT de l'OSFI, avril 2023
Ce que cela implique pour votre application mobile
Les tests d'intrusion et le red teaming sont des attentes de B-13, avec des déclencheurs que vous définissez. L'I-CRT est un exercice différent, plus large, mené par l'OSFI et destiné aux grandes institutions.
Comment Ostorlab vous aide
Ostorlab ne réalise ni le red teaming ni l'I-CRT. Il vous aide à aborder l'un ou l'autre avec les problèmes connus de l'application et des API déjà corrigés, puis à retester les éléments applicatifs et API d'un plan de remédiation.
Ce qui reste de votre ressort
Le cadrage et la conduite des tests d'intrusion et du red teaming, l'évaluation I-CRT avec l'OSFI et le choix des prestataires.
- Ligne directrice B-13 de l'OSFI, 3.2.6 et 2.6 ; Technology Risk Bulletin de l'OSFI sur l'IA de pointe, avril 2026
Corriger selon des délais fondés sur le risque
Ce que dit le texte
Maintenez des capacités de correction rapide et fondée sur le risque des vulnérabilités des logiciels fournisseurs et des applications internes, en tenant compte de la gravité de la menace et de l'exposition du système. Appliquez les correctifs au plus tôt, en proportion du risque et conformément aux délais établis, mettez en place des contrôles compensatoires lorsqu'aucune correction n'est disponible, par exemple pour les attaques zero-day, et suivez et rapportez régulièrement l'état des correctifs et des remédiations par rapport aux délais définis, y compris tout arriéré et toute exception. En avril 2026, le Technology Risk Bulletin de l'OSFI sur l'intelligence artificielle de pointe a indiqué que le délai pour identifier et exploiter les vulnérabilités s'est compressé et a renvoyé les institutions à B-13, B-10 et E-21.
Ce que cela implique pour votre application mobile
Un délai de correction doit être défendable : gravité, exposition, preuve de clôture et exception documentée lorsque vous acceptez le risque.
Comment Ostorlab vous aide
Les résultats sont classés critiques, élevés, moyens ou faibles, suivis sous forme de tickets dans la plateforme ou dans Jira et ServiceNow, et retestés une fois le correctif publié : l'arriéré et le registre de clôture viennent de la plateforme.
Ce qui reste de votre ressort
Le calendrier de correctifs, les contrôles compensatoires, les décisions d'acceptation des risques et le reporting à la direction générale.
- Ligne directrice B-13 de l'OSFI, 3.2.7
Imposer la MFA sur les canaux exposés à l'extérieur
Ce que dit le texte
Mettez en œuvre des contrôles d'identité et d'accès fondés sur le risque, notamment l'authentification multifacteur et la gestion des accès privilégiés. Lorsque c'est possible, déployez la MFA sur les canaux exposés à l'extérieur et les comptes privilégiés, y compris les clients, les employés et les tiers, appliquez le principe du moindre privilège, procédez à des attestations régulières des accès, gérez les identifiants des comptes privilégiés dans un coffre sécurisé, et journalisez et surveillez l'activité des comptes dans le cadre d'une surveillance de sécurité continue.
Ce que cela implique pour votre application mobile
L'application mobile est un canal exposé à l'extérieur. La MFA et les contrôles d'accès doivent être imposés par le backend, y compris lorsque l'application ou un attaquant saute une étape.
Comment Ostorlab vous aide
Les tests authentifiés couvrent la connexion et la déconnexion, le renouvellement des jetons, les délais d'expiration, l'invalidation des sessions et l'application effective de la MFA, y compris les parcours d'authentification renforcée, ainsi que les appels d'API qui les sous-tendent.
Ce qui reste de votre ressort
Le choix et le déploiement des méthodes de MFA, la gestion des accès privilégiés et la surveillance continue de l'activité des comptes.
- Ligne directrice B-13 de l'OSFI, 3.1.4 et 3.2.5
Protéger les données tout au long de leur cycle de vie
Ce que dit le texte
En partant d'une classification claire de l'information, concevez et mettez en œuvre des contrôles fondés sur le risque pour protéger les données tout au long de leur cycle de vie, y compris des capacités de prévention des fuites de données et des contrôles pour les données au repos, en transit et en cours d'utilisation. Identifiez, classez et protégez les données structurées et non structurées selon leur classification de confidentialité, et réalisez des scans de découverte périodiques pour identifier les écarts par rapport aux contrôles qui protègent les données contre les accès non autorisés.
Ce que cela implique pour votre application mobile
Les mots de passe, jetons et données personnelles ne devraient pas rester en clair sur le téléphone ni transiter sans protection vers le backend, quelle que soit la classification des données.
Comment Ostorlab vous aide
Ostorlab recherche les jetons de session et les données personnelles dans le stockage local, les caches, les journaux et les captures d'écran, vérifie la protection du transport et détecte les identifiants laissés dans le package de l'application.
Ce qui reste de votre ressort
La classification des données, la gestion des clés, les outils de prévention des fuites de données et la conservation.
- Ligne directrice B-10 de l'OSFI, 2.2.2, 2.3.2, 2.3.3 et 4.2
Gérer les SDK et les fournisseurs derrière l'application
Ce que dit le texte
Menez une diligence raisonnable proportionnée au risque et à la criticité de chaque arrangement avec un tiers, avant de le conclure et de façon continue, portant sur la capacité du tiers à gérer les risques technologiques et cyber conformément à B-13 et à vous fournir suffisamment d'informations pour respecter vos exigences de signalement des incidents. Définissez les responsabilités de chaque partie quant à la confidentialité, à la disponibilité et à l'intégrité des enregistrements et des données, conservez le droit de réaliser ou de mandater un audit indépendant et, lorsque le risque ou la criticité l'exige, assurez-vous que le tiers respecte vos normes ou des normes sectorielles reconnues, notamment en matière de gestion des accès et de sécurité et de protection des données. Utilisez un éventail de méthodes d'audit et de collecte d'informations.
Source :Ligne directrice B-10 de l'OSFI, 2.2.2, 2.3.2, 2.3.3 et 4.2
Ce que cela implique pour votre application mobile
Une version mobile peut embarquer des dizaines de SDK tiers, chacun communiquant avec son propre backend. Ce sont des arrangements avec des tiers à l'intérieur de votre application, et ils relèvent de la même diligence raisonnable et de la même vision d'audit.
Comment Ostorlab vous aide
Ostorlab recense les SDK et bibliothèques natives de chaque version avec leurs versions et leur emplacement dans le bundle de l'application, les rapproche des vulnérabilités connues et montre avec quels backends l'application et ses SDK communiquent.
Ce qui reste de votre ressort
Les contrats, les dossiers de diligence raisonnable, les droits d'audit et la décision de conserver ou de remplacer un fournisseur.
- Avis de l'OSFI sur le signalement des incidents de technologie et de cybersécurité, 13 août 2021
Signaler les incidents à l'OSFI dans les 24 heures
Ce que dit le texte
Signalez un incident de technologie ou de cybersécurité à la Division du risque technologique de l'OSFI et à votre superviseur principal dans les 24 heures, ou plus tôt si possible, à l'aide du formulaire de signalement des incidents, et tenez l'OSFI informé jusqu'à ce que l'incident soit contenu ou résolu, y compris les mesures et plans de remédiation à court et à long terme. Après le confinement de l'incident, la reprise et la clôture, rendez compte de la revue post-incident et des enseignements tirés. Un incident de technologie ou de cybersécurité est un incident qui a, ou pourrait avoir, un impact sur les opérations de l'institution, y compris la confidentialité, l'intégrité ou la disponibilité de ses systèmes et de ses informations.
Source :Avis de l'OSFI sur le signalement des incidents de technologie et de cybersécurité, 13 août 2021
Ce que cela implique pour votre application mobile
La vitesse de détection et de constitution des preuves compte : pour signaler en 24 heures, il faut savoir ce qui s'est passé, quels systèmes et données sont touchés et ce que l'application et ses API ont exposé.
Comment Ostorlab vous aide
Ostorlab fournit un exploit fonctionnel et les requêtes et réponses à l'appui pour chaque résultat, et reteste après correction : vous pouvez délimiter les parcours concernés, produire la revue post-incident et démontrer la clôture.
Ce qui reste de votre ressort
Le signalement lui-même, la réponse aux incidents, la communication et la revue post-incident avec l'OSFI.
- LPRPDE, annexe 1, clause 4.7 et articles 10.1 à 10.3 ; Loi 25, Québec (texte français)
Respecter les obligations de confidentialité liées aux données de l'application
Ce que dit le texte
La LPRPDE exige que les renseignements personnels soient protégés par des mesures de sécurité proportionnées à leur sensibilité, contre la perte ou le vol ainsi que contre l'accès, la communication, la copie, l'utilisation ou la modification non autorisés, au moyen de mesures physiques, organisationnelles et technologiques, et impose aux organisations de signaler au Commissariat à la protection de la vie privée et d'aviser les personnes concernées lorsqu'une atteinte aux mesures de sécurité crée un risque réel de préjudice grave, et de tenir un registre de toutes les atteintes. Au Québec, la Loi 25 impose aux entreprises de prendre des mesures de sécurité pour protéger les renseignements personnels, d'aviser la Commission d'accès à l'information et les personnes concernées d'un incident de confidentialité présentant un risque de préjudice sérieux, de tenir un registre des incidents, de publier les coordonnées d'un responsable de la protection des renseignements personnels, de réaliser des évaluations des facteurs relatifs à la vie privée pour les projets de systèmes d'information et, depuis le 22 septembre 2024, d'offrir la portabilité des données sur demande (texte français).
Source :LPRPDE, annexe 1, clause 4.7 et articles 10.1 à 10.3 ; Loi 25, Québec (texte français)
Ce que cela implique pour votre application mobile
Des résultats comme des données personnelles laissées dans les journaux ou les caches, ou un transport faible, sont des incidents de confidentialité en puissance. Les deux régimes vous demandent de protéger les données et de pouvoir en rendre compte.
Comment Ostorlab vous aide
Ostorlab teste les contrôles techniques de l'application et de ses API : ce qui est écrit sur l'appareil, ce qui circule sans protection et qui peut accéder à quoi par les API.
Ce qui reste de votre ressort
Les politiques de confidentialité, le consentement, les évaluations des facteurs relatifs à la vie privée, l'avis d'incident et le registre des incidents.
Synthèse des textes publics de l'OSFI, de la LPRPDE et des documents québécois sur la Loi 25, vérifiée le 27 septembre 2026. Les lignes directrices de l'OSFI énoncent des attentes de supervision. La partie québécoise est résumée d'après les pages en français de la Commission d'accès à l'information. Cette page ne constitue pas un avis juridique.
Les attentes de l'OSFI, contrôle par contrôle
Les contrôles visés par les textes canadiens, la manière dont Ostorlab les teste dans votre application et ses API, et les preuves que vous pouvez conserver.
| Contrôle | Comment Ostorlab vous aide | Preuves conservées |
|---|---|---|
| Contrôles de sécurité dès la conception pour les applications et les APIB-13 3.2.1 | Intercepte le trafic de l'application même avec TLS pinning et teste les autorisations, le traitement des entrées et la logique métier des API derrière la connexion. Détails | Requêtes et réponses à l'appui de chaque résultat d'API |
| Tests statiques et dynamiques avant la mise en productionB-13 3.2.9 | Mobile SAST sur le binaire et Mobile DAST sur l'application en cours d'exécution, depuis la CI/CD à chaque build. Détails | Résultats avec contexte de code décompilé, trafic, traces d'exécution et captures d'écran |
| Évaluation de vulnérabilité de l'application et de ses APIB-13 3.1.3 | Pentest par agents IA de l'application et de ses API, derrière la connexion, sur la version que vous livrez. Détails | Un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA, et une heatmap de couverture |
| Tests d'intrusion, red teaming et préparation à l'I-CRTB-13 3.1.2 ; I-CRT | Teste l'application et ses API derrière la connexion, vous aide à corriger les problèmes connus avant un I-CRT, et reteste les éléments applicatifs et API d'un plan de remédiation. | Résultats avec étapes de reproduction, et résultats de retest après correction |
| Logiciels fournisseurs, composants et délais de correctionB-13 3.2.6, 2.6 | SCA identifie par empreinte les bibliothèques compilées statiquement et les associe aux vulnérabilités connues, d'une version à l'autre. Détails | Vulnérabilités identifiées avec recommandations de mise à niveau ou de remplacement, et résolution suivie d'une version à l'autre |
| MFA sur les canaux exposés à l'extérieurB-13 3.2.7 | Se connecte avec des codes à usage unique et teste l'application effective de la MFA, les parcours d'authentification renforcée et les appels d'API qui les sous-tendent. Détails | Résultats sur les parcours de connexion et d'authentification renforcée, avec étapes de reproduction |
| Sessions, jetons et accès privilégiésB-13 3.2.7 | Teste la connexion et la déconnexion, le renouvellement des jetons, les délais d'expiration et l'invalidation des sessions. Détails | Résultats sur les sessions et les jetons, avec journaux des requêtes et réponses |
| Protection des données sur l'appareil et en transitB-13 3.1.4, 3.2.5 | Recherche les jetons et les données personnelles dans le stockage, les caches, les journaux et les captures d'écran, et vérifie la protection du transport. Détails | Preuves sur le système de fichiers montrant ce qui a été écrit, où et quand |
| SDK tiers et composants fournisseursB-10 2.2.2, 4.2 | Recense les SDK et bibliothèques natives de chaque version avec leurs versions, et montre avec quels backends l'application et ses SDK communiquent. Détails | Identité, version et emplacement de chaque composant dans le bundle de l'application, par version |
| Identifiants intégrés au package de l'applicationB-13 3.2.5 | Détecte les clés d'API, jetons et identifiants dans le package de l'application et vérifie s'ils sont fonctionnels. Détails | Secrets validés, avec les permissions et les services qu'ils exposent |
Ostorlab teste les contrôles de l'application et de ses API. La détection et le signalement des incidents à l'OSFI, le red teaming et l'I-CRT, la surveillance de la fraude, les sauvegardes et la reprise, la gouvernance, les contrats et la conformité en matière de vie privée restent du ressort de vos équipes.
Les contrôles de l'OSFI à tester dans votre application mobile
Une liste pratique pour les équipes sécurité et risque technologique, fondée sur B-13, B-10 et l'avis sur le signalement des incidents.
L'application et les API dans le SDLC
Intégrez l'application mobile au cycle de vie du développement sécurisé : exigences de sécurité dès la conception et scan comme point de contrôle avant la mise en production.
Scanner chaque build
Lancez Mobile SAST et DAST depuis le pipeline à chaque build, et scannez chaque version publiée sur les stores, pas seulement celle testée le trimestre dernier.
Évaluations classées
Incluez l'application et les API qu'elle appelle dans l'évaluation de vulnérabilité régulière, avec une fréquence nommée et une note de gravité par résultat.
Délais de correction
Fixez des délais de correctifs selon la gravité et l'exposition, conservez les preuves de clôture et documentez toute exception acceptée.
MFA et sessions
Vérifiez que la MFA, l'expiration des sessions et l'invalidation des jetons sont imposées côté serveur pour les opérations clés de l'application.
Données sur l'appareil
Vérifiez le stockage, les caches, les journaux et les captures d'écran à la recherche de données personnelles et de jetons, et contrôlez la protection du transport et les secrets du package.
Tiers et SDK
Tenez un inventaire versionné des SDK et des bibliothèques, et conservez les preuves de sécurité des fournisseurs et les droits d'audit pour les plus risqués.
Preuves pour les incidents et les contrôles
Conservez les exploits et les résultats de retest avec chaque version, prêts pour les revues post-incident, les obligations de confidentialité et la supervision de l'OSFI.
Une liste indicative, et non un modèle de l'OSFI. Ceci ne constitue pas un avis juridique.
Les capacités associées à cette page
Chacune a sa propre page détaillée.
- Mobile Agentic Deep ScanDes agents IA pentestent la version publiée à chaque release, avec un exploit fonctionnel à rejouer pour chaque résultat d'un agent IA.En savoir plus
- Tests authentifiésTestez la connexion, les codes à usage unique et les parcours d'authentification renforcée avec vos comptes de test.En savoir plus
- Tests des API et du backendInterceptez le trafic de l'application même avec TLS pinning, puis testez les API et backends derrière les comptes et les paiements.En savoir plus
- Mobile SASTAnalyse statique des binaires APK, AAB et IPA, avec analyse de propagation (taint) sur l'application et ses SDK intégrés.En savoir plus
- SCA et SBOMDétectez les dépendances vulnérables, y compris les bibliothèques natives compilées statiquement, et suivez leur résolution version après version.En savoir plus
- Mobile Shielding ScanTestez à l'exécution la détection du root et du jailbreak, l'anti-altération et le pinning, et voyez quelles protections ont tenu et lesquelles ont été contournées.En savoir plus
- Votre propre clé IALancez les scans par agents IA avec la clé de votre fournisseur d'IA et un plafond de dépense par scan, pour respecter vos politiques internes.En savoir plus
- Scan on-premisesScannez les applications de préproduction, API et dépôts derrière votre pare-feu ou VPN, sur une infrastructure que vous contrôlez.En savoir plus
Des banques et fintechs nous font confiance, dont
Sources
Les textes officiels sur lesquels s'appuie cette page, vérifiés le 27 septembre 2026.
- Guideline B-13: Technology and Cyber Risk ManagementOSFI, publiée en juillet 2022, applicable depuis le 1er janvier 2024. Trois domaines : gouvernance et gestion des risques, opérations technologiques et résilience, et cybersécurité, dont le cycle de vie du développement des systèmes (2.4), la gestion des changements et des versions (2.5), la gestion des correctifs (2.6) et la cybersécurité (3.1 et 3.2)
- Guideline B-10: Third-Party Risk ManagementOSFI, datée du 30 avril 2023, applicable depuis le 1er mai 2024. Diligence raisonnable (2.2.2), sécurité et contrôles des données (2.3.2), droits à l'information et d'audit (2.3.3) et risque technologique et cyber dans les arrangements avec des tiers (section 4)
- Guideline E-21: Operational Risk Management and ResilienceOSFI, datée du 22 août 2024. Sections 1 et 2 applicables immédiatement, section 4 attendue pour le 1er septembre 2025, conformité complète pour le 1er septembre 2026. Gestion des changements (4.4), tests de scénarios (3.3) et gestion du risque lié aux données (4.7)
- Technology and Cyber Security Incident ReportingAvis de l'OSFI, daté du 13 août 2021, applicable le jour même. Signalement à la Division du risque technologique et au superviseur principal dans les 24 heures, ou plus tôt si possible. Remplace l'avis de janvier 2019
- OSFI's Intelligence-led Cyber Resilience Testing (I-CRT) FrameworkOSFI, publié le 21 avril 2023. Évaluation red team menée par le régulateur et fondée sur le renseignement, portant sur les actifs technologiques et les services qui soutiennent les fonctions critiques, applicable aux banques d'importance systémique et aux groupes d'assurance actifs à l'international, au moins une fois par cycle de supervision de trois ans à compter de 2023
- Personal Information Protection and Electronic Documents Act (PIPEDA)Codification de Justice Canada, L.C. 2000, ch. 5. Annexe 1, clause 4.7 (mesures de sécurité) et articles 10.1 à 10.3 (atteintes aux mesures de sécurité), en vigueur le 1er novembre 2018 avec le Règlement sur les atteintes aux mesures de sécurité, DORS/2018-64
- Principaux changements apportés par la Loi 25Commission d'accès à l'information du Québec (texte français). Mesures de sécurité, responsable de la protection des renseignements personnels, évaluations des facteurs relatifs à la vie privée, avis et registre des incidents de confidentialité, communication à l'extérieur du Québec et portabilité des données depuis le 22 septembre 2024. La page complémentaire Incidents de confidentialité et mesures de sécurité traite des mesures de sécurité et du traitement des incidents
- Technology Risk Bulletin: Frontier Artificial Intelligence: Implications for Technology, Cyber Security, and Operational ResilienceOSFI, avril 2026. Renvoie les institutions à B-13, B-10 et E-21 et indique que le délai pour identifier et exploiter les vulnérabilités s'est compressé. L'index des bulletins liste aussi un bulletin de juillet 2026 sur l'IA générative et agentique
Questions fréquentes
Des réponses claires sur la couverture, la mise en place et la façon dont les résultats parviennent à vos équipes.
Vous ne trouvez pas votre réponse ? Réservez une démo ou contactez-nous.
Testez votre application bancaire mobile face aux attentes de l'OSFI
Commencez par un scan gratuit de votre application depuis le store, ou réservez une démo pour lancer des tests authentifiés de votre application et de vos API avec notre équipe.