Introduction
Cet article relie les obligations de DORA Article 28 aux contrôles techniques concrets et aux preuves que les auditeurs s’attendent à vérifier. Il fait le pont entre deux perspectives complémentaires :
- De l’outillage aux preuves : comment les outils DevSecOps et CI/CD couramment utilisés en entreprise appliquent les contrôles et produisent des sorties prêtes pour l’audit.
- De la réglementation aux preuves : comment chaque exigence de l’Article 28 se mappe à des contrôles implémentables et des preuves vérifiables.
L’objectif est d’éliminer l’ambiguïté entre le texte réglementaire, l’outillage, la gouvernance et la conformité — et de fournir une référence unique pour la préparation des audits et la conformité continue.
Mapping par obligation de l’Article 28
1. Identification des tiers ICT
Exigence Article 28 : Les entités financières doivent identifier et maintenir un inventaire de tous les prestataires de services ICT tiers.
| Contrôles implémentés | Preuves produites |
|---|---|
| Inventaire centralisé des fournisseurs ICT | Export du registre fournisseurs |
| Enregistrement obligatoire des outils CI/CD, cloud, SaaS | Enregistrements d’inventaire incluant les outils CI/CD |
| Propriété et mapping métier | Mapping fournisseur → service métier |
| Revue périodique de l’inventaire | Comptes rendus / journaux de revue |
2. Classification de criticité
Exigence Article 28 : Les prestataires de services ICT tiers doivent être classés en fonction de leur criticité et du risque.
| Contrôles implémentés | Preuves produites |
|---|---|
| Cadre de classification des fournisseurs basé sur le risque | Méthodologie de classification |
| Identification des fournisseurs ICT critiques | Liste des fournisseurs critiques |
| Outils CI/CD classés lorsqu’ils supportent des services critiques | Mapping CI/CD → services |
| Escalade de gouvernance pour les fournisseurs critiques | Enregistrements du comité des risques |
3. Due diligence pré-contractuelle
Exigence Article 28 : Des évaluations des risques doivent être réalisées avant la conclusion d’arrangements contractuels.
| Contrôles implémentés | Preuves produites |
|---|---|
| Processus de due diligence de sécurité | Rapports de due diligence |
| Évaluation des risques couvrant les risques ICT et opérationnels | Documents d’évaluation des risques |
| Revue de divulgation des sous-traitants | Divulgations fournisseurs |
| Approbation formelle avant onboarding | Enregistrements d’approbation |
4. Garanties contractuelles
Exigence Article 28 : Les contrats doivent inclure des dispositions minimales de sécurité, d’audit et de sortie.
| Contrôles implémentés | Preuves produites |
|---|---|
| Clauses contractuelles standard pour les fournisseurs ICT | Extraits de clauses contractuelles |
| Droits d’audit et d’inspection | Contrats signés |
| SLA de notification d’incident | Documentation SLA |
| Obligations de rétention des preuves | Termes contractuels |
| Clauses de sortie et de résiliation | Dispositions de sortie |
5. Contrôle d’accès & séparation des tâches
Exigence Article 28 : L’accès aux services ICT doit être contrôlé de manière appropriée.
| Contrôles implémentés | Preuves produites |
|---|---|
| Contrôle d’accès basé sur les rôles (RBAC) | Exports de configuration IAM |
| Séparation des tâches dans le CI/CD | Matrice d’accès |
| Surveillance des accès privilégiés | Journaux d’accès |
| Revues d’accès périodiques | Rapports de revue |
6. Contrôles d’application CI/CD
Exigence Article 28 : Les contrôles doivent prévenir les changements non autorisés et assurer l’intégrité.
| Contrôles implémentés | Preuves produites |
|---|---|
| Approbations obligatoires et barrières de politique | Configurations de pipeline |
| Application policy-as-code | Définitions de politiques |
| Runners CI/CD contrôlés | Configuration des runners |
| Protection de l’intégrité des artefacts | SBOM, rapports de signature |
| Traçabilité des changements | Journaux d’audit CI/CD |
7. Surveillance & gestion des incidents
Exigence Article 28 : Les risques ICT tiers doivent être surveillés en continu.
| Contrôles implémentés | Preuves produites |
|---|---|
| Surveillance continue des services ICT | Tableaux de bord de surveillance |
| Alertes sur les défaillances tierces | Journaux d’alertes |
| Suivi des incidents | Tickets d’incident |
| Procédures d’escalade des incidents | Workflows d’incident |
| Revues post-incident | Rapports RCA |
8. Gouvernance des sous-traitants
Exigence Article 28 : Les risques découlant des chaînes de sous-traitance doivent être gérés.
| Contrôles implémentés | Preuves produites |
|---|---|
| Visibilité sur les sous-traitants | Divulgations fournisseurs |
| Processus d’approbation des sous-traitants | Enregistrements d’approbation |
| Évaluations des risques pour les sous-traitants | Rapports de risques |
| Surveillance des changements de sous-traitants | Notifications de changements |
9. Stratégie de sortie & résilience
Exigence Article 28 : Les stratégies de sortie doivent assurer la continuité en cas de défaillance du fournisseur.
| Contrôles implémentés | Preuves produites |
|---|---|
| Stratégies de sortie documentées | Plans de sortie |
| Évaluations de faisabilité | Rapports de faisabilité |
| Tests de sortie ou de repli | Rapports de tests |
| Revue périodique des plans de sortie | Enregistrements de revue |
10. Gestion & rétention des preuves
Exigence Article 28 : Les preuves doivent être disponibles, protégées et conservées.
| Contrôles implémentés | Preuves produites |
|---|---|
| Référentiel centralisé de preuves | Stockage des preuves |
| Journaux horodatés et immuables | Configuration des journaux |
| Politiques de rétention appliquées | Documents de politique de rétention |
| Accès contrôlé aux preuves | Journaux d’accès |
| Production de preuves à la demande | Extraits d’audit |
Mapping par catégorie d’outillage
La section suivante mappe les outils DevSecOps d’entreprise couramment utilisés aux contrôles qu’ils appliquent et aux preuves qu’ils produisent sous DORA Article 28.
1. Gestion du code source (Plateformes Git)
Outils typiques : GitHub Enterprise, GitLab, Bitbucket
| Contrôles appliqués | Preuves produites |
|---|---|
| Contrôle d’accès basé sur les rôles | Journaux d’accès aux dépôts |
| Séparation des tâches (PR vs merge) | Règles de protection des branches |
| Revues et approbations obligatoires | Historique des pull requests |
| Traçabilité des changements | Historique des commits |
| Gouvernance des accès tiers | Journaux d’audit des utilisateurs et tokens |
Pertinence Article 28 : Les plateformes Git sont des prestataires ICT tiers influençant l’intégrité du code.
2. Plateformes d’orchestration CI/CD
Outils typiques : GitHub Actions, GitLab CI, Jenkins (managé), Azure DevOps Pipelines
| Contrôles appliqués | Preuves produites |
|---|---|
| Barrières d’approbation dans le pipeline | Exports de configuration de pipeline |
| Application policy-as-code | Définitions de politiques |
| Environnements d’exécution contrôlés | Configuration des runners |
| Tokens de pipeline à moindre privilège | Configuration de la portée des tokens |
| Journalisation des changements de pipeline | Journaux d’audit CI/CD |
Pertinence Article 28 : Les plateformes CI/CD SaaS doivent être gouvernées en tant que fournisseurs ICT critiques.
3. Sécurité du build & des dépendances (SCA / SBOM)
Outils typiques : Snyk, Dependency-Check, Mend, GitHub Dependabot, Syft / CycloneDX
| Contrôles appliqués | Preuves produites |
|---|---|
| Analyse des risques de dépendances | Rapports SCA |
| Génération de SBOM | Fichiers SBOM |
| Suivi de provenance | Métadonnées de build |
| Surveillance des vulnérabilités | Alertes et rapports |
| Transparence de la chaîne d’approvisionnement | Inventaires de dépendances |
Pertinence Article 28 : Fournit une visibilité sur les risques logiciels tiers et les sous-traitants.
4. Dépôts d’artefacts & registres
Outils typiques : Artifactory, Nexus, registres Docker, registres de conteneurs cloud
| Contrôles appliqués | Preuves produites |
|---|---|
| Contrôle d’accès aux artefacts | Journaux d’accès aux dépôts |
| Immutabilité des artefacts | Configuration du dépôt |
| Signature des artefacts | Vérification des signatures |
| Vérification de provenance | Enregistrements d’attestation |
| Politiques de rétention | Configuration de rétention |
Pertinence Article 28 : Protège l’intégrité des livrables fournis par les systèmes tiers.
5. Plateformes runtime & cloud
Outils typiques : AWS / Azure / GCP, plateformes Kubernetes, services PaaS managés
| Contrôles appliqués | Preuves produites |
|---|---|
| IAM et séparation des rôles | Exports de politiques IAM |
| Isolation réseau | Configurations des groupes de sécurité |
| Surveillance runtime | Journaux et métriques |
| Détection d’incidents | Alertes |
| Surveillance de la disponibilité | Rapports SLA |
Pertinence Article 28 : Les fournisseurs cloud sont des prestataires de services ICT tiers critiques.
6. Gestion des secrets
Outils typiques : HashiCorp Vault, gestionnaires de secrets cloud-natifs, stockage de secrets CI/CD
| Contrôles appliqués | Preuves produites |
|---|---|
| Stockage centralisé des secrets | Inventaire des secrets |
| Restriction d’accès | Journaux d’accès |
| Rotation des secrets | Enregistrements de rotation |
| Prévention des secrets codés en dur | Rapports de scan |
| Auditabilité | Pistes d’accès aux secrets |
Pertinence Article 28 : Contrôle l’accès aux données sensibles gérées par des plateformes tierces.
7. Surveillance, journalisation & SIEM
Outils typiques : Splunk, Elastic, Datadog, journalisation cloud-native
| Contrôles appliqués | Preuves produites |
|---|---|
| Collecte centralisée des journaux | Enregistrements d’ingestion des journaux |
| Surveillance des services tiers | Tableaux de bord |
| Alertes sur les incidents | Journaux d’alertes |
| Corrélation des incidents | Tickets d’incident |
| Rétention des preuves | Politiques de rétention |
Pertinence Article 28 : Supporte les obligations de surveillance continue et de preuves d’incidents.
8. Gestion des identités & des accès (IAM)
Outils typiques : IAM d’entreprise, IAM cloud, plateformes SSO
| Contrôles appliqués | Preuves produites |
|---|---|
| Gestion centralisée des identités | Inventaires utilisateurs |
| Application du MFA | Journaux d’authentification |
| Séparation des rôles | Définitions des rôles |
| Revues d’accès | Enregistrements de revue |
| Révocation d’accès | Journaux de départ |
Pertinence Article 28 : Assure un accès contrôlé aux plateformes ICT tierces.
9. Plateformes de gouvernance & gestion des risques
Outils typiques : Plateformes GRC, CMDB, registres de risques
| Contrôles appliqués | Preuves produites |
|---|---|
| Inventaire des fournisseurs | Registres fournisseurs |
| Évaluations des risques | Rapports de risques |
| Classification de criticité | Enregistrements de classification |
| Propriété des contrôles | Documentation RACI |
| Préparation d’audit | Référentiels de preuves |
Pertinence Article 28 : Fournit la colonne vertébrale de gouvernance pour la gestion des risques ICT tiers.
Vue de bout en bout
Sous DORA Article 28 :
- Les outils ne sont pas synonymes de conformité.
- Les contrôles créent la conformité.
- Les preuves prouvent la conformité.
Les outils ne sont acceptables que s’ils appliquent des contrôles et génèrent des preuves vérifiables.
Comment les auditeurs utilisent ce mapping
Les auditeurs procèdent typiquement ainsi :
- Partir des exigences de l’Article 28 (mapping des obligations).
- Identifier le prestataire ICT tiers et sa catégorie d’outillage.
- Vérifier que les contrôles existent et fonctionnent via l’outillage.
- Demander les sorties de preuves directes pour chaque contrôle.
- Valider la cohérence dans le temps.
Tout lien manquant entre obligation → contrôle → preuve, ou entre outil → contrôle → preuve, est un constat potentiel. Si un contrôle ne peut pas produire de preuve, il est considéré comme inefficace.
Point clé
La conformité à DORA Article 28 est atteinte lorsque chaque exigence réglementaire est traçable vers des contrôles, et que chaque contrôle produit des preuves — indépendamment de l’outillage utilisé.
Ce double mapping (par obligation et par outil) fournit la base pour :
- la préparation d’audit,
- la conformité continue,
- la gouvernance CI/CD dans les environnements réglementés.
Un environnement CI/CD aligné DORA est un environnement où chaque outil tiers est gouverné, chaque contrôle est appliqué techniquement et chaque contrôle produit des preuves automatiquement.
Contenu connexe recommandé
- DORA Article 28 — Pack de preuves (Vues auditeur & ingénieur)
- DORA Article 28 — Checklist auditeur (Oui / Non / Preuve)
- Architecture DORA Article 28 : Contrôles de risques tiers dans les pipelines CI/CD
- Conformité continue via les pipelines CI/CD
