CI/CD security best practices for protecting software delivery pipelines in enterprise and regulated environments. This category covers CI/CD pipeline security, secrets management, artifact integrity, access control, and risk mitigation across the continuous integration and continuous delivery lifecycle.
This checklist is designed for formal audit reviews of ICT third-party risk management under DORA Article 28. Each control must be objectively verifiable through evidence. 1. ICT Third-Party Inventory Control Yes No Evidence A complete inventory of ICT third-party providers exists ☐ ☐ Supplier register CI/CD platforms are included as ICT providers ☐ ☐ Supplier … Read more
This checklist contrasts what auditors verify with what engineers must actually implement to achieve effective and defensible DORA Article 28 compliance. 1. Supplier Inventory & Criticality Auditor checks Engineer implements Complete inventory of ICT third-party providers CMDB or supplier registry including CI/CD, Git, cloud, registries Supplier classification by criticality Criticality tags linked to delivery systems … Read more
Why This Split Matters One of the most common causes of friction during DORA Article 28 audits is a mismatch of expectations. Both views are valid — but they are not interchangeable. This article bridges that gap by showing: High-Level Perspective Perspective Focus Auditor View Can this organization demonstrate effective third-party ICT risk control? Engineer … Read more
Introduction DORA Article 28 requires regulated financial entities to demonstrate effective control over ICT third-party risks. This obligation goes far beyond vendor questionnaires or contractual statements. Auditors do not assess intent — they assess evidence. This article provides a practical evidence pack for DORA Article 28, focusing on what auditors typically ask for, where evidence … Read more
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. This section presents the same CI/CD architecture, viewed through two different lenses: Understanding both perspectives is essential to avoid compliance gaps and audit friction. … Read more
DORA Article 28 requires regulated organizations to treat ICT third-party providers as part of their operational risk perimeter. In practice, this means your CI/CD and cloud delivery chain must be designed so that: This page provides a practical architecture view: where third-party dependencies sit, which controls apply, and what evidence you should be able to … Read more
How Regulatory Objectives Shape Security and CI/CD Design NIS2 and DORA are often mentioned together, but they are not interchangeable. While both regulations focus on cybersecurity and operational resilience, they differ significantly in scope, regulatory intent, and architectural implications. This article compares NIS2 vs DORA through an architectural lens, highlighting how governance, CI/CD pipelines, and … Read more
Governance, CI/CD, Vendors, and Software Supply Chain This checklist reflects how NIS2 supply chain requirements are actually reviewed by auditors and supervisory authorities. It focuses on governance, technical enforcement, and evidence, rather than high-level policy statements. Use this checklist to assess readiness before an audit or to guide evidence preparation during supervision. 1. Scope and … Read more
What Financial Institutions Must Show Auditors Under the NIS2 Directive, financial institutions are required to manage cybersecurity risks across their entire supply chain, including software vendors, CI/CD platforms, cloud providers, and outsourced ICT services. In practice, supervisory authorities apply a high level of scrutiny to supply chain controls due to systemic risk and interdependencies across … Read more
What to Show Auditors (CI/CD, Vendors, Software Supply Chain) Supply chain security is one of the most scrutinized areas under the NIS2 Directive. Auditors and supervisory authorities are not looking for theoretical risk statements — they expect concrete, system-generated evidence showing how supplier-related cybersecurity risks are identified, controlled, monitored, and addressed. This article provides a … Read more
