Governance Body

A governance body is a standing group with authority to decide a defined class of questions on behalf of the organization: an investment committee, an architecture board, a change approval board, a risk committee. The word standing distinguishes it from a working group that disbands, and defined class is where most of the trouble starts.

NIST’s risk management strategy definition emphasizes making the basis of investment and operational decisions explicit. A governance body can provide authority and a wider view for such decisions. Its coordination and review effort have costs that should be justified by the decisions it is assigned.

A mandate that can be read

A written mandate helps requesters find the right authority and prevents advisory work from quietly becoming a mandatory gate. It should make the following boundaries usable.

1. Which decisions are its own, and which it only advises on. A body whose advice is treated as approval has a veto nobody granted it; the underlying allocation is the subject of decision rights.
2. The delegation boundary. State which decisions a team is authorized to make, with scope, exposure limits, evidence, and required escalation. Being below a numerical threshold alone does not grant permission.
3. What evidence a decision requires, so that preparation is a checklist rather than a guess at what the room will ask.
4. A clock. Match cadence and response targets to the decision class, with an escalation route for missed targets. With no backlog or submission cutoff and arrivals uniformly spread over the cycle, a fortnightly meeting adds an average of seven days of waiting for the next meeting, ranging from zero to fourteen. Actual waits depend on arrival time, preparation, and capacity.
5. Where the decision is recorded, in a form the next reader can find, so later readers can distinguish an applicable precedent from a decision that needs revision. See decision record and, for design choices, architecture decision record.

The test for whether a body should decide this

A repeatable rule may be implemented as policy as code. First compare its protection, input quality, maintenance cost, and residual judgment with the existing review. A rule that is cheap to check manually on rare occasions may not justify automation. When automated, it needs a protected policy enforcement point on each relevant path; machine readability alone does not enforce it.

DORA’s change-approval guidance reports worse delivery performance associated with heavyweight external approvals and no evidence that more formal review was associated with lower change fail rates. It describes delays and larger batches as a supported explanation for greater deployment risk. These findings concern software delivery; applying the reasoning to other governance domains requires examining their risks and authority needs.

The guidance warns that a centralized reviewer may lack implementation context. It also retains strategic coordination and business tradeoffs as reasons for higher-level involvement. Escalate when wider knowledge, risk scrutiny, or authority is needed, while keeping routine checks close to the work. Physical or organizational distance alone does not establish review quality.

Matching a body to its decisions

Body	Decides well	Should delegate
Investment or portfolio	What is funded, what is stopped, and what trade-off between initiatives the organization accepts	How the funded work is built
Architecture	Commitments that bind others: interfaces between domains, data ownership, an expensive platform choice	Choices within the team’s delegated authority, with records and any required checks
Change or release	Coordination of conflicting plans, high-risk scrutiny, and business decisions requiring wider authority	Routine changes within approved scope, using peer review and automated checks that meet applicable requirements
Risk	Accepting exposure on behalf of the organization, and setting the thresholds others apply	Assessing individual findings, which belongs with the teams that own the systems

These allocations are design examples. DORA recommends peer review with automation for routine software approval; the organization still needs to define the permitted scope and check that it provides the required protection. A body can retain genuinely shared decisions without becoming the queue for every implementation detail.

How a mandate breaks down

• Advisory in the charter, gate in practice. Nobody proceeds without the nod, so the body holds authority without owning the consequence.
• Uniform treatment. DORA cautions against treating all changes alike. Allocate scrutiny by the change’s assessed risk and authority requirements rather than applying the same ceremony everywhere.
• Adding approval after every failure. DORA warns that heavier approval can increase delays and batch sizes. Identify the failure a proposed review would address and compare it with changes to testing, deployment, or recovery.
• Membership without authority. Delegates who must check with someone else turn one meeting into two, which is a hidden multiplier on the wait.
• Unrecorded decisions. The same question returns in six months and is decided differently, which teaches teams that the outcome depends on who attends. A body without a retrievable record generates precedent it cannot cite.

Judging a body

Read waiting time by decision class, as described in decision latency, alongside what review verified or changed and what happened afterward. Include pre-submission changes and withdrawn proposals. An approval rate near 100% does not distinguish sound proposals from ineffective review; required independent verification can be useful without altering a proposal. Compare delegation shares within similar classes and risk ranges rather than requiring them always to rise.

Bodies are also where accountability is assigned or lost, and the distinction between being responsible for work and being answerable for its outcome is covered in responsibility and accountability.

How decision rights, bodies, automated controls, and latency fit together in a technology organization is worked through in Forty Approvals and Two Rejections.

References

• DORA, Capabilities: Streamlining change approval — the goals of an approval process, the reported effect of external approval boards, the stated mechanism, and the listed pitfalls.
• NIST Computer Security Resource Center Glossary, risk management strategy. The definition summarized here is attributed on the page to NIST SP 800-160 Vol. 2 Rev. 1, drawing on NIST SP 800-39.