Factor VII

Continuous Governance

Principle

Apply the principles of Continuous Integration and Continuous Delivery to governance.

Governance should be continuously developed, tested, promoted and verified alongside the systems it governs.

Build, UAT and production should each provide progressively more representative feedback loops, ensuring governance evolves with the implementation rather than lagging behind it.

Problem

Governance often receives feedback too late. Policies are written separately from software, exercised only during periodic audits, and first encounter real workloads in production. As a result, governance defects are discovered after they have already created operational risk.

Modern software engineering solved the same problem through Continuous Integration and Continuous Delivery: shorten feedback loops and validate continuously. Governance should follow the same pattern, with progressively richer verification throughout build, UAT and production.

Characteristics

Build-time governance

Governance definitions should be verified as they are developed. Unit tests, policy tests, schema validation and decision-function tests provide rapid feedback that governance behaves as expected before it is promoted further through the lifecycle.

Integration-time governance

Governance should be exercised against representative implementations in development and UAT. Behavioural tests validate that real software, infrastructure, configuration and organisational processes conform to their Governance Twins before reaching production.

Production-time governance

Production systems should continuously produce evidence that is verified against the expected governance posture. Rather than periodic audits, governance becomes an operational capability that detects drift, exceptions and emerging risks as they occur.

Continuous improvement

Each stage forms a feedback loop. Build failures improve governance definitions, UAT failures improve implementations and configuration, and production verification improves both governance and future software changes. Governance therefore evolves continuously alongside the systems it governs.

Positive examples

Policy Unit Tests

Every change to the Governance Twin runs automated policy and decision-function tests during the build. Governance defects are found within minutes, long before they can affect deployed systems.

UAT Behavioural Testing

A representative cloud deployment is exercised using Common Cloud Controls behavioural tests before release. The implementation, configuration and governance are verified together, producing evidence that the system conforms to its Governance Twin.

Production Drift Detection

A live payment platform continuously verifies production evidence against its expected governance posture. Configuration drift and failed controls are detected automatically rather than waiting for the next compliance review.

Governance Promotion Pipeline

Changes to governance definitions are versioned, tested, promoted through development and UAT, and released alongside the software they govern. Both twins evolve together using the same engineering lifecycle.

Negative examples

Annual Compliance Programme

Governance is reviewed once a year through a formal compliance exercise. Problems are discovered long after they were introduced, making them expensive to understand and correct.

Production as the Test Environment

A new governance policy is first exercised against live production systems after deployment. The organisation has no confidence that the policy behaves correctly before it begins affecting real users and services.

Untested Configuration Changes

An application passes all software tests, but a small production configuration change bypasses an important governance control. The implementation was tested, but the deployed socio-technical system was never verified against its Governance Twin.

Governance by Committee

Governance changes are approved through meetings and documentation reviews but are never exercised against representative systems before release. The organisation validates the paperwork rather than the behaviour.

Passing Infrastructure Tests

A cloud deployment successfully provisions through Infrastructure-as-Code and all resources are created correctly. However, no behavioural verification is performed, so the organisation knows the infrastructure exists but not whether it actually conforms to its intended governance.

Anti-patterns

Testing only one stage

Assuming governance only needs to be verified during build, only in UAT or only in production. Each stage provides different feedback, and removing one weakens the overall governance lifecycle.

Treating every stage the same

Running identical governance checks everywhere. Build, pre-production and production should each verify different aspects of governance using increasingly representative implementations and evidence.

Blocking everything

Good governance uses a range of responses, including warnings, obligations, remediation and observation, depending on the stage and the risk.

Ignoring feedback

Collecting evidence and posture but never using it to improve governance definitions, implementations or operational practices. Continuous governance is a feedback system, not simply continuous measurement.

Diagram

Governance Through the Lifecycle

The Implementation Twin and Governance Twin progress together through build, pre-production and production, with each stage providing increasingly representative verification and feedback.

Stage	Implementation Activities	Governance Activities
Build	Build and unit-test the Implementation Twin.	Test and validate the Governance Twin and decision functions.
Pre-production	Deploy representative instances of the Implementation Twin.	Exercise the Governance Twin against representative implementations.
Production	Operate the live Implementation Twin and emit evidence receipts.	Continuously verify the Implementation Twin against the Governance Twin, updating governance posture.

Discussion

Continuous Governance applies the principles of Continuous Integration and Continuous Delivery to governance itself.

Software engineers do not wait until production to discover whether their implementation works. They build fast feedback loops throughout the delivery lifecycle, progressively increasing confidence as software moves from build to development, pre-production and finally production. Governance should follow exactly the same pattern.

Each stage of the lifecycle exercises a different aspect of the system. Build verifies the Governance Twin itself: schemas, policy definitions and decision functions. Pre-production verifies that representative implementations, configurations and organisational processes conform to their Governance Twins using behavioural tests. Production completes the loop by continuously verifying operational evidence, updating governance posture and identifying drift as the socio-technical system evolves.

Applying this principle means:

1. Develop governance as an engineering artefact, versioning, reviewing and testing it alongside the software it governs.
2. Verify governance continuously throughout the delivery lifecycle, not just before release or during periodic audits.
3. Use increasingly representative environments, validating governance definitions in build, implementations in pre-production and operational behaviour in production.
4. Produce evidence at every stage, allowing governance to be explained, verified and improved using objective data rather than manual attestations.
5. Close the feedback loop, using verification results to improve both the Governance Twin and the Implementation Twin before promoting further changes.

This follows the same engineering principle described in Risk-First's Cadence Chapter: feedback loops should operate at the cadence appropriate to the decisions they influence. Fast loops provide cheap, rapid correction during development, while slower loops validate behaviour under increasingly realistic conditions. Continuous Governance therefore uses multiple nested feedback loops rather than relying on a single production monitoring loop or periodic compliance review.

Related factors

Continuous Governance brings the previous factors together into an engineering lifecycle:

• Govern Sensitive Activities — identifies which activities require continuous verification throughout the lifecycle.
• Build a Governance Twin — provides the governance artefacts that are developed, tested and promoted alongside the implementation.
• Context In, Decisions Out — defines the decision functions exercised during build, pre-production and production.
• Evidence by Default — provides the evidence that drives verification, posture and continuous improvement.
• Governance Has Owners — ensures verification results lead to remediation and governance improvements.

References

• Open Policy Agent — admission and continuous policy evaluation
• Gatekeeper — Kubernetes admission and audit modes
• Kubernetes — admission controllers in the path of change
• Flux — policy gates in continuous delivery
• Gemara — measurement layers that map to evaluate / enforce / audit