Vergelijking NL / FR

Article 1er. Pour l'application du présent règlement, il y a lieu d'entendre par :
  1° "la loi" : la loi du 24 mars 2017 relative à la surveillance des processeurs d'opérations de paiement ;
  2° "processeur" : tout processeur d'importance systémique tel que visé par la loi.
  Pour le reste, les définitions de l'article 3 de la loi sont applicables pour l'application du présent règlement.

Art.2. Les dispositions de ce Chapitre précisent les modalités des obligations visées à l'article 8 de la loi.

Art.3. § 1er. Lorsqu'il existe une relation contractuelle entre l'exploitant d'un schéma de paiement et un processeur ou que l'exploitant d'un schéma de paiement impose au processeur d'obtenir son agrément (licence ou équivalent) pour traiter ses opérations, l'exploitant du schéma de paiement devra disposer d'une procédure visant à s'assurer de la capacité du processeur de se conformer aux dispositions du Chapitre 3 de la loi, et prend spécifiquement en compte la capacité du processeur à implémenter les développements et les adaptations qu'il doit apporter à ses systèmes afin de traiter les opérations du schéma de paiement.
  § 2. La diligence requise de l'exploitant du schéma de paiement s'exerce :
  1° lorsqu'un processeur non-systémique utilisé par le schéma devient systémique et que notification en est faite par la Banque au processeur ;
  2° préalablement à l'établissement de la relation entre l'exploitant du schéma de paiement et le processeur. L'exploitant du schéma de paiement s'abstient d'entrer en relation contractuelle avec un processeur qu'il estime, après analyse, incapable de se conformer au Chapitre 3 de la loi ;
  3° durant la relation entre l'exploitant du schéma de paiement et le processeur. A cette fin l'exploitant du schéma de paiement obtient annuellement du processeur la confirmation qu'il est toujours en conformité avec le Chapitre 3 de la loi. Cette confirmation est réalisée ou validée par un auditeur interne du processeur ou externe.
  § 3. L'exploitant du schéma de paiement tient à la disposition de la Banque la documentation de la procédure visée au paragraphe premier, ainsi que les analyses qu'il a effectuées ou fait effectuer en vertu de cette procédure et les attestations annuelles obtenues des processeurs avec lesquels l'exploitant du schéma travaille sur une base contractuelle.

Art.4. Les dispositions de cette Section précisent les modalités des obligations visées à l'article 11, § 2 de la loi.

Art.5. Tout processeur met en place, préventivement, toute mesure raisonnable de réduction des risques opérationnels et de sécurité qu'il a identifiés.

Art.6. Tout processeur prend les dispositions nécessaires en matière de cybersécurité et assure la confidentialité, l'intégrité et la disponibilité de l'ensemble de ses ressources physiques et logiques, ainsi que celles des données de paiement sensibles qu'elles soient stockées, en transit ou en cours de traitement. Le processeur met notamment, mais pas exclusivement, en oeuvre les principes suivants :
  1° une approche de type "défense en profondeur" (defence in depth), impliquant des contrôles en couches multiples et successives qui couvrent tant le personnel, les processus et la technologie utilisée ;
  2° l'application de la ségrégation tant au niveau des environnements IT (développement, intégration, production) qu'au niveau des tâches à effectuer par le personnel. Le personnel est dûment formé et surveillé et dispose des accès aux fonctionnalités et aux données sur une base "besoin d'en connaître" (need-to-know). En outre, les membres du personnel se voient accorder les accès aux seules ressources indispensables à l'exercice de leurs tâches et responsabilités (principe du "moindre privilège" (least privilege)). L'allocation des privilèges d'accès fait l'objet d'une révision à intervalles réguliers, au minimum une fois par an, et dans tous les cas (a) lors d'un changement d'affectation à l'intérieur de l'entreprise, (b) lors de la mise en production de nouveaux services, (c) lors de toute modification affectant une prestation de service et (d) à la suite de tout incident trouvant sa cause, même partiellement, dans un accès inadéquat à une ou plusieurs ressources. Des "journaux/historiques d'événements" (loggings) relatifs aux accès sont réalisés et conservés pendant une période corrélée à la criticité de la fonctionnalité, du processus ou de "l'actif du système d'information" (information asset). Ces "journaux/historiques d'événements" sont notamment utilisés afin de faciliter l'identification et l'examen de toute activité anormale détectée dans l'exercice de la fourniture de services.

Art.7. Tout processeur dispose de mesures de sécurité physique adéquates afin de protéger notamment l'ensemble des données qui font l'objet des services de traitement, ainsi que les systèmes ICT utilisés pour prester ces services.

Art.8. Tout processeur dispose d'un processus formel de gestion des changements, assurant que ceux-ci soient correctement planifiés, testés, documentés et autorisés. En fonction des menaces observées en matière de sécurité ainsi que des modifications envisagées, lesdits tests incorporent des scénarios impliquant notamment des attaques déjà connues ou vraisemblables. Le processeur détermine si les changements apportés à son environnement opérationnel affectent d'une manière ou d'une autre les mesures de sécurité en place, ou requièrent l'adoption de mesures supplémentaires de réduction des risques.

Art.9. Tout processeur s'assure de manière régulière que l'ensemble des programmes utilisés pour la prestation de ses services soient en permanence mis à jour, et que les patches et correctifs critiques, et singulièrement ceux relatifs à la sécurité, soient déployés sans retard. Des mécanismes de contrôle d'intégrité vérifient en permanence l'intégrité des applications, des "microprogrammes/micrologiciels" (firmware) ainsi que des données utilisées dans la prestation des services de traitement.

Art.10. Tout processeur contrôle en permanence le degré d'utilisation des ressources informatiques mises en oeuvre, et veille à disposer à tout moment des réserves de capacités adéquates pour faire face à des variations imprévues d'activités. Ce contrôle s'effectue également sur longues périodes afin de détecter les évolutions à l'oeuvre et afin de pouvoir prévoir, le cas échéant, suffisamment à l'avance les adaptations majeures d'infrastructure à réaliser.
  La Banque peut émettre des directives pour déterminer quelles adaptations sont majeures. Le processeur consulte la Banque en cas de doute sur l'importance de l'adaptation.

Art.11. Tout processeur choisit son infrastructure et les technologies utilisées en tenant compte de l'évolution probable de ses activités.

Art.12. Tout processeur évalue et implémente les mesures complémentaires à celles visées aux articles 5 à 11, qu'il convient de mettre en place pour atteindre les objectifs repris à l'article 11, § 2, de la loi.

Art.13. Les dispositions de cette Section précisent les modalités des obligations visées à l'article 11, § 3, de la loi.

Art.14. § 1er. La gestion efficace de la continuité des activités telle que mise en place doit avoir pour objectif de permettre au processeur d'être en toute circonstance et à tout moment capable de prester les services de traitement qui lui incombent et à limiter au maximum la durée des interruptions. Cette disposition n'exclut toutefois pas pour le processeur la possibilité de planifier des interruptions de services pour réaliser la maintenance de ses systèmes.
  § 2. Le processeur priorise les actions à entreprendre en matière de continuité des opérations, en analysant notamment les fonctions, processus, systèmes et transactions identifiés et classifiés comme critiques, et en adoptant une approche qui est notamment, mais pas exclusivement, basée sur les risques. Cette analyse permet au processeur de développer et d'activer à tout moment des procédures de continuité des activités afin de réagir de façon appropriée aux urgences, tout en continuant à prester ses activités critiques.

Art.15. § 1er. Le processeur dispose d'un plan de continuité visant à :
  1° limiter au maximum la durée des interruptions d'activités et
  2° protéger et, si besoin, rétablir l'intégrité et la disponibilité des opérations et de la confidentialité des données.
  Le plan de continuité est bien documenté, disponible et directement accessible au personnel des services opérationnels et de support. Ce plan se focalise sur le rétablissement rapide de l'exercice et du traitement des fonctions, processus, systèmes et transactions critiques.
  § 2. Le plan de continuité est testé au moins annuellement. Les tests considèrent un ensemble adéquat de scénarios plausibles, et incluent des procédures pour vérifier la capacité du personnel (y compris en matière de prise de décision) et des processus de faire face adéquatement aux scénarios proposés. Les plans sont tenus à jour :
  1° régulièrement pour tenir compte des résultats des tests, des menaces nouvellement identifiées et des leçons tirées des incidents antérieurs et des objectifs adaptés de rétablissement des activités ;
  2° après tout changement apporté aux systèmes et processus.

Art.16. En situation d'urgence ou d'interruption des activités, le processeur dispose de et utilise des procédures de communication de crise afin d'informer rapidement et de manière appropriée toutes les parties prenantes qu'elles soient internes (direction, équipes techniques, etc.) ou externes (schémas de paiement, marchands, détenteurs de cartes, régulateurs, etc.).

Art.17. Les dispositions de cette Section précisent les modalités des obligations visées à l'article 11, §§ 1er et 4 de la loi.

Art.18. § 1er. Tout processeur conçoit, développe et met en oeuvre sur une base permanente un cadre global de gestion des risques opérationnels. Ce cadre est présenté par la direction au conseil d'administration qui :
  1° l'approuve formellement ;
  2° veille à soutenir effectivement sa mise en oeuvre et son évolution, en prenant les décisions adéquates en termes de moyens tant humains que techniques à y consacrer ;
  3° est impliqué de façon active, notamment au moyen de rapports qui lui sont fournis par la direction, dans la définition du niveau de tolérance aux risques de l'entreprise, ainsi que dans la validation des orientations à suivre dans la mise en oeuvre effective des mesures de réduction de risques.
  § 2. Le cadre global de gestion des risques opérationnels est documenté en détails et doit notamment, mais pas exclusivement :
  1° détailler la politique globale de gestion des risques opérationnels pour l'ensemble de l'entreprise. A cette fin le processeur établit un inventaire complet, ainsi qu'une classification selon leur criticité respective (a) des fonctions opérationnelles, rôles clés et processus sous-jacents, ainsi que leurs interdépendances éventuelles et (b) des "actifs du système d'information", tels que les systèmes ICT, leurs configurations et leurs interconnexions avec d'autres systèmes internes et externes ;
  2° prévoir la mise en oeuvre de politiques spécifiques visant à disposer à tout moment des ressources humaines expérimentées, ainsi que des procédures et systèmes indispensables afin d'identifier, mesurer et gérer l'ensemble des risques opérationnels liés à la prestation de services de processing. A cet effet, le processeur veille à définir clairement les responsabilités incombant à chaque membre du personnel en matière de gestion des risques opérationnels, avec une attention particulière pour l'existence d'un processus clair et efficace de prise de décision en situation d'urgence et/ou période de crise.
  § 3. Le cadre global de gestion des risques opérationnels est revu selon une fréquence adéquate, au minimum une fois par an, de sorte que ses mises à jour intègrent les leçons tirées de sa mise en oeuvre quotidienne. Une mise à jour est également effectuée :
  1° à l'issue de chaque incident majeur, de nature opérationnelle ou relatif à la sécurité des services presté ;
  2° préalablement à la mise en production de changements majeurs relatifs à l'infrastructure, aux processus et procédures.
  La Banque peut émettre des directives pour déterminer quels incidents ou changements sont majeurs. Le processeur consulte la Banque en cas de doute sur l'importance de l'incident ou du changement.

Art.19. § 1er. Le processeur s'organise de manière telle qu'il surveille de près, sur une base permanente, les menaces et vulnérabilités. Il adapte régulièrement les scénarios de risques susceptibles d'impacter ses fonctions opérationnelles, processus et "actifs du système d'information" critiques.
  § 2. Pour atteindre l'objectif visé au paragraphe premier, le processeur effectue et documente des études et évaluations de risques, à une fréquence annuelle ou plus courte si la Banque l'exige, pour chaque fonction opérationnelle, processus et "actif du système d'information" tel qu'identifié et classé par niveau de criticité, ainsi que préalablement à toute modification majeure apportée à son infrastructure, ses processus et ses procédures. Les conclusions des études et évaluations de risques sont également utilisées afin de déterminer dans quelle mesure des adaptations doivent être apportées aux technologies utilisées, aux mesures de sécurité et aux procédures en place, ainsi qu'aux prestations offertes. Les études et évaluations de risques, ainsi que leurs conclusions sont tenues à la disposition de la Banque.
  La Banque peut émettre des directives pour déterminer quels changements sont majeurs. Le processeur consulte la Banque en cas de doute sur l'importance du changement.
  § 3. L'identification et la gestion sur le terrain des risques opérationnels et de sécurité s'opère à l'aide d'un modèle interne de contrôle et de gestion des risques, tel que celui des trois lignes de défense. Ce modèle interne dispose de l'autorité, de l'indépendance et des ressources requises, ainsi que d'un canal de rapportage direct vers la direction et le conseil d'administration.
  Les mesures mises en place pour gérer les risques opérationnels et de sécurité font l'objet d'un audit régulier, selon une fréquence adéquate mené par des auditeurs spécialisés en matière IT et de sécurité IT. L'audit est mené par des auditeurs internes mais indépendants des fonctions business, ou par des auditeurs externes du processeur.

Art.20. Les dispositions de cette Section précisent les modalités des obligations visées à l'article 12, §§ 1er et 2 de la loi.

Art.21. § 1er. Le processeur fait évaluer par un auditeur interne ou externe la conformité de son organisation avec les dispositions de l'article 12, §§ 1er et 2 de la loi. La Banque peut si elle l'estime nécessaire demander expressément que le processeur fasse réaliser cette évaluation par un organisme indépendant (c'est-à-dire qui ne fait pas partie de la même entité juridique que le processeur, ni du groupe auquel le processeur appartient) L'organisme indépendant devra jouir d'un degré élevé d'expertise et de compétence dans le domaine concerné et est reconnu comme tel par l'industrie concernée.
  § 2. Le rapport de conformité est actualisé au minimum tous les trois ans, ou après chaque adaptation majeure des infrastructures et/ou des processus du processeur.
  La Banque peut émettre des directives pour déterminer quelles adaptations sont majeures. Le processeur consulte la Banque en cas de doute sur l'importance de l'adaptation.

Art.22. Les dispositions de cette Section précisent les modalités des obligations visées à l'article 12, § 5, de la loi.

Art.23. § 1er. Le processeur met en place un canal de communication permettant d'informer les prestataires de services de paiement, les schémas de paiement et les utilisateurs des services de paiement concernés des indisponibilités de service de traitement des opérations de paiement visées par la loi. Ce canal de communication peut notamment comprendre une page sur le site internet du processeur indiquant entre autres l'état du réseau.
  Les informations transmises peuvent être différenciées en fonction de leurs destinataires et des besoins de ceux-ci en la matière :
  1° pour les prestataires de services de paiement et pour les schémas de paiement il s'agira notamment des causes et conséquences, ainsi que la durée prévue de la perturbation et le délai de rétablissement total estimé ;
  2° pour les utilisateurs des services de paiement, ces informations pourront se limiter à une estimation de la durée prévue de la perturbation et du délai de rétablissement total.
  Ces informations seront communiquées sans délai dès qu'elles seront connues du processeur et seront mises à jour régulièrement.
  Si le processeur est dans l'impossibilité de communiquer ces informations, l'exploitant du schéma de paiement visé à l'article 5 de la loi se chargera de communiquer aux prestataires de services de paiement et aux utilisateurs finaux les informations dont il dispose concernant notamment la durée prévue de la perturbation dans le traitement de ses opérations et le délai de rétablissement total estimé.
  § 2. Le processeur informe au préalable les prestataires de services de paiement, les schémas de paiement et les utilisateurs de services de paiement, du canal de communication qui sera utilisé en priorité aux fins visées au paragraphe premier, ainsi que d'un éventuel canal de réserve ou de secours.

Art.24. Les dispositions de cette Section précisent les modalités des obligations visées à l'article 13, §§ 1er et 2, de la loi.

Art.25. § 1er. Le processeur notifie la Banque de toute indisponibilité (au sens de la loi) des services de traitement des opérations de paiement. Cette notification peut être communiquée par téléphone ou par courrier électronique dans les délais prévus à l'article 13, § 1er, de la loi, et est en tout cas suivie par une deuxième notification par courrier électronique pour confirmation dans les 24 heures ouvrables après la première notification. Une liste de personnes de contact est convenue avec la Banque et fait l'objet d'une mise à jour à chaque changement de personne de contact.
  § 2. Les informations à transmettre lors des notifications de l'indisponibilité visées au paragraphe premier, comprennent au minimum :
  1° la date et l'heure de détection et de début de l'indisponibilité ;
  2° la description de l'incident ayant conduit à l'indisponibilité ;
  3° le ou les schéma(s) de paiement concerné(s) ;
  4° le volume de transactions concerné ;
  5° la durée estimée ou mesurée, si l'indisponibilité a pris fin avant sa notification.
  Si certaines de ces informations ne sont pas disponibles au moment de la notification, elles sont transmises dès qu'elles seront connues du processeur.

Art.26. Les dispositions de cette Section précisent les modalités des obligations visées à l'article 13, § 4, de la loi.

Art.27. § 1er. L'analyse approfondie d'un incident qui constitue une infraction aux dispositions des articles 11 et 12 de la loi, est transmise à la Banque dès qu'elle est réalisée et validée par le processeur et au plus tard dans les deux semaines après la résolution de l'incident.
  Si la nature et la complexité de l'incident ne permettent pas d'en réaliser une analyse suffisamment détaillée dans le délai visé à l'alinéa précédent, la Banque et le processeur peuvent convenir d'un délai supplémentaire, après communication d'une analyse intermédiaire.
  § 2. L'analyse approfondie indique également les mesures que le processeur envisage de prendre pour éviter que l'incident ne se reproduise et le délai endéans lequel elles seront mises en place.
  § 3. Le rapportage de l'analyse approfondie peut, le cas échéant et après accord de la Banque, être aligné avec d'autres rapportages d'incidents qui s'imposent au processeur en vertu d'autres législations.

Art.28. Tout processeur examine et répond aux questions reprises dans l'annexe, pour valider sa conformité avec les Chapitres 3 et 4 de ce règlement. Ces questions sont fournies à titre de guidance.

Art.29. Le présent règlement entre en vigueur à la date d'entrée en vigueur de l'arrêté royal qui l'approuve.

Art. N. Annexe
  Afin d'évaluer sa conformité aux Chapitres 3 et 4 de ce règlement, le processeur examine et répond aux questions suivantes :
  1. DETECTION ET GESTION DES RISQUES
  Cadre de gestion des risques à l'échelle de l'entreprise
  - Quels sont les processus et les systèmes du processeur pour recenser et documenter ses risques, y compris les risques opérationnels, financiers et de ressources humaines pertinents ? Quels risques le processeur a-t-il recensés et documentés à l'aide de ses processus et de ses systèmes ?
  - Quels sont les processus et les systèmes du processeur pour gérer ces risques ? Comment le processeur décide-t-il d'accepter les risques résiduels ?
  - Comment le processeur réévalue-t-il ses risques et le caractère adéquat de son cadre de gestion des risques pour faire face aux risques recensés ? A quelle fréquence cette réévaluation est-elle effectuée ?
  - Comment le processeur répond-il aux exigences légales ou réglementaires ou aux changements d'exigences ?
  - Comment le processeur évalue-t-il les risques liés à ses relations avec les utilisateurs ?
  - Comment le processeur intègre-t-il la gestion des risques dans son processus décisionnel stratégique, y compris l'évaluation des risques commerciaux généraux et de la situation financière ?
  Dépendances à l'égard des tiers
  - Comment le processeur recense-t-il et surveille-t-il les risques que les dépendances à l'égard de fournisseurs tiers pourraient poser pour ses activités ?
  - Comment le processeur évalue-t-il que la sécurité, la fiabilité et la résilience de ses activités ne sont pas réduites par les dépendances à l'égard de tiers ?
  - Comment le processeur gère-t-il et traite-t-il toute réduction non acceptée en matière de sécurité, de fiabilité et de résilience de ses activités découlant de ses dépendances à l'égard de tiers ?
  Gouvernance du cadre de gestion des risques à l'échelle de l'entreprise
  - Quelles sont les modalités de gouvernance du processeur pour le recensement et la gestion des risques ? Quelles sont les chaînes de responsabilité au sein du processeur en matière de gestion des risques ? A quelle fréquence l'efficacité de la fonction d'audit interne fait - elle l'objet d'un examen ?
  - Comment le conseil d'administration du processeur examine-t-il et approuve-t-il explicitement le cadre de gestion des risques à l'échelle de l'entreprise ?
  Fonction d'audit interne
  - Comment le processeur assure-t-il l'indépendance et le professionnalisme de la fonction d'audit ? A quelles pratiques acceptées à l'échelle internationale qui régissent la profession d'auditeur la fonction d'audit interne adhère-t-elle ?
  - Quels sont les mécanismes de reporting permettant à la fonction d'audit interne de communiquer ses constatations au conseil d'administration et, le cas échéant, à son autorité de contrôle ou d'oversight ?
  2. SECURITE DE L'INFORMATION
  Cadre de sécurité de l'information
  - Quel est le cadre de sécurité de l'information du processeur à l'échelle de l'entreprise permettant de fournir une orientation générale et globale sur les solutions et les pratiques destinées à faire face aux risques de sécurité physique et de cybersécurité ? Comment ce cadre englobe-t-il les politiques et les procédures destinées à :
  1° la catégorisation des actifs (systèmes et services) selon la confidentialité, l'intégrité et la disponibilité ;
  2° le recensement continu des menaces internes et externes ;
  3° la sélection, la mise en oeuvre et la documentation des contrôles de sécurité afin d'atténuer les risques et les vulnérabilités recensés ; et
  4° la gouvernance adéquate de toutes les activités de gestion des risques en matière de sécurité ?
  - Comment le processeur intègre-t-il les normes internationales, nationales et sectorielles pertinentes dans ses politiques et ses procédures ?
  - Quelles sources de risques liés à la sécurité de l'information le processeur a-t-il recensées en ce qui concerne ses services critiques ? Comment le processeur a-t-il traité ces risques ?
  - Quel est le rôle joué par le conseil d'administration dans le cadre de sécurité de l'information du processeur ? Le conseil d'administration examine-t-il et approuve-t-il explicitement ce cadre ? A quelle fréquence le conseil d'administration révise-t-il ce cadre ?
  - Comment le conseil d'administration du processeur a-t-il approuvé les rôles et les responsabilités clés de la haute direction en matière de sécurité de l'information ?
  Politiques et procédures de sécurité de l'information
  - Quelles sont les politiques et procédures utilisées pour prévenir l'accès non autorisé et la divulgation non autorisée de l'information ? En particulier, quelles sont les politiques et les procédures concernant les aspects suivants :
  1° l'octroi et la suppression d'autorisations aux utilisateurs, y compris l'accès logique et l'accès physique ;
  2° la recertification périodique des privilèges d'utilisateur ;
  3° l'octroi, l'utilisation et le contrôle des comptes administrateurs (ou hautement privilégiés) ;
  4° la prévention des atteintes à la confidentialité des données ;
  5° la protection de l'intégrité des systèmes contre les attaques logiques ou physiques ; et
  6° l'intégration de contrôles dans des applications fournies au schéma de paiement pour prévenir les erreurs, la perte, la modification non autorisée ou l'utilisation abusive de l'information ?
  - Comment le processeur s'assure-t-il que tous les employés et toutes les tierces parties concernées sont informés de leurs responsabilités, ainsi que des menaces à la sécurité, telles que définies dans le cadre de sécurité de l'information ?
  - Quelles sont les politiques et procédures utilisées pour assurer la confidentialité, l'intégrité et la non-répudiation des données, y compris lorsqu'elles sont en transit sur les réseaux et stockées chez le processeur ?
  - Quelles sont les politiques et procédures utilisées pour détecter les incidents liés à la sécurité de l'information, y réagir et rétablir la situation ?
  Suivi de la conformité à la sécurité
  - Comment le processeur vérifie-t-il la conformité à son cadre de sécurité de l'information et surveille-t-il l'efficacité des contrôles de sécurité ? Plus précisément, ces politiques et procédures comprennent-elles une analyse de vulnérabilité et des tests de pénétration au niveau de l'infrastructure et des applications ?
  - Dans quelle mesure le cadre de sécurité de l'information du processeur est-il assujetti à un audit interne et externe ?
  - Comment et à quelle fréquence le conseil d'administration du processeur est-il informé des principales constatations des activités de suivi de la conformité en matière de sécurité ?
  Planification des capacités
  - Quelles sont les politiques du processeur en matière de planification des capacités ? Comment le processeur surveille-t-il et ajuste-t-il l'utilisation des ressources pour répondre aux besoins du schéma de paiement et, le cas échéant, de ses participants, même au cours de périodes de tensions sur les marchés ? Comment le processeur aborde-t-il les situations où les besoins du schéma de paiement ou des participants dépassent la capacité opérationnelle ?
  - Comment le processeur examine-t-il, audite-t-il et teste-t-il l'évolutivité et l'adéquation de sa capacité à gérer, à tout le moins, les volumes de tension projetés qui sont recensés par un schéma de paiement donnée et, le cas échéant, les volumes de tension projetés concomitants lorsqu'il agit pour plusieurs schémas de paiement ? A quelle fréquence le processeur effectue-t-il ces examens, audits et tests ?
  Gestion du changement
  - Comment les politiques et procédures du processeur en matière de gestion du changement et de gestion de projet atténuent-elles les risques que des changements nuisent fortuitement à la sécurité et à la fiabilité des activités du processeur ?
  - Comment les politiques de gestion du changement élaborées par le processeur définissent-elles les responsabilités et procédures officielles de gestion pour la planification et les tests des changements, y compris en matière de tests de régression, de performance et de sécurité ?
  - Dans quelle mesure les changements ayant une incidence sur les utilisateurs sont-ils soumis à la consultation du schéma de paiement et testés avec la participation de ce dernier et, le cas échéant, de ses participants ?
  3. FIABILITE ET RESILIENCE
  Des activités disponibles, fiables et résilientes
  - Quels sont les objectifs de disponibilité, de fiabilité et de résilience opérationnelles du processeur et comment sont-ils documentés ? Comment ces objectifs répondent-ils aux besoins du schéma de paiement et, le cas échéant, de ses participants ou les dépassent-ils ?
  - Comment les politiques et les procédures du processeur étayent-elles ses objectifs de disponibilité, de fiabilité et de résilience ?
  - Comment le processeur s'assure-t-il qu'il fournit des activités fiables et résilientes au schéma de paiement et, le cas échéant, à ses participants ? En particulier, comment s'assure-t-il que ses différents sites d'exploitation présentent des profils de risque suffisamment différents ? Comment s'assure-t-il que ses sites d'exploitation sont adéquatement protégés contre les catastrophes naturelles, les pannes d'électricité et les actions humaines préjudiciables ? Comment s'assure-t-il que ses sites de sauvegarde disposent d'une capacité suffisante pour traiter les services critiques pendant une période prolongée ?
  Suivi des activités et gestion des incidents
  - Comment le processeur surveille-t-il ses activités ? Comment vérifie-t-il s'il atteint les objectifs de fiabilité et de résilience du schéma de paiement ? Comment ce processus est-il documenté et comment le maintien de sa mise en oeuvre est-il assuré ?
  - Comment le processeur recense-t-il, enregistre-t-il, catégorise-t-il, analyse-t-il et gère-t-il les incidents opérationnels ? Comment ces incidents sont-ils signalés à la haute direction ? Comment le processeur informe-t-il le schéma de paiement et, le cas échéant, les autorités compétentes de ces incidents ? Quel est le processus permettant de faire passer un incident au statut de crise ?
  - Quel est le processus d'analyse post mortem des incidents et comment ce processus est-il conçu pour assurer la détermination de la cause profonde des incidents et pour éviter qu'ils ne se reproduisent ? Quelle est la contribution du schéma de paiement à cette analyse post mortem ?
  Continuité des activités
  - Quels sont les objectifs du processeur en matière de continuité des activités et de reprise après sinistre ? Comment ces objectifs sont-ils fixés par le conseil d'administration et la haute direction ? A quelle fréquence ces objectifs sont-ils réexaminés par le conseil d'administration et la haute direction ?
  - Comment les plans de continuité des activités et de reprise après sinistre élaborés par le processeur garantissent-ils la reprise en temps opportun de ses services critiques en cas d'interruption de service, y compris en cas de perturbation à grande échelle ? Que prévoient ces plans en matière de perte potentielle de données à la suite d'une interruption de service ?
  - Comment le processeur détermine-t-il les scénarios de perturbation potentielle du service et comment le schéma de paiement participe-t-il à ce processus ?
  - Que prévoient les plans du processeur en matière de continuité des activités et de reprise après sinistre pour ce qui concerne les cyberattaques ? Comment ces plans garantissent-ils que le processeur aura la capacité de déterminer et de gérer l'incidence d'une cyberattaque, y compris en matière de rétablissement des systèmes après un compromis ?
  - Quel est le plan de communication de crise du processeur pour faire face aux interruptions de service ? En particulier, comment le plan aborde-t-il les communications et l'échange d'informations avec le schéma de paiement et les autorités compétentes ?
  - Comment les plans de continuité des activités et de reprise après sinistre sont-ils testés et à quelle fréquence ? Quels sont les scénarios testés, et incluent-ils des cyberattaques ? Comment les résultats de ces tests sont-ils évalués et audités ? Comment le schéma de paiement et, le cas échéant, ses participants, contribuent-ils aux tests de simulation de continuité des activités ?
  - Qu'est-il prévu pour l'évaluation régulière, en fonction des attentes du schéma de paiement, des plans du processeur en matière de continuité des activités et de reprise après sinistre ?
  4. PLANIFICATION TECHNOLOGIQUE
  Politiques, procédures et modalités de gouvernance en matière de planification technologique
  - Quelles sont les politiques, les procédures et les modalités de gouvernance du processeur en matière de planification technologique ? Que prévoient ces politiques, procédures et modalités de gouvernance concernant le cycle de vie en matière d'utilisation des technologies et de choix des normes technologiques ?
  - A quelle fréquence le processeur évalue-t-il ses risques technologiques ? Comment ces évaluations tiennent-elles compte de la fiabilité et de la résilience, des risques d'obsolescence et des risques de sécurité de l'information liés à l'utilisation de sa technologie ? Comment ces évaluations tiennent-elles compte des risques technologiques susceptibles de nuire au schéma de paiement et, le cas échéant, à ses participants ?
  Politiques, procédures et modalités de gouvernance en matière de gestion des changements technologiques
  - Quelles sont les politiques, les procédures et les modalités de gouvernance du processeur en matière de mise en oeuvre des changements à apporter aux technologies utilisées ? Comment ces politiques et ces procédures abordent-elles la gestion des versions, l'utilisation cohérente de la technologie et le maintien de la sécurité et de la stabilité de la technologie ?
  - Comment ces politiques, ces procédures et ces modalités de gouvernance garantissent-elles que les risques liés aux changements technologiques sont recensés et atténués de façon adéquate, afin d'éviter que ces changements puissent nuire à la fiabilité et à la résilience des services critiques du fournisseur ? Comment et à quelle fréquence le processeur évalue-t-il et teste-t-il les processus utilisés pour mettre en oeuvre les changements technologiques ?
  - Comment le processeur consulte-t-il le schéma de paiement et, le cas échéant, ses participants, au sujet de toute proposition de changement important à apporter à sa technologie qui pourrait avoir une incidence importante sur le schéma de paiement ?
  - Comment le service critique fait-il intervenir le schéma de paiement lorsque cela est opportun lors de la mise en oeuvre d'un changement technologique ? Par exemple, le schéma de paiement participe-t-il aux tests des changements technologiques de façon appropriée ?