Introduction
DORA Article 28 requires regulated financial entities to demonstrate effective control over ICT third-party risks.
This obligation goes far beyond vendor questionnaires or contractual statements.
Auditors do not assess intent — they assess evidence.
This article provides a practical evidence pack for DORA Article 28, focusing on what auditors typically ask for, where evidence should come from, and how CI/CD and cloud delivery systems must support third-party ICT risk management.
What Article 28 Audits Are Really About
From an audit perspective, Article 28 answers four fundamental questions:
- Do you know which ICT third parties you rely on?
- Are contractual obligations enforceable in practice?
- Can you continuously monitor third-party risks?
- Can you exit safely if a provider fails or becomes non-compliant?
Evidence must be operational, traceable, and verifiable — not policy-only.
Evidence Pack Overview
A DORA Article 28 evidence pack typically spans five evidence domains:
- Supplier inventory & criticality
- Contractual controls & audit rights
- CI/CD and cloud control enforcement
- Monitoring & incident evidence
- Exit strategy & resilience evidence
Each domain below explains:
- what auditors expect,
- what evidence to show,
- where it should come from.
1. Supplier Inventory & Criticality Evidence
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.
Evidence to provide
- Centralized ICT supplier inventory
- Criticality classification (critical / important / non-critical)
- Mapping between:
- suppliers,
- CI/CD tooling,
- cloud runtime components
Typical evidence artifacts
- Supplier inventory register (exportable)
- Risk classification methodology
- Mapping table: Supplier → CI/CD / Cloud component
2. Contractual Controls & Audit Rights
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.
Evidence to provide
- Contract excerpts showing:
- audit rights,
- monitoring access,
- 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
3. CI/CD & Cloud Control Enforcement Evidence
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,
- 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
4. Monitoring & Incident Evidence
What auditors expect
DORA requires continuous monitoring, not periodic checks.
Auditors verify that:
- third-party services are monitored,
- incidents are detected,
- evidence is retained and traceable.
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
5. Exit Strategy & Resilience Evidence
What auditors expect
Exit strategies must be realistic and tested.
Auditors will challenge:
- whether exit plans exist,
- whether they apply to critical providers,
- 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
Evidence Characteristics Auditors Care About
Across all domains, auditors assess evidence against four criteria:
- Traceable → linked to a specific provider or control
- Repeatable → generated consistently by systems
- Time-bound → shows when controls were active
- Tamper-resistant → logs and evidence are protected
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.
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.
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.
Optional Internal Links (recommandé en bas d’article)
- DORA Article 28 Architecture — Explained
- CI/CD Audit Red Flags
- Continuous Compliance via CI/CD Pipelines
