Introduction
A ransomware alert fires at 2 a.m. The CISO wants to isolate the affected systems — but that would take down order processing for six hours. The CEO needs to approve that call. The CEO wants legal's sign-off first. Legal is waiting to hear whether this crosses the materiality threshold for SEC disclosure. Nobody wrote that threshold down.
Four hours pass. The incident spreads.
The problem wasn't a lack of expertise. Everyone in that scenario knew what to do technically. The gap was that no one had authority assigned in advance to make the call under pressure.
A decision rights matrix closes that gap before the alert fires. This guide covers what it is, how it differs from a standard decision matrix, the components that make it work, a five-step build process, common frameworks, and why it matters most in board and cyber governance.
TLDR
- A decision rights matrix is a governance tool that maps who holds the authority to decide, approve, recommend, consult on, and be informed about specific decision categories.
- It answers "who decides" — not "which option is best" (that's a decision matrix).
- Core components: defined roles, categorized decisions, authority levels, and escalation thresholds.
- RACI, RAPID, and DACI are the most common structuring frameworks — each suited to different organizational contexts.
- Unclear decision rights produce bottlenecks, delayed incidents, audit findings, and governance failures.
- Boards and executives in regulated industries should make these rights explicit before an incident forces the question.
What Is a Decision Rights Matrix?
A decision rights matrix is a structured document that maps specific categories of decisions to the individuals or roles authorized to make, approve, recommend, or be informed about them.
This is not the same as a decision matrix, which scores options against weighted criteria to identify the best choice. A decision matrix answers which option. A decision rights matrix answers who decides.
For each decision category, a well-built matrix answers four questions:
- Who makes the final call?
- Who must approve before action is taken?
- Who should be consulted beforehand?
- Who gets informed after the fact?
As Bain's foundational work on the topic notes, ambiguity about who is accountable stalls decisions at organizational bottlenecks, and the Decide role is the single point of accountability that commits the organization to action.
Decision Types the Matrix Should Cover
Most organizations need to map three layers:
- Strategic — board-level decisions on risk appetite, capital allocation, and regulatory exposure
- Operational — executive and management-level decisions on programs, vendors, and incidents
- Tactical — departmental decisions on exceptions, priorities, and day-to-day controls
Mapping across all three layers prevents two common failure modes: boards micromanaging operational decisions, and management making strategic calls without board visibility.
Authority vs. Accountability
One distinction that boards and executives frequently blur: the person with decision authority is not always the person accountable for outcomes. A CISO may have authority to declare an incident — the CEO is accountable for how the company responds. A department head may approve an exception — the business owner carries the resulting risk.
A well-designed matrix separates these concepts explicitly. When they are conflated, ownership collapses at exactly the moments when clarity matters most.
That ambiguity has a measurable cost. According to McKinsey, decision-making costs a typical Fortune 500 company around $250 million each year, with executives spending nearly 40% of their time on decisions — and 60% of that time used ineffectively.
Key Components of a Decision Rights Matrix
Roles and Decision Categories
The matrix must list roles, not names. CEO, Board Risk Committee, CISO, General Counsel, CFO — these designations hold when individuals change. A matrix built around names becomes obsolete the moment someone leaves.
Decision categories should be grouped meaningfully rather than listing every possible decision. Useful categories include:
- Technology investments above a defined dollar threshold
- Cybersecurity incident declaration and escalation
- Vendor selection and third-party risk approval
- Policy changes and security exceptions
- Regulatory disclosures and external communications
- Budget tradeoffs when security competes with delivery
Categories make the matrix scalable. A list of 200 individual decisions does not get used. A matrix with 12 well-defined categories does.
Authority Levels
At minimum, the matrix should define five authority levels:
| Level | Definition |
|---|---|
| Decide | Sole authority to make the call; commits the organization |
| Approve | Must sign off before action proceeds |
| Recommend | Provides input that shapes the decision |
| Consult | Must be engaged before the decision is finalized |
| Inform | Notified after the fact |
Conflating these levels is one of the most common design errors. When Approve and Decide are assigned to the same committee, decisions stall in review loops. Treat Consult and Inform as interchangeable and stakeholders learn about decisions too late — typically at the next audit.
Escalation Thresholds
The matrix must include explicit criteria for when a decision escalates to a higher authority level. Thresholds should be expressed in measurable units:
- Technology purchases above a specified dollar amount
- Incidents affecting more than a defined number of customers
- Downtime exceeding agreed tolerance hours
- Any action that triggers regulatory reporting obligations
- Data exposure involving regulated data types
Without written thresholds, escalation happens by consensus — meaning it happens too slowly, or not at all. PwC notes that ambiguous roles, responsibilities, and escalation paths lead directly to delayed, redundant, and inconsistent decisions.
Formalization and Enforcement
A matrix that lives in a shared drive folder provides no protection when an incident hits. For the tool to function:
- Formalize it in governance documents and incident response plans
- Reference it in board committee charters and management policies
- Schedule an annual review
- Trigger an off-cycle review after any leadership change, merger, or significant incident
- Test it against real scenarios before finalizing (more on this below)
Enforcement also means governing exceptions. Any exception granted without an expiry date stops being an exception — it becomes your actual operating model, whether you intended that or not.
How to Build a Decision Rights Matrix in 5 Steps
Step 1 — Map Your Decision Inventory
Start by identifying the decisions the organization actually makes — not the ones leadership thinks it makes. Involve cross-functional stakeholders. Surface the decisions that currently fall through the cracks or create recurring conflict.
Common categories that surface through this process: who approves security exceptions, who owns go or no-go decisions for critical vendors, who can accept risk at different threshold levels, and who decides when to take systems offline during an incident.
Step 2 — Define Roles and Authority Levels
For each decision category, assign a specific role to each authority level. The goal is a single Decider per category. A committee as the Decider is not a Decider — it's a delay mechanism.
Map three lanes as a starting structure:
- Owns: What the relevant leader controls directly (security policy, incident escalation, exception process)
- Shared: Decisions requiring cross-functional sign-off (go-live approvals, budget tradeoffs, major architecture changes)
- Advises: Areas where input is provided but final authority sits elsewhere (risk acceptance by business owners, public statements owned by legal and executives)
Step 3 — Build the Matrix Structure
Rows represent decision categories. Columns represent authority levels: Decide, Approve, Recommend, Consult, Inform. Each cell contains the relevant role.
Keep the initial version simple. A clean spreadsheet is more likely to be used than an elaborate governance platform. In board advisory engagements, Tyson Martin delivers decision rights mapping within the first one to three days of assessment work — as a one-page, board-ready artifact, not a complex framework document.
Step 4 — Test Against Real Scenarios
Before finalizing, walk the matrix through three to five real or recent decisions. Once those pass, run an executive tabletop exercise that uses the matrix to navigate a live incident scenario — this stress-tests the authority structure under pressure, not just on paper.
Watch for specific failure signals:
- A board committee is listed as Decider on operational questions
- A department head has no decision authority over their own budget
- Multiple roles are listed as Decider for the same category
- Nobody can name who declares incident severity without consulting the org chart
If the test exposes these gaps, revise before the matrix is formalized.
Step 5 — Communicate, Embed, and Maintain
Leaders need to understand escalation thresholds — not just receive a document. Practical embedding includes:
- Reference the matrix in governance documents, incident response plans, and committee charters
- Establish a weekly decision rhythm — a short meeting with the smallest group capable of making the relevant calls
- Maintain a simple decision log: date, risk, decision, owner, review date
- Schedule an annual review and trigger an off-cycle review after any leadership change, M&A event, or post-incident review that reveals an authority gap
Common Frameworks: RACI, RAPID, and DACI
These three frameworks each serve a different purpose. Organizations should choose one and apply it consistently rather than mixing terminology across teams.
RACI
Responsible, Accountable, Consulted, Informed — the most widely used framework, well-documented by the Project Management Institute. The critical rule: only one person can be Accountable per item.
RACI works well for operational and project-level decisions where the focus is on clarifying who does the work, who owns the outcome, and who needs to be kept in the loop. It is less suited to high-stakes governance decisions where approval authority needs to be separated from accountability.
RAPID
Recommend, Agree, Perform, Input, Decide — developed by Bain & Company, and the strongest fit for strategic and governance-level decisions. RAPID separates the recommending function from the deciding function, which is valuable when board, CEO, CISO, and General Counsel each play distinct roles in a single decision.
The Agree role is particularly useful — it identifies who holds veto power, clarifying who must align before the decision moves forward. For executive teams navigating cross-functional decisions under regulatory pressure, that specificity prevents decisions from being reversed or disputed after they're made.
DACI
Driver, Approver, Contributors, Informed — commonly used in product and technology organizations. The Driver owns the process, the Approver makes the final call, Contributors provide input, and Informed parties are notified. Atlassian's team playbook is the most widely cited implementation reference for this framework.
DACI works well when coordinating input across teams is the primary challenge. For board and cyber governance contexts — where strategic authority must be clearly separated from operational execution — RAPID is the better starting point.
Quick Reference: Choosing the Right Framework
| Framework | Best For | Key Distinction |
|---|---|---|
| RACI | Operational and project-level decisions | Clarifies who does the work vs. who owns the outcome |
| RAPID | Strategic, governance, and cross-functional decisions | Separates recommending from deciding; identifies veto holders |
| DACI | Product and technology team decisions | Emphasizes coordinating input across contributors |
When Decision Rights Break Down
Warning Signs
Observable symptoms of absent or broken decision rights:
- Every significant decision requires a new committee, even operational ones
- The same decision type gets made differently depending on who's in the room
- Policy exceptions pile up because rejecting them feels political
- Stakeholders are routinely surprised by decisions they expected to be consulted on
- Audit findings keep returning quarter after quarter — indicating a leadership and accountability gap, not a tool gap
- During incident scenarios, teams debate who can take systems offline rather than acting
These symptoms become especially visible during post-incident reviews and regulatory audits. If your last board review surfaced any of these patterns, the decision rights structure is the starting point for remediation — not the security tools.
High-Risk Transition Moments
Decision rights tend to break down hardest during transitions. The highest-risk moments:
- CISO departures or transitions — decisions migrate to side conversations, exceptions live in old tickets, open incidents sit in someone's inbox
- M&A activity — security due diligence gets deferred, integration ownership is unclear, inherited access paths and vendor contracts create unknown exposure
- New executive leadership — authority assumptions from the prior regime persist until someone gets burned
- Major technology transformation or cloud migration — every workload becomes a one-off argument when identity, logging, and data controls haven't been decided upfront
Each of these moments shares a common failure mode: authority gaps that existed quietly before the transition become active liabilities once the pressure is on. McKinsey research found that less than one-third of organizational transformations successfully improve and sustain performance, with nearly a quarter of value loss occurring during target-setting. Establishing decision rights before targets and budgets are locked is not a bureaucratic step — it determines whether the transformation holds.
Fixing a Broken Structure
Triage sequence:
- Audit actual decision-making patterns — not the org chart
- Identify the three to five categories causing the most friction — typically incident declaration, risk acceptance, and exception approvals
- Assign clear authority for those categories first
- Expand from there once the core framework is operational
The goal at the start is a matrix people will actually use — one that covers the highest-friction categories with named owners and clear thresholds. Completeness can follow.
Decision Rights in Board and Cyber Governance
The Board-Management Boundary
The most consequential decision rights line in any organization sits between board oversight and management execution — and it's the one most often left undefined.
Boards set risk appetite, approve funding, and oversee material decisions. Management executes within those parameters, reports progress, and escalates when reality conflicts with the plan. When this boundary is not explicit, boards either micromanage operational responses or abdicate oversight entirely. Both create governance risk.
Decision categories that blur most often:
- Incident response authority — who can shut systems down, who calls counsel, who speaks externally
- Risk acceptance thresholds — when does a management-level risk decision require board visibility
- Policy exceptions and security spend — who approves, for how long, and what evidence is required
Per NACD's Director's Handbook on cyber-risk oversight, in 2022 public-company board surveys, 47% of boards delegated cybersecurity oversight to the audit committee, 32% handled it at the full board level, and 13% assigned it to a risk committee. The matrix should name the specific board body with cyber oversight authority — not just "the board."
Cybersecurity and Technology Decision Rights
Naming the right body is only half the work. In regulated industries — financial services, healthcare, retail — cyber and technology decisions carry legal and regulatory weight that makes pre-assigned authority non-negotiable.
The matrix must specify:
- Who authorizes major technology investments
- Who can declare a cybersecurity incident
- Who approves a ransomware payment decision (and what the policy posture is)
- Who communicates with regulators and under what triggering conditions
- Who determines materiality for SEC disclosure purposes
The SEC's 2023 cybersecurity disclosure rules require public companies to disclose material incidents within four business days of determining materiality. That clock starts when materiality is determined — which means the organization must pre-assign who makes that call. Waiting until an incident is underway to figure out who owns that decision is a governance failure with a regulatory consequence.
The SEC enforcement action against R.R. Donnelley illustrates the stakes. The SEC ordered RRD to pay $2.125M after finding the company failed to oversee its managed security services provider and had no prioritization scheme for alert escalation. The gap wasn't technical — it was a decision rights gap. A board advisor's role in this context is to build escalation thresholds that hold under real incident conditions, not just in tabletop discussions.
Escalation Thresholds for Incident Response
The matrix should include explicit, time-bound escalation paths:
- CISO to CEO: defined impact thresholds — downtime, data sensitivity, customer exposure, dollar amounts
- CEO to board: materiality thresholds tied to financial impact, regulatory notification triggers, or reputational exposure requiring public statements
- Board to external counsel: data exposure, privilege strategy, regulatory notice requirements
The first update to the board chair should occur within 24 hours: what happened, current impact, actions underway, and next update time. A steady rhythm after that prevents the silence that causes boards to assume the worst.
NIST CSF 2.0's GOVERN function makes this explicit: cybersecurity risk management roles, responsibilities, and authorities must be established, communicated, understood, and enforced — not just documented.
Frequently Asked Questions
What is a decision rights matrix?
A decision rights matrix is a governance tool that maps who holds authority to decide, approve, recommend, consult on, and be informed about specific categories of decisions within an organization. It is distinct from a decision matrix, which evaluates and scores options to identify the best choice — the decision rights matrix answers "who decides," not "which option is best."
What is the difference between a RACI chart and a decision rights matrix?
A RACI chart is one framework used to build a decision rights matrix, but the matrix is the broader governance artifact. It can be structured using RACI, RAPID, DACI, or a custom model — and it typically includes escalation thresholds and decision categories that go beyond what a standard RACI chart addresses.
What decisions should the board own versus management?
Boards generally own risk appetite, strategic direction, and oversight of material decisions. Management owns execution within those parameters. The decision rights matrix makes this boundary explicit, with material thresholds (financial, regulatory, reputational) determining when management decisions require board visibility or formal approval.
What is the 5-5-5 rule of decision-making?
The 5-5-5 rule is a gut-check framework asking how a decision will look in 5 minutes, 5 months, and 5 years — helping decision-makers assess short versus long-term implications. It is complementary to a decision rights matrix but addresses what to decide, not who has authority to decide.
What are the 7 C's of decision-making?
The 7 C's (Construct, Compile, Collect, Concern, Choose, Commit, Carry Out) provide a process framework for moving through a decision. A decision rights matrix provides the governance structure that defines who is authorized to move through that process in the first place. The two tools address different layers of the same problem.
When should an organization create or update its decision rights matrix?
Build one during any governance formalization effort. Update it after leadership transitions, mergers or acquisitions, significant regulatory changes, or any post-incident review that reveals authority gaps or escalation failures. An annual scheduled review is the baseline; those trigger events require an off-cycle review regardless of timing.
