Decision Rights: Who Recommends, Decides, Approves, and Executes?

October 8, 2026
2:33 am

TLDR: An organizational decision rights framework assigns one final decision owner, identifies any governing authority that retains oversight, names the people who must contribute or be informed, and defines the guardrails and escalation triggers. Start with a short list of recurring or consequential decisions rather than trying to map every choice at once.

Many organizations do not have a participation problem. They have an authority problem. Several people discuss an issue, someone recommends an option, another person assumes approval is required, and a team begins work without knowing who can make the final call. The result is delay, duplicated review, or a decision that must later be reversed.

A decision-rights map makes authority visible without concentrating every choice at the top. It separates governing oversight from operating authority and distinguishes the person who decides from the people who recommend, approve within a defined process, execute, advise, or receive notice.

What an organizational decision rights framework does

Decision rights define who has authority over a particular class of decisions and under what conditions. They complement job descriptions, committee charters, policies, budgets, contracts, and project plans. They do not replace them—or override governing documents or applicable law.

This distinction matters because governance and management are related but different functions. The G20/OECD Principles of Corporate Governance distinguish the board’s strategic guidance and monitoring role from management responsibilities and emphasize clear board responsibilities and management accountabilities. Readers who need the formal governance context can consult the G20/OECD principles on board responsibilities. ISO 37000 likewise addresses accountability, oversight, stakeholder engagement, decisions, and risk governance across different types of organizations.

A RACI chart usually identifies who is responsible, accountable, consulted, and informed for work. That can be useful for execution, but it may leave the actual decision authority unclear. RAPID is another model that explicitly distinguishes roles such as recommending, agreeing, performing, providing input, and deciding. The practical framework below borrows the core lesson shared by these approaches: participation in a decision is not the same as authority to make it.

Separate the roles before assigning them

For each important decision, distinguish the following functions. One person may hold more than one function, but the functions should not be blurred.

Function	Question it answers	Typical assignment
Recommend	Who develops and presents the proposed course of action?	A manager, project owner, committee, or specialist
Decide	Who makes the final choice within the stated guardrails?	One role or a formally constituted governing body
Approve	Is a separate authorization legally, financially, or procedurally required?	A board, executive, budget holder, regulator, or contract owner
Execute	Who carries out the decision and reports progress?	A team, employee, contractor, or partner
Consult	Whose input must be obtained before the decision?	Finance, legal, people operations, privacy, program, or affected stakeholders
Inform	Who must be notified, and when?	The board, leadership team, staff, funders, or partners
Oversee	Who monitors whether delegated authority is being used properly?	A governing body, executive, committee, or control function

Do not add a separate approval step merely to make senior leaders comfortable. Approval should exist because a governing document, policy, funding restriction, risk control, contract, or law requires it—or because the decision falls outside the owner’s delegated authority. Otherwise, assigning both a “decider” and a discretionary “approver” can create two final owners.

Use a five-layer decision map

A compact map can cover five organizational layers. The boundaries will vary, but the following division provides a useful starting point.

1. Board or governing body

The governing body should identify matters reserved to it by law, bylaws, governing documents, or adopted policy. Depending on the organization, these may include appointing or evaluating the chief executive, approving strategy and major budgets, overseeing material risk, authorizing certain transactions, or changing foundational policies. An advisory board should not be treated as a governing body unless it actually holds formal authority.

Delegation does not eliminate oversight. The board should receive information proportionate to the significance and risk of delegated decisions. Charity Commission guidance, for example, recommends clear terms of reference, reporting procedures, and accountability lines when trustees delegate; it also cautions that novel or high-risk decisions should not ordinarily be delegated.

2. Executive leadership

Executives translate strategy and policy into operating priorities. They commonly allocate resources within an approved budget, resolve cross-functional conflicts, set management controls, and make decisions that exceed a manager’s authority but do not require governing-body action.

3. Managers and functional leaders

Managers should have authority over defined areas such as staffing assignments, vendor selection, program methods, communications, or spending within approved limits. Their authority should be expressed by role rather than by the name of the current employee. The UK Information Commissioner’s Office scheme of delegations illustrates this role-based approach by delegating functions to roles or grades while retaining the board’s overall accountability.

4. Teams and project owners

Teams need room to make delivery decisions without repeatedly returning to senior management. Their map might cover work sequencing, routine purchases, testing, stakeholder scheduling, or adjustments that remain within approved scope, budget, policy, and risk limits.

5. Partners, vendors, and collaborators

External organizations receive only the authority provided by a contract, memorandum of understanding, statement of work, or joint-governance charter. A vendor may execute a service without gaining authority to change program goals, spend additional funds, use organizational data for another purpose, speak publicly for the organization, or make commitments in its name.

Label every decision as reserved, delegated, consult, inform, or escalate

Apply five actions to each decision class:

Reserved: The named governing body or senior role must make the decision. It cannot be passed downward through ordinary delegation.
Delegated: A role may decide within documented limits without seeking case-by-case permission.
Consult: The decision owner must obtain specified input before deciding, but contributors do not acquire a veto unless one is explicitly stated.
Inform: Named parties receive notice before or after the decision according to a defined timetable.
Escalate: The decision moves to another authority when a threshold, exception, conflict, or risk condition is met.

These labels make the map operational. “The program director manages vendors” is vague. “The program director may select vendors within the approved program budget, after security and finance review when applicable, and must escalate nonstandard data terms or commitments beyond the contract period” is usable.

A seven-field decision-rights worksheet

Create one row or short record for each recurring or consequential decision. The following seven fields are enough for most organizations.

Field	What to record
1. Decision statement	A specific choice, written as a verb and object, such as “select a vendor for program scheduling.”
2. Decision owner	The single role with authority to make the final decision within guardrails.
3. Accountable governing role	The body or senior role retaining oversight, if one exists.
4. Required contributors	Roles that recommend, analyze, review, or provide mandatory input.
5. Informed parties	People who must receive notice and the required timing.
6. Guardrails	Budget, policy, risk, legal, funding, time, scope, or contractual limits.
7. Escalation trigger	The event that transfers the decision to a higher or different authority.

Write the decision narrowly enough that one owner is plausible. “Make all technology decisions” is too broad. Separate architecture, purchasing, cybersecurity incidents, access control, data retention, and software selection if they involve different authority or risk.

Completed example: selecting a service vendor

Worksheet field	Example entry
Decision statement	Select a scheduling vendor for an existing community program.
Decision owner	Program director.
Accountable governing role	Executive director oversees compliance with procurement policy; the board receives reporting only if its reserved-matter threshold is triggered.
Required contributors	Finance reviews available budget and payment terms; the technology or privacy lead reviews data handling; intended users assess workflow requirements.
Informed parties	Executive director after selection; affected staff before implementation.
Guardrails	Use approved funds, follow procurement policy, stay within the authorized contract period, and do not accept nonstandard data use or public-brand commitments.
Escalation trigger	Escalate if funding is restricted, total commitment exceeds delegated authority, the vendor requests unusual data rights, the contract creates material operational risk, or contributors identify an unresolved compliance concern.

Funding conditions belong directly in the guardrails. A manager’s general spending authority does not necessarily permit use of money restricted by a donor or grant agreement. Organizations developing this part of the map may also need to review the distinction between restricted and unrestricted nonprofit funds.

Handle cross-functional decisions without creating multiple owners

Cross-functional impact is a reason to define consultation, not to assign several final decision owners. If program, finance, communications, and technology all “own” a decision, each can wait for the others or exercise an informal veto.

Name one owner based on the decision’s primary outcome. Then give other functions explicit input rights and limited stop authority where necessary. For example, a privacy officer might be able to stop a proposed data practice that violates policy, while not deciding which vendor offers the best program workflow. If required contributors disagree, the framework should name the role that resolves the conflict and the time allowed for resolution.

Define partner authority at the boundary

Partner governance becomes fragile when an agreement describes deliverables but not decision authority. For every significant partnership, identify who may decide about shared funds, data access, brand use, public statements, scope changes, staffing, participant safety, subcontracting, and performance remedies.

Also specify which decisions require joint approval and what happens when the parties cannot agree. A useful escalation path names the operational contacts, executive contacts, governing forum if applicable, response deadline, and final dispute mechanism. NIST’s Cybersecurity Framework 2.0 includes governance outcomes addressing the establishment, communication, and coordination of cybersecurity roles and responsibilities involving suppliers, customers, and partners, illustrating why third-party responsibilities must be explicit rather than assumed.

Implement the framework without creating another bureaucracy

Begin with 10 to 20 decisions that repeatedly stall, attract duplicate approvals, cross organizational boundaries, or carry meaningful financial, legal, mission, people, data, or reputation risk. Interview the people currently involved, compare actual practice with formal authority, and resolve the gaps.

List recurring and consequential decisions—not every daily task.
Identify any authority already fixed by law, governing documents, policy, funding terms, or contract.
Assign one decision owner by role.
Add required contributors and informed parties.
Write measurable guardrails and escalation triggers.
Approve and publish the map through the appropriate authority.
Record material decisions in a simple log with the decision, owner, date, rationale, conditions, and required follow-up.
Review the map after leadership changes, restructuring, new regulation, major partnerships, control failures, or shifts in organizational risk.

Emergency authority needs its own line in the map. State who may act, what constitutes an emergency, how long temporary authority lasts, who must be notified, and whether the action requires later ratification or review. Document what happened even when speed prevented the ordinary consultation process.

The practical test: can someone tell who has the decision?

A sound map lets a staff member answer four questions quickly: Who can decide? What input is mandatory? What limits apply? What would require escalation? If the answers depend on who is in the room or which senior leader is available, the organization still has informal authority rather than a dependable framework.

Use the worksheet first on one decision that has recently stalled or been revisited. Clarify its owner, oversight, contributors, guardrails, and escalation path, then test the arrangement during the next decision cycle. That small application will reveal more than an ambitious chart covering the entire organization.

Finally, reconcile the map with bylaws, legislation, contracts, funding restrictions, employment responsibilities, and adopted policies. Governing powers and delegation rules vary by organization and jurisdiction. Decisions involving legal obligations, regulated services, privacy, employment, tax, or material financial exposure may require qualified specialist review. The framework organizes authority; it does not create authority that the organization does not possess.