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.

8 minute read For: the person drafting it Reviewed September 2026

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.

A responsibility grid with activities down the left and the roles data owner, steward, custodian, governance lead and sponsor across the top, with single accountable marks highlighted in one column per row.
The shape of the finished grid. The only rule the whole thing depends on is one accountable mark per row. Illustration

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:

  1. Register a new dataset
  2. Classify it for sensitivity
  3. Assign its trust level
  4. Accept ownership of it
  5. Approve an access request
  6. Revoke access when someone changes role
  7. Approve a schema change to a source system
  8. Promote a dataset to the trusted tier
  9. Define or change a reported measure (net revenue, active customer)
  10. Investigate a quality incident
  11. Set a retention period
  12. Execute deletion at end of retention
  13. Approve a procedure or a change to one
  14. Review the register periodically
  15. 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).

ActivityOwnerStewardCustodianLeadSponsor
Register a new datasetARCI
Classify for sensitivityARC
Assign the trust levelARCI
Approve an access requestACRI
Revoke access on a role changeICAI
Approve a schema changeACRI
Promote to the trusted tierARCCI
Define or change a reported measureCRCA
Investigate a quality incidentARCII
Set a retention periodARCCI
Execute deletion at end of retentionACRI
Approve a procedureCCCRA
Review the register quarterlyCRCAI
Report maturity to the boardICRA

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?
Responsible, Accountable, Consulted, Informed. Responsible is whoever does the work; Accountable is the single person who answers for the outcome and signs it off; Consulted must be asked before the decision; Informed is told afterwards. The rule that matters is exactly one accountable name per activity.
How many rows should a data RACI matrix have?
Twelve to eighteen for a business of 50 to 1,000 people. Cover the recurring events where damage happens or a decision needs justifying later: registering, classifying, approving access, revoking access, schema changes, promotion to trusted, defining measures, quality incidents, retention, deletion, procedure approval and periodic review.
Who should be accountable for defining a reported measure like net revenue?
Someone senior enough to refuse a fourth variant — usually the executive sponsor rather than a domain owner. A measure definition is a company-level commitment, and if each domain owner defines it for themselves you reproduce the disagreement the matrix was meant to end.
Can two people be accountable for the same activity?
No. Two accountable names is the same as none: each assumes the other has it. If a row genuinely spans two domains, split the row into two activities with clearer boundaries rather than doubling the A.

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.