Data governance sounds like a committee. To me it is a much smaller question, and it is about every record in the system: who owns it, who can read it, and when does it get deleted? If I cannot answer those three, I do not have governance. I have a policy document.
I build systems where more than one tenant's data lives in the same place, and that is where I learned the shape of this. Governance is not a phase you add at the end of a project. It is a set of decisions that live in the code, checked every sprint, owned by a named person. Here is how I keep it inside an agile project instead of next to it.
1. Name the owner, then measure the gaps.
"Successful governance" means nothing until you can measure it. My version is a count, not a maturity score: how many record types have a named owner, how many records sit with no owner at all, how many access grants are stale, how many retention rules are overdue. The dashboard shows those numbers. If the count of unowned rows is going down sprint over sprint, governance is working. If nobody can see the count, nobody knows.
2. Put the rule in the code, not the document.
Lightweight governance means the check runs where the work happens. Ownership is a column on the record, not a line in a slide. The audit log is written by the service when the access happens, not filled in after the fact. Retention is a job that deletes on a schedule, not a policy that asks someone to remember. When a ticket touches a new kind of data, the ticket carries the data contract with it: these are the records, this is the owner, this is who can read them. If the contract is not in the ticket, the work is not ready.
3. Show the numbers in the same review as the features.
Progress on governance is invisible unless you make it visible, and a status update is the weakest way to do it. I put the counts in the sprint review next to the features: unowned records shrinking sprint over sprint, stale grants revoked, the retention job ran and deleted what it was supposed to. A dashboard beats a report because nobody has to take my word for it. Early wins matter here more than anywhere — the first time the retention job catches something real, the team stops treating governance as paperwork.
4. The person who answers for the data sits in the room.
Stakeholders are not a separate committee you report to. They are in sprint planning when the data decisions get made, because that is when the decisions are cheapest to change. The person who owns the customer records is the one who signs off on who can export them. If the owner is not in the room, the decision waits. I would rather delay a ticket than ship a data decision nobody owns — an unowned decision is the one that leaks.
5. The retrospective covers the data too.
Every retro, I ask what leaked, what got over-shared, what the retention rule caught. Governance that never changes is governance nobody is testing. The point of iterating is not to add more rules. It is to remove the ones nobody follows and strengthen the ones that actually caught something. A rule that catches a real over-share is worth ten rules nobody remembers.
That is the whole of it. Three questions answered in the code, checked every sprint, owned by a named person. Everything else is decoration.
I write about backend systems and the decisions hiding inside them. Follow along. Next in this series: Progress Updates on Projects.
Top comments (0)