RACI Matrix

Path: /raci

The RACI Matrix tracks who is Responsible, Accountable, Consulted, and Informed for each recurring compliance objective. It gives an auditor a single, defensible answer to "who owns this?" for every recurring control test and every evidence request, and it surfaces gaps (such as an objective with no Accountable owner) before they become audit findings.

The R/A/C/I Model

Each cell in the matrix records the role a person holds on an objective:

Role	Value	Meaning
Responsible	responsible	Does the work — collects the evidence, runs the test.
Accountable	accountable	Owns the outcome and signs off. Exactly one per objective.
Consulted	consulted	Provides input; two-way communication.
Informed	informed	Kept up to date; one-way communication.

One Accountable per objective

Each objective should have exactly one Accountable owner. The matrix flags an objective with no Accountable as a warning. When you assign an Accountable role, the one-Accountable-per-objective rule is enforced as a soft warning returned with the assignment — it is surfaced, not hard-blocked, so you can fix it deliberately.

Objectives — the Rows

A matrix row is a recurring compliance objective. There are two kinds:

• Evidence request (evidence_request) — a PBC / evidence request.
• Control objective (control_objective) — a recurring control test (a control schedule row).

People are the columns; objectives are the rows; each filled cell is the R/A/C/I role that person holds on that objective.

One Evidence Request → Many Controls = One Line Item

A single evidence request often satisfies several controls across multiple frameworks (for example one vendor SOC 2 report that satisfies CC9.2, CC6.1, and ISO 27001 A.8.16). The matrix collapses all of those controls onto one row — the evidence request — with the controls shown as chips on that row.

This means you assign ownership once for the request, and that ownership applies to every control it satisfies. You are not duplicating the same person across three near-identical rows, and the matrix row count reflects the number of real objectives, not the number of control mappings.

To map an additional control/framework onto an existing request:

POST /api/v1/orgs/{org_id}/raci/evidence-controls

with the request id plus the control_id and framework_id. The request stays a single line item with one more chip; the total row count does not change. Remove a mapping with DELETE /raci/evidence-controls/{link_id}.

The Matrix Page and Audit-Mode View

The page offers two orientations of the same underlying data, toggled in-page:

• Matrix view (GET /raci) — the Objectives × People grid. Each row is an objective with its collapsed control chips; each column is a person; each cell is their role. A per-row warning highlights missing Accountable owners.
• Audit view (GET /raci/audit) — the same data re-oriented for an auditor: per objective it shows the Owner (Accountable), the Responsible parties, the associated controls, and the current evidence status. This is the view to share during an audit because it reads as a sign-off sheet rather than a grid.

Both render on the same page; use the Matrix / Audit toggle to switch.

Assigning Roles

Assign a person a role on an objective:

POST /api/v1/orgs/{org_id}/raci/assignments

with the objective_type (evidence_request or control_objective), the objective_id, the user_id, and the role. The matrix re-fetch reflects the new cell immediately, along with any updated Accountable warning. Remove an assignment with DELETE /raci/assignments/{assignment_id}.

Who Can Edit

Action	Required permission
View the matrix and audit view	Org read
Assign / unassign roles	Org configure
Map / unmap a control on a request	Org configure

Reading the matrix needs only read access, so auditors and viewers can consult it. Changing assignments or control mappings requires the org configure permission, which admins and managers hold — viewers and auditors cannot alter ownership.