DORA Article 28 — Checklist d'audit (Perspectives ingénieur & auditeur)

Introduction

Cette checklist est conçue pour les revues d’audit formelles de la gestion des risques ICT tiers sous DORA Article 28. Elle s’adresse simultanément à deux audiences :

Les auditeurs l’utilisent pour vérifier les contrôles, évaluer les preuves et identifier les lacunes.
Les ingénieurs l’utilisent pour comprendre ce qui doit être implémenté et où les lacunes courantes surviennent.

Chaque section couvre un domaine spécifique de l’Article 28 avec : la checklist d’audit formelle (Oui / Non / Preuve), les attentes d’implémentation correspondantes pour les ingénieurs, et les lacunes courantes qui apparaissent typiquement lors des audits.

1. Inventaire des tiers ICT

Checklist d’audit

Contrôle	Oui	Non	Preuve
Un inventaire complet des prestataires ICT tiers existe	☐	☐	Registre fournisseurs
Les plateformes CI/CD sont incluses comme prestataires ICT	☐	☐	Extrait de l’inventaire fournisseurs
Les fournisseurs de services cloud sont inclus	☐	☐	Inventaire fournisseurs
Les registres d’artefacts et écosystèmes de paquets sont listés	☐	☐	Correspondance fournisseurs
L’inventaire est revu et mis à jour périodiquement	☐	☐	Enregistrements de revue

Implémentation ingénieur

L’auditeur vérifie	L’ingénieur implémente
Inventaire complet des prestataires ICT tiers	CMDB ou registre fournisseurs incluant CI/CD, Git, cloud, registres
Classification des fournisseurs par criticité	Étiquettes de criticité liées aux systèmes de livraison
Alignement avec les services métier	Correspondance pipelines → services → fournisseurs
Inventaire tenu à jour	Mises à jour automatisées ou pilotées par processus liées à l’utilisation des outils

Lacune courante : Les outils CI/CD SaaS ne sont pas listés comme fournisseurs.

2. Classification de criticité

Checklist d’audit

Contrôle	Oui	Non	Preuve
Les prestataires ICT sont classés par criticité	☐	☐	Méthodologie de classification
Les critères de classification sont documentés	☐	☐	Cadre de risques
Les prestataires critiques sont explicitement identifiés	☐	☐	Liste fournisseurs
Les outils CI/CD prenant en charge des fonctions critiques sont classés en conséquence	☐	☐	Document de correspondance
La classification conditionne les exigences de gouvernance	☐	☐	Correspondance des contrôles

3. Due diligence pré-contractuelle

Checklist d’audit

Contrôle	Oui	Non	Preuve
Une due diligence de sécurité est réalisée avant l’intégration	☐	☐	Rapports de due diligence
L’évaluation des risques couvre les risques ICT et opérationnels	☐	☐	Évaluation des risques
L’utilisation de sous-traitants est évaluée	☐	☐	Divulgations fournisseurs
Les résultats de due diligence sont documentés	☐	☐	Enregistrements de revue
Une approbation est requise avant l’intégration	☐	☐	Workflow d’approbation

4. Garanties contractuelles

Checklist d’audit

Contrôle	Oui	Non	Preuve
Les contrats incluent des exigences de sécurité de l’information	☐	☐	Clauses contractuelles
Les droits d’audit et d’inspection sont définis	☐	☐	Extraits contractuels
Les obligations de notification d’incident sont définies	☐	☐	Clauses SLA
Les exigences de rétention des preuves sont incluses	☐	☐	Termes contractuels
Les clauses de sortie et de résiliation sont définies	☐	☐	Clauses contractuelles

Implémentation ingénieur

L’auditeur vérifie	L’ingénieur implémente
Droits d’audit définis dans les contrats	Plateformes capables d’accès audit en lecture seule
Obligations de notification d’incident	Pipelines de surveillance et d’alerte connectés aux workflows d’incident
Engagements de rétention des preuves	Rétention des journaux et artefacts configurée pour respecter la durée contractuelle
Visibilité sur les sous-traitants	Chaînes de dépendances SaaS documentées

Lacune courante : Les contrats existent mais l’outillage ne peut techniquement pas prendre en charge les audits.

5. Contrôle d’accès & séparation des tâches

Checklist d’audit

Contrôle	Oui	Non	Preuve
L’accès aux plateformes tierces est basé sur les rôles	☐	☐	Configuration IAM
La séparation des tâches est appliquée	☐	☐	Matrice d’accès
L’accès privilégié est restreint et surveillé	☐	☐	Journaux d’accès
Les revues d’accès sont effectuées périodiquement	☐	☐	Enregistrements de revue
La révocation d’accès est documentée	☐	☐	Enregistrements de départ

Implémentation ingénieur

L’auditeur vérifie	L’ingénieur implémente
Séparation des rôles appliquée	Rôles IAM pour dev, approbateur, opérateur
Pas de contrôle de bout en bout par un seul utilisateur	Protection des branches + workflows d’approbation
Revues d’accès effectuées	Revues d’accès périodiques appuyées par les journaux
Moindre privilège appliqué	Portées de tokens, permissions des runners, séparation des environnements

Lacune courante : L’accès admin est partagé entre les rôles CI/CD.

6. Contrôles d’application CI/CD

Checklist d’audit

Contrôle	Oui	Non	Preuve
Les pipelines CI/CD imposent des barrières d’approbation	☐	☐	Configuration du pipeline
Les contrôles de sécurité ne peuvent pas être contournés	☐	☐	Définitions de politiques
Les runners CI/CD tiers sont gouvernés	☐	☐	Configuration des runners
L’intégrité des artefacts est protégée	☐	☐	Rapports SBOM / signature
Les changements de pipeline sont journalisés	☐	☐	Journaux d’audit

Implémentation ingénieur

L’auditeur vérifie	L’ingénieur implémente
Contrôles appliqués automatiquement	Policy-as-code dans les pipelines
Pas de contournement des approbations	Barrières obligatoires pour la livraison et le déploiement
Intégrité des artefacts assurée	Génération de SBOM, signature, vérification
Outils tiers gouvernés	Images de runners approuvées, plugins restreints

Lacune courante : Les contrôles sont appliqués « par convention », pas techniquement.

7. Surveillance & gestion des incidents

Checklist d’audit

Contrôle	Oui	Non	Preuve
Les services tiers sont surveillés en continu	☐	☐	Tableaux de bord de surveillance
Les incidents de sécurité sont détectés	☐	☐	Journaux d’alertes
Les incidents impliquant des prestataires ICT sont suivis	☐	☐	Tickets d’incident
Les délais de notification d’incident sont respectés	☐	☐	Enregistrements d’incident
Les post-mortems sont documentés	☐	☐	Rapports RCA

Implémentation ingénieur

L’auditeur vérifie	L’ingénieur implémente
Surveillance continue des fournisseurs	Journaux CI/CD, registres, cloud collectés
Capacité de détection d’incidents	Alertes liées aux services tiers
Traçabilité des incidents	Tickets liés aux journaux, pipelines, artefacts
Preuves d’incidents passés	Journaux conservés, chronologies, documentation RCA

Lacune courante : Les journaux existent mais ne sont pas centralisés ou conservés.

8. Gouvernance des sous-traitants

Checklist d’audit

Contrôle	Oui	Non	Preuve
La visibilité sur les sous-traitants existe	☐	☐	Divulgations fournisseurs
Les sous-traitants sont approuvés	☐	☐	Enregistrements d’approbation
Les risques des sous-traitants sont évalués	☐	☐	Évaluations des risques
Les changements de sous-traitants sont surveillés	☐	☐	Notifications de changements

Implémentation ingénieur

L’auditeur vérifie	L’ingénieur implémente
Visibilité sur les sous-traitants	Documentation des dépendances SaaS
Connaissance des flux de données	Diagrammes d’architecture montrant les chemins tiers
Connaissance des risques	Évaluation des risques référençant les dépendances réelles

Lacune courante : Sous-traitants « cachés » au sein des plateformes CI/CD.

9. Stratégie de sortie & résilience

Checklist d’audit

Contrôle	Oui	Non	Preuve
Des stratégies de sortie existent pour les fournisseurs critiques	☐	☐	Plans de sortie
Les stratégies de sortie sont documentées	☐	☐	Documentation
La faisabilité de sortie a été évaluée	☐	☐	Rapports d’évaluation
Des tests de sortie ou de repli ont été effectués	☐	☐	Rapports de tests
Les stratégies de sortie sont revues périodiquement	☐	☐	Enregistrements de revue

Implémentation ingénieur

L’auditeur vérifie	L’ingénieur implémente
Stratégie de sortie documentée	Outillage alternatif identifié
Faisabilité de sortie	Portabilité des artefacts, reproductibilité IaC
Preuves de tests de sortie	Tests PRA / sortie exécutés et journalisés
Pas de dépendance mono-fournisseur	Couplage réduit aux fonctionnalités spécifiques SaaS

Lacune courante : Le plan de sortie n’existe que sous forme de document.

10. Gestion & rétention des preuves

Checklist d’audit

Contrôle	Oui	Non	Preuve
Les preuves sont stockées de manière centralisée	☐	☐	Référentiel de preuves
Les preuves sont horodatées et immuables	☐	☐	Configuration des journaux
La rétention des preuves répond aux besoins réglementaires	☐	☐	Politiques de rétention
L’accès aux preuves est contrôlé	☐	☐	Journaux d’accès
Les preuves peuvent être produites sur demande	☐	☐	Extraits d’audit

Implémentation ingénieur

L’auditeur vérifie	L’ingénieur implémente
Les preuves sont objectives	Journaux, approbations, SBOM générés automatiquement
Les preuves sont horodatées	Enregistrements horodatés et immuables
Les preuves sont accessibles	Stockage centralisé, accès contrôlé
Les preuves sont cohérentes	Mêmes contrôles dans tous les environnements

Lacune courante : Les preuves sont collectées manuellement « juste avant l’audit ».

Conclusion de l’auditeur

Évaluation	Résultat
Conformité globale Article 28	☐ Conforme ☐ Partiellement conforme ☐ Non conforme
Constats majeurs identifiés	☐ Oui ☐ Non
Plan de remédiation requis	☐ Oui ☐ Non

Principes clés

Réalité de l’auditeur

Les auditeurs ne valident pas les intentions, les explications ou les supports d’architecture seuls. Ils valident : les contrôles en fonctionnement, les preuves produites par les systèmes et la cohérence dans le temps.

Sous DORA Article 28, l’absence de preuve est une preuve d’absence. Les contrôles doivent être opérationnels, reproductibles et prouvables.

Réalité de l’ingénieur

Les ingénieurs réussissent lorsque : la conformité est intégrée dans le CI/CD, les contrôles génèrent des preuves en continu, et les audits deviennent une vérification — pas une reconstruction.

Contenu connexe recommandé

Contexte “audit-ready”

Contenu conçu pour les environnements réglementés : contrôles avant outils, enforcement par politiques dans le CI/CD, et evidence-by-design pour l’audit.

Focus sur la traçabilité, les approbations, la gouvernance des exceptions et la rétention des preuves de bout en bout.

Voir la méthodologie sur la page About.