{"id":1884,"date":"2026-02-24T13:53:29","date_gmt":"2026-02-24T12:53:29","guid":{"rendered":"https:\/\/regulated-devsecops.com\/dora\/"},"modified":"2026-03-26T09:46:37","modified_gmt":"2026-03-26T08:46:37","slug":"dora","status":"publish","type":"page","link":"https:\/\/regulated-devsecops.com\/es\/cumplimiento\/dora\/","title":{"rendered":"DORA"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\"><strong>Digital Operational Resilience Act (DORA) \u2014 CI\/CD &amp; ICT Risk in Regulated Environments<\/strong><\/h2>\n\n<p>The Digital Operational Resilience Act (DORA) establishes a unified framework for managing ICT risk in the European financial sector.<\/p>\n\n<p>It applies to:<\/p>\n\n<ul class=\"wp-block-list\">\n<li>Banks<\/li>\n\n\n\n<li>Insurance companies<\/li>\n\n\n\n<li>Investment firms<\/li>\n\n\n\n<li>Payment institutions<\/li>\n\n\n\n<li>Crypto-asset service providers<\/li>\n\n\n\n<li>Critical ICT third-party providers<\/li>\n<\/ul>\n\n<p>DORA does not regulate code.<br\/>It regulates operational resilience.<\/p>\n\n<p>CI\/CD pipelines, cloud infrastructure, and third-party ICT services fall directly within its scope.<\/p>\n\n<h2 class=\"wp-block-heading\"><strong>Why DORA Matters for CI\/CD<\/strong><\/h2>\n\n<p>In regulated financial environments, CI\/CD pipelines are part of the ICT system.<br\/>This means they must:<\/p>\n\n<ul class=\"wp-block-list\">\n<li>Enforce access controls<\/li>\n\n\n\n<li>Segregate duties<\/li>\n\n\n\n<li>Protect production environments<\/li>\n\n\n\n<li>Generate audit evidence<\/li>\n\n\n\n<li>Manage third-party risk<\/li>\n\n\n\n<li>Support incident response and recovery<\/li>\n<\/ul>\n\n<p>DORA transforms CI\/CD from a delivery tool into a regulated control system.<\/p>\n\n<h2 class=\"wp-block-heading\"><strong>The Two Critical DORA Pillars for CI\/CD<\/strong><\/h2>\n\n<p>While DORA contains multiple chapters, two areas are particularly relevant for CI\/CD and cloud architectures:<\/p>\n\n<h3 class=\"wp-block-heading\"><strong>1. Article 21 \u2014 ICT Risk Management &amp; Control Framework<\/strong><\/h3>\n\n<p>Article 21 requires financial entities to implement robust ICT risk management controls.<\/p>\n\n<p>For CI\/CD, this translates into:<\/p>\n\n<ul class=\"wp-block-list\">\n<li>Secure change management<\/li>\n\n\n\n<li>Controlled deployments<\/li>\n\n\n\n<li>Segregation of duties<\/li>\n\n\n\n<li>Access governance<\/li>\n\n\n\n<li>Logging and traceability<\/li>\n\n\n\n<li>Evidence retention<\/li>\n\n\n\n<li>Secure development lifecycle enforcement<\/li>\n<\/ul>\n\n<p>CI\/CD must support:<\/p>\n\n<ul class=\"wp-block-list\">\n<li>Risk-based approvals<\/li>\n\n\n\n<li>Mandatory policy gates<\/li>\n\n\n\n<li>Blocking security controls<\/li>\n\n\n\n<li>Traceable change history<\/li>\n<\/ul>\n\n<p>\ud83d\udd0e Related guides:<\/p>\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/regulated-devsecops.com\/compliance\/dora-article-21-deep-dive-enforcing-ict-risk-controls-via-ci-cd\/\" data-type=\"post\" data-id=\"252\">DORA Article 21 \u2014 Deep Dive<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/compliance\/dora-article-21-%e2%86%94-ci-cd-controls-mapping\/\" data-type=\"post\" data-id=\"255\">DORA Article 21 \u2014 CI\/CD Controls Mapping<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/ci-cd-security\/dora-article-21-auditor-checklist-ci-cd-ict-risk-management\/\" data-type=\"post\" data-id=\"257\">DORA Article 21 \u2014 Auditor Checklist<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/compliance\/dora-article-21-evidence-pack-for-auditors\/\" data-type=\"post\" data-id=\"259\">DORA Article 21 \u2014 Evidence Pack<\/a><\/li>\n<\/ul>\n\n<h3 class=\"wp-block-heading\"><strong>2. Article 28 \u2014 ICT Third-Party Risk Management<\/strong><\/h3>\n\n<p>Article 28 focuses on third-party ICT service providers.<\/p>\n\n<p>For modern CI\/CD ecosystems, this includes:<\/p>\n\n<ul class=\"wp-block-list\">\n<li>Git hosting platforms<\/li>\n\n\n\n<li>CI\/CD SaaS providers<\/li>\n\n\n\n<li>Artifact registries<\/li>\n\n\n\n<li>Cloud runtime environments<\/li>\n\n\n\n<li>Marketplace plugins and integrations<\/li>\n<\/ul>\n\n<p>Article 28 requires:<\/p>\n\n<ul class=\"wp-block-list\">\n<li>Formal supplier risk assessment<\/li>\n\n\n\n<li>Contractual security clauses<\/li>\n\n\n\n<li>Audit rights<\/li>\n\n\n\n<li>Exit strategies<\/li>\n\n\n\n<li>Resilience testing<\/li>\n\n\n\n<li>Ongoing monitoring<\/li>\n<\/ul>\n\n<p>If your pipeline runs on SaaS infrastructure, you are managing third-party ICT risk.<\/p>\n\n<p>\ud83d\udd0e Related guides:<\/p>\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/regulated-devsecops.com\/compliance\/dora-article-28-explained-managing-ict-third-party-risk-in-ci-cd-and-cloud-environments\/\" data-type=\"post\" data-id=\"337\">DORA Article 28 \u2014 Explained<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/compliance\/dora-article-28-architecture-third-party-risk-controls-across-ci-cd-pipelines\/\" data-type=\"post\" data-id=\"364\">DORA Article 28 \u2014 Architecture<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/compliance\/dora-article-28-auditor-checklist-yes-no-evidence\/\" data-type=\"post\" data-id=\"353\">DORA Article 28 \u2014 Auditor Checklist<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/compliance\/dora-article-28-evidence-pack-what-auditors-expect-to-see\/\" data-type=\"post\" data-id=\"366\">DORA Article 28 \u2014 Evidence Pack<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/compliance\/dora-article-28-exit-strategy-testing-dr-bcp\/\" data-type=\"post\" data-id=\"879\">DORA Article 28 \u2014 Exit Strategy Testing<\/a><\/li>\n<\/ul>\n\n<h2 class=\"wp-block-heading\"><strong>DORA &amp; CI\/CD Architecture<\/strong><\/h2>\n\n<p>A DORA-aligned architecture must:<\/p>\n\n<ul class=\"wp-block-list\">\n<li>Enforce mandatory approval workflows<\/li>\n\n\n\n<li>Prevent direct production access<\/li>\n\n\n\n<li>Block non-compliant builds<\/li>\n\n\n\n<li>Sign and trace artifacts<\/li>\n\n\n\n<li>Retain deployment logs<\/li>\n\n\n\n<li>Monitor runtime events<\/li>\n\n\n\n<li>Isolate privileged access<\/li>\n<\/ul>\n\n<p>DORA compliance is not achieved by documentation alone.<br\/>It requires architectural enforcement.<\/p>\n\n<h2 class=\"wp-block-heading\"><strong>DORA &amp; Continuous Compliance<\/strong><\/h2>\n\n<p>DORA expects controls to operate continuously \u2014 not periodically.<\/p>\n\n<p>CI\/CD can support this by:<\/p>\n\n<ul class=\"wp-block-list\">\n<li>Automating policy enforcement<\/li>\n\n\n\n<li>Generating tamper-resistant logs<\/li>\n\n\n\n<li>Recording approval chains<\/li>\n\n\n\n<li>Preserving deployment traceability<\/li>\n\n\n\n<li>Tracking third-party service usage<\/li>\n<\/ul>\n\n<p>When designed correctly, the pipeline becomes a compliance engine.<\/p>\n\n<h2 class=\"wp-block-heading\"><strong>DORA vs Other Frameworks<\/strong><\/h2>\n\n<p>DORA overlaps with:<\/p>\n\n<ul class=\"wp-block-list\">\n<li>ISO 27001 (Annex A controls)<\/li>\n\n\n\n<li>SOC 2 (Logical Access &amp; Change Management)<\/li>\n\n\n\n<li>NIS2 (Supply chain resilience)<\/li>\n\n\n\n<li>PCI DSS (Secure development &amp; access control)<\/li>\n<\/ul>\n\n<p>However, DORA is regulation \u2014 not a voluntary certification.<br\/>It introduces supervisory expectations and enforcement mechanisms.<\/p>\n\n<h2 class=\"wp-block-heading\"><strong>Common DORA Misconceptions<\/strong><\/h2>\n\n<h3 class=\"wp-block-heading\"><strong>\u274c \u201cDORA is only about cybersecurity.\u201d<\/strong><\/h3>\n\n<p>DORA covers operational resilience, including governance, monitoring, and third-party management.<\/p>\n\n<h3 class=\"wp-block-heading\"><strong>\u274c \u201cCloud providers handle DORA compliance.\u201d<\/strong><\/h3>\n\n<p>Financial entities remain accountable, even when using third-party ICT providers.<\/p>\n\n<h3 class=\"wp-block-heading\"><strong>\u274c \u201cHaving security tools equals compliance.\u201d<\/strong><\/h3>\n\n<p>Without enforced governance and evidence, tools alone are insufficient.<\/p>\n\n<h2 class=\"wp-block-heading\"><strong>DORA Maturity Model for CI\/CD<\/strong><\/h2>\n\n<p>Organizations typically fall into one of four categories:<\/p>\n\n<p><strong>Level 1 \u2014 Informal Controls<\/strong><\/p>\n\n<p>Manual approvals, inconsistent logging.<\/p>\n\n<p><strong>Level 2 \u2014 Tool-Based Security<\/strong><\/p>\n\n<p>Security tools integrated but not blocking.<\/p>\n\n<p><strong>Level 3 \u2014 Enforced CI\/CD Controls<\/strong><\/p>\n\n<p>Policy gates block non-compliant releases.<\/p>\n\n<p><strong>Level 4 \u2014 Regulated ICT System<\/strong><\/p>\n\n<p>Full segregation of duties, traceability, evidence retention, and third-party governance.<\/p>\n\n<p>Financial institutions should aim for Level 3 or Level 4.<\/p>\n\n<h2 class=\"wp-block-heading\"><strong>Practical DORA Resources<\/strong><\/h2>\n\n<p>Architecture:<\/p>\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/regulated-devsecops.com\/compliance\/dora-compliance-architecture-explained\/\" data-type=\"post\" data-id=\"277\">DORA Compliance Architecture \u2014 Explained<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/compliance\/dora-compliance-architecture-ci-cd-as-a-regulated-ict-system\/\" data-type=\"post\" data-id=\"274\">DORA Compliance Architecture: CI\/CD as a Regulated ICT System<\/a><\/li>\n<\/ul>\n\n<p>Article 21:<\/p>\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/regulated-devsecops.com\/compliance\/dora-article-21-deep-dive-enforcing-ict-risk-controls-via-ci-cd\/\" data-type=\"post\" data-id=\"252\">DORA Article 21 \u2014 Deep Dive<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/compliance\/dora-article-21-%e2%86%94-ci-cd-controls-mapping\/\" data-type=\"post\" data-id=\"255\">DORA Article 21 \u2014 Controls Mapping<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/compliance\/dora-article-21-evidence-pack-for-auditors\/\" data-type=\"post\" data-id=\"259\">DORA Article 21 \u2014 Evidence Pack<\/a><\/li>\n<\/ul>\n\n<p>Article 28:<\/p>\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/regulated-devsecops.com\/compliance\/dora-article-28-architecture-third-party-risk-controls-across-ci-cd-pipelines\/\" data-type=\"post\" data-id=\"364\">DORA Article 28 \u2014 Architecture<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/compliance\/dora-article-28-exit-strategy-testing-dr-bcp\/\" data-type=\"post\" data-id=\"879\">DORA Article 28 \u2014 Exit Strategy Testing<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/compliance\/third-party-risk-in-ci-cd-pipelines-under-dora-article-28\/\" data-type=\"post\" data-id=\"368\">Third-Party Risk in CI\/CD under DORA<\/a><\/li>\n<\/ul>\n\n<p>Audit &amp; Governance:<\/p>\n\n<ul class=\"wp-block-list\">\n<li><a href=\"https:\/\/regulated-devsecops.com\/compliance\/executive-audit-briefing-ci-cd-pipelines-in-regulated-environments\/\" data-type=\"post\" data-id=\"272\">Executive Audit Briefing \u2014 CI\/CD in Regulated Environments<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/compliance\/audit-day-playbook-how-to-handle-ci-cd-audits-in-regulated-environments\/\" data-type=\"post\" data-id=\"268\">Audit Day Playbook<\/a><\/li>\n\n\n\n<li><a href=\"https:\/\/regulated-devsecops.com\/compliance\/how-auditors-actually-review-ci-cd-pipelines\/\" data-type=\"post\" data-id=\"261\">How Auditors Actually Review CI\/CD Pipelines<\/a><\/li>\n<\/ul>\n\n<h2 class=\"wp-block-heading\"><strong>Final Principle<\/strong><\/h2>\n\n<p>DORA is not a documentation exercise.<br\/>It is an operational resilience mandate.<\/p>\n\n<p>In modern financial institutions, CI\/CD pipelines are part of the regulated ICT perimeter.<\/p>\n\n<p>If your architecture enforces controls and generates evidence by design, DORA becomes manageable.<br\/>If controls are manual or informal, DORA becomes a systemic risk.<\/p>\n\n<p><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Digital Operational Resilience Act (DORA) \u2014 CI\/CD &amp; 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: DORA does not regulate code.It regulates operational resilience. CI\/CD pipelines, cloud infrastructure, and third-party ICT services fall directly within its &#8230; <a title=\"DORA\" class=\"read-more\" href=\"https:\/\/regulated-devsecops.com\/es\/cumplimiento\/dora\/\" aria-label=\"Leer m\u00e1s sobre DORA\">Leer m\u00e1s<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":2094,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-1884","page","type-page","status-publish"],"_links":{"self":[{"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/pages\/1884","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/comments?post=1884"}],"version-history":[{"count":0,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/pages\/1884\/revisions"}],"up":[{"embeddable":true,"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/pages\/2094"}],"wp:attachment":[{"href":"https:\/\/regulated-devsecops.com\/es\/wp-json\/wp\/v2\/media?parent=1884"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}