Guide · Responsibilities
A RACI matrix for data, with a worked example
RACI has a bad reputation, earned mostly by grids that were filled in by one person, circulated once and never opened again. Used properly it does one thing extremely well: it forces the question of who is accountable to be answered by name, in front of the people it affects.
The short answer
A data RACI maps each recurring activity — registering a dataset, approving access, changing a schema, deleting at end of retention — to who is Responsible for doing it, Accountable for the outcome, Consulted before it and Informed after. One accountable name per row, never two. At mid-market scale twelve to eighteen rows covers everything that matters.
What the letters mean, precisely
- Responsible — does the work. Can be several people.
- Accountable — answers for the outcome, and is the one who signs it off. Exactly one per row. If there are two, there are none.
- Consulted — has to be asked before the decision, and their view has to be heard. Two-way.
- Informed — told afterwards. One-way, and cheap, which is why it gets over-used until every row informs everybody and nobody reads anything.
The distinction that does real work is R against A. In most organisations the person doing the work has quietly absorbed the accountability too, because they are the only one who understands it. Separating the two is the entire point of the exercise.
The activities worth including
Cover the events where something goes wrong, or where a decision gets made that somebody will later be asked to justify. For a business of 50 to 1,000 people that is around fifteen rows:
- Register a new dataset
- Classify it for sensitivity
- Assign its trust level
- Accept ownership of it
- Approve an access request
- Revoke access when someone changes role
- Approve a schema change to a source system
- Promote a dataset to the trusted tier
- Define or change a reported measure (net revenue, active customer)
- Investigate a quality incident
- Set a retention period
- Execute deletion at end of retention
- Approve a procedure or a change to one
- Review the register periodically
- Report maturity to the board
Resist adding rows for things that happen once. A row for "select a data platform" tells you nothing you will need again.
A worked example
A 250-person manufacturer, five roles: Owner (a business director per domain), Steward (a senior analyst per domain), Custodian (the IT infrastructure lead), Lead (the operations manager who holds the operating model), Sponsor (the finance director, on the exec).
| Activity | Owner | Steward | Custodian | Lead | Sponsor |
|---|---|---|---|---|---|
| Register a new dataset | A | R | C | I | — |
| Classify for sensitivity | A | R | — | C | — |
| Assign the trust level | A | R | C | I | — |
| Approve an access request | A | C | R | I | — |
| Revoke access on a role change | I | C | A | I | — |
| Approve a schema change | A | C | R | I | — |
| Promote to the trusted tier | A | R | C | C | I |
| Define or change a reported measure | C | R | — | C | A |
| Investigate a quality incident | A | R | C | I | I |
| Set a retention period | A | R | C | C | I |
| Execute deletion at end of retention | A | C | R | I | — |
| Approve a procedure | C | C | C | R | A |
| Review the register quarterly | C | R | C | A | I |
| Report maturity to the board | I | C | — | R | A |
Copy it, then change it, because two of those rows are wrong for you.
The two rows that always cause an argument
Defining a reported measure
We have put A against the sponsor, and people object. The argument for the owner is that they know the domain; the argument for the sponsor is that a definition of net revenue is a company-level commitment, and when two directors each define it for their own domain you get precisely the disagreement the exercise was meant to end. Somebody senior has to be able to say no to the fourth variant. Put A wherever you like, but put it against a person who can refuse.
Revoking access when someone changes role
This is the row everyone skips, and it is the one that shows up in a security review. We put A against the custodian rather than the owner, on the grounds that the trigger is an HR event the owner never sees. Whoever holds it, the row needs a mechanism attached — a leavers and movers checklist that includes data access — or it is a letter in a grid.
How to run the session
Draft it alone first. A blank grid in a workshop produces two hours of definitional argument; a filled-in grid produces an hour of specific disagreement, which is what you want.
Then get the named people in a room, go row by row, and hold one rule: nobody may leave a row with two accountable names. When the discussion stalls — and it will stall on ownership of customer data, every time — the useful question is not "who should own this?" but "if this were wrong in front of a customer next week, who would be asked to explain it?" That question has an answer.
Afterwards, publish it where the procedures live, not in a shared drive folder. A responsibility matrix that is not next to the thing it governs is a document that gets found during the next audit and nowhere else.
When RACI is the wrong tool
If you have fewer than about forty staff, a grid this size is heavier than the problem. Three names on a page — who owns the numbers, who maintains them, who runs the systems — does the same job. And if your real problem is that two departments genuinely disagree about what a customer is, RACI will not settle it; it will only tell you who has to.
Common questions
What does RACI stand for in data governance?
How many rows should a data RACI matrix have?
Who should be accountable for defining a reported measure like net revenue?
Can two people be accountable for the same activity?
Where the product comes in
The matrix lives next to the procedures it governs
Lake On Rails ships a responsibility matrix already drafted against the seven procedures, so each step in a procedure names the accountable role and the grid and the steps cannot drift apart. Changes are recorded in the audit trail with who made them and what they changed from.
The first step costs you nothing
Forty-five minutes with whoever runs your reporting
We tell you honestly whether this is worth doing at all, and roughly what it would take. If the answer is not yet, you will hear that. "Not for us" is a fine outcome, and a better one than a slow maybe.