Factor III

Governance is Version Controlled

Principle

Treat governance artefacts with the same care and approach as code: it should be versioned, testable, reviewable, composable and deployable.

Problem

Software changes continuously. Governance often does not.

As applications evolve, governance captured in documents, spreadsheets or wiki pages gradually diverges from the systems it is supposed to describe. Engineers implement new behaviour while policies remain unchanged, exceptions accumulate without review and evidence becomes difficult to relate to the version of the system that produced it.

In regulated environments this creates a fundamental problem: organisations can no longer answer simple questions such as "Which governance definition authorised this deployment?" or "Which version of the approval policy was in force when this decision was made?"

Governance that cannot evolve with software inevitably becomes either documentation or bureaucracy.

Characteristics

Review Like Code

Governance changes should be proposed, reviewed and approved before they become operational. Pull requests, peer review and approval workflows create a transparent history of who changed governance, why it changed and when it took effect.

Test Before You Trust

Governance should be validated before it is relied upon. Policies, controls and governance artefacts should be automatically checked for correctness and exercised against representative scenarios to ensure they behave as intended.

Promote Through Environments

Governance should move through development, testing and production alongside the systems it governs. Promoting governance through controlled environments improves confidence while providing a clear record of which governance definition was active at any point in time.

Manage Exceptions Explicitly

Temporary departures from normal governance should be treated as governance artefacts in their own right. Every exception should have an owner, a rationale, an approval, a defined scope and an expiry date so that exceptional behaviour remains visible, auditable and temporary.

Positive examples

Mortgage Approval Policy

The approval thresholds for mortgage decisions are stored in Git, reviewed through pull requests and promoted through development, test and production environments alongside the lending platform.

Production Release Controls

The controls governing software releases are versioned with the build pipeline. Every deployment records exactly which control definition authorised it.

AI Model Approval Policy

The governance rules controlling when a model may be promoted are reviewed and versioned independently of the model itself.

Privileged Access Exceptions

Temporary administrative access is granted through version-controlled exception artefacts with owners, expiry dates and approval history.

Negative examples

Lending Policy in Word Documents

Mortgage approval rules exist in Word documents while the implementation changes independently. Nobody knows whether production reflects the documented policy.

Emergency Production Changes

Firewall or deployment policies are edited directly in production, leaving no review history or reproducible baseline.

Email-Based Exceptions

Critical production exceptions are approved over email and never incorporated into the governance baseline.

Anti-patterns

Governance by attachment

The “real” policy lives in an email or SharePoint folder while systems run on something else. Nobody can say which version was in force.

Copy-paste policy forks

Each team forks the baseline into a private document. Divergence grows until the enterprise standard is a rumour.

Evidence captured after the fact

Definitions and results exist only when someone remembers to write them down for an audit—too late to govern change.

Governance Snapshot

Governance is exported from operational systems into PDFs for an audit, then forgotten until the next assessment.

Diagram

How does governance evolve?

Treat definitions like code: branch, review, merge and promote alongside the software they govern.

Discussion

Applying this principle means putting operational governance on the same rails as software delivery.

For each Governance Twin:

• store its governance artefacts in version control;
• review proposed changes;
• validate schemas and policy definitions;
• promote changes through environments;
• record which version produced which governance decision.

Related factors

Version control is how definitions stay honest as the rest of the model scales:

• Build a Governance Twin — what those versioned artefacts attach to
• Governance Is Composable — how smaller artefacts combine without fork chaos
• Evidence by Default — emitted evidence that cites definition versions
• Continuous Governance — deploying and evaluating definitions in the path of change
• Context In, Decisions Out — executable decision logic stored as artefacts

References

• OSCAL — machine-readable controls, profiles and assessment results
• Gemara — versioned layered GRC artefacts
• Open Policy Agent — policies as testable code
• Cedar — reviewable authorisation policy as code
• CI/CD — validate and promote governance through environments
• SLSA — provenance as a verifiable artefact
• in-toto — signed supply-chain layouts and links