DocsProcess GovernanceRAPID Accountability Model

RAPID Accountability Model

Use the RAPID decision framework in Dictiva procedures to clarify who Recommends, Agrees, Performs, provides Input, and Decides on each governance step.

What Is RAPID?

RAPID is a decision-rights framework developed by Bain & Company to make complex organisational decisions faster and clearer. For every step in a procedure, RAPID defines five distinct roles:

LetterRoleMeaning
RRecommendProposes the action and builds the case
AAgreeMust formally agree before the decision proceeds
PPerformExecutes the work once a decision is made
IInputProvides information or analysis that informs the recommendation
DDecideThe single person with final decision authority

Unlike RACI, RAPID separates the recommendation from the decision — useful in governance contexts where the subject-matter expert (R) is different from the authority who commits the organisation (D).

When to Use RAPID vs RACI

Use RACI when your procedure is primarily an operational workflow — a sequence of tasks with clear hand-offs.

Use RAPID when your procedure centres on a decision — a point where multiple stakeholders provide input, someone agrees, and one person ultimately decides.

ScenarioRecommended Model
Onboarding a new data sourceRACI
Approving a new data policyRAPID
Running a quarterly control reviewRACI
Deciding on a regulatory interpretationRAPID
Publishing a new assembly of statementsEither

Assigning RAPID Roles in Dictiva

  1. Open a procedure from the Procedures section in the sidebar
  2. Select a step
  3. In the step detail panel, find the Accountability section
  4. Click the RACI / RAPID toggle to switch to RAPID mode
  5. Click any lettered block (R, A, P, I, or D) to enter a name, team, or role title
  6. Press Enter or click outside the field to save

Switching models on a step preserves any values already stored — R maps to Recommend and A maps to Agree when you switch.

Common Patterns

Policy adoption decisions:

  • R — Compliance analyst (recommends adopting or updating a statement)
  • A — Legal team (must agree before proceeding)
  • P — Policy owner (publishes the approved change)
  • I — Risk team (informed of the change)
  • D — CISO or DPO (final sign-off)

Exception approvals:

  • R — Business unit requesting the exception
  • A — Risk function
  • P — IT security (implements any compensating controls)
  • I — Audit committee
  • D — Risk committee chair

Tips

  • One D per decision — like RACI's single A, ambiguous Decide roles slow everything down
  • A is a veto, not a rubber stamp — if Agree is always automatic, the role adds no value; use it for genuine blockers
  • Distinguish R from I — Recommend actively builds the case; Input simply supplies data on request
  • Use role titles, not names — governance programmes outlast individuals