Introduction
DORA Article 28 requires financial entities to manage risks arising from ICT third-party service providers.
In modern software delivery, these providers are not peripheral — they are embedded directly into CI/CD pipelines and cloud runtime environments.
This article presents a practical architecture view of DORA Article 28, showing:
- where third-party providers intervene across the CI/CD lifecycle,
- which controls must be applied to remain compliant,
- and how evidence must be produced to satisfy auditors.
The objective is not to describe tools, but to clarify control boundaries, enforcement points, and audit expectations.
The Real CI/CD Supply Chain Under DORA
A typical enterprise CI/CD pipeline relies on multiple external ICT providers, often without being explicitly treated as such.
Under DORA Article 28, the following components must be considered ICT third-party services:
- Source code hosting platforms
- CI/CD orchestration services
- Artifact registries and dependency ecosystems
- Cloud runtime and managed infrastructure services
Each of these components can impact software integrity, availability, confidentiality, and operational resilience.
Where Third-Party Providers Intervene
Git Hosting Platforms
Source code hosting platforms are a critical control point in the delivery lifecycle.
They provide:
- access to source code,
- change management workflows,
- identity and permission enforcement.
From a DORA perspective, Git platforms:
- influence code integrity,
- enforce (or bypass) segregation of duties,
- generate key audit evidence (approvals, commits, access logs).
They must therefore be governed as ICT third-party providers, not just developer tools.
CI/CD SaaS Platforms
CI/CD orchestration platforms automate build, test, and deployment workflows.
They often execute code with elevated privileges and access to sensitive assets.
Under Article 28, CI/CD SaaS platforms:
- represent a high-impact third-party dependency,
- must be subject to strict access control,
- must enforce policy consistently across pipelines.
Failure or compromise of these platforms can directly lead to software supply chain incidents.
Artifact Registries and Dependency Ecosystems
Artifact repositories and dependency registries introduce external code and artifacts into production systems.
They are responsible for:
- storing build outputs,
- distributing dependencies,
- enforcing integrity and immutability.
From a DORA standpoint, they:
- act as supply chain intermediaries,
- require controls to prevent tampering,
- must support traceability and provenance.
Cloud Runtime and Managed Infrastructure
Cloud providers host:
- runtime environments,
- deployment platforms,
- monitoring and logging systems.
They are critical ICT third-party providers whose availability and security directly affect business services.
Under Article 28, cloud runtime services must be:
- included in supplier inventories,
- governed by contractual safeguards,
- continuously monitored for operational risk.
Controls Required Under DORA Article 28
DORA Article 28 does not prescribe specific technologies.
It requires enforceable controls that reduce third-party risk and generate evidence.
Three control categories are fundamental in CI/CD architectures.
Access Isolation
Access isolation ensures that third-party platforms cannot be misused or over-privileged.
Key principles include:
- role-based access control,
- segregation of duties across development, approval, and deployment,
- least-privilege access for pipelines and automation.
In CI/CD architectures, access isolation applies to:
- Git repositories,
- CI/CD pipelines and runners,
- artifact repositories,
- cloud runtime environments.
Evidence must demonstrate that no single actor or system can bypass controls end-to-end.
Contractual Policy Enforcement
Contracts alone are not sufficient under DORA Article 28.
Policies defined contractually must be enforced technically.
This includes:
- mandatory approvals,
- security gates,
- restricted execution paths,
- audit and inspection capabilities.
CI/CD pipelines are the natural enforcement layer for these policies:
- approvals are enforced before release,
- policy-as-code prevents unauthorized changes,
- third-party platforms operate under defined constraints.
Auditors expect consistency between what contracts require and what systems enforce.
Evidence Collection and Retention
DORA Article 28 is fundamentally evidence-driven.
Controls must produce:
- access logs,
- approval records,
- build and artifact metadata,
- monitoring and incident records.
Evidence must be:
- automatically generated,
- time-stamped,
- protected against tampering,
- retained according to regulatory requirements.
Manual evidence collection shortly before audits is a common red flag.
Architecture Principles for Article 28 Compliance
An effective DORA Article 28 architecture follows these principles:
- Third-party platforms are treated as in-scope ICT providers
- Controls are enforced inside CI/CD pipelines, not externally
- Evidence is generated as a by-product of normal operations
- Exit strategies are supported by architectural choices, not documents alone
This approach aligns governance, engineering, and audit needs.
Relationship with DORA Article 21
Article 21 focuses on internal ICT risk management.
Article 28 extends the same logic to external ICT dependencies.
In practice:
- Article 21 defines what controls must exist,
- Article 28 defines where else they must apply.
A single CI/CD architecture must therefore satisfy both internal and third-party risk requirements.
Key Takeaway
DORA Article 28 compliance is not achieved through vendor questionnaires or contractual statements alone.
It requires:
- explicit identification of third-party dependencies,
- enforceable controls embedded in CI/CD pipelines,
- continuous evidence generation.
A well-designed CI/CD architecture transforms third-party risk management from a periodic exercise into continuous, auditable control.
Related Content
- DORA Article 28 Evidence Pack — What to Show Auditors
- DORA Article 28 — Tools → Controls → Evidence Mapping
- DORA Article 28 — Auditor Checklist (Yes / No / Evidence)
- Continuous Compliance via CI/CD Pipelines
- DORA Article 28 — Architecture Explained
