Data Governance and Organization

Two departments calculating “revenue” with two different scopes produce two different truths, and the data team ends up arbitrating without realizing it, line of code after line of code.…

Guide≈ 7 min readCheckedReading

On this page

Why this theme
What this theme measures
The five levels
Milestones by level
Detailed reading by level
Partial achievement and rating
Moving to the next level
See also

Level: 🟢→🔴 · Theme code: GOV

Why this theme#

Two departments calculating “revenue” with two different scopes produce two different truths, and the data team arbitrates without realizing it, line of code after line of code. Governance answers a simple question: who has the right to say what a data item means, who is accountable for its quality, and what happens when people disagree. Without an answer, definitions are set where development happens, anomalies have no owner, and every change becomes a bilateral negotiation. Governance that is too heavy is just as costly: a committee that meets quarterly gets bypassed. This theme therefore measures effectiveness (rules are actually applied) rather than the existence of governance bodies. It is distinct from project steering (PI — governance and steering): here we govern the data asset, not the project.

What this theme measures#

Axis: from local, implicit definition to distributed, verified, low-cost accountability.
Key indicator: share of critical data with an active owner, an arbitrated definition, and an applied rule.
Unit: percentage of critical data (established list, typically 20 to 100 items) meeting all three conditions.

The five levels#

Level	Short name	Promise	Typical indicator (orders of magnitude)
1	Implicit	Each team gets its own numbers; gaps between teams are discovered in meetings.	0 critical data items with a documented owner
2	Identified	People know who to contact for the main data; disagreements are escalated to one person.	≥ 50% of critical data with a named owner
3	Defined	A single dated definition exists for each critical data item; arbitration occurs within a known timeframe.	≥ 80% arbitrated definitions; arbitration < 15 days
4	Applied	Governance rules are checked in data flows; gaps are visible and handled by their owner.	≥ 90% controlled compliance; gaps handled < 30 days
5	Distributed	Governance supports teams without slowing them down; domains govern themselves under minimal shared rules.	Local decisions > 90%; annual rule review

Milestones by level#

ID	Milestone	Verifiable evidence
PD-GOV-1.1	The main data objects (customer, product, store, user, calendar) are listed.	Dated list, even if basic.
PD-GOV-1.2	A technical contact is known for each source system.	Source directory with one name per row.
PD-GOV-1.3	Data access rights are assigned to identified individuals, not shared accounts.	Account review: no generic read account on sensitive data.
PD-GOV-1.4	Reference data change requests go through a queue.	Traceable request tickets.
PD-GOV-2.1	Each critical data item has a named business owner (data owner).	Owner ↔ data register reviewed with stakeholders.
PD-GOV-2.2	A technical lead (data steward) is designated per domain.	Assignment letter or line in the org chart.
PD-GOV-2.3	Definitions of the top 10 indicators are written in a shared location.	Accessible document with author and date.
PD-GOV-2.4	Owners know they are owners.	Interview with three owners: they describe their role.
PD-GOV-3.1	A single glossary exists, with version and change history.	Versioned glossary; last change < 6 months.
PD-GOV-3.2	An arbitration body (committee, duo, lead) resolves definition conflicts within a set timeframe.	Arbitration log with observed turnaround time.
PD-GOV-3.3	Business rules are linked to a data item, an owner, and an effective date.	Rule sheet with those three fields.
PD-GOV-3.4	Data classification (public, internal, confidential, personal) is applied to critical objects.	Classification column populated for critical objects (see SEC).
PD-GOV-4.1	Automatic checks verify compliance with rules (naming, classification, owner present).	Dated check results, not manual entry.
PD-GOV-4.2	Governance gaps are reported to the owner, with a deadline.	Gap report sent by domain.
PD-GOV-4.3	A definition change follows a process with impact analysis on consuming reports.	Change request with list of impacted objects (support: MET).
PD-GOV-4.4	Governance indicators (coverage, arbitration time) are tracked.	Governance dashboard updated monthly.
PD-GOV-5.1	Business domains take on most data decisions within a minimal shared framework.	Share of decisions made locally vs centrally, measured over a quarter.
PD-GOV-5.2	Governance rules are reviewed annually and removed if their cost exceeds their value.	Review report with retired rules.
PD-GOV-5.3	New hires know their role in under one month.	Data onboarding path and comprehension test.
PD-GOV-5.4	Governance is measured by its effects (indicator gaps avoided, disputes), not by activity.	Effect indicator tracked over 4 quarters.

Detailed reading by level#

🟢 Level 1 — Implicit#

Signs: “ask Marie, she knows”; two departments produce two totals; access rights follow habits.
Benefit: zero apparent friction.
Does not guarantee: consistency across reports; survival of knowledge when someone leaves.
Difficulty: 1/5 · Effort: 1/5.

🟢 Level 2 — Identified#

Signs: an owner register exists; when in doubt, people know where to go; key definitions are written somewhere.
Benefit: questions find a point of contact; first inconsistencies are acknowledged.
Does not guarantee: that the owner truly decides; that written definitions are followed by code.
Difficulty: 2/5 · Effort: 2/5.

🟡 Level 3 — Defined#

Signs: versioned glossary; tracked arbitration with timeframe; classification applied to critical data.
Benefit: a definition conflict is settled once; the data team stops arbitrating alone.
Does not guarantee: that existing reports are aligned; automatic rule enforcement.
Difficulty: 3/5 · Effort: 3/5.

🧪 Example

The “revenue” in a sales force report includes credit notes, while finance controlling does not: a constant 1.8% gap. At level 1, this is discovered in an executive committee meeting. At level 3, the glossary says: “Net revenue = billed − credit notes, company scope, validated by Finance on 2026-03-04,” and the report measure uses that exact name.

🟡 Level 4 — Applied#

Signs: an automatic check detects objects with no owner or no classification; every definition change goes through impact analysis.
Benefit: governance stops depending on individual vigilance.
Does not guarantee: that rules are relevant (you can perfectly apply a bad rule).
Difficulty: 4/5 · Effort: 4/5.

🔴 Level 5 — Distributed#

Signs: domains publish their data as products with owner and contract (see CTR); the center sets a common minimum.
Benefit: scaling without a central bottleneck.
Does not guarantee: interoperability if the shared minimum is too weak; requires an already mature culture.
Difficulty: 5/5 · Effort: 5/5.

Partial achievement and rating#

Score based on the critical data list: take the 20 most consumed items (reports, interfaces) and measure, for each, owner / definition / rule. A milestone based on a rate is worth 1 at ≥ 90%, 0.5 between 50 and 90%, 0 below.

A “partial 5”: three out of seven domains operate with real autonomy with a contract and an owner (5.1 at 0.5), the annual rule review removed two rules (5.2 at 1), onboarding is solid (5.3 at 1), but no effect indicator exists (5.4 at 0). This is still a very good situation.

⚠️ Pitfall

Facade governance: a monthly committee, meeting minutes, but no applied rule (PD-GOV-4.1 at 0). Symptom: lots of meetings, same disputes keep coming back. Cause: activity is measured, not enforcement. Remedy: any level ≥ 4 milestone requires evidence produced by a control, not by meeting minutes.

Moving to the next level#

Possible means (optional)

Transition	Possible levers
1 → 2	A “data — owner — backup” spreadsheet completed in one workshop; include it in the relevant job descriptions.
2 → 3	A glossary in the source repository (versioned like code, see Version Control for Data: SQL and Power BI); a posted arbitration timeframe.
3 → 4	Automatic checks on database metadata (extended properties, schema); an impact review before any definition change.
4 → 5	Contracts per domain, a very short shared minimum (identifiers, classification, published quality), removal of redundant central approvals.

Cross-cutting pitfalls: (1) False positive — an owner is named but never reachable: test it. (2) Goodhart — targeting “100% of data with an owner” leads to naming whoever is available first; measure response time to a real question. (3) Governance vs agility: if arbitration takes longer than a sprint, the team will bypass it; set deadlines and a fallback owner.

🤖 AI

AI speeds up drafting candidate definitions, detects synonyms or duplicate columns, and prepares reports. It does not resolve business arbitration and can confidently lock in an incorrect definition; every suggested definition must go through the owner.