CentralPay Documentation CentralPay Documentation
  • Informations générales
  • Documentation
  • Développeurs
CentralPay Documentation CentralPay Documentation
  • Informations générales
  • Documentation
  • Développeurs
Informations générales
  • Folder icon closed Folder open iconContacter CentralPay >
  • Folder icon closed Folder open iconL'établissement CentralPay
    • Certifications et agréments
    • Sécurité et hébergement
    • Engagements de disponibilité
    • Évolution de la plateforme
  • Folder icon closed Folder open iconOuvrir un compte Marchand CentralPay
    • Parcours d'entrée en relation
    • Pièces justificatives : KYC / KYB
    • Pays autorisés
    • Activités interdites
    • Principes de réserve
    • Conditions générales d’utilisation
  • Folder icon closed Folder open iconGlossaire
    • Terminologies CentralPay
    • Lexique des paiements
  • Folder icon closed Folder open iconAPI et interfaces
    • Utilisation des API CentralPay
    • Portail Marchand
    • Portail Client
    • Portail d’inscription
  • Folder icon closed Folder open iconModèles contractuels
    • Marchand standard
    • Marchand Partenaire
      • Déclaration MOBSP (Orias)
    • Marchand Mandataire
      • Déclaration Agent PSP (ACPR)
      • Déclaration Distributeur ME (ACPR)
  • Folder icon closed Folder open iconTarifs
    • Offres commerciales
    • Frais d'interchange et réseaux cartes
    • Forfaits d'accompagnement
  • Folder icon closed Folder open iconLogos et visuels
    • Logos CentralPay
    • Logos PaySecure
    • Visuels de réassurance (FR/EN)
  • Folder icon closed Folder open iconTrust Center
    • Conformité et résilience opérationnelleDORA
      • FAQ – Conformité et résilienceDORA
    • Protection des données personnellesRGPD
      • FAQ – Protection des données personnellesRGPD

Conformité et résilience opérationnelle

Estimated reading: 14 minutes

Dernière mise à jour : 30 juin 2025

« Notre engagement pour protéger vos transactions et assurer un service sans interruption. Un dispositif aligné sur les exigences européennes en matière de sécurité et de continuité des services financiers »

1. Gouvernance et organisation de la sécurité

Chez CentralPay, la sécurité n’est pas seulement un ensemble de règles techniques, mais une démarche de gouvernance intégrée à tous les niveaux de l’entreprise. Notre dispositif repose sur une organisation claire, des responsabilités définies et une supervision régulière par la direction.

La politique de sécurité constitue le socle de ce dispositif. Elle fixe les principes directeurs en matière de protection des données et de continuité des services. Mise à jour chaque année, elle est validée en comité de direction et diffusée à l’ensemble des collaborateurs concernés. Chaque employé est ainsi sensibilisé aux bonnes pratiques et s’engage à respecter les règles établies.

La gouvernance TIC est structurée autour de plusieurs acteurs clés. Le Responsable de la Sécurité des Systèmes d’Information (RSSI) pilote la stratégie globale, supervise les contrôles de sécurité et veille à la conformité avec les standards internationaux (PCI DSS, DORA). La direction technique est en charge de l’exploitation quotidienne des infrastructures et garantit la disponibilité des systèmes critiques. Enfin, un Comité TIC se réunit régulièrement afin d’analyser les incidents, de valider les évolutions techniques et budgétaires, et d’assurer une amélioration continue de la sécurité.

Cette organisation permet de concilier réactivité opérationnelle et exigence réglementaire. Elle offre également à nos clients une visibilité claire : la sécurité est suivie, pilotée et contrôlée de manière documentée, avec un partage des responsabilités entre le management, les équipes techniques et la direction générale.

2. Gestion des accès et habilitations

La gestion des accès constitue l’un des piliers de la sécurité de CentralPay. Chaque droit d’accès est attribué selon une procédure formalisée et validée par le management, afin de s’assurer qu’il corresponde strictement aux besoins métier du collaborateur. À l’arrivée d’un nouvel employé, ses accès sont créés dans l’Active Directory et validés par son supérieur hiérarchique ; au départ, ils sont immédiatement révoqués par le service informatique.

La sécurité repose également sur le principe du moindre privilège : nul ne peut accéder à plus de ressources que ce qui est strictement nécessaire à sa mission. Les accès sensibles, comme ceux aux systèmes critiques ou aux bases de données, font systématiquement l’objet d’une authentification multi-facteurs (MFA). Pour renforcer ce dispositif, des revues périodiques des habilitations sont menées chaque trimestre, permettant d’identifier et de corriger toute anomalie.

Cette rigueur garantit une maîtrise complète des identités et des droits, et protège nos clients contre tout risque d’accès non autorisé à leurs données.

3. Sécurité technique

La sécurité technique de CentralPay repose sur une architecture conçue selon les principes de défense en profondeur. Chaque couche – du réseau jusqu’aux applications – bénéficie de mécanismes de protection redondants et régulièrement testés.

Cloisonnement des réseaux

L’infrastructure est segmentée en plusieurs zones :

  • DMZ publique pour les serveurs exposés à Internet (reverse proxy, WAF, relais SMTP) ;
  • zone interne pour les bases de données et services sensibles ;
  • réseau administratif réservé aux opérations d’administration ;
  • zone de logs isolée pour la collecte et l’analyse des journaux.

Les flux entre ces zones sont strictement contrôlés par des firewalls en redondance, configurés en stateful inspection et avec des règles de NAT. Ces firewalls intègrent des mécanismes d’anti-spoofing et de détection d’anomalies de trafic. Les configurations sont maintenues par le groupe « administrateurs systèmes et réseau » et font l’objet d’une revue périodique.

Protection physique et logique

L’accès aux locaux de production est contrôlé par badge nominatif, surveillance vidéo et télésurveillance (SECURITAS). L’accès aux salles serveurs et à la zone PCI est limité aux personnes habilitées.
Sur le plan logique, chaque accès aux systèmes se fait par identifiant unique, renforcé par MFA. Les droits sont attribués en fonction des rôles définis et selon le principe du moindre privilège.

Surveillance et détection d’intrusion

La surveillance est assurée en continu grâce à une combinaison d’outils :

  • Zabbix, pour le monitoring temps réel des serveurs, applications et flux critiques ;
  • Wazuh, intégré avec Snort, pour la détection d’intrusions et la corrélation des événements ;
  • ElasticSearch/Kibana, pour l’agrégation et la visualisation des logs.

Les alertes critiques sont transmises en temps réel aux équipes techniques par mail et SMS, et leur traitement est tracé dans un registre d’incidents.

Chiffrement et gestion des clés

Les données de paiement sensibles (PAN, dates d’expiration) sont chiffrées en AES-256 et rendues illisibles via un hash SHA-512 avec salt pour les comparaisons.
La gestion des clés est réalisée exclusivement au sein de modules matériels de sécurité (HSM) certifiés. La clé maîtresse est fragmentée en plusieurs composantes, détenues par des personnes distinctes, afin d’éviter tout risque de compromission. Les clés applicatives ne peuvent pas être exportées en clair et leur usage est strictement tracé.

En combinant ces mesures, CentralPay garantit un environnement technique robuste, conforme aux exigences PCI DSS 4.0.1 et aux standards de résilience DORA.

4. Gestion des risques et des incidents

La maîtrise des risques constitue un axe stratégique de la gouvernance CentralPay. L’approche adoptée vise à anticiper les menaces, limiter leur probabilité de survenance et garantir une réponse rapide et efficace en cas d’incident.

Gestion des risques

Chaque année, une étude de risques est menée sur la base de la méthodologie Ebios, intégrant :

  • l’identification des risques liés à la sécurité (intrusions, attaques malveillantes, fuites de données) et au fonctionnement (pannes techniques, défaillances logicielles) ;
  • leur analyse en termes de probabilité et d’impact métier ;
  • leur classification en Low, Medium ou High ;
  • leur traitement via des mesures de prévention (patching, segmentation réseau, chiffrement, supervision) ou de mitigation (plans de contournement, redondances).

Le registre des risques est mis à jour en continu et présenté lors des revues annuelles de direction.

Gestion des incidents

CentralPay a mis en place une procédure complète de gestion des incidents, alignée sur les obligations DORA et les orientations de l’EBA :

  • Détection : par monitoring automatisé (Zabbix, Wazuh) ou par signalement interne/externe (clients, partenaires).
  • Qualification : chaque incident est analysé et classé selon son impact, sa durée, sa portée géographique et sa criticité.
  • Priorisation : une matrice d’évaluation (urgence de résolution et impact financier) permet de définir des niveaux de priorité allant de 1 à 4.
  • Notification réglementaire : les incidents qualifiés comme « majeurs » font l’objet d’un reporting à l’ACPR :
    • rapport initial transmis dans les 4 heures,
    • rapport intermédiaire sous 3 jours ouvrés,
    • rapport final sous 20 jours.

Transparence et retour d’expérience

En parallèle du reporting réglementaire, les incidents majeurs font l’objet d’une communication transparente envers les clients impactés. Une analyse post-mortem est systématiquement menée afin de tirer les enseignements, renforcer les procédures existantes et mettre en place des actions correctives.

Ce dispositif permet à CentralPay non seulement de répondre efficacement aux incidents, mais surtout de renforcer continuellement sa résilience et la confiance de ses clients.

5. Tests de résilience

CentralPay considère que la résilience d’une infrastructure ne se prouve pas uniquement sur le papier mais par des tests réguliers et documentés. C’est pourquoi la plateforme organise différents scénarios de test visant à mesurer son niveau de sécurité, sa capacité de reprise et la réactivité de ses équipes.

Tests d’intrusion

Les tests d’intrusion sont réalisés de manière récurrente par des équipes internes et par des prestataires spécialisés, afin de bénéficier d’un regard externe indépendant. Trois méthodologies sont appliquées :

  • Black-box : l’auditeur ne dispose d’aucune information préalable, ce qui simule le comportement d’un attaquant externe ;
  • Grey-box : l’auditeur dispose d’informations partielles (comptes utilisateurs limités, schémas d’architecture simplifiés) afin de reproduire un scénario réaliste d’utilisateur malveillant ;
  • White-box : l’auditeur dispose d’une connaissance complète de l’architecture, permettant une analyse approfondie et la détection de vulnérabilités complexes.

Ces tests couvrent à la fois les couches réseau et applicatives, avec un focus particulier sur les vulnérabilités répertoriées par le Top Ten OWASP. Les résultats font l’objet de rapports détaillés, comprenant une classification des failles selon leur criticité (Critical, High, Medium, Low) et des recommandations de remédiation.

Tests de segmentation réseau

CentralPay réalise aussi des tests de segmentation afin de vérifier que les cloisonnements logiques entre les zones (DMZ, interne, administration, logs) sont efficaces et qu’aucun flux non autorisé n’est possible. Ces tests garantissent que, même en cas de compromission d’une zone exposée, l’attaquant ne puisse pas atteindre les systèmes critiques.

Exercices de simulation et bascules PCA

En parallèle des tests techniques, des exercices de simulation de crise sont menés. Ces exercices impliquent plusieurs équipes (techniques, conformité, direction) et simulent des scénarios d’attaque ou de panne majeure. L’objectif est de tester non seulement la robustesse de l’infrastructure, mais aussi la qualité de la coordination et de la communication en situation de crise.

Enfin, des tests de bascule PCA sont organisés au minimum une fois par an. Ils permettent de vérifier que les services critiques peuvent être transférés vers le site secondaire dans les délais prévus et que les équipes maîtrisent parfaitement les procédures de reprise.

Ces différents tests, documentés et suivis, démontrent la volonté de CentralPay de s’inscrire dans une démarche d’amélioration continue de sa résilience.

6. Haute disponibilité et PCA

La disponibilité des services de paiement est une exigence absolue pour CentralPay. Afin de garantir une continuité sans faille, l’entreprise a conçu son architecture autour du principe de haute disponibilité (HA) et d’un Plan de Continuité d’Activité (PCA) multi-sites.

Architecture multi-sites

CentralPay dispose de deux sites distincts : un site de production principal et un site secondaire dédié au PCA. Ces sites sont opérés par des fournisseurs différents, intègrent un routage BGP et utilisent des accès Internet fournis par plusieurs opérateurs, ce qui réduit le risque de dépendance vis-à-vis d’un seul acteur.

Redondance des composants

Chaque composant critique est déployé en redondance :

  • Firewalls et load balancers : configurés en actif/actif ou actif/passif, permettant une bascule automatique en cas de défaillance ;
  • Serveurs applicatifs : répartis sur plusieurs nœuds afin de garantir la tolérance aux pannes ;
  • Bases de données : répliquées en temps réel entre les sites de production et de PCA, assurant un RPO quasi nul ;
  • Proxys applicatifs et WAF : disposés en frontal pour absorber les charges et filtrer les menaces, avec bascule automatique.

Objectifs de reprise (RTO et RPO)

  • RPO (Recovery Point Objective) : grâce à la réplication continue, les données critiques peuvent être restaurées à l’état quasi instantané précédant l’incident ;
  • RTO (Recovery Time Objective) : les mécanismes de bascule automatique permettent un retour en service des applications critiques en quelques minutes à une heure maximum selon le type de composant.

Scénarios de bascule et tests

Le PCA est conçu pour répondre à divers scénarios : panne matérielle, défaillance réseau, indisponibilité d’un datacenter, attaque cyber majeure. Chaque scénario dispose d’un plan d’action documenté. Des tests réguliers de bascule confirment que les engagements RTO/RPO sont tenus dans la pratique.

Grâce à ce dispositif, CentralPay assure à ses clients que, même en cas d’incident majeur, leurs transactions de paiement resteront disponibles et sécurisées.

7. Continuité et sauvegardes

La continuité des services de CentralPay ne repose pas uniquement sur la redondance de son infrastructure et le PCA. Elle est également assurée par une politique stricte de sauvegarde et de restauration des données.

Sauvegardes quotidiennes et chiffrées

Les données critiques – qu’il s’agisse des données de paiement ou des données opérationnelles de la plateforme – font l’objet de sauvegardes quotidiennes. Celles-ci sont chiffrées en AES-256, conformément aux standards internationaux, afin de garantir leur confidentialité en cas d’accès non autorisé.

Stockage sécurisé et rotation

Les sauvegardes sont stockées selon une logique de redondance et de rotation :

  • Une copie est conservée sur les serveurs de sauvegarde internes, protégés par des accès restreints ;
  • Une copie est déplacée et conservée dans un coffre-fort sécurisé ;
  • D’autres copies sont externalisées hors site, afin de garantir la disponibilité même en cas de sinistre physique affectant un site.

La rotation régulière des supports assure que les sauvegardes restent fiables et exploitables.

Tests de restauration

La valeur d’une sauvegarde ne se mesure pas uniquement à sa conservation mais aussi à sa capacité à être restaurée. CentralPay procède donc à des tests de restauration réguliers, qui permettent de vérifier non seulement l’intégrité des données sauvegardées mais aussi la rapidité avec laquelle elles peuvent être réinjectées dans le système de production.

Grâce à cette approche, CentralPay garantit que, même en cas d’incident majeur, ses clients ne subiront pas de perte significative de données et pourront reprendre leurs activités sans interruption prolongée.

8. Gestion des prestataires critiques

CentralPay est conscient que la sécurité et la continuité de ses services dépendent également de la solidité de ses partenaires. C’est pourquoi l’entreprise a mis en place une gouvernance stricte autour de la gestion des prestataires critiques, en particulier ceux qui participent directement à l’hébergement, au traitement des données ou aux services de paiement.

Audits et certifications

Chaque année, un audit est conduit auprès de l’hébergeur principal et des prestataires considérés comme critiques. L’objectif est de vérifier la solidité de leurs dispositifs de sécurité, leurs capacités de continuité et leur conformité réglementaire.
Pour les prestataires qui traitent, stockent ou transmettent des données de cartes, CentralPay exige la certification PCI DSS et obtient une attestation de conformité (AOC) actualisée chaque année.

Clauses contractuelles et supervision

Les contrats avec les prestataires critiques incluent des clauses spécifiques DORA, portant notamment sur :

  • les engagements de service (SLA en matière de disponibilité et de performance),
  • les obligations de sécurité,
  • la mise en place d’un PCA/PRA compatible avec celui de CentralPay,
  • la notification immédiate en cas d’incident de sécurité.

CentralPay conserve une cartographie actualisée de l’ensemble de ses prestataires critiques et de leurs services associés. Ce registre est régulièrement mis à jour et constitue une base de reporting vers l’ACPR et les autorités de supervision.

Pérennité et amélioration continue

Enfin, la relation avec les prestataires ne se limite pas à un contrôle ponctuel. Les résultats des audits, les tests de continuité et les incidents éventuels sont présentés en comité de gouvernance. Des plans d’action sont ensuite décidés pour renforcer la sécurité ou la disponibilité des services externalisés.

Ainsi, CentralPay garantit à ses clients que les tiers qui contribuent à ses services critiques sont soumis au même niveau d’exigence que ses propres équipes.

Accédez aux pages détaillées de cette section en cliquant sur les liens ci-dessous.

  • FAQ – Conformité et résilience
Conformité et résilience opérationnelle - Previous Trust Center Next - Conformité et résilience opérationnelle FAQ – Conformité et résilience

Pages récemment consultées

  • FAQ – Conformité et résilience
  • Protection des données personnelles
  • Voir plus
CONTENU