Part 30: Enterprise Delivery, Governance & Compliance

Introduction

Everything changes when you add the word "enterprise." A startup with 10 engineers can deploy via git push and fix issues in minutes. An enterprise with 1,000 engineers, regulated data, SLAs, and external auditors operates under fundamentally different constraints. The question isn't whether to have governance — it's how to implement governance that enables delivery rather than blocking it.

The enterprises that win are not the ones that move fast without controls. They're the ones that have automated their controls so thoroughly that compliance happens as a side effect of normal delivery. Every deployment automatically generates audit evidence. Every code change automatically passes through security scanning. Every infrastructure modification automatically checks policy compliance. The controls exist — they're just invisible to developers.

The Governance Paradox

Traditional enterprise governance creates a paradox: the more controls you add, the slower delivery becomes — and the slower delivery becomes, the larger each change is — and the larger each change is, the riskier it is — and the riskier changes are, the more controls you add. This is a death spiral that turns quarterly releases into annual releases.

Modern enterprise governance inverts this: enable small, frequent changes with automated controls. Small changes are inherently less risky. Automated controls are faster than manual ones. The result: more deployments, fewer incidents, complete audit trails.

flowchart LR
    subgraph Traditional["Traditional (Death Spiral)"]
        A[More Controls] --> B[Slower Delivery]
        B --> C[Larger Changes]
        C --> D[More Risk]
        D --> A
    end

    subgraph Modern["Modern (Virtuous Cycle)"]
        E[Automated Controls] --> F[Faster Delivery]
        F --> G[Smaller Changes]
        G --> H[Less Risk]
        H --> I[More Confidence]
        I --> E
    end
                            

Change Management

ITIL (Information Technology Infrastructure Library) defined change management for enterprises decades ago. Its core mechanism is the Change Advisory Board (CAB) — a weekly meeting where proposed changes are reviewed, risk-assessed, and approved or rejected by a committee of stakeholders.

Traditional Change Categories

The problem with traditional CAB: it was designed for an era when deployments happened monthly and involved physical hardware. When you deploy 50 times a day, a weekly CAB meeting is not governance — it's a bottleneck. DORA research consistently shows that external change approval processes (like CAB) do not reduce change failure rates. They only slow delivery.

Modern Alternatives

Elite-performing organisations replace manual CAB with automated change records:

• Peer review as change approval — A merged pull request with 2+ approvals is the change approval. No separate ticket required
• Automated change records — CI/CD pipelines automatically create change records in ServiceNow/Jira when deployments occur
• Risk-based routing — Low-risk changes (standard services, passing tests) deploy automatically. High-risk changes (database migrations, security changes) trigger additional review
• Post-deployment verification — Instead of approving before deployment, verify after deployment with automated health checks and instant rollback

# Automated change record generation in CI/CD
# .github/workflows/deploy.yml (excerpt)
- name: Create Change Record
  if: github.ref == 'refs/heads/main'
  run: |
    curl -X POST "$SERVICENOW_URL/api/sn_chg_rest/change" \
      -H "Authorization: Bearer $SNOW_TOKEN" \
      -H "Content-Type: application/json" \
      -d '{
        "type": "standard",
        "short_description": "Deploy ${{ github.repository }} v${{ env.VERSION }}",
        "description": "Automated deployment via CI/CD pipeline",
        "assignment_group": "${{ env.TEAM_ID }}",
        "risk": "low",
        "impact": "low",
        "justification": "PR #${{ github.event.pull_request.number }} approved by ${{ env.APPROVERS }}",
        "test_plan": "Automated: ${{ env.TEST_RESULTS_URL }}",
        "backout_plan": "Automated rollback via ArgoCD",
        "state": "implement"
      }'

Compliance Frameworks

Different industries face different regulatory requirements. Understanding what each framework actually requires for software delivery is essential — because most organisations over-interpret requirements and implement heavier processes than necessary.

Mapping CI/CD Controls to Compliance

The good news: a well-designed CI/CD pipeline already satisfies most compliance requirements. The key is making the evidence visible and immutable:

Compliance as Code

Compliance as Code means encoding compliance requirements as machine-readable policies that are automatically enforced and automatically generate evidence. Instead of a human checking a spreadsheet, a policy engine evaluates every deployment against codified rules.

Open Policy Agent (OPA)

OPA is the industry standard for policy-as-code. It uses a declarative language called Rego to express policies that can be evaluated against any structured data (Kubernetes manifests, Terraform plans, CI/CD metadata).

# OPA Rego policy: Enforce deployment compliance
# compliance/deployment_policy.rego

package deployment.compliance

# Deny deployment if no peer review
deny[msg] {
    input.change.approvals < 2
    msg := sprintf("Deployment blocked: requires 2+ approvals, got %d", [input.change.approvals])
}

# Deny deployment if security scan has critical findings
deny[msg] {
    input.security_scan.critical_count > 0
    msg := sprintf("Deployment blocked: %d critical vulnerabilities found", [input.security_scan.critical_count])
}

# Deny deployment to production outside maintenance window (emergency override exists)
deny[msg] {
    input.environment == "production"
    not input.override.emergency
    not within_maintenance_window
    msg := "Production deployment blocked: outside maintenance window (Mon-Thu 09:00-16:00 UTC)"
}

within_maintenance_window {
    day := time.weekday(time.now_ns())
    day != "Friday"
    day != "Saturday"
    day != "Sunday"
    hour := time.clock(time.now_ns())[0]
    hour >= 9
    hour < 16
}

# Generate compliance evidence
evidence[record] {
    record := {
        "timestamp": time.now_ns(),
        "service": input.service_name,
        "version": input.version,
        "approvers": input.change.approvers,
        "test_results": input.test_results.url,
        "security_scan": input.security_scan.report_url,
        "deployer": input.deployer.identity,
        "environment": input.environment,
        "change_record": input.change.ticket_id
    }
}

HashiCorp Sentinel

For Terraform-managed infrastructure, Sentinel provides policy-as-code that evaluates infrastructure changes before they're applied:

# Sentinel policy: Enforce tagging and encryption
# policies/infrastructure-compliance.sentinel

import "tfplan/v2" as tfplan

# All resources must have required tags
mandatory_tags = ["owner", "environment", "cost-center", "data-classification"]

all_resources_tagged = rule {
    all tfplan.resource_changes as _, rc {
        all mandatory_tags as tag {
            rc.change.after.tags contains tag
        }
    }
}

# All storage must be encrypted
storage_encrypted = rule {
    all tfplan.resource_changes as _, rc {
        rc.type in ["aws_s3_bucket", "aws_ebs_volume", "aws_rds_instance"] implies
        rc.change.after.encrypted == true
    }
}

# No public S3 buckets
no_public_buckets = rule {
    all tfplan.resource_changes as _, rc {
        rc.type == "aws_s3_bucket" implies
        rc.change.after.acl != "public-read"
    }
}

main = rule { all_resources_tagged and storage_encrypted and no_public_buckets }

Audit Trails

An audit trail is a chronological record of all activities related to a software change. For regulated environments, the audit trail must be immutable (cannot be modified after the fact), complete (captures all relevant events), and attributable (every action is tied to a specific identity).

What to Log

• Who — Identity of the person or service account that performed the action
• What — The specific change (commit SHA, artifact version, configuration diff)
• When — Timestamp with timezone (ISO 8601 format)
• Where — Target environment, cluster, region
• Why — Link to change request, PR, or incident ticket
• How — Pipeline run ID, deployment method, approval chain
• Result — Success/failure, test results, health check outcomes

{
  "event_type": "deployment",
  "timestamp": "2026-05-13T14:32:17Z",
  "service": "payment-service",
  "version": "v2.3.1",
  "environment": "production",
  "deployer": {
    "identity": "ci-bot@company.com",
    "triggered_by": "jane.smith@company.com",
    "method": "merged_pr"
  },
  "change_record": {
    "pr_number": 1847,
    "approvers": ["bob.jones@company.com", "alice.wang@company.com"],
    "approved_at": "2026-05-13T14:28:00Z",
    "ticket": "JIRA-4521"
  },
  "testing": {
    "unit_tests": {"passed": 342, "failed": 0, "coverage": "87.3%"},
    "integration_tests": {"passed": 48, "failed": 0},
    "security_scan": {"critical": 0, "high": 0, "medium": 2, "low": 5},
    "report_url": "https://ci.internal/runs/98765/tests"
  },
  "deployment": {
    "strategy": "canary",
    "pipeline_run": "run-98765",
    "duration_seconds": 340,
    "rollback_available": true,
    "previous_version": "v2.3.0"
  },
  "result": "success",
  "health_check": {
    "status": "healthy",
    "latency_p99_ms": 45,
    "error_rate_percent": 0.01
  }
}

Role-Based Access Control (RBAC)

In enterprise environments, not everyone should be able to deploy to production, modify pipelines, or access secrets. RBAC ensures the principle of least privilege — users get exactly the permissions they need and nothing more.

# GitHub branch protection + environment rules
# Enforces RBAC for production deployments

# .github/settings.yml
branches:
  - name: main
    protection:
      required_pull_request_reviews:
        required_approving_review_count: 2
        dismiss_stale_reviews: true
        require_code_owner_reviews: true
      required_status_checks:
        strict: true
        contexts:
          - "ci/tests"
          - "ci/security-scan"
          - "ci/policy-check"
      enforce_admins: true
      restrictions:
        users: []
        teams: ["senior-engineers", "tech-leads"]

environments:
  - name: production
    protection_rules:
      - type: required_reviewers
        reviewers:
          - team: "production-deployers"
      - type: wait_timer
        wait_timer: 5  # 5-minute delay for awareness
    deployment_branch_policy:
      protected_branches: true

Multi-Team Coordination

When hundreds of teams deploy independently, coordination becomes critical for changes that cross service boundaries. The goal is to minimise coordination — most changes should be deployable independently — but some changes (API breaking changes, shared library upgrades, platform migrations) require synchronisation.

Release Trains (SAFe)

The Scaled Agile Framework (SAFe) introduces Agile Release Trains (ARTs) — fixed-cadence delivery cycles (typically 8-12 weeks) where multiple teams coordinate on larger initiatives. While SAFe is controversial in the engineering community, the release train concept is useful for managing cross-team dependencies in large organisations.

Dependency Management

Cross-team dependencies are the #1 killer of enterprise delivery velocity. Strategies to minimise them:

• API contracts — Teams publish versioned API contracts. Consumers test against contracts, not live services (cross-reference Part 20: Contract Testing)
• Semantic versioning — Breaking changes increment major version, giving consumers time to migrate
• Feature flags — New behaviour ships disabled, then enabled independently of deployment
• Expand-and-contract — Add new API alongside old, migrate consumers, remove old API
• Platform abstractions — Shared concerns handled by the platform, reducing team-to-team coupling

flowchart TB
    subgraph Independent["Independent Deployment (90% of changes)"]
        A[Team A deploys Service A]
        B[Team B deploys Service B]
        C[Team C deploys Service C]
    end

    subgraph Coordinated["Coordinated Changes (10% of changes)"]
        D[API Contract Change]
        E[Shared Library Upgrade]
        F[Platform Migration]
    end

    subgraph Mechanisms["Coordination Mechanisms"]
        G[Contract Testing]
        H[Deprecation Policy]
        I[Migration Runbooks]
        J[Communication Channels]
    end

    D --> G
    E --> H
    F --> I
    Coordinated --> J
                            

Inner Source

Inner source applies open-source development practices within an enterprise. Instead of teams working in silos with private repositories, code is visible across the organisation. Any engineer can propose changes to any codebase through pull requests, subject to the owning team's review and approval.

Inner source principles:

• Open by default — All source code is readable by all engineers (with exceptions for security-critical components)
• Contribution guidelines — Every repository has a CONTRIBUTING.md explaining how to propose changes
• Trusted committers — Each repo has designated reviewers who can merge external contributions
• Documentation — READMEs, architecture decision records (ADRs), and runbooks are maintained
• Shared libraries — Common functionality is extracted into internal packages with semantic versioning

Vendor Management

Enterprise software doesn't exist in isolation — it depends on thousands of third-party packages, libraries, and services. Managing these dependencies at scale requires deliberate processes for security, licensing, and operational risk.

Approved Package Registries

Rather than allowing developers to pull packages directly from public registries (npm, PyPI, Maven Central), enterprises maintain approved internal registries that mirror vetted packages:

# Artifactory/Nexus configuration for approved packages
# Only packages passing security + license checks are mirrored

registries:
  npm-approved:
    type: npm
    url: https://registry.internal.company.com/npm/
    policy:
      security:
        max_critical_vulns: 0
        max_high_vulns: 0
        scan_tool: snyk
      licensing:
        allowed:
          - MIT
          - Apache-2.0
          - BSD-2-Clause
          - BSD-3-Clause
          - ISC
        blocked:
          - GPL-3.0    # Copyleft — requires legal review
          - AGPL-3.0   # Strong copyleft — blocked for SaaS
          - SSPL       # Server-side copyleft — blocked
        review_required:
          - GPL-2.0    # Weak copyleft — case-by-case
      maintenance:
        min_downloads_monthly: 1000
        max_days_since_update: 365
        require_multiple_maintainers: true

SBOM (Software Bill of Materials)

An SBOM is a complete inventory of all components in a software artifact — every dependency, its version, its license, and its known vulnerabilities. SBOMs are increasingly required by regulation (US Executive Order 14028, EU Cyber Resilience Act) and are generated automatically in CI/CD pipelines using tools like Syft, CycloneDX, or SPDX.

Scaling CI/CD

Going from 1 pipeline to 1,000 pipelines introduces challenges that don't exist at small scale: consistency, maintenance burden, cost, and security. The key strategies:

Pipeline Templates & Standards

# Reusable workflow (GitHub Actions)
# .github/workflows/standard-deploy.yml (owned by platform team)
name: Standard Deployment Pipeline

on:
  workflow_call:
    inputs:
      service_name:
        required: true
        type: string
      language:
        required: true
        type: string
        default: "python"
      deploy_environment:
        required: true
        type: string

jobs:
  build-test-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Language
        uses: company/setup-language@v2
        with:
          language: ${{ inputs.language }}

      - name: Run Tests
        uses: company/run-tests@v2

      - name: Security Scan
        uses: company/security-scan@v3

      - name: Build Artifact
        uses: company/build-artifact@v2
        with:
          service: ${{ inputs.service_name }}

      - name: Policy Check
        uses: company/policy-check@v1
        with:
          environment: ${{ inputs.deploy_environment }}

      - name: Deploy
        uses: company/deploy@v4
        with:
          service: ${{ inputs.service_name }}
          environment: ${{ inputs.deploy_environment }}
          strategy: canary

Individual teams then consume this template with minimal configuration:

# Team's pipeline (3 lines of real config)
# payment-service/.github/workflows/deploy.yml
name: Deploy Payment Service
on:
  push:
    branches: [main]
jobs:
  deploy:
    uses: company/platform-workflows/.github/workflows/standard-deploy.yml@v2
    with:
      service_name: payment-service
      language: python
      deploy_environment: production

Centralised vs Federated CI/CD

Balancing Speed & Control

The belief that speed and control are opposites is the fundamental fallacy of traditional enterprise governance. DORA research proves conclusively that elite performers achieve both — they deploy more frequently AND have lower change failure rates than their slower peers.

How elite enterprises achieve both:

• Automation replaces manual gates — Every manual approval that can be expressed as a rule gets automated
• Trust-but-verify — Deploy freely, but monitor continuously. Automated rollback catches issues faster than pre-deployment reviews
• Progressive delivery — Canary deployments, feature flags, and traffic shifting reduce blast radius without slowing deployment
• Shift-left security — Security scanning happens at code commit time, not deployment time. Issues caught earlier are cheaper to fix
• Immutable evidence — Instead of proving you followed a process, prove the outcome. Automated systems generate evidence as a byproduct

flowchart LR
    A[Code Commit] --> B[Automated Tests]
    B --> C[Security Scan]
    C --> D[Policy Check]
    D --> E{Risk Score}
    E -->|Low Risk| F[Auto-Deploy]
    E -->|Medium Risk| G[Additional Review]
    E -->|High Risk| H[Manual Approval]
    F --> I[Canary Deploy]
    G --> I
    H --> I
    I --> J[Health Monitoring]
    J -->|Healthy| K[Full Rollout]
    J -->|Degraded| L[Auto-Rollback]
    K --> M[Audit Log Generated]
    L --> M
                            

Exercises

Conclusion & Next Steps

Enterprise delivery governance is not about choosing between speed and control — it's about encoding control into automation so thoroughly that compliance becomes invisible. The organisations that excel at this don't have fewer controls; they have better automated controls that generate more evidence, catch more issues, and slow delivery less than their manual predecessors.

Key takeaways from this article:

• Traditional CAB meetings slow delivery without reducing risk — replace them with automated change records and peer review
• Compliance frameworks (SOC 2, HIPAA, PCI-DSS) map cleanly to CI/CD controls — make evidence generation automatic
• Policy-as-Code (OPA, Sentinel) enables compliance enforcement at machine speed
• Audit trails must be immutable, complete, and attributable — store them in append-only systems
• RBAC on CI/CD ensures least privilege — not everyone should deploy to production
• Inner source practices improve code quality and reduce silos across large organisations
• Pipeline templates enable consistency at scale while preserving team autonomy
• Elite enterprises prove that speed and control are complementary, not contradictory