Qu'est-ce que DORA dans l'exploitation IT ?
DORA dans l'exploitation IT désigne la mise en œuvre pratique et continue du règlement européen DORA (Digital Operational Resilience Act) dans le quotidien informatique des entreprises financières. DORA exige avant tout une gestion du risque lié aux TIC traçable : contrôles d'accès vérifiés, mesures de protection documentées et journaux fiables, permettant de prouver à tout moment la résilience opérationnelle numérique, et non de la décrire une seule fois. Les obligations précises, les champs d'application et les exceptions découlent du texte du règlement lui-même et doivent être vérifiés au cas par cas. Pour l'exploitation Zscaler, DORA signifie avant tout : un contrôle vécu et vérifié, plutôt qu'une policy rédigée une fois pour toutes.
DORA dans l'exploitation IT en détail
DORA s'adresse aux entreprises financières et à leurs prestataires tiers critiques de services TIC, avec un cadre unifié pour la résilience opérationnelle numérique : la gestion du risque lié aux TIC, le signalement des incidents majeurs, les tests de résilience et le pilotage des risques liés aux tiers en sont les briques centrales. Pour l'exploitation Zscaler au quotidien, cela signifie tenir les droits d'accès, les règles et la configuration de sécurité de façon à ce qu'ils restent à tout moment exploitables et vérifiables.
La distinction est importante ici aussi : Zscaler fournit des briques techniques telles que la protection contre les menaces, l'application des policies et les logs de transactions et d'événements, mais un programme DORA complet d'une entreprise financière va au-delà, avec ses propres programmes de tests et ses processus de gouvernance. Les exigences sont à mettre en œuvre, selon l'article 4, de façon proportionnée à la taille et au profil de risque ; pour certains petits établissements, le cadre simplifié de l'article 16 s'applique.
Pourquoi DORA compte-t-il dans l'exploitation Zscaler ?
Les entreprises financières sont sous une surveillance prudentielle particulièrement stricte, et DORA exige explicitement que la gestion du risque lié aux TIC soit continue et démontrable, pas seulement sur le papier. Une exploitation Zscaler sans documentation propre et tenue à jour des accès et des modifications devient alors rapidement une faille d'audit.
Le pilotage des prestataires tiers de services TIC joue lui aussi un rôle : toute entreprise financière qui fait appel à des prestataires comme SourcingBlox ou Zscaler lui-même doit tenir compte de leur contribution au risque dans son propre cadre DORA et pouvoir le documenter en conséquence.
Sources d'erreur courantes
- La documentation DORA existe, mais ne reflète pas l'état de configuration réel dans l'exploitation Zscaler.
- La piste d'audit n'est pas tenue sans lacune, notamment lors d'exceptions manuelles.
- Le pilotage des prestataires tiers de services TIC n'est pas relié à l'exploitation opérationnelle.
- La proportionnalité et les exceptions propres à l'établissement ne sont pas suivies en continu.
DORA en pratique : ce qu'apporte CentaurNexus
Compliance Mapping, dans CentaurNexus, relie automatiquement les signaux réels du tenant Zscaler aux contrôles DORA et les regroupe dans un Evidence Pack exportable pour les contrôles internes et les demandes des autorités de surveillance. Policy Health Saga fournit à cet effet un rapport de configuration adapté à DORA avec un plan d'actions priorisé, et l'audit trail, tenu en append-only, atteste chaque modification effectuée via CentaurNexus dans l'exploitation Zscaler. L'état réel de la gestion du risque lié aux TIC peut ainsi être montré à tout moment, au lieu d'être rassemblé seulement au moment du contrôle. Pour en savoir plus sur la vérification systématique de la configuration, consultez le guide Tirer davantage de votre licence Zscaler.
DORA en exploitation : comment le reconnaître
DORA est le plus souvent lu comme un sujet juridique. Dans l'exploitation, la question se pose autrement : non pas « sommes-nous conformes », mais « pouvons-nous le montrer si on nous le demande ». Quatre situations rendent cette différence visible.
« L'auditeur demande qui a modifié la règle. »
Ce que c'est le plus souvent : La question ne vise pas l'outil, mais la traçabilité. Une réponse de mémoire ne compte pas.
Comment le vérifier : Ce qui compte, c'est un historique des modifications qui réunit horodatage, rôle intervenant et état antérieur. Audited Change History est conçu pour cela.
« Nous ne savons pas quel prestataire accède à quoi. »
Ce que c'est le plus souvent : Le point où DORA bascule du papier vers l'exploitation. Le registre des prestataires externalisés ne vaut que ce que vaut l'état d'accès réel.
Comment le vérifier : C'est l'état vécu qui doit être confronté au registre, et non l'inverse. Vendor Session Access rend visibles les accès des prestataires tiers, avec statut et validité.
« La preuve nous coûte à chaque fois des jours. »
Ce que c'est le plus souvent : Un signe que les preuves sont rassemblées après coup au lieu d'être produites en continu.
Comment le vérifier : Compliance Mapping projette en continu les signaux du tenant sur le référentiel de contrôle. L'effort se déplace de la date butoir vers le quotidien.
« Nous avons signalé un incident, mais le délai était déjà serré. »
Ce que c'est le plus souvent : Les délais de signalement courent à partir du moment où l'incident est connu. Qui n'apprend une panne que par le premier appel a déjà perdu le début du délai.
Comment le vérifier : La détection précoce n'est pas ici un confort, mais une protection du délai. Le Watchdog signale les états définis dès qu'ils surviennent, et de même leur résolution.
Dans l'exploitation, DORA pose trois questions : qui a modifié quoi, qui accède depuis l'extérieur, et depuis quand le sait-on. Les trois se construisent en continu, ou pas du tout.
Termes associés
Questions fréquentes sur DORA dans l'exploitation IT
DORA (Digital Operational Resilience Act) s'applique directement dans l'UE depuis le 17 janvier 2025 et vise les entreprises financières, des banques aux assurances en passant par les entreprises d'investissement et les établissements de paiement, ainsi que les prestataires tiers de services TIC. L'article 2 énumère les types d'établissements et les exceptions ; la qualification doit être vérifiée au cas par cas.
Dans le contexte Zscaler, cela signifie avant tout tenir les droits d'accès, les règles et les journaux de façon à pouvoir prouver à tout moment qui peut accéder à quoi, quelles mesures de protection sont actives et comment les incidents sont traités. DORA exige pour cela un processus continu et documenté, plutôt que des mesures ponctuelles.
Non. Zscaler fournit des briques techniques importantes comme la protection contre les menaces et la journalisation, mais DORA exige en plus des éléments organisationnels tels que des programmes de tests, des processus de signalement et le pilotage des prestataires tiers de services TIC, qui vont au-delà d'un seul service de sécurité.
DORA accorde une grande importance à la traçabilité des incidents liés aux TIC et des décisions de gouvernance. Une piste d'audit sans lacune de toutes les modifications pertinentes pour la sécurité dans l'exploitation Zscaler apporte exactement cette traçabilité et appuie aussi bien les contrôles internes que les demandes des autorités de surveillance.
Oui. DORA s'adresse explicitement aussi aux prestataires tiers de services TIC. Les autorités européennes de surveillance (AES) supervisent directement les prestataires critiques ; le classement suit les critères de l'article 31, par exemple l'importance systémique pour les clients et le caractère substituable. Les AES ont publié une première liste de prestataires critiques en novembre 2025 ; le classement doit être vérifié au cas par cas.
- Règlement (UE) 2022/2554 (DORA) - eur-lex.europa.eu
- BaFin : résilience opérationnelle numérique (DORA) - bafin.de
- ABE/AES : désignation des premiers prestataires tiers critiques de services TIC (novembre 2025) - eba.europa.eu
- Portail d'aide Zscaler : documentation officielle sur le reporting et la journalisation - help.zscaler.com
Remarque : CentaurNexus est un produit indépendant de SourcingBlox GmbH et non une offre de Zscaler, Inc. Les noms de produits et de marques appartiennent à leurs détenteurs respectifs. Pour l'état juridique concret de DORA, la version actuelle du règlement et la pratique de surveillance en vigueur font foi.