DORA Article 28 requires regulated organizations to treat ICT third-party providers as part of their operational risk perimeter. In practice, this means your CI/CD and cloud delivery chain must be designed so that:
- third-party services are identified and classified,
- contracts and controls are enforceable,
- risks are monitored continuously,
- and auditors can verify evidence (not statements).
This page provides a practical architecture view: where third-party dependencies sit, which controls apply, and what evidence you should be able to produce.
The real CI/CD supply chain under DORA
Even for “internal” delivery, enterprise pipelines typically rely on external services:
- Source code hosting (Git SaaS / managed Git)
- CI/CD orchestration (SaaS or managed CI platform)
- Runners / build execution (self-hosted or managed runners)
- Artifact & container registries
- Dependency ecosystem (packages, mirrors, SBOM generators)
- Cloud runtime / managed platforms
- Observability (logs, traces, SIEM)
- ITSM / ticketing / approvals tooling (change management)
Article 28 applies because each of these suppliers can affect:
integrity (supply chain), availability (delivery), confidentiality (secrets), and auditability (evidence).
This architecture is intentionally control-driven. It does not describe tools, but responsibilities, enforceable controls, and auditable evidence as expected under DORA Article 28.
Architecture principles for Article 28 compliance
1) Treat third-party tooling as production-grade assets
CI/CD platforms and registries must follow production rules: hardening, access control, logging, monitoring, and tested continuity.
2) Make contracts enforce controls
You need contract clauses that enable (or at least support): audit rights, incident notification, evidence retention, data processing transparency, and exit strategies.
3) Evidence must be designed, not “collected later”
Evidence should be generated by the platform and retained automatically:
logs, approvals, SBOM/provenance, access records, incident timelines, and exit tests.
What auditors typically ask for (Article 28 lens)
Auditors usually want to see:
- a clear supplier inventory (classified by criticality),
- contract excerpts demonstrating required clauses,
- ongoing monitoring (not annual checkboxes),
- evidence of subprocessor visibility,
- and a realistic exit plan (with testing, not just a PDF).
How this architecture maps to concrete controls and evidence
This architecture is the foundation for the following practical guides:
- DORA Article 28 — Auditor Checklist (what will be reviewed)
- DORA Article 28 — Evidence Pack (what to show auditors)
- DORA Article 28 — CI/CD Controls Mapping
- DORA Article 28 — Exit Strategy Testing (DR & BCP)
