Technology Governance Roles and Operating Model

Consider a fictional architecture review board after its first year. Its minutes show forty requests approved, two rejected, and one withdrawn. The average time from submission to decision is nineteen days.

Two questions about that record are hard to answer. What did the forty approvals change about what was built? And where did the work go that never came to the board — the analytics environment on a corporate card, the vendor trial that became a production dependency, the second messaging system that arrived as a library?

Those counts do not establish whether the board helped. It might have verified sound proposals, prompted changes before submission, or delayed work without useful scrutiny. Governance determines who decides what, within which authority, on what basis, and with what record. Evaluating this board requires evidence about those decisions and their consequences.

The question governance answers

Management organizes how work gets done; governance assigns decision authority and makes its exercise accountable. NIST’s definition of a risk management strategy connects assessment, response, and monitoring with an explicit basis for investment and operational decisions. That basis lets others understand why a choice was authorized and when it needs reconsideration.

Investment, architecture, change, and risk illustrate how decision scope affects the authority and response time needed. These are useful design categories, not an exhaustive framework.

Domain	The decision	Who is usually best placed
Investment	What gets funded, what stops, what trade-off between initiatives is accepted	A body, because the decision is a comparison across things no single team can see
Architecture	Commitments that bind other teams: interfaces, data ownership, platform choices	A body or designated authority for cross-team commitments; the team within its delegated scope
Change and operations	Whether a specific change may proceed now	The team within its delegated scope, using peer review and automated checks; higher-risk changes, conflicting plans, and business approvals follow the relevant authority path
Risk	Whether to accept an exposure, and the thresholds others will apply	The accountable owner for acceptance; a body for the thresholds

Applying a scheduled committee process to every operational decision can create avoidable waiting. Use the fictional board’s record to investigate whether that happened, rather than inferring it from the approval counts.

Decision rights come before bodies

List the decisions, assign their holders, and then choose the instruments that support them. For each class, state who decides, who must be consulted, and who is informed, together with scope, limits, required evidence, and escalation when those limits are exceeded. The allocation is the subject of decision rights, and responsibility and accountability distinguishes doing the work from answering for its outcome.

An accountability gap appears when everyone is consulted but nobody has authority to decide. A different failure occurs when the only available forum accumulates decisions beyond its mandate. A maintained authority record should let a requester find the appropriate owner; needing to consult that record is normal, while finding no owner or conflicting assignments exposes a gap.

An authorized decision with reusable scope can guide later work through a decision record or, for design choices, an architecture decision record. Record the authority, assumptions, and limits as well as the outcome. A precedent helps only while those conditions still apply; the existence of a document alone does not grant delegation.

Committees and automated controls do different work

A repeatable rule is a candidate for automation. Compare the protection it provides with the review it would replace: can the inputs be trusted, can every relevant path enforce it, and does any required judgment remain? Include implementation, maintenance, and exception-handling costs; a rarely used rule may be cheaper to check manually. Implementation options include a service control policy and policy as code. A policy enforcement point must apply the rule where work can be allowed or blocked, with bypass and rule changes controlled.

DORA’s change-approval guidance, drawing on its 2019 State of DevOps research, reports worse delivery performance associated with heavyweight external approval and no evidence that more formal external review was associated with lower change fail rates. It describes a supported hypothesis: approval delays encourage larger, less frequent releases, whose impact can increase risk. This supports examining routine software delivery gates; it does not establish that every approval increases risk or that the same effect holds for every investment decision.

DORA also warns that reviewers far from the implementation can miss its implications. It retains a role for coordination and business tradeoffs requiring higher authority, and recommends extra scrutiny for high-risk changes. For governance design, ask what knowledge or authority an escalation adds. Cross-team commitments and difficult-to-reverse choices can need wider review even when routine deployment checks remain close to the team.

For routine software changes, DORA recommends peer review during development, supported by automated checks. Apply that pattern within the organization’s authorization requirements. The mandate of a reviewing body is covered in governance body; the judgment about a particular deployment is covered in release gate.

The cost of waiting for approval

Approval consumes reviewer effort and requester time. In the fictional example, nineteen days is an average, not the wait imposed on every request. Compare waits within decision classes and examine their consequences. Decision latency explains how to define the measurement boundary and distinguish preparation, queueing, deliberation, and communication.

Delay can encourage larger batches or workarounds, and a late decision may address a proposal whose options have already changed. Work outside the prescribed path may still leave contracts, messages, or system logs; recover and correlate that evidence instead of assuming it is unreviewable. Where refusal has little visible cost but approval exposes the decider to blame, examine whether incentives discourage reasonable decisions. These are mechanisms to investigate locally, not inevitable outcomes of waiting.

DORA cautions against responding to instability by adding heavyweight approval indiscriminately. Added delay can reinforce the batch-size problem. Review an incident’s specific failure mode and ask whether the proposed control would detect or prevent it, then compare its protection and delay with alternatives.

The same guidance associates a clear understanding of the approval process with better delivery performance. Publishing the authority path and evidence requirements removes avoidable uncertainty. A supported default can also reduce requests within an agreed scope, as explained in standard development paths and the platform contract. Its effect must be assessed locally; the clarity finding does not establish that this design has a larger effect.

Separation of duties without a committee

Separation of duties is sometimes implemented through independent approval of changes. DORA describes that requirement in its change-approval guidance; which obligations apply to a particular organization must be established from its applicable rules. NIST’s access-control definition focuses on preventing one user from having enough privileges to misuse a system alone.

A committee is one way to supply independent review, but a qualified peer with the required authority may provide it. DORA recommends preserving reviews and approvals in the development platform. Automation can enforce a previously authorized policy; it does not replace an independent person where that approval is required. Protect the policy, evidence, and bypass permissions from the person whose work is being checked. Separation of duties develops these implementation choices and the limits of compensating controls.

For delivery, ask who can change the verifier, approval evidence, trusted inputs, or deployment permissions. A shared orchestration system can enforce an independent check if the build cannot alter or bypass it. Separate identities provide little protection if one can impersonate the other. Bind the check to the artifact actually deployed, as explained in The Pipeline Had the Keys.

Where governance meets risk and exceptions

Risk thresholds help define a team’s delegated scope, but they do not themselves confer authority. Specify the affected systems, permitted consequences, evidence, and conditions that require escalation. For service reliability, risk tolerance explains acceptable failure and degradation. Investment, security, and binding obligations need their own criteria and authorized decision holders; the reliability threshold does not settle them.

Where policy permits a departure, record the authorized exception, its scope, owner, review conditions, and expiry. Vulnerability exception and Twelve Thousand Findings show how this works for vulnerabilities. Internal approval cannot waive a binding external obligation. If an exception is unavailable, stopping, rejecting, or redesigning the work are valid outcomes. A usable exception path can reduce hidden workarounds where departures are permitted, but not every unmet standard is eligible.

Both connect to the controls themselves, whose types and evidence are covered in security control and, in the risk vocabulary, risk control. Where a change still needs coordinated approval, the process side belongs to change enablement and the wider service structure to ITSM, ITIL, and the operating model.

Judging the governance itself

Assess governance using comparable decision classes and periods. The following measures help locate costs and failures; none establishes value alone.

• Wait per decision class, median and tail. The tail is what teams plan around.
• Share of decisions delegated within each class and risk range. Interpret changes alongside the mix of requests, outcomes, and required authority; a lower share can be appropriate when exposure rises.
• Review findings and consequences. Include changes before submission, withdrawn proposals, verified requirements, and later outcomes. A high approval rate can reflect sound proposals or ineffective scrutiny; even no alterations can be consistent with useful independent verification.
• Standards with automated enforcement. Distinguish rules that are merely machine-readable from checks that actually cover the relevant paths. Track exceptions, maintenance effort, and remaining human decisions alongside waiting time.
• Decisions outside the prescribed path. Investigate unmanaged accounts, vendor commitments, and environments without owners. Correlate available evidence to distinguish unauthorized work from an authorized route missing from the central record.
• Open exceptions with an owner and an expiry, against those that expired and are still in force.
• Reasons decisions are reopened. Separate missing records and avoidable rework from new evidence, appeals, or correction of an earlier mistake. Preserve authority and rationale in decision records or retained minutes, and connect them to execution evidence in the audit log. Logs and minutes answer different questions.

Policies, committee calendars, approval rates, and incident counts each describe part of the system. Read them with evidence of actual decisions and control performance. A quiet quarter alone cannot show whether a control prevented failures, and a busy calendar cannot show whether its decisions justified the wait.

These questions also apply to data governance and Platform Engineering and the responsibility boundary. Repetitive manual gates associated with running a production service can be toil when they provide little enduring value and could be automated or designed away. Google’s SRE definition distinguishes that operational work from administrative overhead and lasting improvements. Count each kind of work accurately before choosing an engineering investment.

What a working arrangement can say

A usable arrangement lets teams find who holds a decision and the limits of that authority. Automate repeatable checks where they provide appropriate protection at a justified lifecycle cost, and retain required judgment and approval. Measure the wait for the decisions that remain. When a standard cannot be met, route the choice to authorized exception, redesign, rejection, or suspension rather than assuming permission.

For the fictional board, investigate what reviewers verified or changed, what happened before submission, and why some work used other paths. Combine that evidence with waiting time and outcomes before deciding which reviews to retain, delegate, or automate. Forty approvals alone cannot answer those questions.

References

• DORA, Capabilities: Streamlining change approval — the goals of approval, segregation of duties as a requirement, the reported effect of external approval boards, the stated mechanism, the listed pitfalls, and the recommendation of peer review with automation. The page presents these as findings from the 2019 State of DevOps Report.
• 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.
• NIST Computer Security Resource Center Glossary, separation of duty. The definition summarized here is attributed on the page to NIST SP 800-192.
• Google, Site Reliability Engineering, Eliminating Toil — operational toil, administrative overhead, and enduring engineering work.