Templates: Governance and Exceptions
The records that hold the operating model together: exceptions, gate minutes, the regulatory mapping, the capability and benefit records, and a terms of reference that survives its first difficult meeting.
These are the least glamorous records in the set and the first ones an auditor asks for. Each answers a question the others cannot: who allowed this, on what basis, against which obligation, and did it deliver anything.
[Practice recommendation] Fields are marked All, T2+, T3+ or T4. A Tier 1 record that fills every Tier 4 field is not more rigorous, it is less honest: the fields stop being answered and start being completed. Delete what your tier does not require and keep the record short enough that people read it.
Architecture Exception
- Purpose
- A time-boxed, owned departure from a standard, pattern or control
- Owner
- Requester; approved by the authority for the affected tier
- Created at
- Any point
- Approval
- Tier-scaled; Tier 3–4 exceptions require the AI Governance Body
- Update
- Reviewed at expiry — extension is a new decision, not a renewal
- Retention
- 3 years after expiry
- Related
- ADR, Control Matrix, Deployment Authorization Record
Download
Architecture ExceptionDOCX · 12 KB
| Field | Required at | What good looks like |
|---|---|---|
| What is being departed from | All | The specific requirement, cited. “Best practice” is not a requirement. |
| Why | All | The business reason and the alternative that was rejected. |
| Risk created | All | Named specifically, and mapped into the Control Matrix as residual risk. |
| Compensating controls | T2+ | What reduces the risk in the meantime, and who owns each. |
| Expiry date | All | A date, not a milestone. Exceptions tied to “when the platform migration completes” never expire. |
| Named owner | All | The person who must close it, who is not the person who benefits from it. |
| Approval authority | All | Matched to the tier of the system, not the seniority of the requester. |
| Extension history | T2+ | Every extension with its reason. Three extensions is a design decision in disguise; make it one. |
How to fill it. The health of an exception register is measured by expiry, not by count. A register where most entries are within their window is working; one where half are expired is a list of things nobody intends to fix.
Plain-text version to copy into your own tooling
ARCHITECTURE EXCEPTION
Reference: System: Tier: Raised:
Requirement departed from (cited):
Reason; alternative rejected:
Risk created (specific):
Compensating controls and owners:
Expiry date (a date):
Named owner to close:
Approval authority:
Extension history:
Gate Decision Minute
- Purpose
- The decision taken at a gate, its basis, and its conditions — in one page
- Owner
- The chair of the deciding body, or the deciding individual at Tier 1–2
- Created at
- At each gate
- Approval
- The minute is the record of approval
- Update
- Conditions tracked to closure
- Retention
- Life of system plus 3 years
- Related
- All records the gate consumed
| Field | Required at | What good looks like |
|---|---|---|
| Gate, system, tier, date | All | So the minute can be found by any of them. |
| Records relied on, with versions | All | Versions matter: a decision taken on version 3 of an assurance summary is not a decision about version 5. |
| Decision | All | Approve / approve with conditions / remediate / escalate / reject. |
| Conditions with owners and dates | All where applicable | Unowned conditions are the most common cause of gate decisions that mean nothing. |
| Questions asked and answered | T3+ | Two or three lines. This is what makes the minute useful a year later, and it is what a regulator reads. |
| Dissent | T3+ | Recorded with its disposition. A body that never records dissent is not deciding, it is confirming. |
| Attendance and quorum | T3+ | Including who was absent for a decision in their domain. |
How to fill it. Write the questions section. Everything else in a gate minute can be reconstructed from other records; the questions the body actually asked cannot, and they are the difference between governance and a signature workflow.
Plain-text version to copy into your own tooling
GATE DECISION MINUTE
Gate: [G1-G5] System: Tier: Date: Chair:
Records relied on (with versions):
Decision: [approve / with conditions / remediate / escalate / reject]
Conditions (owner, date):
Questions asked and answers given:
Dissent and disposition:
Attendance / quorum / notable absences:
Regulatory Overlay Reference
- Purpose
- Which regimes apply to which systems, so a regulatory change has a known blast radius
- Owner
- Risk and Compliance Lead
- Created at
- On adoption; maintained continuously
- Approval
- Reviewed at least annually and on any regime change
- Update
- A change in any mapped regime is a drift event
- Retention
- Permanent, versioned
- Related
- Control Matrix, Risk Classification Record, sector overlay
| Field | Required at | What good looks like |
|---|---|---|
| Regime or obligation | All | Including contractual obligations, which are often stricter than regulation. |
| Jurisdiction and applicability test | All | What makes a system in scope. Written so someone else can apply it. |
| Systems affected | All | The list, maintained. This field is the entire point of the record. |
| Obligations in practice | T2+ | What it requires you to be able to show, not a summary of the text. |
| Records carrying the evidence | All | Which IRGF record answers each obligation. |
| Monitoring source | T2+ | How you find out the regime changed — a feed, a subscription, a person. |
| Last reviewed and by whom | All | A mapping nobody has reviewed for two years is a liability, not an asset. |
| Open gaps | T3+ | Obligations with no record behind them yet, with an owner. |
How to fill it. This is the record that makes policy and regulatory drift detectable at all. Without the systems list, a regime change requires somebody to remember which systems are affected — which is not a control.
Plain-text version to copy into your own tooling
REGULATORY OVERLAY REFERENCE
Per regime:
Regime / obligation (incl. contractual):
Jurisdiction and applicability test:
Systems affected (maintained list):
What it obliges in practice:
IRGF records carrying the evidence:
Monitoring source:
Last reviewed / by:
Open gaps and owners:
Capability Record
- Purpose
- Baseline and target maturity for a business capability, and whether AI is enabling it
- Owner
- Sponsor with Architect
- Created at
- T1
- Approval
- Portfolio governance
- Update
- On re-baselining, at least annually
- Retention
- Permanent, versioned
- Related
- AI Use-Case Canvas, Benefit Record, Business Capability Map (derived)
| Field | Required at | What good looks like |
|---|---|---|
| Capability name and owner | All | From the capability map, not invented per initiative. |
| Current and target maturity | All | On whatever scale you already use. Do not introduce a new one for AI. |
| Gap and consequence | All | What the gap costs, so the AI question has a baseline to beat. |
| AI-enablement flag | All | Whether AI is part of the intended path, and which use cases attach. |
| Dependencies | T2+ | Capabilities that must move first. |
| Re-baseline date | T2+ | Capability drift is not telemetry-detectable; it is caught by re-baselining, which means the date has to exist. |
Plain-text version to copy into your own tooling
CAPABILITY RECORD
Capability: Owner: Date:
Current maturity: Target maturity: Gap and its consequence:
AI-enablement flag and attached use cases:
Dependencies:
Next re-baseline date:
Benefit Record
- Purpose
- Realized value against the baseline the use case claimed
- Owner
- Sponsor
- Created at
- T6, after value should have appeared
- Approval
- Portfolio governance
- Update
- At each measurement point until closed
- Retention
- 3 years
- Related
- AI Use-Case Canvas (the baseline), Capability Record, Benefit Map (derived)
| Field | Required at | What good looks like |
|---|---|---|
| Claimed outcome and baseline | All | Copied from the canvas, unedited. Editing it is how benefits are always realized. |
| Measured outcome | All | The same measure, measured the same way. |
| Attribution | T2+ | What else changed in the period. Honest attribution is rare and valuable. |
| Cost to date | T2+ | Including the governance and operating cost, not only the build. |
| Decision | All | Continue, change, restrict or retire. A benefit record with no decision is reporting. |
| Learning | T2+ | What this says about the next use case of the same kind. |
How to fill it. The framework's honesty depends on this record being allowed to say no. A portfolio where every benefit record reports success is not measuring.
Plain-text version to copy into your own tooling
BENEFIT RECORD
System / initiative: Sponsor: Measured on:
Claimed outcome and baseline (copied from canvas, unedited):
Measured outcome (same measure, same method):
Attribution / what else changed:
Cost to date (build + run + governance):
Decision: [continue / change / restrict / retire]
Learning for the next use case:
Governance Body Terms of Reference
- Purpose
- What a body decides, who sits on it, and what it must not decide
- Owner
- The body's chair
- Created at
- On standing the body up
- Approval
- Enterprise governance
- Update
- Annually, and after any escalation that exposed a gap
- Retention
- Permanent, versioned
- Related
- RACI, Escalation policy, Gate decision minutes
| Field | Required at | What good looks like |
|---|---|---|
| Mandate | All | In two sentences. Long mandates are a sign the body has absorbed work it should delegate. |
| Decisions held | All | Specific: which gates, at which tiers, plus standing decisions such as pattern ratification. |
| Decisions explicitly not held | All | The field that prevents scope creep. Keeping “is this the right architecture” separate from “is this safe to run” is the reason there are two bodies. |
| Membership and required expertise | All | Including the expertise that must be present for a decision to be valid. |
| Quorum and decision rule | All | And what happens when quorum fails — usually defer, not delegate. |
| Cadence and capacity | T2+ | Decisions per meeting, realistically. This is the scaling limit every AI governance body hits, and it is better faced in the terms of reference than in a queue. |
| Escalation in and out | All | What arrives here and where it goes when this body cannot resolve it. |
| Conflict of interest rule | T3+ | How a member with delivery accountability for the item participates. |
How to fill it. Write the capacity line honestly. Two bodies exist instead of six so that queues stay short; if the calculation shows the body cannot handle the expected volume, the answer is more self-certification against patterns, not longer meetings.
Plain-text version to copy into your own tooling
GOVERNANCE BODY TERMS OF REFERENCE
Body: Chair: Version / date:
Mandate (two sentences):
Decisions held (gates, tiers, standing decisions):
Decisions explicitly NOT held:
Membership and required expertise:
Quorum and decision rule; behaviour when quorum fails:
Cadence and realistic decisions per meeting:
Escalation in / out:
Conflict of interest rule: