DORA

Digital Operational Resilience Act (DORA) — CI/CD & ICT Risk in Regulated Environments

The Digital Operational Resilience Act (DORA) establishes a unified framework for managing ICT risk in the European financial sector.

It applies to:

  • Banks
  • Insurance companies
  • Investment firms
  • Payment institutions
  • Crypto-asset service providers
  • Critical ICT third-party providers

DORA does not regulate code.
It regulates operational resilience.

CI/CD pipelines, cloud infrastructure, and third-party ICT services fall directly within its scope.

Why DORA Matters for CI/CD

In regulated financial environments, CI/CD pipelines are part of the ICT system.
This means they must:

  • Enforce access controls
  • Segregate duties
  • Protect production environments
  • Generate audit evidence
  • Manage third-party risk
  • Support incident response and recovery

DORA transforms CI/CD from a delivery tool into a regulated control system.

The Two Critical DORA Pillars for CI/CD

While DORA contains multiple chapters, two areas are particularly relevant for CI/CD and cloud architectures:

1. Article 21 — ICT Risk Management & Control Framework

Article 21 requires financial entities to implement robust ICT risk management controls.

For CI/CD, this translates into:

  • Secure change management
  • Controlled deployments
  • Segregation of duties
  • Access governance
  • Logging and traceability
  • Evidence retention
  • Secure development lifecycle enforcement

CI/CD must support:

  • Risk-based approvals
  • Mandatory policy gates
  • Blocking security controls
  • Traceable change history

🔎 Related guides:

2. Article 28 — ICT Third-Party Risk Management

Article 28 focuses on third-party ICT service providers.

For modern CI/CD ecosystems, this includes:

  • Git hosting platforms
  • CI/CD SaaS providers
  • Artifact registries
  • Cloud runtime environments
  • Marketplace plugins and integrations

Article 28 requires:

  • Formal supplier risk assessment
  • Contractual security clauses
  • Audit rights
  • Exit strategies
  • Resilience testing
  • Ongoing monitoring

If your pipeline runs on SaaS infrastructure, you are managing third-party ICT risk.

🔎 Related guides:

DORA & CI/CD Architecture

A DORA-aligned architecture must:

  • Enforce mandatory approval workflows
  • Prevent direct production access
  • Block non-compliant builds
  • Sign and trace artifacts
  • Retain deployment logs
  • Monitor runtime events
  • Isolate privileged access

DORA compliance is not achieved by documentation alone.
It requires architectural enforcement.

DORA & Continuous Compliance

DORA expects controls to operate continuously — not periodically.

CI/CD can support this by:

  • Automating policy enforcement
  • Generating tamper-resistant logs
  • Recording approval chains
  • Preserving deployment traceability
  • Tracking third-party service usage

When designed correctly, the pipeline becomes a compliance engine.

DORA vs Other Frameworks

DORA overlaps with:

  • ISO 27001 (Annex A controls)
  • SOC 2 (Logical Access & Change Management)
  • NIS2 (Supply chain resilience)
  • PCI DSS (Secure development & access control)

However, DORA is regulation — not a voluntary certification.
It introduces supervisory expectations and enforcement mechanisms.

Common DORA Misconceptions

❌ “DORA is only about cybersecurity.”

DORA covers operational resilience, including governance, monitoring, and third-party management.

❌ “Cloud providers handle DORA compliance.”

Financial entities remain accountable, even when using third-party ICT providers.

❌ “Having security tools equals compliance.”

Without enforced governance and evidence, tools alone are insufficient.

DORA Maturity Model for CI/CD

Organizations typically fall into one of four categories:

Level 1 — Informal Controls

Manual approvals, inconsistent logging.

Level 2 — Tool-Based Security

Security tools integrated but not blocking.

Level 3 — Enforced CI/CD Controls

Policy gates block non-compliant releases.

Level 4 — Regulated ICT System

Full segregation of duties, traceability, evidence retention, and third-party governance.

Financial institutions should aim for Level 3 or Level 4.

Practical DORA Resources

Architecture:

Article 21:

Article 28:

Audit & Governance:

Final Principle

DORA is not a documentation exercise.
It is an operational resilience mandate.

In modern financial institutions, CI/CD pipelines are part of the regulated ICT perimeter.

If your architecture enforces controls and generates evidence by design, DORA becomes manageable.
If controls are manual or informal, DORA becomes a systemic risk.