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.
It also bridges the perspective gap between auditors and engineers — two audiences who read the same architecture very differently, and whose alignment is essential for successful compliance.
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 (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:
- the confidentiality and integrity of source code and artifacts,
- the availability of delivery pipelines,
- the traceability and auditability of changes.
Any third-party component involved in building, testing, deploying, or running software is within the scope of Article 28.
Two Perspectives on the Same Architecture
DORA Article 28 requires financial entities to manage ICT third-party risk in a way that is verifiable, enforceable, and auditable. However, auditors and engineers do not read architectures the same way.
Auditor View (Governance & Evidence Lens)
An auditor reviewing DORA Article 28 compliance is not assessing tools or pipelines directly. They are verifying that risk is controlled, documented, and continuously managed.
From an auditor’s perspective, the architecture must answer:
- Do you have a complete inventory of ICT third-party providers?
- Are providers classified by criticality?
- Are contracts enforceable and do they include audit rights, incident notification, and exit clauses?
- Is evidence produced continuously and retained?
- Can you exit critical providers under pressure?
Engineer View (Implementation & Enforcement Lens)
An engineer looking at the same architecture sees a control plane — a set of enforcement mechanisms that must be built, configured, and maintained.
Their focus includes:
- Where are third-party services integrated into pipelines?
- How are access controls, approvals, and isolation enforced technically?
- How are SBOMs, signing, and provenance generated?
- How are logs, metrics, and alerts collected from third-party platforms?
- What happens if a provider fails or must be replaced?
Same Architecture, Two Readings
| Aspect | Auditor View | Engineer View |
|---|---|---|
| Focus | Risk, governance, compliance | Automation, enforcement, reliability |
| Primary question | “Can you prove control?” | “Where do I enforce control?” |
| CI/CD pipeline | Risk surface | Control plane |
| Third-party providers | Suppliers to govern | Platforms to integrate securely |
| Evidence | Explicit requirement | Automatic output |
| Exit strategy | Mandatory | Often overlooked |
DORA Article 28 requires both perspectives to be satisfied simultaneously.
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.
They are not development tools — they are regulated ICT systems.
2. Make Contracts Enforce Controls
Contract clauses must enable (or at least support): audit rights, incident notification, evidence retention, data processing transparency, and exit strategies.
Contracts alone are not sufficient under DORA Article 28. Policies defined contractually must be enforced technically:
- mandatory approvals,
- security gates,
- restricted execution paths,
- audit and inspection capabilities.
CI/CD pipelines are the natural enforcement layer for these policies.
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.
If evidence requires manual assembly during an audit, it is unlikely to meet auditor expectations for objectivity and continuity.
Control Layers Across the CI/CD Lifecycle
Access Control & Isolation
Under DORA Article 28, organizations must demonstrate 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.
Access isolation applies across:
- 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
Policies defined contractually must be enforced technically through CI/CD pipelines:
- approvals are enforced before release,
- policy-as-code prevents unauthorized changes,
- third-party platforms operate under defined, auditable constraints.
Supply Chain Integrity
DORA Article 28 requires visibility into the software supply chain, particularly when third-party components are involved.
This includes:
- dependency tracking and software composition analysis (SCA),
- software bill of materials (SBOM) generation,
- artifact signing and provenance verification,
- container image scanning and integrity checks.
Auditors expect proof that artifacts produced through third-party CI/CD systems have not been tampered with.
Monitoring & Incident Response
Third-party services must be continuously monitored:
- availability and performance indicators,
- incident detection and escalation,
- integration with centralized logging or SIEM.
Auditors verify that monitoring applies to third-party providers, not only to internal systems. Incident workflows must reference affected third-party providers and demonstrate traceable escalation.
Exit Strategy & Continuity
Exit planning is a regulatory requirement under Article 28, not an optional exercise.
Auditors will challenge:
- whether documented exit plans exist for critical providers,
- whether these plans have been tested or exercised,
- whether the organization could realistically transition under pressure.
Engineers support exit strategies by:
- avoiding hard vendor lock-in,
- documenting replacement or fallback paths,
- maintaining infrastructure-as-code reproducibility,
- participating in DR, BCP, and exit tests.
What Auditors Typically Ask For
Under DORA Article 28, auditors expect evidence across five domains:
- Supplier inventory — complete list of ICT third-party providers, classified by criticality, mapped to CI/CD and cloud components
- Contract clauses — audit rights, incident SLAs, evidence retention, subprocessor visibility, exit obligations
- CI/CD control evidence — access logs, approval records, SBOM/provenance, pipeline policy definitions
- Monitoring evidence — dashboards, incident tickets referencing third-party providers, SIEM integration
- Exit strategy evidence — documented exit plans, DR/BCP test results, dependency replacement documentation
Evidence must be:
- 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 Gaps and Misalignment Patterns
Many organizations fail DORA Article 28 reviews not because controls are missing, but because:
- engineers implemented controls without contractual backing,
- evidence exists but is not clearly attributable,
- exit strategies exist only on paper,
- third-party dependencies are implicitly trusted,
- CI/CD SaaS platforms are excluded from supplier scope,
- logs are available but not retained long enough.
By explicitly separating Auditor View and Engineer View, you ensure that:
- every control is backed by a contractual basis,
- every technical enforcement maps to an auditable evidence trail,
- exit readiness is validated, not assumed.
Conclusion
DORA Article 28 architecture is not about listing tools — it is about defining where third-party ICT risk lives, how it is controlled, and how compliance is proven.
The architecture must support both the auditor’s need for evidence and the engineer’s need for enforceable, automated controls. When both views are aligned, Article 28 compliance becomes a structural property of the delivery system — not a periodic exercise.
Related Resources
- DORA Article 28 Evidence Pack (Auditor & Engineer Views)
- DORA Article 28 — Auditor Checklist
- Third-Party Risk in CI/CD Pipelines under DORA Article 28
- Continuous Compliance via CI/CD Pipelines
