Article 21 of the Digital Operational Resilience Act (DORA) defines the core ICT risk management requirements that financial entities must implement, monitor, and continuously evidence. Unlike high-level governance obligations, Article 21 focuses on concrete technical and organizational controls — and for most institutions, the CI/CD pipeline is where a large share of those controls is enforced in practice.
This is the complete, consolidated reference for Article 21 in a CI/CD context. It brings together, in a single audit-ready resource, four things that compliance and assurance teams normally have to piece together separately: a deep dive into each Article 21 requirement, a control-by-control mapping from the regulation to specific CI/CD controls and the evidence they generate, an auditor checklist for internal and supervisory reviews, and an evidence pack describing exactly what artifacts to present and where to find them.
The intended audience is auditors, compliance officers, and GRC professionals preparing for — or conducting — a DORA assessment. Read the deep dive to understand intent, use the mapping to connect requirements to controls, work through the checklist during fieldwork, and assemble the evidence pack to demonstrate that controls are enforced consistently and reproducibly.
Understanding the Scope of DORA Article 21
Article 21 requires financial entities to establish, implement, and maintain a comprehensive ICT risk management framework. This framework must ensure the confidentiality, integrity, availability, and authenticity of ICT systems supporting critical or important functions.
CI/CD pipelines fall within this scope because they directly influence:
- production system behavior
- deployment frequency and stability
- software supply chain integrity
- privileged access to infrastructure and applications
As a result, CI/CD pipelines must be governed and controlled as regulated ICT systems.
Article 21(1): ICT Risk Management Framework and CI/CD
Article 21(1) mandates a structured ICT risk management framework covering identification, protection, prevention, detection, response, and recovery.
CI/CD pipelines support this requirement by:
- identifying risk through automated security testing
- preventing risk via policy enforcement and approval gates
- detecting anomalies through pipeline monitoring
- supporting response via traceable rollback mechanisms
- enabling recovery through controlled deployment processes
Embedding these mechanisms into CI/CD workflows ensures that ICT risk management is operational rather than theoretical.
Article 21(2)(a): Access Control and Privileged Operations
Article 21(2)(a) requires appropriate access control mechanisms to protect ICT systems from unauthorized access.
In CI/CD contexts, this translates into:
- strict separation between human users and pipeline identities
- enforcement of least privilege for CI/CD service accounts
- role-based access control for pipeline configuration
- mandatory MFA for administrators
Failure to secure CI/CD access paths exposes organizations to systemic risk, as pipelines often hold elevated privileges across environments.
Article 21(2)(b): Segregation of Duties and Governance
Article 21 emphasizes segregation of duties to reduce the risk of unauthorized or unreviewed changes.
CI/CD pipelines enforce segregation of duties by:
- requiring independent code review before pipeline execution
- separating build, validation, and deployment permissions
- enforcing approval workflows for sensitive releases
- logging all overrides and exceptions
Automated segregation within pipelines provides stronger guarantees than manual controls.
Article 21(2)(c): Logging, Monitoring, and Detection
Article 21 requires continuous monitoring and detection capabilities to identify ICT-related incidents.
CI/CD pipelines contribute by:
- logging all pipeline executions and configuration changes
- recording security scan results and approval decisions
- emitting alerts on abnormal behavior or failed controls
- integrating with centralized monitoring and SIEM systems
These logs form a critical part of DORA-compliant detection and investigation processes.
Article 21(2)(d): Change Management and System Integrity
Change management is a core component of Article 21. CI/CD pipelines directly implement controlled change processes.
Key enforcement mechanisms include:
- mandatory change approval via pipeline gates
- artifact integrity validation and signing
- traceability between source code, pipeline run, and deployed artifact
- prevention of out-of-band deployments
These controls ensure that only authorized and verified changes reach production systems.
Article 21(2)(e): Resilience, Backup, and Recovery
Operational resilience is a central objective of DORA. CI/CD pipelines must not become single points of failure.
Resilient pipeline design includes:
- hardened and isolated build environments
- redundancy for critical CI/CD components
- tested rollback and redeployment mechanisms
- secure backup of pipeline configuration and artifacts
CI/CD pipelines that fail gracefully and recover quickly support broader ICT resilience objectives.
Continuous Evidence Generation for Article 21 Compliance
One of the most significant advantages of CI/CD-based compliance is continuous evidence generation.
CI/CD pipelines naturally produce:
- access logs and approval records
- security test results
- artifact provenance metadata
- deployment histories
This evidence directly supports Article 21 audit expectations by demonstrating that controls are enforced consistently and continuously.
Common Gaps Observed During DORA Assessments
Organizations often underestimate CI/CD relevance during DORA readiness efforts. Common gaps include:
- treating pipelines as non-regulated tooling
- excessive privileges granted to automation
- lack of artifact provenance
- insufficient log retention
- undocumented exceptions and overrides
Addressing these gaps early significantly reduces regulatory and operational risk.
Article 21 ↔ CI/CD Controls Mapping
The deep dive above explains what each Article 21 requirement asks for. The mapping below turns that into an operational view: for every requirement, it names the corresponding CI/CD control and the specific evidence that control produces. Auditors can read each row as a testable assertion — the requirement on the left should be satisfied by the control in the middle, and provable by the evidence on the right.
Article 21(1) — ICT Risk Management Framework
| DORA Requirement | CI/CD Control | Evidence Generated |
|---|---|---|
| Identify and assess ICT risks | Automated security testing (SAST, SCA, DAST) | Scan reports, pipeline logs |
| Prevent and mitigate ICT risks | Policy enforcement and pipeline gates | Gate decisions, approvals |
| Detect anomalous activities | Pipeline monitoring and alerts | Alert logs, SIEM events |
| Respond to ICT incidents | Controlled rollback and redeployments | Deployment history |
| Recover from disruptions | Reproducible builds and releases | Build metadata |
Article 21(2)(a) — Access Control
| DORA Requirement | CI/CD Control | Evidence Generated |
|---|---|---|
| Prevent unauthorized access | RBAC for CI/CD configuration | Access control logs |
| Protect privileged operations | Least privilege service accounts | IAM policies |
| Secure administrative access | MFA for CI/CD admins | Authentication logs |
| Control automation identities | Separate pipeline identities | Identity inventory |
Article 21(2)(b) — Segregation of Duties
| DORA Requirement | CI/CD Control | Evidence Generated |
|---|---|---|
| Separate conflicting roles | Code review requirements | Pull request history |
| Prevent self-approval | Approval rules enforced by pipeline | Approval records |
| Control release authority | Separate build and deploy permissions | Pipeline role mapping |
| Log overrides and exceptions | Exception logging | Override audit logs |
Article 21(2)(c) — Logging and Monitoring
| DORA Requirement | CI/CD Control | Evidence Generated |
|---|---|---|
| Monitor ICT system activity | Full pipeline execution logging | Execution logs |
| Detect security-relevant events | Failed controls and anomaly alerts | Security alerts |
| Retain logs securely | Centralized log storage | Retention configuration |
| Support investigations | Immutable audit trails | Forensic-ready logs |
Article 21(2)(d) — Change Management & Integrity
| DORA Requirement | CI/CD Control | Evidence Generated |
|---|---|---|
| Control changes to ICT systems | Mandatory CI/CD pipelines | Deployment history |
| Ensure integrity of changes | Artifact signing and verification | Signature metadata |
| Trace changes end-to-end | Source → pipeline → artifact linkage | Provenance records |
| Prevent unauthorized deployments | Policy gates and approvals | Gate enforcement logs |
Article 21(2)(e) — Resilience, Backup, and Recovery
| DORA Requirement | CI/CD Control | Evidence Generated |
|---|---|---|
| Ensure system resilience | Hardened, isolated build environments | Environment configuration |
| Prevent single points of failure | Redundant CI/CD components | Architecture documentation |
| Enable recovery mechanisms | Rollback and redeploy workflows | Recovery logs |
| Protect configurations | Secure backup of pipeline config | Backup records |
Article 21(2)(f) — Continuous Improvement
| DORA Requirement | CI/CD Control | Evidence Generated |
|---|---|---|
| Review ICT risk posture | Periodic pipeline security reviews | Review reports |
| Update controls as needed | Pipeline configuration changes | Change logs |
| Improve detection and prevention | Tool updates and rule tuning | Version history |
| Align with evolving threats | Threat-informed pipeline updates | Risk assessments |
How Auditors Use This Table
- Validate that Article 21 requirements are technically enforced
- Identify where CI/CD contributes to ICT risk management
- Request specific evidence generated by pipelines
- Assess consistency and repeatability of controls
Auditor Checklist for Article 21
Once the mapping establishes which controls should exist, the checklist below lets an assessor confirm whether they actually do. It is organized by the same Article 21 subsections and is suitable for internal audits, supervisory reviews, and regulatory assessments. Each line is a yes/no control check; a “no” marks a gap that warrants a finding or remediation action.
Article 21(1) — ICT Risk Management Framework
| Control Check | Yes | No |
|---|---|---|
| CI/CD pipelines are included in the ICT risk management scope | ⬜ | ⬜ |
| ICT risks related to software delivery are formally identified | ⬜ | ⬜ |
| Preventive controls are enforced via CI/CD pipelines | ⬜ | ⬜ |
| Detection mechanisms exist for pipeline-related incidents | ⬜ | ⬜ |
| CI/CD supports response and recovery processes | ⬜ | ⬜ |
Article 21(2)(a) — Access Control
| Control Check | Yes | No |
|---|---|---|
| CI/CD access follows least privilege principles | ⬜ | ⬜ |
| Pipeline identities are separated from human users | ⬜ | ⬜ |
| RBAC is enforced for pipeline configuration | ⬜ | ⬜ |
| MFA is required for CI/CD administrators | ⬜ | ⬜ |
| Privileged actions are restricted and monitored | ⬜ | ⬜ |
Article 21(2)(b) — Segregation of Duties
| Control Check | Yes | No |
|---|---|---|
| Developers cannot self-approve production changes | ⬜ | ⬜ |
| Code review is mandatory before pipeline execution | ⬜ | ⬜ |
| Build and deploy permissions are separated | ⬜ | ⬜ |
| Overrides and exceptions are logged | ⬜ | ⬜ |
| Segregation of duties is reviewed periodically | ⬜ | ⬜ |
Article 21(2)(c) — Logging and Monitoring
| Control Check | Yes | No |
|---|---|---|
| All CI/CD executions are logged | ⬜ | ⬜ |
| Logs include approvals and security checks | ⬜ | ⬜ |
| Logs are centrally collected | ⬜ | ⬜ |
| Log retention meets regulatory requirements | ⬜ | ⬜ |
| Alerts exist for abnormal pipeline behavior | ⬜ | ⬜ |
Article 21(2)(d) — Change Management & Integrity
| Control Check | Yes | No |
|---|---|---|
| All production changes go through CI/CD pipelines | ⬜ | ⬜ |
| Artifact integrity is verified before deployment | ⬜ | ⬜ |
| Provenance links source code to deployed artifacts | ⬜ | ⬜ |
| Out-of-band deployments are prevented or logged | ⬜ | ⬜ |
| Change approvals are auditable | ⬜ | ⬜ |
Article 21(2)(e) — Resilience, Backup, and Recovery
| Control Check | Yes | No |
|---|---|---|
| CI/CD pipelines are designed for resilience | ⬜ | ⬜ |
| Build environments are isolated and hardened | ⬜ | ⬜ |
| Pipeline configurations are backed up securely | ⬜ | ⬜ |
| Rollback procedures are tested | ⬜ | ⬜ |
| CI/CD components do not represent single points of failure | ⬜ | ⬜ |
Article 21(2)(f) — Continuous Improvement
| Control Check | Yes | No |
|---|---|---|
| CI/CD security controls are reviewed periodically | ⬜ | ⬜ |
| Pipeline controls evolve with threat landscape | ⬜ | ⬜ |
| Lessons learned are fed back into pipelines | ⬜ | ⬜ |
| Compliance gaps trigger corrective actions | ⬜ | ⬜ |
| Management oversight includes CI/CD risk posture | ⬜ | ⬜ |
Auditor Guidance
When using this checklist:
- Request technical evidence, not policies alone
- Verify that controls are automated and enforced
- Confirm that evidence is current and reproducible
- Assess consistency across teams and pipelines
- Pay special attention to exceptions and overrides
Evidence Pack for Auditors
A checklist confirms that a control is present; the evidence pack proves it to an auditor. This final section lists, subsection by subsection, the technical and operational artifacts financial institutions should present, what auditors expect from each, and where that evidence typically lives. The emphasis throughout is on system-generated, timestamped, and reproducible evidence rather than policy statements alone.
How to Use This Evidence Pack
- Use as a checklist during audit preparation
- Share with engineering, security, and compliance teams
- Attach references to real systems, logs, and repositories
- Ensure evidence is current, traceable, and reproducible
Article 21(1) — ICT Risk Management Framework
Evidence to Provide
| Evidence Type | What Auditors Expect |
|---|---|
| ICT risk register | CI/CD pipelines explicitly listed as in-scope ICT systems |
| Threat models | CI/CD-related risks (credential abuse, supply chain, integrity) |
| Risk treatment plans | Controls mapped to CI/CD pipelines |
| Governance documentation | Ownership of CI/CD security and risk |
Typical Sources
- Risk management tooling
- Architecture documentation
- Security governance repositories
Article 21(2)(a) — Access Control
Evidence to Provide
| Evidence Type | What Auditors Expect |
|---|---|
| IAM policies | Least privilege for CI/CD service accounts |
| RBAC configuration | Role separation for pipeline administration |
| MFA enforcement | Proof MFA is required for privileged users |
| Identity inventory | Distinction between human and automation identities |
Typical Sources
- IAM platform
- CI/CD system configuration
- Access review reports
Article 21(2)(b) — Segregation of Duties
Evidence to Provide
| Evidence Type | What Auditors Expect |
|---|---|
| Code review rules | Mandatory peer review enforced |
| Approval workflows | Independent approval for production changes |
| Role mapping | Separation between build, validation, deploy roles |
| Exception logs | Records of overrides and approvals |
Typical Sources
- Source control platform
- CI/CD pipeline definitions
- Audit logs
Article 21(2)(c) — Logging and Monitoring
Evidence to Provide
| Evidence Type | What Auditors Expect |
|---|---|
| Pipeline execution logs | Complete history of runs and outcomes |
| Security event logs | Failed checks, blocked releases |
| Monitoring dashboards | Visibility into pipeline health |
| Log retention policies | Alignment with regulatory requirements |
Typical Sources
- CI/CD platforms
- SIEM / logging systems
- Monitoring tools
Article 21(2)(d) — Change Management & Integrity
Evidence to Provide
| Evidence Type | What Auditors Expect |
|---|---|
| Deployment records | All production changes traceable to pipelines |
| Artifact signing | Proof of cryptographic integrity |
| Provenance metadata | Source → build → artifact linkage |
| Release approvals | Auditable decision points |
Typical Sources
- Artifact repositories
- CI/CD metadata stores
- Release management systems
Article 21(2)(e) — Resilience, Backup, and Recovery
Evidence to Provide
| Evidence Type | What Auditors Expect |
|---|---|
| CI/CD architecture diagrams | Redundancy and isolation |
| Backup procedures | Secure backups of pipeline configs |
| Recovery tests | Evidence of rollback and recovery exercises |
| Incident playbooks | CI/CD-specific response procedures |
Typical Sources
- Architecture documentation
- Backup systems
- Incident management tooling
Article 21(2)(f) — Continuous Improvement
Evidence to Provide
| Evidence Type | What Auditors Expect |
|---|---|
| Review reports | Periodic CI/CD security reviews |
| Change logs | Improvements to pipeline controls |
| Metrics & KPIs | Security and resilience indicators |
| Management oversight | Evidence of governance review |
Typical Sources
- Security review records
- CI/CD change history
- Governance meeting notes
Common Audit Pitfalls (What NOT to Show Alone)
Auditors will challenge:
- High-level policies without technical enforcement
- Screenshots without traceability
- Manual attestations without system evidence
- One-off examples instead of repeatable controls
Evidence must be system-generated, timestamped, and reproducible.
Auditor-Friendly Packaging Tips
- Group evidence by Article 21 subsection
- Provide read-only access to logs and dashboards
- Include sample evidence + explanation
- Clearly indicate control owners
- Avoid overloading auditors with irrelevant data
Conclusion
Article 21 of DORA establishes a clear expectation: ICT risk management must be embedded, continuous, and technically enforced. CI/CD pipelines, as core enablers of software delivery, are central to meeting that expectation — and, because they generate logs, approvals, and provenance as a by-product of normal operation, they are also one of the richest sources of audit evidence available to a financial entity.
By aligning pipeline design with the Article 21 controls described here, and by preparing the mapping, checklist, and evidence pack in advance, institutions can move from reactive audit scrambles to a state of continuous audit-readiness — demonstrating operational resilience, reducing systemic risk, and giving regulators concrete, reproducible proof of compliance.
Related Resources
- Continuous Compliance via CI/CD under DORA
- CI/CD Security Audit — ISO 27001 / SOC 2 / DORA Mapping
- DORA Compliance Architecture
- Compliance
- CI/CD Security
