Introduction
The Digital Operational Resilience Act (DORA) introduces a comprehensive framework to strengthen the digital resilience of financial entities across the European Union. While much attention is often given to internal ICT risk management under Article 21, Article 28 shifts the focus outward, addressing risks introduced by third-party ICT service providers.
In modern enterprise environments, software delivery relies heavily on external platforms such as cloud providers, CI/CD SaaS tools, source code hosting services, and managed security solutions. DORA Article 28 formally brings these dependencies into scope, requiring organizations to identify, assess, control, and continuously monitor third-party ICT risks.
This article explains what DORA Article 28 really requires, why CI/CD pipelines and DevSecOps tooling are directly impacted, and how organizations should approach compliance in regulated environments.
What DORA Article 28 Covers
DORA Article 28 establishes a structured framework for ICT third-party risk management. Its objective is to ensure that financial entities maintain operational resilience even when critical services are provided by external vendors.
At a high level, Article 28 requires organizations to:
- Identify and maintain an inventory of ICT third-party service providers
- Classify providers based on criticality and risk
- Perform due diligence prior to onboarding
- Define mandatory security and audit clauses in contracts
- Continuously monitor third-party risks
- Manage concentration risk and dependency chains
- Prepare and test exit strategies
Unlike traditional vendor management approaches, DORA Article 28 treats ICT suppliers as integral components of the operational risk landscape, not as peripheral outsourcing concerns.
Why CI/CD and DevSecOps Are Explicitly in Scope
Although DORA does not mention CI/CD or DevSecOps explicitly, Article 28 clearly applies to them in practice.
Modern CI/CD pipelines depend on multiple third-party ICT services, including:
- Source code hosting platforms (e.g. Git hosting SaaS)
- CI/CD orchestration platforms
- Build runners and managed execution environments
- Artifact repositories and container registries
- Dependency management and package ecosystems
- Cloud infrastructure and managed runtime services
Each of these services can impact:
- Code integrity
- Software supply chain security
- Availability of delivery pipelines
- Incident response timelines
- Evidence and auditability
Under Article 28, these platforms must be treated as ICT third-party service providers, and their risks must be governed with the same rigor as internal systems.
ICT Third-Party Classification and Criticality
A key requirement of Article 28 is the classification of ICT third-party providers.
Organizations must assess:
- Whether a provider supports critical or important functions
- The potential impact of provider failure
- The level of substitutability
- Dependency on sub-contractors and fourth parties
In CI/CD contexts, platforms that directly influence code, builds, or deployments are often classified as high-impact or critical ICT providers, even if they are widely used SaaS services.
This classification drives the depth of controls required, including contractual clauses, audit rights, and monitoring obligations.
Contractual and Governance Requirements
Article 28 places strong emphasis on contractual governance.
Contracts with ICT third-party providers must include provisions covering:
- Information security requirements
- Access control and segregation of duties
- Incident notification timelines
- Audit and inspection rights
- Data location and processing constraints
- Business continuity and disaster recovery
- Exit and termination conditions
For CI/CD and DevSecOps tooling, this means contracts must explicitly address:
- Security of build and deployment environments
- Protection against unauthorized code injection
- Evidence retention for audit purposes
- Transparency into subcontractors and shared infrastructure
Continuous Monitoring and Evidence Collection
DORA Article 28 does not allow for “set-and-forget” vendor risk management.
Organizations are expected to:
- Continuously monitor ICT third-party performance and security
- Track incidents involving third-party services
- Maintain auditable evidence of oversight activities
- Reassess risk profiles over time
In CI/CD environments, this typically includes:
- Logs from third-party CI/CD platforms
- Access and activity records
- Artifact integrity evidence (signatures, SBOMs)
- Incident reports involving external services
- Change and approval records tied to vendor-provided tooling
This requirement aligns closely with DevSecOps practices that emphasize automation, traceability, and evidence-driven governance.
Exit Strategies and Concentration Risk
Article 28 explicitly requires organizations to prepare exit strategies for ICT third-party services.
This includes:
- The ability to terminate contracts without unacceptable disruption
- Migration plans to alternative providers
- Controls to avoid excessive concentration risk
In practice, this is one of the most challenging aspects of Article 28 compliance, particularly for CI/CD and cloud platforms where vendor lock-in is common.
Organizations must demonstrate that:
- Critical delivery pipelines are not dependent on a single provider without mitigation
- Exit plans are documented, realistic, and periodically reviewed
- Dependencies on sub-processors are understood and managed
Relationship with DORA Article 21
DORA Article 28 does not stand alone. It extends and complements Article 21.
- Article 21 focuses on internal ICT risk management and controls
- Article 28 applies those principles to external ICT service providers
In regulated DevSecOps environments, this means that:
- Security controls enforced internally must also be enforced through third-party platforms
- Evidence collected from CI/CD pipelines must include third-party tooling
- Governance and accountability must span organizational boundaries
Together, Articles 21 and 28 form a continuous risk management model across the entire digital delivery chain.
Common Article 28 Pitfalls in CI/CD Environments
Organizations frequently struggle with Article 28 due to:
- Treating CI/CD SaaS platforms as “low-risk utilities”
- Lacking visibility into sub-processors used by vendors
- Missing audit rights in standard SaaS contracts
- No defined exit strategy from critical CI/CD tools
- Insufficient evidence retention tied to third-party services
These gaps often surface during regulatory reviews or audits, even in otherwise mature DevSecOps organizations.
What Comes Next
This article provides the conceptual foundation for DORA Article 28. In the next articles in this series, we will explore:
- DORA Article 28 architecture patterns for CI/CD and cloud environments
- An Article 28 evidence pack: what auditors actually expect
- A practical audit checklist for ICT third-party risk
- CI/CD-specific third-party risk scenarios and red flags
Together, these resources provide a practical roadmap for implementing DORA-aligned third-party risk management in modern DevSecOps environments.
