Introduction
DORA Article 28 exige des entités financières réglementées qu’elles démontrent un contrôle efficace des risques tiers ICT.
Cette obligation va bien au-delà des questionnaires fournisseurs ou des déclarations contractuelles. Les auditeurs n’évaluent pas l’intention — ils évaluent les preuves.
Cet article fournit un pack de preuves pratique pour DORA Article 28, se concentrant sur ce que les auditeurs demandent généralement, d’où les preuves doivent provenir, et comment les systèmes CI/CD et de livraison cloud doivent soutenir la gestion des risques tiers ICT.
Il comble l’écart entre deux perspectives complémentaires :
- Les auditeurs pensent en termes d’objectifs de contrôle, de preuves et de responsabilité.
- Les ingénieurs pensent en termes de systèmes, pipelines, configurations et automatisation.
Les deux vues sont valides — mais elles ne sont pas interchangeables. Cet article montre ce que les auditeurs cherchent réellement à vérifier, comment les ingénieurs doivent implémenter les contrôles pour satisfaire ces attentes, et où les malentendus surviennent généralement.
Ce que les audits Article 28 vérifient réellement
Du point de vue de l’audit, l’Article 28 répond à quatre questions fondamentales :
- Savez-vous de quels tiers ICT vous dépendez ?
- Les obligations contractuelles sont-elles applicables en pratique ?
- Pouvez-vous surveiller continuellement les risques tiers ?
- Pouvez-vous sortir en toute sécurité si un fournisseur défaille ou devient non conforme ?
Les preuves doivent être opérationnelles, traçables et vérifiables — pas uniquement documentaires.
Comment les auditeurs abordent une revue Article 28
Les auditeurs ne commencent pas par les outils ou les diagrammes d’architecture. Ils commencent par des questions de risque :
- Les fournisseurs ICT tiers introduisent-ils un risque opérationnel non géré ?
- Les contrôles sont-ils applicables au-delà des systèmes internes ?
- L’organisation peut-elle démontrer une supervision continue ?
- Les preuves sont-elles objectives et temporellement bornées ?
Les preuves sont évaluées comme preuve de contrôle opérationnel, pas comme confirmation de politique.
| Perspective | Focus |
|---|---|
| Vue auditeur | Cette organisation peut-elle démontrer un contrôle efficace du risque tiers ICT ? |
| Vue ingénieur | Comment appliquer et générer des preuves via les systèmes CI/CD et cloud ? |
Vue d’ensemble du pack de preuves
Un pack de preuves DORA Article 28 couvre généralement cinq domaines de preuves :
- Inventaire des fournisseurs et criticité
- Contrôles contractuels et droits d’audit
- Application des contrôles CI/CD et cloud
- Preuves de surveillance et d’incidents
- Preuves de stratégie de sortie et de résilience
Each domain below explains what auditors expect, what evidence to show, and where it should come from — from both the Vue auditeur and the Vue ingénieur.
1. Supplier Inventory & Criticality
What auditors expect
Auditors want proof that you have:
- identified all ICT third-party providers,
- classified them by criticality,
- linked them to business services and delivery pipelines.
They expect inclusion of CI/CD SaaS platforms (not just traditional vendors), visibility into cloud services, registries, and code hosting, and linkage between suppliers and actual systems in use.
Evidence to provide
- Centralized ICT supplier inventory
- Criticality classification (critical / important / non-critical)
- Mapping between suppliers, CI/CD tooling, and cloud runtime components
Typical evidence artifacts
- Supplier inventory register (exportable)
- Risk classification methodology
- Mapping table: Supplier → CI/CD / Cloud component
Auditor View
Auditors ask:
- Do you have a complete inventory of ICT third-party providers?
- Are providers classified by criticality?
- Is this classification tied to business services and delivery systems?
What they verify: inventory completeness, consistency with actual systems in use, and traceability to risk management decisions.
Engineer View
Engineers must ensure:
- CI/CD platforms, Git hosting, registries, runners, cloud services are explicitly registered as suppliers,
- supplier metadata (criticality, owner, usage) is kept in sync with real usage,
- pipelines reference approved suppliers only.
Typical implementation:
- CMDB or supplier registry linked to CI/CD tooling,
- automated checks preventing unapproved services,
- documentation generated from live configurations.
2. Contrôles contractuels et droits d’audit
What auditors expect
Contracts must enable control, not just describe it. Auditors look for enforceable clauses covering:
- audit rights,
- incident notification timelines,
- evidence retention,
- subcontractor transparency,
- exit and transition obligations.
More importantly, they verify that these clauses are operationally enforceable.
« You have audit rights in the contract — how do you exercise them in practice? »
Evidence to provide
- Contract excerpts showing audit rights, monitoring access, and incident notification clauses
- Proof contracts apply to actual providers in use
Typical evidence artifacts
- Contract clause extracts
- Supplier contract register
- Legal review notes linking clauses to Article 28 requirements
Auditor View
Auditors look for:
- enforceable audit rights,
- incident notification obligations,
- evidence retention commitments,
- visibility over subprocessors,
- defined exit clauses.
They do not assume contracts are effective just because they exist.
Engineer View
Engineers must:
- know which contractual obligations impact technical controls,
- ensure platforms can actually produce the required evidence,
- support audits without ad-hoc data collection.
Typical implementation:
- mapping contract clauses → technical controls,
- ensuring logs, SBOMs, approvals are retained long enough,
- making audit access technically possible (read-only, scoped).
3. CI/CD & Cloud Control Enforcement
What auditors expect
Auditors verify that third-party tooling is controlled in practice, not trusted blindly. This includes source code hosting platforms, CI/CD orchestration services, runners and execution environments, and artifact registries and dependency ecosystems.
Evidence to provide
- Access control configuration (IAM, roles, SoD)
- Branch protection and approval rules
- Build isolation and runner governance
- Artifact integrity (SBOM, signing)
Typical evidence artifacts
- CI/CD platform configuration screenshots or exports
- Pipeline policy definitions (Policy as Code)
- SBOM and artifact signing reports
- Access logs from Git / CI/CD platforms
Auditor View
Auditors want proof that:
- access is controlled and segregated,
- approvals are enforced,
- artifacts are protected against tampering,
- third-party tooling does not bypass internal controls.
They test whether controls are systematic, not manual.
Engineer View
Engineers implement:
- IAM, role separation, branch protections,
- pipeline approvals and policy gates,
- SBOM generation and artifact signing,
- runner isolation and token scoping.
Key mindset shift:
« Secure by default » is not enough — controls must be provable.
4. Monitoring & Incident Management
What auditors expect
DORA requires continuous monitoring, not periodic checks. Auditors verify that third-party services are monitored, incidents are detected, and evidence is retained and traceable.
They look for:
- live or historical monitoring data,
- alerts tied to third-party services,
- visibility into CI/CD platform availability and integrity.
Monitoring evidence must demonstrate that third-party degradation would be detected and incidents would be escalated within defined timelines. Static risk assessments alone are insufficient.
Evidence to provide
- Monitoring dashboards (availability, integrity signals)
- Incident logs involving third-party services
- Evidence of incident escalation and notification
Typical evidence artifacts
- Logs and metrics from CI/CD and cloud platforms
- Incident tickets referencing third-party providers
- SIEM or observability integration evidence
Auditor View
Auditors assess whether:
- third-party services are continuously monitored,
- incidents involving suppliers are detectable,
- incident handling is documented and traceable.
They reject annual risk assessments without operational monitoring.
Engineer View
Engineers ensure:
- CI/CD platforms, registries, and cloud runtimes emit logs,
- monitoring feeds SIEM or centralized logging,
- incidents reference affected third-party providers.
Typical implementation:
- observability pipelines,
- incident tickets linked to logs and metrics,
- alerting on supplier degradation or failure.
Incident Notification SLAs: Tested in Reality
Auditors verify that:
- incident notification SLAs exist contractually,
- internal processes can receive and act on notifications,
- timelines are realistic and tested.
They often request past incident examples, timestamps showing notification delays, and evidence of escalation and response. An SLA that has never been exercised is treated as unproven.
5. Exit Strategy & Resilience
What auditors expect
Exit strategies must be realistic and tested. Auditors will challenge whether exit plans exist, whether they apply to critical providers, and whether they have ever been tested.
Evidence to provide
- Documented exit strategies per critical provider
- Evidence of exit or fallback testing
- DR / BCP test results involving third-party dependencies
Typical evidence artifacts
- Exit plans and transition procedures
- Test reports or tabletop exercise outputs
- Dependency replacement or fallback documentation
Auditor View
Auditors ask:
- Do exit strategies exist for critical suppliers?
- Have they been tested?
- Could you realistically exit under pressure?
A PDF exit plan alone is insufficient.
Engineer View
Engineers support exit strategies by:
- avoiding hard vendor lock-in,
- documenting replacement or fallback paths,
- participating in DR and exit tests.
Typical implementation:
- artifact portability,
- infrastructure-as-code reproducibility,
- tested backup and restore procedures.
Evidence Quality: How Auditors Judge Credibility
Auditors assess evidence against four implicit criteria:
- Objectivity – system-generated, not manually edited
- Traceability – linked to a specific supplier or control
- Continuity – produced consistently over time
- Integrity – protected against alteration
Evidence failing any of these criteria weakens the entire pack. Manual spreadsheets alone rarely meet these criteria.
Common Article 28 Audit Findings (Red Flags)
Auditors frequently raise findings when they see:
- supplier inventories not linked to CI/CD tooling,
- contracts without operational enforcement,
- monitoring limited to annual reviews,
- no proof of subcontractor visibility,
- exit plans that were never tested.
| Situation | Auditor Reaction |
|---|---|
| « We trust this SaaS provider » | ❌ Not acceptable |
| Evidence collected manually before audit | ⚠️ Weak control |
| Logs exist but are not retained | ❌ Non-compliant |
| Exit plan never tested | ❌ High-risk finding |
From audit experience, evidence packs often fail because:
- CI/CD SaaS platforms are excluded from supplier scope
- Evidence exists but cannot be linked to a control
- Logs are available but not retained long enough
- Incident SLAs exist but were never tested
- Exit strategies are documented but unsupported by technical reality
These issues usually surface during the audit, not during preparation. Designing evidence into pipelines avoids these gaps.
How CI/CD Architecture Enables Article 28 Compliance
Modern Article 28 compliance depends heavily on CI/CD and cloud architecture:
- pipelines enforce access and approvals,
- SBOMs provide supply chain transparency,
- logs and audit trails generate evidence automatically,
- monitoring systems detect third-party failures.
Without CI/CD-level evidence, Article 28 compliance remains fragile.
Designing for Both Views
The most mature organizations:
- design controls once,
- satisfy both audit and engineering needs,
- generate evidence continuously via CI/CD and cloud platforms.
This is the foundation of continuous compliance under DORA.
Final Takeaway
DORA Article 28 is not a documentation exercise — it is an operational control problem.
The strongest evidence packs:
- integrate CI/CD, cloud, and vendor governance,
- generate evidence continuously,
- align architecture, contracts, and monitoring.
If auditors can verify controls without relying on explanations, your Article 28 posture is solid.
Recommended Related Reading
- DORA Article 28 Architecture — Explained
- Conformité continue via les pipelines CI/CD
- CI/CD Audit Red Flags
