RACI & decision rights¶
Most program failures are not technical. They are decision-rights failures. "Who decides whether to add Tool X?" "Who approves an exception?" "Who calls for a pause?" When those questions don't have named answers, the program runs on whichever senior voice was loudest in the last meeting.
This page defines who decides what, using a compact RACI matrix and a decision-rights table.
The RACI taxonomy (compact)¶
- R, Responsible. Does the work.
- A, Accountable. Owns the outcome; signs off. (Only one A per decision.)
- C, Consulted. Two-way dialogue required before the decision.
- I, Informed. Told after the decision.
Roles (not people):
| Code | Role |
|---|---|
| Sponsor | Executive sponsor (charter owner) |
| CoE | Center of Excellence Lead (or equivalent) |
| CISO | Head of Security (or delegate) |
| Legal | Head of Legal (or delegate) |
| Privacy | Data Protection Officer (or equivalent) |
| Proc | Procurement lead |
| DevEx | Developer Experience / Platform lead |
| TL | Tech lead (system-level) |
| AppSec | AppSec reviewer |
| Comms | Head of Communications |
| IR | Incident Response lead |
| Audit | Internal Audit / risk function |
RACI matrix¶
| Decision | Sponsor | CoE | CISO | Legal | Privacy | Proc | DevEx | TL | AppSec | Comms | IR | Audit |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Adopt the program (charter) | A | C | C | C | C | I | C | I | I | I | I | C |
| Approve a new tool | A | R | C | C | C | C | C | I | I | I | I | I |
| Ban / remove a tool | A | R | C | C | I | C | C | I | I | I | I | I |
| Amend the AUP | A | R | C | C | C | I | C | I | C | I | I | I |
| Classify / re-classify a system | I | C | C | I | C | I | I | A | C | I | I | I |
| Approve an exception | I | A | C | I | I | I | I | C | C | I | I | I |
| Approve agent write access to prod | A | C | C | I | I | I | I | C | R | I | C | I |
| Declare an AI-adjacent incident | I | I | C | I | I | I | I | C | R | I | A | I |
| Pause the program | A | C | C | C | I | I | I | I | I | I | I | I |
| Publish external statement | C | C | C | C | I | I | I | I | I | A/R | I | I |
| Report to board / regulator | A | C | C | C | C | I | I | I | I | C | I | C |
| Define / update metrics | I | A | C | I | I | I | R | I | I | I | I | I |
| Approve training curriculum | I | A | C | I | C | I | C | C | C | I | I | I |
| Sign quarterly framework review | A | R | C | I | I | I | I | I | I | I | I | C |
| Approve retirement of a tool (Phase 4) | A | R | C | C | C | C | C | I | I | C | I | I |
| Set / update endpoint security config | I | C | A | I | I | I | R | C | C | I | I | I |
| Set / update network-layer controls | I | C | A | I | I | I | R | I | C | I | I | I |
| Update per-tool enforcement matrix | I | A/R | C | I | I | I | C | I | C | I | I | I |
The matrix is opinionated but adjustable. Changes belong in a Decision Record.
Decision-rights table (plain English)¶
| Decision | Who decides | Who signs off | Timeframe |
|---|---|---|---|
| Add a tool to the approved list | CoE Lead | Sponsor + CISO + Legal | ≤ 30 days |
| Remove a tool | CoE Lead | Sponsor (CISO if security-triggered) | Immediate if incident; ≤ 14 days otherwise |
| Amend AUP | CoE Lead | Sponsor + CISO + Legal | ≤ 14 days |
| Classify a new system | Tech lead with Architecture + AppSec | CoE Lead | ≤ 5 business days |
| Approve an exception (single team) | CoE Lead | (none) | ≤ 3 business days |
| Approve an exception (org-wide) | CoE Lead | Sponsor + CISO | ≤ 7 business days |
| Pause the program | Sponsor | (none) | Immediate |
| Pause a specific tool | CISO | (none) | Immediate |
| Declare incident severity | IR Lead | (none) | Immediate |
| Approve external comms | Comms | Sponsor | Per incident timeline |
| Update endpoint security config | DevEx | CISO | ≤ 14 days; triggered by tool addition or quarterly drift check |
| Update network-layer controls | DevEx / Platform Security | CISO | ≤ 7 days after tool addition; quarterly otherwise |
| Update per-tool enforcement matrix | CoE Lead | CoE Lead + CISO | ≤ 14 days after any tool addition or vendor admin-surface change |
Anti-patterns¶
Don't
- Don't have more than one Accountable per decision. The entire point of RACI is one accountable role. Two As means no one.
- Don't let "the CoE decides everything" become the default. The CoE is a standards and support body. Hot operational decisions (like declaring severity) live with IR and AppSec.
- Don't skip board-level decisions. For large enterprises, report-to-board is a decision; it has a named accountable role and a cadence.
- Don't rewrite RACI quietly. Changes produce a DR. Otherwise it becomes a ghost document that people pretend to follow.
Integration points¶
- RACI is referenced by the Charter's decision-rights table.
- The AUP §8 (exceptions) references the exception-approval row.
- The Incident response framework references the incident-severity and external-comms rows.
- Vendor & tool standards references the tool-add and tool-remove rows.
Sizing guidance¶
Sizing guide
- Small (< 50): Three roles typically (Founder/Sponsor, Senior Engineer/CoE, External Legal/Security contact). Many As collapse to the Sponsor role.
- Mid (50–500): Most roles exist distinctly. CoE and DevEx may be combined.
- Enterprise (500+): All roles named; BU champions feed the CoE.
- Regulated: add a Compliance role and an Audit-Liaison role.
Next¶
- Acceptable Use Policy: consumes the exception row.
- Incident response: consumes the severity and comms rows.
- Worksheets: decision record template: how to record RACI changes.