Carte des contrôles · Règlement (UE) 2022/2554

DORA

Preuve issue du code pour la protection et la prévention, et preuve de processus issue des déploiements et des releases pour l’Article 9.

Réserver un pilote d’audit Voir un exemple de rapport

DORA · Règlement (UE) 2022/25546 articles dans le périmètre · selon la correspondance de v1.4.1

Code 1
Processus Art.9
Prévu 5

Preuve issue du code

1articles vérifiés à chaque pull request

Actif (processus)

Art.9issue des déploiements et des releases

Prévu

5peut être prouvé à partir du code ou de GitHub ; pas encore construit

Articles au niveau de l’organisation

Politiques, personnes, fournisseurs, sécurité physique et le reste, listés ci-dessous.Toevan apporte une preuve d’appui pour 1 d’entre eux.Gérés par les processus de votre organisation

DORA s’applique aux entités financières de l’UE depuis le 17 janvier 2025. Il demande un cadre de gestion du risque lié aux TIC dont vous pouvez montrer le fonctionnement, y compris une gestion des changements documentée.

Le blueprint DORA apporte une preuve issue du code pour l’Article 9 (protection et prévention) à chaque pull request ; la détection de l’Article 10 est prévue. L’Article 9 a aussi une preuve de processus issue des déploiements et des releases : un déploiement réussi d’un commit en production, une revue de déploiement approuvée avec la séparation des tâches calculée, et le tag d’une release et le commit qu’il désigne. La gouvernance, la notification des incidents, les tests de résilience et le risque lié aux tiers restent à votre processus.

Sur la feuille de route : le RTS sur la gestion du risque lié aux TIC (Règlement délégué (UE) 2024/1774), avec l’Article 17 sur la gestion des changements TIC à partir de la preuve de processus et l’Article 16 à partir de la preuve issue du code. Son édition du catalogue reste à ajouter.

Toevan apporte des preuves pour des contrôles ; il ne les certifie jamais et ne prétend pas qu’un référentiel est couvert. Que les preuves suffisent relève du jugement de votre auditeur.

Preuve issue du code1

Scellée à chaque pull request. Toujours partielle : le contrôle exige aussi des éléments hors du code. Les règles du blueprint DORA vérifient une partie de chacun à chaque pull request.

Art.9Protection et préventionCh.II Gestion du risque lié aux TICPreuve de processus issue des déploiements et des releases : un déploiement réussi d’un commit en production, selon le drapeau de GitHub ou la désignation de l’organisation. Une revue de déploiement approuvée, avec la séparation des tâches calculée. Le tag d’une release et le commit qu’il désigne.

En appui1

Toevan enregistre des preuves connexes, mais l’obligation relève de l’organisation : elle n’est donc jamais comptée comme couverte.

Art.28Principes générauxCh.V Gestion du risque lié aux prestataires tiers de TICPreuve d’appui : une règle enregistre des preuves liées à cette obligation. L’obligation elle-même relève de la politique de l’organisation.

Prévu5

Peut être prouvé à partir du code ou de GitHub. Aucune règle ne les vérifie encore ; chacun est prévu, et aucun ne compte aujourd’hui comme preuve.

Art.7Systèmes, protocoles et outils TICCh.II Gestion du risque lié aux TIC
Art.8IdentificationCh.II Gestion du risque lié aux TIC
Art.10DétectionCh.II Gestion du risque lié aux TIC
Art.12Politiques et procédures de sauvegarde, procédures et méthodes de restauration et de rétablissementCh.II Gestion du risque lié aux TIC
Art.25Tests des outils et systèmes TICCh.IV Tests de résilience opérationnelle numérique

Articles au niveau de l’organisation

Les contrôles au niveau de l’organisation (politiques, personnes, fournisseurs, sécurité physique et le reste) restent dans le processus propre à votre organisation ; Toevan ne s’en charge pas.

Afficher la liste

Ch.II Gestion du risque lié aux TIC

Art.5Gouvernance et organisationde la politique de l’organisation

Art.6Cadre de gestion du risque lié aux TICde la politique de l’organisation

Art.11Réponse et rétablissementd’un processus opérationnel

Art.13Apprentissage et évolutiond’un processus opérationnel

Art.14Communicationd’un processus opérationnel

Art.15Harmonisation accrue des outils, méthodes, processus et politiques de gestion du risque TICd’une procédure réglementaire

Art.16Cadre simplifié de gestion du risque lié aux TICde la politique de l’organisation

Ch.III Gestion, classification et signalement des incidents liés aux TIC

Art.17Processus de gestion des incidents liés aux TICd’un processus opérationnel

Art.18Classification des incidents liés aux TIC et des cybermenacesd’un processus opérationnel

Art.19Signalement des incidents majeurs liés aux TIC et notification volontaire des cybermenaces importantesd’une procédure réglementaire

Art.20Harmonisation du contenu et des modèles de signalementd’une procédure réglementaire

Art.21Centralisation du signalement des incidents majeurs liés aux TICd’une procédure réglementaire

Art.22Retour de la supervisiond’une procédure réglementaire

Art.23Incidents opérationnels ou de sécurité liés aux paiements concernant les établissements de crédit, de paiement, les prestataires de services d’information sur les comptes et les établissements de monnaie électroniqued’une procédure réglementaire

Ch.IV Tests de résilience opérationnelle numérique

Art.24Exigences générales pour les tests de résilience opérationnelle numériquede la politique de l’organisation

Art.26Tests avancés des outils, systèmes et processus TIC fondés sur le TLPTd’une évaluation externe

Art.27Exigences applicables aux testeurs pour la réalisation du TLPTd’une évaluation externe

Ch.V Gestion du risque lié aux prestataires tiers de TIC

Art.29Évaluation préliminaire du risque de concentration TIC au niveau de l’entitéde la politique de l’organisation

Art.30Principales dispositions contractuellesdes contrats et des fournisseurs

Ch.VI Dispositifs de partage d’informations

Art.45Dispositifs de partage d’informations sur les cybermenacesd’une procédure réglementaire

L’utiliser dans un audit

Prenez la population dans les enregistrements de changement
Chaque pull request fusionnée dans la branche par défaut et chaque push vers une branche protégée qu’aucune pull request fusionnée n’explique, sur la période, capturés depuis GitHub au fil de l’eau, forment un enregistrement scellé que vous pouvez exporter pour échantillonner. Vous pouvez refaire la population de la branche par défaut à partir de l’historique git ; les branches de production désignées sont prévues.
Lisez les preuves issues du code pour la période
Chaque pull request porte des résultats de code scellés par rapport aux règles du blueprint, rattachés au commit et à la version du jeu de règles en vigueur.
Testez un échantillon
Pour chaque enregistrement échantillonné, vérifiez ses résultats, puis vérifiez-le hors ligne avec la clé publiée, avec openssl et le shell : récupérez la preuve, confirmez la clé, contrôlez l’enregistrement. Pour rejouer toute la chaîne, Toevan fournit la commande toevan sur demande ; elle n’est pas encore publique.
Les trois étapes, avec les commandes exactes

Comment chaque fait a été obtenu6 étiquettes

Recalculé: Toevan l’a calculé lui-même à partir du code ou de l’historique git.
Rapporté + scellé: GitHub l’a rapporté ; Toevan l’a capturé au moment de l’événement et signé.
Déclaré + scellé: L’organisation l’a déclaré, par exemple un changement de ce qui est vérifié ; Toevan a signé la déclaration et son historique.
Enregistrement Toevan, non scellé: Conservé dans la base de données de Toevan mais non scellé dans le registre, comme une dérogation aujourd’hui. Aucune signature ne le protège.
Consommé: Repris des enregistrements de déploiement et de release de GitHub et relié par commit ou empreinte.
Non capturé: Aucune source fiable n’était disponible. Toevan ne le déduit pas.

L’exemple de rapport de preuves de changement montre les preuves telles que votre auditeur les reçoit, chaque fait étant étiqueté.Ouvrir l’exemple de rapport

Testez la correspondance sur un vrai audit.

Venez avec un dépôt et un audit à venir. Nous configurerons le blueprint et guiderons votre auditeur dans la vérification.

Réserver un pilote d’audit Voir un exemple de rapport

Un dépôt, un référentiel
Des preuves dès la première pull request
Vérifiable sans compte Toevan