Introduction
A cyber incident hits. Systems go down. And in the first critical minutes, your leadership team is debating who is authorized to isolate the affected environment—not because they lack skill, but because no one established that authority before the event.
This scenario plays out repeatedly across organizations that have org charts, job descriptions, and governance policies—but no documented answer to who owns their highest-stakes decisions. The gap is invisible during normal operations. Under pressure, it becomes the most expensive problem in the room.
When decision rights are vague, risk gets expensive fast. The confusion in the first hour of an incident drives up cost and reputational harm in ways no after-action report can fully undo.
This guide covers the full picture:
- What decision rights are and why they break down
- How the three dominant frameworks—RACI, RAPID, and OVIS—differ in practice
- Why technology and cyber governance require them before an incident occurs
- A practical path to building a framework that holds
TL;DR
- Decision rights answer three questions: who is empowered to decide, who provides input, and who is simply informed of the outcome.
- Ambiguous decision rights cause slow escalation, governance failures, and organizational paralysis—especially during incidents.
- RACI, RAPID, and OVIS each fit different decision contexts — they are not interchangeable.
- In cyber governance, decision rights must be established and tested before an incident—pressure exposes every gap in authority.
- Start by identifying your most consequential decisions, then assign single-point ownership with documented escalation thresholds.
What Are Decision Rights?
Deloitte's organizational design research defines decision rights as clarifying three things: what decisions will be made, how they will be made, and who makes them. That who/what/how framing is the simplest way to distinguish decision rights from everything else organizations call "governance."
Decision Rights vs. Reporting Structure
This is where most organizations get it wrong. A senior title does not automatically confer decision authority. A VP of Technology does not automatically own the decision to disclose a breach—that may rest with General Counsel or the CEO, depending on how rights are assigned. When organizations allow reporting lines to function as de facto decision rights, the result is that decisions escalate to the most senior person available, regardless of whether they have the right context or whether escalation is even warranted.
Decision Rights vs. Information Rights
These are separate questions, and conflating them creates two distinct failure modes:
- Decision-makers who lack context — they have authority but not enough information to use it well
- Informed parties who assume veto power — they receive updates and begin treating awareness as authority
Knowing about a decision is not the same as owning it. Documenting both separately prevents the slow, sideways negotiation that stalls organizations in moments that require speed.
The Decision Inventory
A useful starting point is building a decision inventory—a focused list of the organization's most consequential decisions at each level: board, executive, and operational. The goal is not comprehensiveness. Bain's research on critical decision architecture suggests organizations typically surface 20–30 critical decisions when they map major business processes seriously. Nike, as one example, identified 33 key decisions across 10 major decision areas.
The number matters less than the clarity it creates. Deloitte's 2020 research found that public companies with high organizational design maturity achieved 23% greater revenue growth over three years. Companies that excelled in five decision-rights attributes averaged 45% EPS growth year over year, compared to an 88% EPS decrease for poor performers. That's a measurable performance gap, not a soft governance benefit.
Why Decision Rights Break Down
The Cost Organizations Underestimate
The framework here comes from Jensen and Meckling's 1992 work on organizational structure. Their model identifies two costs: delegating to someone with the right knowledge but misaligned incentives, and transferring information to a central decision-maker who lacks it.
Organizations almost universally underestimate the second cost. Centralizing decisions without centralizing the information needed to make them well slows execution and produces worse outcomes than delegating would have. The instinct to push decisions up the hierarchy feels like control—it's actually a drag on performance.
When Hierarchy Substitutes for Authority
The most common structural failure is treating reporting lines as decision rights. When this happens:
- Decisions escalate to the most senior person available, not the most informed
- Middle-layer leaders learn to avoid owning outcomes
- Speed drops and accountability diffuses across everyone and no one
This pattern produces bottlenecks at the top and avoidance culture below. Neither is recoverable quickly under incident pressure.
The Political Barrier
Deloitte identifies something most governance consultants don't say plainly: senior executives often resist explicitly defining decision rights because ambiguity preserves informal influence. When decision-making is opaque, leaders can shape outcomes without being accountable for them.
Clarifying decision rights surfaces that dynamic. Governance improvement efforts frequently stall not because of technical complexity, but because of political resistance from those who benefit from the current opacity. Framing decision rights work as governance risk reduction — with specific accountability owners and escalation thresholds — tends to move through that resistance where bureaucratic process redesign does not.
The Major Frameworks: RACI, RAPID, and OVIS
Choosing the Right Tool
These three frameworks are often treated as interchangeable. They're not.
| Framework | Best For | Core Rule |
|---|---|---|
| RACI | Role accountability within processes | Exactly one Accountable party per decision |
| RAPID | Cross-functional, high-stakes decisions | Agree role used sparingly—only where legally required |
| OVIS | Governance-layer authority and veto clarity | No more than one Veto holder per decision |
RACI
RACI stands for Responsible, Accountable, Consulted, and Informed.
- Responsible — does the work
- Accountable — owns the decision outcome; exactly one per decision
- Consulted — expertise or perspective solicited before the decision
- Informed — notified after
The single most important rule: every decision has exactly one Accountable party. Shared accountability is no accountability. RACI works best when the decision boundary is clear and ownership sits within a defined function. When boundaries cross departments, a different tool is needed.
RAPID
RAPID (Recommend, Agree, Perform, Input, Decide) was developed by Bain to resolve lateral authority conflicts on high-consequence decisions. The roles:
- Recommend — gathers facts, builds the proposal
- Agree — formally signs off (used sparingly)
- Perform — executes once decided
- Input — provides information without formal veto
- Decide — makes the final call
Bain's guidance is explicit: the Agree role should be reserved for decisions requiring genuine regulatory or legal sign-off. Overuse of Agree recreates the same bottlenecks RAPID is designed to eliminate. Use it when multiple senior leaders have competing claims and the organization needs a named Decider without a political standoff.
OVIS
BCG's OVIS framework makes veto power visible rather than implicit.
- Owner — holds final authority, accountable for outcomes and for running an inclusive process
- Veto — can block a decision; ideally no more than one per decision, and only for those with direct legal or managerial impact
- Influence — has implementation responsibility or unique expertise; must have the opportunity to raise concerns before the decision is final
- Support — provides required data without broader participation
OVIS is the right tool at the board and governance layer, where authority relationships are frequently contested but rarely written down. Making veto power explicit prevents the common pattern where informal blocking goes unacknowledged until a real decision stalls.
A Selection Guide
- Use RACI for functional processes and role accountability
- Use RAPID for cross-functional decisions where lateral authority is contested
- Use OVIS for board-level oversight, organizational transformations, or any situation where veto power needs to be explicitly scoped
The most common mistake: deploying all three at once with no principle for which applies when. Start with one framework, applied to your 5–10 most contested or highest-consequence decisions, then expand once the pattern holds.
Decision Rights in Technology and Cyber Governance
The Board/Management Boundary
The board's role in technology and cyber risk is to set risk appetite, ask oversight questions, and receive credible reporting—not to make operational security decisions. Management's role is to execute within that appetite and escalate when thresholds are crossed.
Without explicit decision rights at this boundary, two failure modes emerge:
- Boards micromanage and slow operations
- Boards are kept uninformed until a crisis forces reactive governance
Tyson Martin's board advisory work specifically addresses this boundary—helping boards define what they need to decide versus what they need to oversee, so oversight is meaningful without becoming operational noise. The deliverable is concrete: a written risk appetite statement, a board decision-rights matrix, and documented escalation thresholds.
Three Decision Categories That Must Be Documented
Three categories consistently surface as undocumented in board governance reviews—and each one creates real exposure when left ambiguous:
- Risk appetite thresholds — what level of residual cyber risk the board has formally accepted, and who approves exceptions above that threshold, for how long
- **Significant technology investments and vendor decisions** — above a defined financial or risk threshold, typically owned by the CIO or CISO with board notification
- Incident response authorization — who can authorize isolating systems, engaging external counsel, notifying regulators, or communicating publicly; at what severity level does each decision require CEO versus CISO versus General Counsel involvement
On incident response specifically, Tyson Martin structures escalation using measurable triggers tied to business impact rather than technical severity alone. Each role carries a distinct lane:
- CEO: enterprise command and final go-forward decisions
- General Counsel: legal strategy, privilege approach, and regulator engagement posture
- CISO: technical containment and investigation
- Board: oversight, disclosure readiness, and exceptional approvals — ransom payment posture, major shutdown tradeoffs, public risk statements
Pre-deciding these before an incident means the first hour is spent solving the problem, not negotiating authority.
Regulatory Expectations Already Require This
Regulators aren't prescribing RACI charts, but they are requiring visible decision ownership:
- SEC Rule 33-11216 requires material incident disclosure and board-level oversight documentation under Regulation S-K Item 106(c)
- NIST CSF 2.0 GV.RR-02 explicitly requires that cybersecurity roles, responsibilities, and authorities are established, communicated, understood, and enforced
- FFIEC requires that information security officers report to the board with sufficient authority, stature, and independence
- HIPAA administrative safeguards require assigned security responsibility and a security official accountable for policies and procedures
The pattern across all four: regulators are asking organizations to demonstrate that decision authority is clear—not just that controls exist.
Inspectable Execution
Once decision rights are established, organizations need a mechanism to verify they're being followed. Tyson Martin describes this as "inspectable execution"—governance that produces evidence of compliance rather than just documentation of intent.
In practice, that means:
- Decision-focused dashboards showing trend data and open decisions, not status colors
- Monthly artifacts and quarterly deep dives that create regular inspection points
- Post-incident reviews that test whether escalation thresholds held and who actually made which decisions at what level
- Exception tracking where risk exceptions require documented owners and expiry dates—not informal email approvals
The WEF's Global Cybersecurity Outlook 2026 found that 99% of respondents from highly resilient organizations report board involvement in cybersecurity—while only 16% of organizations with industrial environments report OT security issues to their boards. The gap between those two numbers is, in large part, a decision rights and reporting problem.
Building a Decision Rights Framework That Holds
Step 1: Build a Decision Inventory
Identify the decisions with the greatest impact on risk, performance, or regulatory exposure. Span board, executive, and operational levels. The goal is not an exhaustive list—it's clarity on the decisions most likely to stall, be made by the wrong person, or produce accountability gaps when pressure hits.
Focus on decisions where:
- Multiple people believe they own the outcome
- Escalation patterns are informal or inconsistent
- A wrong call has significant financial, regulatory, or reputational consequence
Step 2: Assign Single-Point Ownership and Validate
Select the appropriate framework (RACI, RAPID, or OVIS) for each decision category. Assign ownership explicitly. Then stress-test the assignments with relevant stakeholders—not to reach consensus on every detail, but to surface conflicts, overlapping assumptions, and gaps before an actual situation exposes them.
That stress-test is where buy-in actually happens. A framework people helped pressure-test will hold when an incident demands fast escalation. One handed down as policy rarely does.
Step 3: Test Before You Need It
NIST SP 800-84 describes tabletop exercises as discussion-based events where personnel walk through scenarios including roles, responsibilities, coordination, and decision-making. That's exactly the mechanism for testing decision rights.
A practical scenario exercise:
- Walk a hypothetical incident through the documented decision rights
- Watch for where people pause, defer incorrectly, or disagree about authority
- Log every gap, assign an owner, and set a re-test date
Tyson Martin's executive tabletop exercises are structured around this principle—a 60-minute scenario that forces real tradeoffs, ends with a short action list, and tests whether the escalation ladder holds before an actual incident demands it. What comes out of the exercise is a shorter, sharper list of gaps with named owners—the kind of clarity a simulation reveals only when the pressure feels real.
Frequently Asked Questions
Frequently Asked Questions
What is meant by decision rights?
Decision rights are an organization's explicit agreement about who is authorized to make specific decisions, who provides input, and who is informed of the outcome. They are distinct from reporting structure: a title does not automatically confer decision authority, and documenting that distinction is the point.
What is the difference between RACI, RAPID, and OVIS?
RACI clarifies role accountability within processes—who does the work, who owns the outcome. RAPID resolves lateral authority conflicts on high-stakes, cross-functional decisions where multiple leaders have competing claims. OVIS explicitly defines veto power and decision ownership, making it most effective at the governance or transformation layer.
How do decision rights apply to cybersecurity and technology governance?
In technology and cyber governance, decision rights define which decisions belong to the board (risk appetite, oversight, exceptional approvals) versus management (execution, investment) versus the CISO (incident containment, technical response). These must be established before an incident—under pressure, authority that only exists informally doesn't hold.
What is the most common reason decision rights fail in organizations?
Two failure modes dominate: conflating seniority with decision authority, and treating framework distribution as implementation. Sending a RACI chart is not the same as testing whether it holds when a real decision needs to move fast.
How often should decision rights be reviewed and updated?
At minimum annually, and whenever significant changes occur—new leadership, M&A activity, a major incident, or regulatory shifts. The decisions that matter most evolve with the organization, and a framework built for last year's structure develops gaps quickly.
What is the 7 types of decision-making question really asking?
In governance contexts, the useful taxonomy is decision ownership: who decides, who recommends, who must be consulted, and who executes. RACI, RAPID, and OVIS each formalize those roles differently depending on the organizational layer.
