Compliance Pipelines, Pipeline Execution Policies, Governance, Audit Evidence, and Enterprise Controls: Configuration, Design Choices, and Tradeoffs

1. Four decisions, four different ownership boundaries

Before adding a policy, classify the need. Is it a non-negotiable invariant, reusable implementation, observation, or exception? That answer determines the proper layer.

2. Choose pipeline strategy from the ownership model

Current pipeline execution policy documentation centers new designs on inject_policy and override_project_ci. The older inject_ci strategy is deprecated.

3. Central enforcement versus project autonomy

Suppose every service must produce a governance proof but teams may choose pytest, Maven, Gradle, or another test stack. Put only the governance proof in policy. Application teams keep their test jobs. This minimizes the policy blast radius, keeps feedback local, and makes separation of duties understandable.

Central policy still has operational cost: one bad change can affect every linked descendant. Roll out to a small test scope first, protect the policy project default branch, require review, and retain a last-known-good policy ref.

4. Versioned reuse is not the same as enforcement

5. Preventive and detective controls are complementary

Use a blocking .pipeline-policy-pre job when violating the invariant must prevent later work. Use a non-blocking detective job when you are measuring adoption, learning false-positive rates, or preparing a rollout.

policy:detect-duplicate-scan:
  stage: .pipeline-policy-pre
  allow_failure: true
  script:
    - ./detect-duplicate-scan.sh
  artifacts:
    when: always
    paths: [governance-evidence/duplicate-scan.json]

policy:required-governance-proof:
  stage: .pipeline-policy-pre
  allow_failure: false
  script:
    - ./verify-governance-proof.sh

Do not call a detective control “enforced” merely because the job exists. The observable state includes whether its failure blocks later execution.

6. A waiver is governed data, not a forgotten exclusion

A project exclusion in policy_scope is technical scope. It does not inherently encode the business lifecycle of a waiver. Store that lifecycle separately and reconcile it.

{
  "id": "EX-CH36-042",
  "project_id": 456,
  "control": "governance-proof",
  "owner": "service-owner@example.invalid",
  "approved_by": "governance@example.invalid",
  "reason": "temporary migration window",
  "created_at": "2026-09-13T00:00:00Z",
  "expires_at": "2026-09-20T00:00:00Z",
  "policy_version_requested_against": "ch36-policy-v1.0.0",
  "ticket": "SIM-CH36-42"
}

An expiry timestamp nobody reconciles is documentation, not enforcement. A production process should alert or fail when a record is expired but the technical exclusion still exists.

7. Variable precedence and protection are part of the control design

Pipeline execution policies can control whether user-defined variables influence policy jobs with variables_override. An allowlist model is easier to reason about than “allow everything except the few names we remembered.”

variables_override:
  allowed: false
  exceptions:
    - CH36_NON_SECRET_MODE

8. Tier, offering, and trust prerequisites

9. Migrate old compliance pipelines without double enforcement

Compliance pipelines are deprecated. Before migration, capture a representative old pipeline: source SHA, effective jobs, variable behavior, reports/artifacts, framework association, and evidence. Create the replacement pipeline execution policy in a narrow test scope. Compare old and new results, including duplicate jobs and exception behavior. Only then remove the old mechanism.

Do not run both mechanisms broadly and call duplication “defense in depth.” GitLab explicitly warns that mixing them can cause duplicated jobs, failures, or missing checks.

10. Worked decision: one control across four teams

11. Rollback restores a known-good policy state and preserves history

Rollback through a reviewed policy change that restores the last known-good policy/CI ref or disables/narrows the broken policy. Preserve failed pipelines and audit evidence. Deleting the bad history destroys the data needed to explain the incident.

Knowledge check

Official references and version notes

Further reading — current official GitLab sources

Behavior and tier assumptions in this chapter were checked against the current documentation on 2026-09-13. Re-check these pages before applying the optional enterprise path because policy schemas and product tiers evolve.

• GitLab Docs — Pipeline execution policies
• GitLab Docs — Security policy projects
• GitLab Docs — Policy enforcement and separation of duties
• GitLab Docs — Compliance pipelines (deprecated)
• GitLab Docs — CI/CD variables and precedence
• GitLab Docs — CI Lint API
• GitLab Docs — Audit events
• GitLab Docs — Audit events API
• GitLab Docs — Compliance frameworks
• GitLab Docs — Deprecations and removals

Current assumptions used in this chapter: Version-sensitive YAML, Runner/executor behavior, APIs, security features, policy controls, tiers, and deprecations must be verified against the exact GitLab, GitLab Runner, tool, and external-system versions used in production. Preserve the exact project/ref/SHA, compiled configuration, pipeline/job IDs, runner/tool versions, and external target evidence used for reproducible work.