CI/CD as a Regulated System
In regulated environments, CI/CD pipelines are not just automation tools.
They are enforcement systems.
Architecture determines whether:
- Security controls are mandatory or optional
- Policies are documented or enforced
- Evidence is manual or system-generated
- Compliance is reactive or continuous
This is the foundational insight for auditors: architecture is where compliance becomes technical reality. A well-designed pipeline makes non-compliance structurally difficult. A poorly designed one makes it structurally inevitable.
New to these concepts? See our Glossary for plain-language definitions of CI/CD terms.
Why Architecture Comes First
Before discussing tools, frameworks, or audits, one principle must be clear:
If your architecture does not enforce controls, no checklist will save you.
A secure CI/CD architecture:
- Prevents unapproved production changes — through mandatory RBAC and approval gates
- Blocks policy violations automatically — through policy-as-code enforcement
- Generates traceable logs — for every pipeline execution, approval, and deployment
- Preserves evidence for regulators — with immutable, timestamped records
- Supports exit and resilience requirements — critical for DORA and NIS2
Controls must be built into the system — not layered on top of it.
What Auditors Should Assess in CI/CD Architecture
When reviewing CI/CD architecture, auditors should evaluate five key questions:
| Question | What Good Looks Like | Red Flag |
|---|---|---|
| Can security stages be skipped? | All stages mandatory; no bypass without governed exception | Stages can be commented out or disabled by developers |
| Who can deploy to production? | Deployment restricted to specific roles; different from code authors | Anyone with repo access can trigger production deployment |
| Are pipeline configs protected? | Pipeline definitions in version control with change approval | Pipeline configs editable without review or audit trail |
| Is evidence system-generated? | Logs, scan results, approval records produced automatically | Evidence compiled manually before audits |
| Can exceptions be traced? | Every bypass has documented approval, reason, and expiry | No exception management process; suppressions ungoverned |
For a comprehensive assessment approach, see How Auditors Actually Review CI/CD Pipelines.
Core Architectural Domains
Modern regulated CI/CD architectures rely on four foundational domains. Each domain addresses a distinct control objective that auditors verify independently.
1. Enforcement Layer
The enforcement layer is the control engine of the pipeline. It determines whether security is advisory or mandatory.
It ensures:
- Mandatory approval workflows — no deployment without authorised review
- Blocking policy gates — critical SAST/DAST/SCA findings prevent release
- Secure build and artifact validation — signed, verified, traceable
- Role-based deployment permissions — segregation of duties enforced by design
- Exception governance with audit trails — every override documented and time-limited
Without enforcement, CI/CD becomes advisory. With enforcement, CI/CD becomes regulated.
Auditor insight: Ask to see a recent deployment that was blocked by a policy gate. If the organisation cannot produce one, enforcement may not be real.
Deep dives:
2. Secure SDLC Integration
Architecture must integrate security from plan to runtime — the shift-left principle embedded in pipeline design.
| SDLC Phase | Security Control | Evidence Produced |
|---|---|---|
| Plan | Threat modelling, security requirements | Threat model documents, security stories |
| Code | SAST, secrets scanning, code review | Scan logs, review approval records |
| Build | SCA, SBOM generation, artifact signing | Dependency reports, SBOM files, signatures |
| Test | DAST, penetration testing | DAST reports, test evidence |
| Release | Policy gate evaluation, approval workflows | Gate pass/fail logs, approval records |
| Deploy | Configuration validation, environment parity | Deployment logs, config checksums |
| Monitor | Runtime protection, incident detection | Alert logs, incident records |
Secure SDLC is not a compliance slogan — it is an architectural pattern.
Deep dives:
- Secure SDLC Fundamentals
- Secure SDLC from the Auditor’s Perspective
- How Auditors Assess Application Security Controls
3. Continuous Compliance Model
Regulated environments require compliance that is continuous, not periodic. The architecture must produce evidence automatically on every pipeline execution.
- Repeatable control execution — same controls, every time, every pipeline
- Evidence-by-design — logs, reports, and approval records generated as a byproduct of normal operations
- Automated traceability — every deployment traceable to a specific commit, review, scan, and approval
- Framework mapping — controls mapped to DORA, NIS2, ISO 27001, SOC 2, PCI DSS
A mature architecture produces compliance continuously — not quarterly.
Deep dives:
- Continuous Compliance via CI/CD
- Continuous Auditing vs Point-in-Time Audits
- Dual-Compliance Architecture — Explained
- Building an Evidence Repository for Continuous Compliance
4. Security Domain Separation
Confusion often arises between overlapping security domains. Clear architecture prevents duplication and control gaps.
| Domain | Focus | Key Concern for Auditors | Hub Page |
|---|---|---|---|
| CI/CD Governance | Pipeline controls, enforcement, access | Are controls mandatory and non-bypassable? | Explore |
| Application Security | Code-level controls (SAST, DAST, SCA) | Is security testing integrated and enforced? | Explore |
| DevSecOps | Operating models, roles, governance | Who owns security? How are decisions escalated? | Explore |
| Regulatory Frameworks | Compliance mapping and assurance | Do controls satisfy regulatory requirements? | Explore |
| Audit & Evidence | Evidence validation, assessment | Is evidence trustworthy, complete, and retained? | Explore |
Understanding these domains prevents duplication and control gaps. Architecture ensures each domain has clear boundaries and responsibilities.
Deep dive: Security Domains Explained
Architectural Maturity Model
Regulated CI/CD systems typically evolve across four stages. Auditors can use this model to quickly assess an organisation’s maturity level.
| Level | Name | Characteristics | Regulatory Readiness |
|---|---|---|---|
| 1 | Automation | Pipelines automate builds and deployments. Controls are optional. No evidence generation. | Not audit-ready. Significant gaps across all frameworks. |
| 2 | Security Integration | Security tools integrated (SAST/DAST/SCA). Results advisory, not blocking. Some logging. | Partially compliant. Evidence exists but enforcement is inconsistent. |
| 3 | Enforced Controls | Critical controls block non-compliant releases. Segregation of duties. Systematic evidence. | Audit-ready for most frameworks. Meets DORA/NIS2/ISO 27001 minimums. |
| 4 | Regulated System | Full traceability. Policy-as-code. Continuous compliance. Exit readiness. Predictive risk. | Exceeds requirements. Continuous assurance model. |
Regulated environments must operate at Level 3 or higher. Most regulatory frameworks (DORA, NIS2, ISO 27001) effectively require Level 3 as a minimum for certification or compliance.
For a structured self-assessment tool, see the DevSecOps Maturity Assessment Framework.
Architecture vs Tooling
Tools do not create architecture. Architecture defines how tools are governed.
| Architecture Decides | Tools Implement |
|---|---|
| Which controls are mandatory | How scans are executed |
| Where enforcement occurs in the pipeline | Which vulnerabilities are detected |
| Which failures block releases | How results are reported |
| How evidence is retained and protected | Where logs are stored |
| Who can override policies | How exceptions are technically processed |
A strong architecture can change tools without losing control. A weak architecture depends entirely on vendor defaults.
For auditor guidance on tool governance, see CI/CD Security Tooling — Auditor’s Guide to Tool Categories and Controls.
Architecture & Regulatory Alignment
A well-designed CI/CD architecture supports multiple regulatory frameworks simultaneously. Rather than adapting architecture per regulation, design architecture once — map controls many times.
| Framework | Architectural Requirement | Key Articles/Controls | Deep Dive |
|---|---|---|---|
| DORA | ICT risk management, third-party control, resilience testing | Art. 9, 21, 28 | Art. 21 Deep Dive |
| NIS2 | Supply chain security, incident readiness, risk management | Art. 21 | Art. 21 Controls Mapping |
| ISO 27001 | Change management, access control, secure development | A.8.25, A.8.28, A.8.29 | Annex A Mapping |
| SOC 2 | Logical access, system operations, change management | CC6, CC7, CC8 | TSC Mapping |
| PCI DSS | Secure development, access control, logging, testing | Req. 6, 7, 8, 10, 11 | Req. 6 Deep Dive |
For cross-framework analysis, see the ISO 27001 vs DORA vs NIS2 Controls Overlap Matrix.
Related Architecture Deep Dives
- CI/CD Only Architecture — Pipeline, Evidence & Approvals
- CI/CD Enforcement Layer
- CI/CD-Based Enforcement Models
- Continuous Compliance via CI/CD
- Secure SDLC Fundamentals
- Core CI/CD Security Controls
- DORA Compliance Architecture — CI/CD as a Regulated ICT System
- NIS2 Security Architecture Explained
Final Principle
In regulated environments, delivery speed and control are not opposites. The right architecture makes them compatible.
If your pipeline is not designed as a control system, compliance will always be reactive. If your architecture enforces policy by design, compliance becomes continuous.
Related for Auditors
- Glossary — Plain-language definitions of technical terms
- How Auditors Actually Review CI/CD Pipelines
- Common Audit Findings — Top 10 CI/CD Failures
- DevSecOps Maturity Assessment Framework
New to CI/CD auditing? Start with our Auditor’s Guide.
