Bank Al-Maghrib et les règles nationales de cybersécurité : évaluez votre application bancaire mobile avant et après chaque version.

1. 01

   Directive n° 3/W/16 de Bank Al-Maghrib, articles premier à 3, 5 et 8 (texte français)

   Conduire un programme de tests d'intrusion fondé sur les risques

   Ce que dit le texte

   La directive n° 3/W/16 fixe les règles minimales. L'établissement doit évaluer la sécurité de son système d'information et inscrire la conduite régulière de tests dans un cadre global d'évaluation de l'efficacité de ses dispositifs de sécurité, selon une démarche fondée sur les risques. Il élabore une cartographie des risques d'intrusion ou de cyberattaque de ses systèmes d'information, puis arrête chaque année un programme de tests précisant le périmètre, la nature, l'étendue et la fréquence des tests pour l'ensemble du système d'information, primaire et de secours. Le programme est soumis pour validation au comité d'audit ou des risques, et le RSSI pilote sa réalisation.

   Source :Directive n° 3/W/16 de Bank Al-Maghrib, articles premier à 3, 5 et 8 (texte français)

   Ce que cela implique pour votre application mobile

   L'application, les API du backend et les comptes qu'elles protègent font partie du système d'information : ils ont leur place dans la cartographie des risques et dans le programme annuel, avec une fréquence adaptée à leur criticité.

   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. Les résultats sont classés critiques, élevés, moyens ou faibles et suivis sous forme de tickets dans la plateforme ou dans Jira et ServiceNow.

   Ce qui reste de votre ressort

   La cartographie des risques, le programme annuel et sa validation par le comité d'audit ou des risques, et l'appétit pour le risque qui détermine la fréquence retenue.

2. 02

   Directive n° 3/W/16 de Bank Al-Maghrib, articles 4, 6 et 7 (texte français)

   Tester les systèmes ouverts sur l'extérieur plus d'une fois par an

   Ce que dit le texte

   Les systèmes d'information ouverts sur l'extérieur doivent faire l'objet de tests plus d'une fois par an. Des tests sont également à effectuer à l'occasion de tout changement dans le système d'information susceptible d'impacter l'exposition globale aux risques de sécurité de l'information ou de cyberattaques. Bank Al-Maghrib peut exiger d'un établissement des tests ciblés, selon la fréquence et les modalités qu'elle détermine. Le périmètre, la nature, l'étendue et la fréquence des tests doivent être adaptés à la criticité des systèmes, aux résultats de l'analyse des risques et à la taille et au volume d'activité de l'établissement.

   Source :Directive n° 3/W/16 de Bank Al-Maghrib, articles 4, 6 et 7 (texte français)

   Ce que cela implique pour votre application mobile

   Votre application mobile et ses API publiques sont des systèmes ouverts sur l'extérieur. Un test annuel unique ne suffit pas, et chaque version significative devrait déclencher des tests.

   Comment Ostorlab vous aide

   Les scans s'exécutent depuis votre pipeline CI/CD à chaque build, et la surveillance des versions publiées sur les stores couvre la version que téléchargent vos clients : un changement n'attend pas le prochain cycle annuel.

   Ce qui reste de votre ressort

   La définition de ce qui constitue un changement significatif, et la planification des tests pour ne pas perturber l'exploitation.

3. 03

   Directive n° 3/W/16 de Bank Al-Maghrib, articles 9 et 10 (texte français)

   Tester de l'extérieur et de l'intérieur, sans et avec connaissances préalables

   Ce que dit le texte

   Les tests doivent être réalisés aussi bien à partir du réseau informatique interne de l'établissement que depuis l'extérieur. L'établissement doit établir une démarche et une méthodologie fondées sur les bonnes pratiques et réaliser au moins deux types de tests : une approche sans connaissances préalables sur le système d'information cible, et une approche avec des connaissances préalables sur le système d'information cible.

   Source :Directive n° 3/W/16 de Bank Al-Maghrib, articles 9 et 10 (texte français)

   Ce que cela implique pour votre application mobile

   Le test en boîte noire montre ce que voit un attaquant depuis Internet ; le test en boîte grise, avec identifiants et documentation, va plus loin dans les parcours authentifiés de l'application et de ses API.

   Comment Ostorlab vous aide

   Ostorlab teste l'application depuis l'extérieur et, avec vos comptes de test, derrière la connexion. Il intercepte le trafic même avec TLS pinning, puis teste les autorisations, les usages abusifs de jetons et les abus comme l'énumération et le rejeu, requêtes et réponses à l'appui.

   Ce qui reste de votre ressort

   Les règles d'engagement, la charte de test, et la décision de savoir qui reçoit quelles informations avant un test.

4. 04

   Directive n° 3/W/16 de Bank Al-Maghrib, articles 11 à 15 (texte français)

   Qualifier les testeurs et encadrer la confidentialité et les preuves

   Ce que dit le texte

   L'établissement établit une charte qui définit le cadre de réalisation des tests et les règles à observer par les équipes internes et externes qui les réalisent. Pour les tests nécessitant de disposer d'informations explicites et confidentielles sur les systèmes ciblés, la banque privilégie le recours à ses équipes internes. Les équipes internes doivent disposer de l'expertise et des certifications nécessaires, être indépendantes et dotées de moyens suffisants. L'exécution par un prestataire externe doit se faire dans le cadre d'une convention définissant le périmètre, les modalités d'exécution et la responsabilité du prestataire. Le prestataire doit disposer des compétences nécessaires, respecter une stricte confidentialité, travailler avec loyauté et intégrité, détruire ses relevés et ceux fournis par l'établissement dans un délai maximum de deux mois en fournissant une preuve formelle, n'exploiter les vulnérabilités identifiées qu'avec l'accord préalable et explicite de l'établissement et sans porter atteinte au système cible, et respecter la législation marocaine.

   Source :Directive n° 3/W/16 de Bank Al-Maghrib, articles 11 à 15 (texte français)

   Ce que cela implique pour votre application mobile

   Ces règles couvrent toute la chaîne, y compris qui peut voir les identifiants et les données personnelles, et ce qu'il advient des preuves de test ensuite.

   Comment Ostorlab vous aide

   Ostorlab a fait l'objet d'un audit SOC 2 Type II. Vous maîtrisez le lieu de vie des données de scan : choisissez une région de résidence des données avec l'offre Enterprise, ou lancez les scans on-premises sur une infrastructure que vous contrôlez.

   Ce qui reste de votre ressort

   La charte de test, le choix entre équipes internes et externes, le contrat du prestataire et l'attestation de destruction.

5. 05

   Directive n° 3/W/16 de Bank Al-Maghrib, articles 16 à 18 (texte français)

   Restituer les résultats à la direction avec un plan d'actions

   Ce que dit le texte

   Les résultats des tests doivent être portés à la connaissance de l'organe de direction et du comité d'audit ou des risques, en retraçant au minimum la démarche et le périmètre des tests ainsi que les risques couverts, la définition et la qualification des tests effectués et les moyens employés, les vulnérabilités détectées et leurs impacts sur la sécurité du système d'information, l'appréciation du niveau de sécurité par rapport aux standards reconnus, et les actions préventives et correctives nécessaires. Lorsqu'un système est externalisé auprès d'un prestataire, l'établissement doit s'assurer que toutes les dispositions de la directive sont observées et prises en compte dans le contrat.

   Source :Directive n° 3/W/16 de Bank Al-Maghrib, articles 16 à 18 (texte français)

   Ce que cela implique pour votre application mobile

   Les résultats ne sont pas une simple liste technique. Ils doivent être lisibles par la direction, comparables à un standard et accompagnés d'un plan d'actions.

   Comment Ostorlab vous aide

   Chaque résultat d'un agent IA est accompagné d'un exploit fonctionnel à rejouer, et les résultats peuvent être regroupés en tickets qui portent la preuve, la gravité et le statut jusqu'à la clôture. Vous disposez ainsi de la matière du rapport et du plan correctif.

   Ce qui reste de votre ressort

   La rédaction du rapport, le processus de direction et de comité, et le plan d'actions correctives.

6. 06

   Lettre circulaire n° LC/BKAM/2018/70, article 5 (texte français)

   Authentifier chaque transaction de paiement mobile et bloquer après des échecs

   Ce que dit le texte

   La lettre circulaire fixe les règles de sécurité minimales applicables aux émetteurs et acquéreurs de m-wallet. Les transactions ne peuvent être initiées qu'après les étapes préalables d'authentification du client. La saisie à plusieurs reprises d'informations d'authentification erronées déclenche un mécanisme d'authentification complémentaire ou un blocage du m-wallet. Le profil de risque des clients et de leurs transactions doit être contrôlé et maîtrisé pour réduire les risques de fraude.

   Source :Lettre circulaire n° LC/BKAM/2018/70, article 5 (texte français)

   Ce que cela implique pour votre application mobile

   Pour une application de paiement mobile, cela se traduit par une application côté serveur : authentification avant chaque transaction, blocage ou authentification renforcée après des échecs répétés, et contrôles de risque qui ne dépendent pas du bon comportement de l'application.

   Comment Ostorlab vous aide

   Les tests authentifiés couvrent la connexion, les codes à usage unique, la confirmation de transaction, les parcours d'authentification renforcée, la gestion des sessions et le verrouillage des comptes avec vos comptes de test, ainsi que les appels d'API qui les sous-tendent.

   Ce qui reste de votre ressort

   Les méthodes et seuils d'authentification, le processus de blocage et de déblocage, et les règles de fraude.

7. 07

   Décision n° 392/W/2018, articles 13 à 15 (texte français)

   Protéger les données du paiement mobile et notifier les nouveaux produits

   Ce que dit le texte

   Les établissements doivent mettre en place des mesures de sécurité appropriées afin de protéger la confidentialité et l'intégrité des données des utilisateurs des m-wallets. Ils sont tenus de déclarer à Bank Al-Maghrib toutes les fraudes relatives aux m-wallets, selon les modalités et conditions fixées par elle. Les émetteurs sont tenus de soumettre à Bank Al-Maghrib, pour avis, tout nouveau produit m-wallet, 15 jours au moins avant sa date de lancement, selon les modalités fixées par elle.

   Source :Décision n° 392/W/2018, articles 13 à 15 (texte français)

   Ce que cela implique pour votre application mobile

   Les données de paiement mobile sur l'appareil et en transit sont concernées, et une nouvelle fonctionnalité de paiement, ou une fonctionnalité fortement modifiée, passe par une étape réglementaire avant son lancement.

   Comment Ostorlab vous aide

   Ostorlab recherche les jetons 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 teste les API derrière les parcours de paiement à la recherche de contrôles d'autorisation défaillants et d'usages abusifs des jetons.

   Ce qui reste de votre ressort

   La classification des données, la déclaration des fraudes à Bank Al-Maghrib et le processus de notification des produits.

8. 08

   Directive n° 4/W/2022 de Bank Al-Maghrib, articles 5, 6, 8, 9 et 10 (texte français)

   Évaluer les risques du cloud et des interconnexions tierces

   Ce que dit le texte

   La directive n° 4/W/2022 fixe les règles minimales en matière d'externalisation vers le cloud. L'établissement définit un dispositif de gestion de ses données comprenant la classification des données, les localisations éligibles à l'hébergement, les mesures et restrictions de sécurité par classe, et les processus de récupération après une perte ou une violation de sécurité. Il conduit une analyse des risques avant toute externalisation, couvrant notamment la perte de gouvernance, la sous-traitance en chaîne, le non-respect des règles de conservation et de destruction, la gestion ineffective des droits d'accès, les transferts internationaux de données, et les faiblesses d'interconnexion entre ses systèmes et ceux du prestataire, comme l'absence de chiffrement, les faiblesses de l'authentification, l'incompatibilité de protocoles et les failles sur les API. Il vérifie les certifications du prestataire, ses mesures de sécurité, ses plans de continuité testés, sa transparence sur les incidents et son assurance cyber, et conserve des clauses d'auditabilité et de réversibilité.

   Source :Directive n° 4/W/2022 de Bank Al-Maghrib, articles 5, 6, 8, 9 et 10 (texte français)

   Ce que cela implique pour votre application mobile

   Tout ce avec quoi votre application communique en dehors de la banque, y compris les services cloud et les API tierces, entre dans la classification et l'analyse des risques, les faiblesses d'authentification et d'API étant des risques explicitement nommés.

   Comment Ostorlab vous aide

   Ostorlab intercepte le trafic de l'application même avec TLS pinning et teste les API appelées à la recherche de contrôles d'autorisation défaillants (BOLA, BFLA, IDOR), d'usages abusifs des jetons et de rejeu. SCA identifie par empreinte les bibliothèques compilées statiquement et rapproche les SDK tiers des vulnérabilités connues.

   Ce qui reste de votre ressort

   La stratégie cloud, la classification des données, les vérifications préalables sur les fournisseurs et les contrats, et les plans de sortie.

9. 09

   Loi n° 05-20 relative à la cybersécurité, articles 3 à 8, 11, 12, 19 et 20 ; décret n° 2-21-406 ; DNSSI V2 approuvée par la circulaire n° 02/2023 (texte français)

   Se conformer à la loi 05-20, à la DNSSI et aux règles des systèmes sensibles

   Ce que dit le texte

   La loi 05-20 impose aux entités et aux infrastructures d'importance vitale de se conformer aux directives, règles et référentiels de l'autorité nationale de la cybersécurité, de mettre en œuvre une politique de sécurité de leurs systèmes d'information, d'identifier les risques et de prendre des mesures techniques et organisationnelles pour les gérer, et de faire auditer, avant sa mise en exploitation puis régulièrement, tout système d'information offrant des services numériques à des tiers. Elles doivent classifier leurs actifs informationnels et leurs systèmes selon leur sensibilité, arrêter des procédures d'habilitation des personnes pouvant accéder aux informations classifiées, désigner un responsable de la sécurité des systèmes d'information (RSSI), et mettre en place des moyens de supervision et de détection. Les incidents de cybersécurité doivent être déclarés à l'autorité nationale. Les données sensibles doivent être exclusivement hébergées sur le territoire national, et toute externalisation d'un système d'information sensible doit faire l'objet d'un contrat de droit marocain comprenant des engagements de protection de l'information, d'auditabilité et de réversibilité. Tout système d'information sensible doit faire l'objet d'une homologation de sa sécurité avant sa mise en exploitation et, à la demande de l'autorité nationale, être audité par cette autorité ou par des prestataires d'audit qualifiés par elle. La DNSSI V2, approuvée par la circulaire n° 02/2023, fixe les mesures organisationnelles et techniques, les entités et infrastructures d'importance vitale disposant de six mois pour établir un calendrier de mise en œuvre.

   Source :Loi n° 05-20 relative à la cybersécurité, articles 3 à 8, 11, 12, 19 et 20 ; décret n° 2-21-406 ; DNSSI V2 approuvée par la circulaire n° 02/2023 (texte français)

   Ce que cela implique pour votre application mobile

   Une application bancaire mobile est un service numérique et un canal vers des systèmes susceptibles d'être qualifiés de sensibles. L'audit avant mise en exploitation, la classification, l'hébergement national des données sensibles et les obligations de supervision s'y appliquent. Si les systèmes de la banque sont désignés comme infrastructure d'importance vitale disposant de systèmes d'information sensibles, le canal mobile et ses backends entrent dans le périmètre.

   Comment Ostorlab vous aide

   Ostorlab fournit des preuves de test de sécurité avant une version : pentests par agents IA de l'application et de ses API, Mobile SAST sur le binaire, SCA sur les composants embarqués et contrôles de shielding pour le root, le jailbreak, l'altération et le pinning, le tout exécutable depuis votre CI/CD ou on-premises sur une infrastructure que vous contrôlez. Ostorlab a fait l'objet d'un audit SOC 2 Type II et ne remplace pas les audits qui doivent être réalisés par des prestataires qualifiés par la DGSSI.

   Ce qui reste de votre ressort

   La politique de sécurité, l'analyse des risques, la classification et sa déclaration, le RSSI, l'homologation des systèmes sensibles, le choix des lieux d'hébergement, la déclaration des incidents à la DGSSI et les audits par des prestataires qualifiés.

10. 10

    Loi n° 09-08, articles 12, 23, 24, 43 et 44 (texte français)

    Protéger les données personnelles au titre de la loi 09-08

    Ce que dit le texte

    Au titre de la loi 09-08, le traitement de données à caractère personnel doit faire l'objet d'une déclaration préalable, et d'une autorisation préalable lorsqu'il concerne des données sensibles, l'utilisation de données à d'autres fins que celles pour lesquelles elles ont été collectées, ou des données génétiques. Le responsable du traitement doit mettre en œuvre des mesures techniques et organisationnelles appropriées pour protéger les données contre la destruction accidentelle ou illicite, la perte, l'altération, la diffusion ou l'accès non autorisé, notamment lorsque le traitement comporte des transmissions de données dans un réseau, et choisir un sous-traitant offrant des garanties suffisantes, lié par un contrat écrit. Des mesures spécifiques s'appliquent aux données sensibles et de santé, dont le contrôle de l'accès, des supports, de la transmission et la journalisation. Les données ne peuvent être transférées que vers un État assurant un niveau de protection suffisant, ou dans les cas dérogatoires de l'article 44, dont l'autorisation expresse et motivée de la CNDP.

    Source :Loi n° 09-08, articles 12, 23, 24, 43 et 44 (texte français)

    Ce que cela implique pour votre application mobile

    Les données clients dans l'application, dans les journaux et dans le backend sont des données personnelles. Les mesures de sécurité, les clauses avec les sous-traitants et tout transfert à l'étranger, y compris vers une plateforme de scan, doivent être encadrés.

    Comment Ostorlab vous aide

    Ostorlab recherche les données personnelles dans le stockage local, les caches, les journaux et les captures d'écran et vérifie comment l'application les transmet. Avec l'offre Enterprise, vous pouvez choisir une région de résidence des données ou lancer les scans on-premises, pour aligner le traitement sur votre position vis-à-vis de la CNDP.

    Ce qui reste de votre ressort

    Les bases légales, les déclarations et autorisations préalables, le registre des traitements et les demandes de transfert auprès de la CNDP.

Synthèse des textes publics de Bank Al-Maghrib, de la DGSSI et de la CNDP, vérifiés le 27 septembre 2026. Les textes de Bank Al-Maghrib, de la DGSSI et de la CNDP sont en français et les synthèses de cette page sont les nôtres. Cette page ne constitue pas un avis juridique.