Factor II
Build a Governance Twin
Every implementation of a sensitive activity should have a corresponding Governance Twin.
The Implementation Twin describes how the activity works. The Governance Twin describes how it is governed.
Problem
Identifying a sensitive activity does not make it governable.
A mortgage approval may be implemented across an application form, decision service, affordability model and case-management system. The implementation knows how to execute the activity, but it does not necessarily describe why the activity is sensitive, which organisational policies apply, which risks must be controlled, or what requirements must be satisfied.
Without a separate governance representation, that knowledge is scattered across regulations, policy documents, control catalogues, tickets and the assumptions of individual teams. The organisation may know that mortgage approval should be governed, but it cannot reliably determine what governing it entails.
A Governance Twin places that governance definition alongside the software implementation. It creates a concrete, machine-readable representation of how one specific activity is expected to operate.
See the section on Governance Artifacts to see how the governance twin is modelled in practice.
Characteristics
Two twins of the same activity
The Implementation Twin and Governance Twin describe the same activity from different perspectives.
The Implementation Twin describes how the activity is performed: its software components, inputs, outputs, decisions and runtime behaviour.
The Governance Twin describes how the activity is governed: the guidance it follows, the risks it creates, the controls it requires and the organisational policy that authorises it.
Neither replaces the other. Governance must remain connected to implementation, but should not be hidden inside it.
Twins evolve together over the lifecycle
An activity’s Implementation Twin and Governance Twin are not set once and forgotten. They move together as requirements change.
When the activity is first designed, the Implementation Twin names the intended components and flows; the Governance Twin records which guidance, controls and policy will apply. As the system is built and released, implementation details harden—new services, models or interfaces appear—and the Governance Twin must gain or tighten the definitions that authorise those behaviours.
When the activity is retired or replaced, both twins should close together: governance definitions are withdrawn or superseded rather than left attached to software that no longer exists.
Governance twins are Scoped to a single sensitive activity
A Governance Twin should be scoped to the sensitive activity being governed.
A lending platform may perform many activities: receiving applications, verifying identity, calculating affordability, approving mortgages, issuing documents and disbursing funds.
The Governance Twin for Approve Mortgage should describe the governance of that decision. It should not become a general model of the entire lending platform (although see Governance is Composable)
Its dependencies may influence its governance, but those relationships are addressed explicitly in Govern Dependencies.
Positive examples
Mortgage approval in a lending platform
The Implementation Twin describes the decision service, application inputs and resulting approval decision. The Governance Twin attaches fair-lending guidance, approval controls, affordability policy and the risks of discriminatory or unsuitable lending.
Trade execution in an order-management system
The Implementation Twin describes the order, execution venue, trader or algorithm and resulting trade. The Governance Twin attaches market-conduct guidance, pre-trade controls, permitted trading policy and risks such as manipulation or unauthorised trading.
Privileged-access approval in an identity platform
The Implementation Twin describes the access request, approver, target system and granted permissions. The Governance Twin attaches least-privilege guidance, approval and segregation-of-duties controls, access policy and the risk of unauthorised administrative access.
AI-generated credit recommendation
The Implementation Twin describes the model, supplied customer facts, recommendation and confidence information. The Governance Twin attaches responsible-AI principles, bias and explainability controls, credit policy and risks arising from unfair or unreliable recommendations.
Negative examples
A twin of the lending platform as a whole
One governance object covering mortgage approval, identity verification, document production and fund disbursement—too broad to say which requirements apply to which decision.
Fair-lending policy with no link to the approval activity
Organisational policy and controls exist, but nothing associates them with the actual approval activity in the lending system.
Decision-service config treated as the policy
Technical behaviour is assumed to express organisational intent, so nobody can tell whether the implementation satisfies the policy.
Anti-patterns
Governing the application rather than the activity
A single “Lending Platform Governance Twin” combines mortgage approval, identity verification, document production and fund disbursement. The resulting governance definition is too broad to say which requirements apply to which decision.
Governance disconnected from implementation
The organisation has fair-lending policies and mortgage controls, but nothing associates them with the actual approval activity in the lending system.
Implementation treated as its own governance definition
The decision service’s configuration is assumed to express organisational policy. Technical behaviour and governance intent become inseparable, making it difficult to identify whether the implementation actually satisfies the policy.
A twin with no governance artefacts
The activity has a catalogue entry, owner and technical metadata, but no linked guidance, controls, risks or policy. It is an inventory record, not a Governance Twin.
Diagram
How it works ↔ how it is governed
The Implementation Twin and Governance Twin describe the same sensitive activity from different perspectives. The Governance Twin is composed of Governance Artefacts.
Discussion
A Governance Twin is the governance definition of a specific sensitive activity, maintained alongside the software that implements it.
The previous factor identifies activities that deserve governance—for example, mortgage approval. This factor requires the lending system’s implementation of that activity to have a corresponding governance representation: what the organisation expects of the activity, why, and under what conditions it may operate.
Putting this into practice:
- Start from the sensitive activity — name the sensitive activity, not the platform that hosts it.
- Identify the Implementation Twin — the components, configuration, environment, inputs, decisions and outputs that perform the activity.
- Identify the governance artefacts - the Guidance, Controls, Policy, Risks etc. that apply.
- Bind those artifacts to the implementation to create a Governance Twin.
- Repeat for every implementation of that activity - Development, UAT, Production, using the same governance definitions but different operational context.