A 90-person company has a data catalogue, a business glossary, a stewardship council meeting fortnightly, a dataset certification process and an access-request workflow with two approvers. Twelve people work with data. Review it — what would you remove, what would you change and what would you leave alone?

What is actually required

Twelve data people and one warehouse. The genuine risks are: someone reads personal data they should not, two dashboards disagree and a decision is made on the wrong one, and the one person who understands the revenue model leaves. Everything in the current stack should be judged against those three.

What I would remove, and why it is safe to

• The stewardship council. A fortnightly meeting between people who sit together is a calendar entry, not a control. The decisions it makes can be made in a pull request, where they are also recorded.
• The second approver on access requests. Two approvers on a team of twelve means the second is approving because the first did, which is not review — it is latency with a signature. Dual approval works where the approvers have independent information; here they do not.
• Dataset certification as a process. A certification badge earned through a review board, on a platform with maybe 40 datasets, costs more to run than it informs. Replace it with an owner field that must be non-empty.

The one change that matters

Move the sensitive-data control from process to placement. Right now access to personal data is guarded by an approval workflow, which means it is guarded by whoever is on holiday. Put the personal columns behind a warehouse-level policy tied to a classification tag, grant the tag-based role to the three people who need it, and the approval workflow stops being load-bearing. One mechanism replaces a process and cannot be bypassed by a notebook.

What I would leave alone, and when not to touch it

• The glossary, if and only if its definitions are bound to the models that compute them. A glossary as a wiki page is decoration; a glossary whose terms are the metric names in the transformation layer is the cheapest defence against the second risk on the list.
• The catalogue, because the third risk is real. At twelve people the catalogue's value is not governance, it is that the revenue model is written down somewhere other than one person's head.

How I would argue this in the review

Not as "this is over-engineered", which sounds like an aesthetic objection and invites an aesthetic defence. As a count: five mechanisms, three risks, and two of the risks are unmitigated — the personal-data control depends on human availability and the definitions are not bound to anything. Then offer the trade explicitly: remove three mechanisms, add one policy, and cover all three risks with less work than the current stack requires.

When the current stack is the right one

At 900 people, most of it comes back, and for reasons that are not bureaucratic: approvers who genuinely do not know the requester, datasets whose owners have left, and a regulator who wants to see the decision record. The mistake is not having these mechanisms; it is having them early, which teaches an organisation that governance is friction before it has ever seen governance be useful. The rough crossover is where the number of data practitioners exceeds about 50, because that is where an approver stops personally knowing the requester and where a dataset can outlive its author.

The failure to watch for on the way up is the opposite of over-engineering: a control that was proportionate at 12 people and was never revisited at 300, so access is granted by one person from memory long after nobody can remember why. Governance frameworks have prescribed periodic recertification for this reason since the 2000s, and it is the practice most often skipped.