Factor IX

Governance Is Composable

Principle

Governance should be composed from reusable, versioned governance artefacts rather than rewritten for every product, project or organisation.

Problem

Large organisations are federated. They have enterprise policies, business-unit policies, project policies, customer overlays and time-bounded exceptions. If every new product, agent or regulator requires a fresh governance stack—or a giant monolithic policy file—the model has already failed.

Without import, overlay, precedence and traceable exceptions, teams fork baselines into private documents until nobody knows what the enterprise standard is. Scale becomes replacement rather than composition.

Characteristics

Reference released governance

Governance should be consumed from released, versioned artefacts rather than copied into every Governance Twin. Referencing preserves provenance, makes dependencies explicit and allows governance to evolve independently of the twins that consume it.

A Governance Twin can reference a released version of a Common Cloud Controls catalogue. Like a software dependency, the referenced artefact has an explicit version, can evolve independently and can be upgraded when the consuming organisation is ready.

Referencing Released GovernanceGemaraA Gemara control catalogue references a released threat catalogue by identifier, version and location. Governance Twins consume published governance artefacts in the same way software consumes versioned libraries.

title: FOSS Contribution Control Catalog

metadata:
  id: foss-contribution-controls
  type: ControlCatalog
  ...
  mapping-references:
    - id: foss-contribution-threat-catalog
      title: FOSS Contribution Threat Catalog
      version: "0.1.0"
      url: https://some.store.url/foss-threats-0.1.0.yaml

controls:
  - id: foss-ctl-001-project-classification
    title: FOSS Project Category Classification
    objective: >
      Ensure every employee FOSS contribution activity is classified into one
      of four project categories and that governed contribution does not proceed
      without the correct category on record.
    ...
    threats:
      - reference-id: foss-contribution-threat-catalog
        entries:
          - reference-id: ungoverned-contribution-activity
 ...   

Extend shared governance

Shared governance should define reusable baselines that can be specialised for a particular organisation, product or sensitive activity. Specialisation retains the relevant parts of the shared baseline while adding more specific controls, obligations or assessment requirements.

For example, an organisation can import the relevant Common Cloud Controls for object storage and add controls governing its own use of personal data. The resulting catalogue remains connected to the shared CCC definitions without copying or modifying them, while introducing governance specific to the organisation and its regulatory context.

Extending a Shared Governance BaselineGemaraAn organisation imports selected Common Cloud Controls for object storage, then adds its own personal-data control and assessment requirements. The shared baseline remains independently versioned and can be upgraded deliberately.

...

metadata:
  mapping-references:
    - id: ccc-objstor-controls
      title: Common Cloud Controls Object Storage Catalog
      version: "2026.06"
      url: https://grc.store/ccc/object-storage-controls/2026.06
    - id: ccc-core-threats
      title: Common Cloud Controls Core Threat Catalog
      version: "2026.06"
      url: https://grc.store/ccc/core-threats/2026.06
  ...

imports:
  - reference-id: ccc-objstor-controls
    entries:
      - reference-id: CCC.ObjStor.CN01
        remarks: Prevent Requests to Buckets or Objects with Untrusted KMS Keys
      - reference-id: CCC.ObjStor.CN02
        remarks: Log All Access and Changes
      - reference-id: CCC.ObjStor.CN03
        remarks: Prevent Bucket Deletion Through Irrevocable Bucket Retention Policy
      ...
       
controls:
  - id: Org.PersonalData.CN01
    group: Personal Data
    title: Prevent Replication of Personal Data Outside Approved Jurisdictions
    objective: |
      Ensure object storage containing personal data cannot replicate data to
      jurisdictions not approved by the organisation's privacy policy.
    threats:
      - reference-id: ccc-core-threats
        entries:
          - reference-id: CCC.Core.TH06
            remarks: Data is Lost or Corrupted
            strength: 2
    assessment-requirements:
      - id: Org.PersonalData.CN01.AR01
        text: |
          When personal data is replicated from the object storage service, the
          destination region MUST be within the organisation's approved
          jurisdictions for personal data processing.
      ...

Parameterise governance patterns

Many governance rules share the same structure while differing only in their configuration. Templates allow governance to expose explicit parameters rather than requiring separate copies for every deployment.

For example, development, UAT and production may all require controls preventing personal data from being replicated outside approved jurisdictions, while differing in the data permitted, enforcement strength, approved regions and evidence-retention requirements. A governance factory can use CUE to instantiate the shared pattern and emit a concrete Gemara control for each environment.

Generating a Parameterised Gemara ControlCUEA CUE template generates concrete Gemara controls for development, UAT and production. Each output retains the same control objective while making its environment-specific configuration explicit.

package governance

import "strings"

environment: "development" | "uat" | "production"

_configurations: {
    development: {
        environmentName:       "development"
        environmentID:         "Dev"
        permittedData:         "synthetic"
        approvedJurisdictions: ["GB", "IE"]
        enforcementStrength:   1
        retentionDays:         30
    }

    uat: {
        environmentName:       "UAT"
        environmentID:         "UAT"
        permittedData:         "masked"
        approvedJurisdictions: ["GB", "IE"]
        enforcementStrength:   2
        retentionDays:         90
    }

    production: {
        environmentName:       "production"
        environmentID:         "Prod"
        permittedData:         "production"
        approvedJurisdictions: ["GB"]
        enforcementStrength:   3
        retentionDays:         2555
    }
}

_config: _configurations[environment]

_controlID:        "Org.PersonalData.\(_config.environmentID).CN01"
_jurisdictionText: strings.Join(_config.approvedJurisdictions, " or ")

output: {
    controls: [{
        id:    _controlID
        group: "Personal Data"
        title: "Prevent Replication of Personal Data Outside Approved Jurisdictions"

        objective: """
            Ensure object storage containing \(_config.permittedData) data in the
            \(_config.environmentName) environment cannot replicate data to
            jurisdictions not approved by the organisation's privacy policy.
            """

        threats: [{
            "reference-id": "ccc-core-threats"
            entries: [{
                "reference-id": "CCC.Core.TH06"
                remarks:        "Data is Lost or Corrupted"
                strength:       _config.enforcementStrength
            }]
        }]

        "assessment-requirements": [{
            id: "\(_controlID).AR01"
            text: """
                Replication destinations MUST be restricted to
                \(_jurisdictionText).
                """
        }, {
            id: "\(_controlID).AR02"
            text: """
                Evidence of replication-policy evaluation MUST be retained for
                at least \(_config.retentionDays) days.
                """
        }]
    }]
}

DEVUATPROD

controls:
  - id: Org.PersonalData.Dev.CN01
    group: Personal Data
    title: Prevent Replication of Personal Data Outside Approved Jurisdictions
    objective: >
      Ensure object storage containing synthetic data in the development
      environment cannot replicate data to jurisdictions not approved by the
      organisation's privacy policy.
    threats:
      - reference-id: ccc-core-threats
        entries:
          - reference-id: CCC.Core.TH06
            remarks: Data is Lost or Corrupted
            strength: 1
    assessment-requirements:
      - id: Org.PersonalData.Dev.CN01.AR01
        text: >
          Replication destinations MUST be restricted to GB or IE.
      - id: Org.PersonalData.Dev.CN01.AR02
        text: >
          Evidence of replication-policy evaluation MUST be retained for at
          least 30 days.

Compose through contracts

Governance is often produced by other teams, organisations and suppliers using their own governance models, tools and execution engines. Consumers should not expect every governance producer to adopt the same implementation technology.

Instead, governance should be exchanged through stable contracts. Like a software API, a governance contract defines the information a producer promises to provide—such as governance definitions, decisions, evidence or obligations— without prescribing how those results are produced. Consumers remain free to interpret that information within their own Governance Twins.

For example, a bank may consume cloud governance published as OSCAL, AI governance published as Gemara, authorisation decisions from an OPA service and manual approvals from a third-party supplier. Each component exposes a different implementation but fulfils an agreed governance contract, allowing them to participate in the same governance architecture without rewriting their native representations.

Consuming OSCAL in GemaraGemaraThe Common Cloud Controls consume a governance contract published by the Cloud Controls Matrix. CCC interprets the published control identifiers within its own governance model without requiring CSA to adopt Gemara or FINOS to adopt OSCAL.

metadata:
  id: CCC.Core
  title: Common Cloud Controls Core
  ... 
  mapping-references:
    - id: CCM
      title: Cyber Controls Matrix
      version: v4.0
      description: |
        The Cloud Controls Matrix (CCM) is a cybersecurity framework developed
        by the Cloud Security Alliance (CSA) to provide a structured and
        standardized set of security controls for cloud computing environments.
        The primary purpose of CCM is to help organizations assess the overall
        security posture of their cloud infrastructure and services.
      url: https://our.server/docs/CCMv4.1.0-oscal_catalog.json
    ...

controls:
 - id: CCC.Core.CN06
    group: Data
    title: Restrict Deployments to Trust Perimeter
    ...
    guidelines:
      - reference-id: CCM
        entries:
          - reference-id: DSP-19
            remarks: Data Location (specify and document processing and backup locations)
            strength: 10  

Publish versioned governance artefacts

Reusable governance should be published to a shared governance repository rather than embedded inside individual Governance Twins. Publishing gives governance a stable identity, version history, ownership and release lifecycle, allowing other Governance Twins to consume released governance exactly as software consumes published libraries.

For example, organisations may publish approved governance artefacts to an internal governance registry, while industry initiatives such as grc.store allow communities to publish reusable governance objects for wider adoption. Governance Twins reference these published releases rather than maintaining private copies.

Positive examples

Common Cloud Controls shared across cloud providers

The FINOS Common Cloud Controls project defines cloud governance once and specialises it for AWS, Azure and GCP. Improvements to the shared control catalogue automatically benefit every cloud provider implementation without rewriting the governance for each platform.

A bank assembles a Governance Twin from published policies

A mortgage approval Governance Twin is assembled from released governance artefacts published by the bank's security, AI governance and compliance teams. Each team owns its own governance, while the product team simply references the approved releases needed for its workflow.

Development, UAT and Production share one governance model

An organisation defines its governance once and parameterises it for development, UAT and production. The environments differ in enforcement mode, approval authorities and permitted data, but all are generated from the same governance template, ensuring governance remains consistent throughout the delivery lifecycle.

A supplier publishes reusable governance

A cloud provider publishes versioned governance artefacts describing its services, controls and evidence. Rather than recreating that governance locally, customers reference the published artefacts within their own Governance Twins, inheriting updates while retaining control over when new versions are adopted.

A lending department governs the complete customer journey

A retail bank's lending department publishes a Governance Twin for the entire mortgage journey by composing the Governance Twins for identity verification, fraud screening, affordability assessment, credit checking, document management and loan approval. The departmental Governance Twin introduces its own obligations, risks and decisions, allowing governance to reason about the customer journey as a whole rather than simply aggregating the status of its constituent activities.

Negative examples

Every project maintains its own cloud controls

A bank copies the Common Cloud Controls catalogue into every cloud project so each team can "customise" it. Two years later, dozens of slightly different versions exist, and a critical security improvement has to be applied manually to every copy.

A mortgage workflow reports 'green' despite conflicting governance

A mortgage approval workflow combines customer identification, fraud screening, credit checking and document storage. Each sensitive activity reports a compliant Governance Twin, yet the overall workflow violates data residency requirements because customer data crosses jurisdictions during composition.

Production and UAT evolve different governance

A team fixes a governance issue in the production Governance Twin but forgets to apply the same change to the UAT version. Months later, governance testing passes in UAT but fails immediately after deployment because the two environments are no longer governed by equivalent policies.

Two organisations cannot share governance

Following an acquisition, the acquiring bank and the fintech both operate equivalent governance, but one publishes Gemara objects while the other uses Cedar policies. Instead of exchanging governance decisions and evidence, the migration team spends months manually rewriting hundreds of governance artefacts before the two businesses can operate together.

Anti-patterns

Copy-and-paste governance

Duplicating policies, controls or Governance Twins rather than composing them from reusable artefacts. Forked governance quickly drifts, making updates expensive and inconsistencies inevitable.

Monolithic governance

Building a single governance artefact that attempts to govern every product, team and regulation. Large governance models become difficult to understand, evolve and reuse.

Pinning incompatible governance versions

A payment processing Governance Twin imports version 2.1 of the organisation's fraud policy while its sanctions screening Governance Twin imports version 3.0. Both activities are individually valid, but they apply different definitions of customer due diligence, leading to inconsistent governance decisions within the same workflow.

Rewriting governance instead of exchanging it

An organisation acquires a fintech whose Governance Twins are implemented using Cedar, while its own governance platform uses Gemara. Rather than exchanging decisions and evidence through a common contract, both teams rewrite hundreds of governance objects into the other's language, introducing errors and permanently duplicating the governance.

Diagram

Modular Governance Composition

Every Governance Twin is both a governance product and a reusable governance module. Higher-level Governance Twins compose lower-level twins, introducing their own obligations, risks and decisions while continuing to consume released governance from the activities upon which they depend.

Discussion

In modern software engineering, systems are built by composing independently developed, versioned and published components. Each component has a clear owner, release lifecycle and public interface, allowing large systems to evolve without every team changing every part at once.

Governance faces exactly the same challenge. Enterprise governance is too large to be developed, versioned and owned as a single artefact. Instead, Governance Twins should be assembled from reusable governance modules published by teams, projects, regulators and industry initiatives. Each module can evolve independently while remaining consumable by the Governance Twins that depend upon it.

This approach naturally separates the responsibilities of governance producers and governance consumers. Producers are responsible for authoring, testing, versioning and publishing governance modules. Consumers are responsible for selecting appropriate releases, composing them into Governance Twins and interpreting them within their own governance context.

Like software, governance composition depends upon a small number of proven engineering principles:

Software Engineering	Governance Engineering
Publish reusable libraries	Publish reusable governance artefacts
Import dependencies	Reference released governance
Extend base classes and interfaces	Specialise shared governance
Configure deployments	Parameterise governance patterns
Publish APIs	Publish governance contracts
Compose applications	Compose Governance Twins

Software engineering did not solve reuse by standardising on one programming language. It solved it by defining stable interfaces (APIs) between independently evolving components.

Governance should do the same: teams, suppliers and regulators should remain free to publish governance using their own native representations, while Governance Twins consume those artefacts through stable contracts rather than common implementations.

Related factors

Composable governance builds on the previous engineering principles:

• Build a Governance Twin — Governance Twins are assembled from reusable governance modules.
• Govern Sensitive Activities — individual Governance Twins become reusable modules within larger business workflows.
• Continuous Governance — composed Governance Twins can be evaluated consistently throughout the software lifecycle.
• Govern Dependencies — governance modules inherit trust, obligations and risk from the governance upon which they depend.
• Governance Has Owners — every published governance module requires clear ownership and an independent release lifecycle.

References

• Gemara — reusable governance objects, imports and mappings.
• grc.store — versioned publication and distribution of governance artefacts.
• OSCAL — reusable control catalogues, profiles and assessment artefacts.
• Common Cloud Controls — shared cloud governance specialised for different providers and environments.
• Cedar — policy templates and parameterised authorisation.
• Open Policy Agent — modular policy packages evaluated at runtime.
• XACML — policy composition and rule-combining algorithms.