Audit & Gouvernance - Regulated DevSecOps

Governing and Auditing CI/CD in Regulated Environments

In regulated environments, CI/CD pipelines are not only delivery mechanisms.
They are control systems subject to audit.

Audit and governance determine whether:

Controls are effectively enforced
Responsibilities are clearly segregated
Evidence is reliable and complete
Exceptions are documented and justified
Third-party risks are managed

This section focuses on how auditors assess CI/CD systems — and how governance structures support regulatory resilience.

New to CI/CD auditing? Start with our Auditor’s Guide and Glossary for plain-language definitions of technical terms.

Governance vs Audit — Understanding the Difference

Although often used interchangeably, governance and audit serve different roles.

Gouvernance

La gouvernance définit :

Who is responsible for controls
Which policies are mandatory
Comment les changements sont approuvés
Comment les risques sont évalués
Comment les exceptions sont gérées

La gouvernance est structurelle.

Audit

L’audit vérifie :

Si les contrôles fonctionnent réellement
Si l’application est cohérente
Si les preuves sont fiables
Si les attentes réglementaires sont respectées

L’audit est la validation.
Dans les organisations matures, la gouvernance conçoit le modèle de contrôle.
L’audit valide son efficacité.

Ce que les auditeurs évaluent réellement en CI/CD

Les auditeurs se concentrent rarement uniquement sur les outils.
Ils évaluent la maturité des contrôles.

Les domaines d’évaluation principaux comprennent :

1. Accès et séparation des fonctions

Les auditeurs vérifient :

Contrôle d’accès basé sur les rôles (RBAC)
Séparation entre l’accès développement et production
Protection des rôles privilégiés
Application de l’authentification multifacteur
Mécanismes de contournement contrôlés

Si les développeurs peuvent déployer directement en production sans contrôles de gouvernance, c’est un constat.

2. Gestion des changements et contrôles d’approbation

Les auditeurs attendent :

Revues de pull request obligatoires
Approbations de changements documentées
Workflows de release contrôlés
Preuves de journaux d’approbation
No undocumented hotfixes

Approval must be enforced by the system — not informal practice.

3. Security Control Enforcement

They examine:

Whether SAST / DAST results block releases
How policy gates are configured
Whether vulnerabilities are risk-accepted formally
Whether suppressions are documented

Advisory-only security controls are weak from an audit perspective.

4. Evidence Integrity

Evidence must be:

System-generated
Tamper-resistant
Time-stamped
Retained according to policy

Manual screenshots are not sufficient.

Reliable evidence includes:

CI/CD logs
Deployment history
Artifact signing records
Security scan outputs
Approval records

5. Third-Party Governance (DORA / NIS2 Focus)

Auditors increasingly review:

CI/CD SaaS vendor governance
Exit strategies
Shared runner risks
Sub-processor transparency
Contractual audit rights

Third-party CI/CD tools are part of the regulated ICT perimeter. See DORA Article 28 — Third-Party ICT Risk and NIS2 Supply Chain Security for regulatory deep dives.

Governance Model for Regulated CI/CD

Strong governance requires:

Défini Roles

Security architect
DevOps lead
Compliance officer
Risk owner
CI/CD platform owner

Documented Policies

Secure SDLC policy
Change management policy
Access management policy
Exception handling policy
Third-party risk policy

Formal Exception Handling

Exceptions must:

Be risk-assessed
Have expiry dates
Be approved
Be traceable

Uncontrolled exceptions create systemic audit risk.

Audit Maturity Levels

Organizations typically fall into one of four audit maturity stages:

Niveau	Name	Characteristics	Préparation à l’audit
1	Informal	Security practices exist but are not enforced. No systematic evidence.	Not audit-ready. Major findings expected.
2	Tool-Based	Security tools integrated but inconsistently applied. Results advisory.	Partial. Evidence exists but enforcement gaps.
3	Enforced	Policies block non-compliant changes. Segregation of duties in place. Systematic evidence.	Audit-ready. Meets DORA/NIS2/ISO 27001 minimums.
4	Governed & Auditable	Continuous evidence. Policy-as-code. Predictive risk. Full traceability.	Exceeds requirements. Continuous assurance.

Regulated environments should operate at Level 3 or Level 4. For a structured self-assessment, see the DevSecOps Maturity Assessment Framework.

Common Audit Red Flags

The following issues frequently trigger findings:

Shared CI/CD administrative accounts
No enforced approval gates
Direct production access
No retention of pipeline logs
Untracked vulnerability suppressions
No documented third-party exit strategy

These are systemic weaknesses, not isolated issues. For a comprehensive analysis, see Common Audit Findings — Top 10 CI/CD Failures.

How Governance Supports Continuous Compliance

Governance enables:

Génération de preuves continue
Risk-based decision tracking
Clear accountability
Resilience planning
Framework mapping across DORA, NIS2, ISO 27001, SOC 2, PCI DSS

Without governance, compliance becomes reactive.
With governance, compliance becomes structural.

Audit & Evidence Deep Dives

Audit Preparation

Framework-Specific Checklists

Evidence & Continuous Compliance

Governance Frameworks

Final Principle

In regulated environments: Architecture enforces. Governance defines. Audit validates.

If governance is weak, architecture cannot compensate. If architecture is weak, governance cannot protect you. A resilient CI/CD system requires both.

Related for Auditors

Glossary — Plain-language definitions of technical terms
Architecture — How CI/CD enforces controls by design
Regulatory Frameworks — DORA, NIS2, ISO 27001, SOC 2, PCI DSS
Full Resource Directory — Checklists, evidence packs, controls mappings

New to CI/CD auditing? Start with our Auditor’s Guide.