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

DORA

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

2 contrôles DORA sur 6 que le code peut prouver, avec v1.4.0, plus 1 en appui

Preuve issue du code pour la protection et la prévention et pour la détection, renforcée par la preuve de gestion des changements dans v1.4.0.

Actif2
Prévu pour v1.4.00
En appui1
Prévu4
Votre organisation20

2 avec preuve issue du code aujourd’huiPreuve partielle, vérifiée à chaque pull request.
1 avec preuve d’appuiToevan enregistre des preuves connexes ; l’obligation reste organisationnelle.
20 restent à votre organisationListés en entier ci-dessous, pour que rien ne soit sous-entendu.

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) et l’Article 10 (détection) à chaque pull request. À partir de v1.4.0, la preuve de gestion des changements pour chaque changement fusionné renforce l’Article 9. 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.

Actif2

Preuve issue du code dès aujourd’hui, scellée à chaque pull request. Toujours partielle : le contrôle exige aussi des éléments hors du code. Preuve issue du code dès aujourd’hui : les règles du blueprint DORA vérifient une partie de ce point à chaque pull request.

Art.9
Protection et prévention
Ch.II Gestion du risque lié aux TIC
Renforcé dans v1.4.0 : preuve de gestion des changements pour chaque changement fusionné.
Art.10
Détection
Ch.II Gestion du risque lié aux TIC

En appui1

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

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

Prévu4

Peut être prouvé à partir du code ou de GitHub. La règle ou la correspondance n’est pas encore construite.

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

Votre organisation20

Politique, personnes, sécurité physique, contrats, procédure réglementaire, exploitation ou audit externe. Votre organisation en apporte la preuve.

Afficher les 20 contrôles

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 (à partir de v1.4.0)
Chaque fusion dans une branche protégée et chaque push direct de 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 pour v1.4.1.
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 sa signature et sa place dans la chaîne, hors ligne.
$ toevan audit verify --path evidence-clone --pub-key toevan.pub

Comment chaque fait a été obtenu

Chaque fait d’un enregistrement et d’un rapport porte l’une de six étiquettes, pour que votre auditeur sache dans quelle mesure s’y fier.

Recalculé: Toevan l’a calculé lui-même à partir du code ou de l’historique git.; Le refaire à partir des mêmes entrées et obtenir le même résultat.
Rapporté + scellé: GitHub l’a rapporté ; Toevan l’a capturé au moment de l’événement et signé.; S’y fier dans la mesure où vous vous fiez à GitHub. Toute modification ultérieure est détectable.
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.; Voir qui a déclaré quoi, quand, et chaque modification ultérieure.
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.; Le considérer comme une déclaration de Toevan et demander à l’organisation l’approbation qui la fonde.
Consommé: Repris de l’enregistrement signé d’un autre système, comme une provenance de build, et relié par commit ou empreinte. Prévu.; Vérifier l’enregistrement d’origine de façon indépendante.
Non capturé: Aucune source fiable n’était disponible. Toevan ne le déduit pas.; L’obtenir auprès de l’organisation par d’autres moyens.

Le voir dans un rapport

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.

Apportez un dépôt et un audit à venir. Nous configurons le blueprint et guidons votre auditeur dans la vérification.