Data Governance Operating Model Template (Data Mesh)

Data governance and data mesh operating model: principles, domain map, roles, decision rights RACI, policies as code, standards register, metrics, maturity roadmap

Datentechnik & Daten-GovernanceVollständigDAMA-DMBOK 2nd Ed. Revised (name only); data mesh principles (Dehghani)governance operating modelAktualisiert 24.10.2026

Im Editor öffnen.md herunterladen

Anleitung: Use it when an organisation moves data ownership to domains and needs agreed decision rights and a small set of automated global rules. Fill the domain register, roles and RACI first, then the policy register and standards register. The main pitfall is a council that reviews status instead of deciding, and global rules with no automated check.

Vorschau

Data Governance Operating Model: [Organisation name]

Operating model for governing data across an organisation that runs, or is moving towards, domain-owned data products: the principles, the domain map and ownership, the roles (data owner, data steward, data product owner, platform team, governance council), decision rights as a RACI matrix, federated computational governance with policies written as code, the standards register that links each data standard, the metrics that show whether governance works, and a maturity roadmap. The vocabulary is compatible with the Data Governance knowledge area of DAMA-DMBOK (2nd Edition Revised) and with the four data mesh principles described by Zhamak Dehghani, both cited by name only. Replace every [bracketed] value and every row marked Example.

Document control

Field	Value
Document ID	[DGOM-001]
Version	[0.1]
Status	[Draft / In review / Approved / Superseded]
Owner	[@chief-data-officer]
Executive sponsor	[@executive-sponsor]
Approvers/reviewers	[@governance-council-chair], [@platform-lead], [@data-protection-officer], [@ciso], [@domain-data-owners]
Scope	[Legal entities, regions and data estates covered]
Effective from	YYYY-MM-DD
Next scheduled review	YYYY-MM-DD
Last updated	YYYY-MM-DD
Classification	[Internal]
Related policies	[Information security policy], [Privacy policy], [Records management policy]

Approvals

Role	Name	Decision	Date
Executive sponsor	[@name]	[Approve / Approve with conditions / Reject]	YYYY-MM-DD
Chief data officer	[@name]	[Decision]	YYYY-MM-DD
Governance council chair	[@name]	[Decision]	YYYY-MM-DD
Data protection officer	[@name]	[Decision]	YYYY-MM-DD

Revision history

Version	Date	Author	Change summary
0.1	YYYY-MM-DD	[@name]	First draft
1.0	YYYY-MM-DD	[@name]	Example: Approved by the executive sponsor; council constituted
1.1	YYYY-MM-DD	[@name]	Example: Added the Fulfilment domain and moved returns data from Sales

1. Purpose, scope and context
2. Principles
3. Domain map and ownership
4. Roles and responsibilities
5. Decision rights (RACI)
6. Federated computational governance
7. Standards register
8. Governance forums and processes
9. Metrics
10. Maturity assessment and roadmap
11. Risks and dependencies
12. Glossary and references
Standard and licence note

1. Purpose, scope and context

1.1 Purpose

[State the business outcomes the model serves, in two to four sentences.]

Example: Corvid Commerce has grown from one central analytics team to six product domains that publish their own data. Definitions of an order and of net revenue now differ between finance and marketing reports, access requests take three weeks, and nobody can say which datasets contain personal data. This operating model assigns ownership to domains, sets a small number of organisation-wide standards enforced by the platform, and gives the governance council clear decision rights.

1.2 Scope

Item	In scope	Out of scope
Data estates	Example: Lakehouse, operational databases that feed data products, business intelligence semantic layer	Example: Employee HR system (governed by the HR data policy)
Data types	Example: Structured and semi-structured analytical data, reference and master data	Example: Source code, unstructured file shares
Entities and regions	Example: All EU and UK entities	Example: Joint venture in [region] until integration
Activities	Ownership, definitions, quality, classification, access, retention, lineage, data product lifecycle	Day-to-day pipeline operations (domain teams), infrastructure operations (platform team)

1.3 Current state summary

Summarise the starting point in a few lines and link the full assessment in section 10. Name the top three problems the model must fix, in business terms.

ID	Problem	Evidence	Impact
PRB-001 (Example)	Conflicting definitions of key metrics	Finance and marketing net revenue differ by 3% for the same month	Board reporting delayed; trust in dashboards falls
PRB-002 (Example)	Slow, manual access approvals	Median access request takes 15 business days	Analysts copy extracts to spreadsheets
PRB-003 (Example)	Unknown location of personal data	No classification tags on 70% of tables	Data subject requests take weeks; regulatory exposure
[PRB-nnn]	[Problem]	[Evidence]	[Impact]

2. Principles

The first four principles reflect the four data mesh principles named by Zhamak Dehghani (martinfowler.com, 2020): domain-oriented decentralized data ownership and architecture, data as a product, self-serve data infrastructure as a platform, and federated computational governance. The others are organisation-specific. Adapt the wording; keep the structure of statement, rationale and implication.

ID	Principle	Rationale	Implication
PRN-001 (Example)	Domains own their data	The people who create the data understand it best and can fix it at the source	Each dataset and data product has a named domain data owner; central teams do not own business data
PRN-002 (Example)	Data is offered as a product	Consumers need discoverable, trustworthy, documented data with a support route	Shared data is published through data products with contracts; ad hoc extracts are not shared
PRN-003 (Example)	The platform makes the right way the easy way	Domains cannot each build storage, lineage, access and quality tooling	The platform team provides self-service capabilities with governance controls built in
PRN-004 (Example)	Global rules are few and automated	Rules that rely on manual review are applied inconsistently and slow delivery	Every organisation-wide rule has an automated check or a documented reason why it cannot
PRN-005 (Example)	Privacy and security by default	Retrofitting controls is costly and leaves exposure in the meantime	New datasets are classified before publication; personal data is minimised and pseudonymised where possible
PRN-006 (Example)	One definition per business term	Conflicting definitions destroy trust in reporting	Shared terms and metrics are defined once in the glossary and semantic model and reused
PRN-007 (Example)	Decisions are recorded and visible	Undocumented decisions are reopened and inconsistently applied	Council decisions are logged in the decision register with a rationale
[PRN-nnn]	[Principle]	[Rationale]	[Implication]

3. Domain map and ownership

3.1 Domain map

The diagram shows the business domains, their main data products and the dependencies between them. Arrows point from the provider to the consumer: Orders reads Products and FX rates and serves Checkout and Revenue reporting; the dotted line shows that Orders carries only the pseudonymous customer key issued by the Customer domain, not customer master data. The platform provides shared capabilities to every domain but owns no business data.

3.2 Domain register

Domain ID	Domain	Data it owns	Key data products	Domain data owner	Data steward	Data product owners
DOM-001 (Example)	Sales	Orders, carts, checkout sessions	Orders, Checkout	[@sales-data-owner]	[@sales-steward]	[@orders-product-owner], [@checkout-product-owner]
DOM-002 (Example)	Catalogue	Products, prices, categories	Products	[@name]	[@name]	[@name]
DOM-003 (Example)	Customer	Customer master records, consent preferences	Customers (master data)	[@name]	[@name]	[@name]
DOM-004 (Example)	Finance	Ledger extracts, FX rates, revenue reporting	FX rates, Revenue reporting	[@name]	[@name]	[@name]
[DOM-nnn]	[Domain]	[Data]	[Products]	[@owner]	[@steward]	[@product-owner]

3.3 Ownership rules

Every dataset that is shared outside its producing team belongs to exactly one domain and has a named domain data owner.
Master and reference data shared across domains (customers, products, currencies) has one owning domain; the design follows Master Data Management Design (architecture/master-data-management-design).
When a dataset has no obvious owner, the governance council assigns one within 30 days (Example); until then it may not be published as a data product.
Ownership changes are recorded in the domain register and in each affected Data Product Specification (data/data-product-specification).

4. Roles and responsibilities

Role	Accountable for	Typical holder	Time commitment
Executive sponsor	Mandate, funding and resolving conflicts between domains the council cannot settle	Executive committee member	Example: Quarterly review
Chief data officer (or governance lead)	Owning this operating model, the standards register and governance metrics; chairing or appointing the council chair	Senior data leader	Example: Full time
Governance council	Approving organisation-wide standards and policies, arbitrating ownership disputes, accepting exceptions	Domain data owners, platform lead, DPO, CISO representative, architecture	Example: Monthly, 90 minutes
Domain data owner	Business accountability for the domain's data: definitions, access decisions, quality targets, legal basis with the DPO	Senior business leader in the domain	Example: 5% of time
Data steward	Day-to-day definitions, glossary terms, quality rule ownership, classification of new datasets, first-line access review	Business analyst or subject matter expert in the domain	Example: 20% to 50% of time
Data product owner	Product value, roadmap, consumers, contracts and lifecycle of one or more data products	Product manager or senior engineer in the domain team	Example: 30% to 100% of time
Domain data engineers	Building and running the product's pipelines, tests and ports	Engineers in the domain team	Part of team capacity
Data platform team	Self-service platform capabilities, policy engine, catalogue, lineage and access tooling; runs the infrastructure but does not own business data	Platform engineering	Full-time team
Data protection officer	Advice and monitoring for personal data, impact assessments, data subject rights	DPO or privacy office	As required
Information security	Security controls, classification alignment with the security policy, incident handling	CISO organisation	As required
Data consumers	Using data within agreed purposes, reporting issues, keeping access current	Analysts, data scientists, applications	Not applicable

Record named holders in a separate roster, linked here, so that people changes do not require a new version of the model. Link each domain team's Team API (architecture/team-api) for how to contact them.

5. Decision rights (RACI)

R = Responsible (does the work), A = Accountable (decides, one per row), C = Consulted, I = Informed. Columns: Spon = executive sponsor, CDO = chief data officer, Cncl = governance council, DOwn = domain data owner, Stew = data steward, Prod = data product owner, Plat = platform team, Priv = data protection officer (DPO), Sec = information security, Cons = consumers.

ID	Decision	Spon	CDO	Cncl	DOwn	Stew	Prod	Plat	Priv	Sec	Cons
DR-001 (Example)	Approve or change this operating model	A	R	C	C	I	I	C	C	C	I
DR-002 (Example)	Approve an organisation-wide data standard	I	R	A	C	C	C	C	C	C	I
DR-003 (Example)	Assign or change domain ownership	I	R	A	C	I	I	I	I	I	I
DR-004 (Example)	Define or change a shared business term or metric	I	I	C	A	R	C	I	I	I	C
DR-005 (Example)	Publish a new data product	I	I	I	A	C	R	C	C	C	I
DR-006 (Example)	Approve a breaking change to a data contract	I	I	I	A	C	R	I	I	I	C
DR-007 (Example)	Classify a new dataset	I	I	I	A	R	C	I	C	C	I
DR-008 (Example)	Grant access to confidential or personal data	I	I	I	A	R	C	I	C	C	I
DR-009 (Example)	Set quality targets for a data product	I	I	I	A	C	R	I	I	I	C
DR-010 (Example)	Add or change a platform policy check	I	C	A	C	I	C	R	C	C	I
DR-011 (Example)	Grant an exception to a standard	I	C	A	R	C	C	C	C	C	I
DR-012 (Example)	Retire a data product	I	I	I	A	C	R	C	I	I	C
[DR-nnn]	[Decision]

Check the matrix row by row: each row has exactly one A, at least one R, and no role is consulted on so many decisions that it becomes a bottleneck. Where personal data is involved, the DPO gives advice; accountability for the processing stays with the business owner.

6. Federated computational governance

6.1 Global versus local

Federated governance divides rules into a small global set, agreed by the council and enforced by the platform for every domain, and a local set that each domain decides. Use the test below to place a rule.

Question	If yes
Does inconsistency break interoperability between domains (identifiers, time zones, currencies, contract format)?	Global
Is it a legal or regulatory duty, or a security control required by policy?	Global
Does it affect only the domain's own consumers and can be agreed with them?	Local
Is it a quality threshold for a specific dataset?	Local, within the global vocabulary

6.2 Policy register

Each global policy has a human-readable statement, an automated check and an enforcement point. Keep the code in a version-controlled policy repository and reference it here by identifier.

ID	Policy statement	Check (policy as code)	Enforcement point	On failure	Owner
POL-001 (Example)	Every data product has a valid ODPS file with an owner and a domain	Schema validation of the product YAML against the pinned ODPS version	Pull request in the product repository	Merge blocked	Platform team
POL-002 (Example)	Every output port references a valid ODCS contract	Contract file exists and validates against the pinned ODCS schema	Pull request; deployment	Merge or deployment blocked	Platform team
POL-003 (Example)	Every column has a classification	Lint of the contract schema: each property's ODCS `classification` field holds a level from the Data Classification Policy	Pull request	Merge blocked	Governance lead
POL-004 (Example)	Columns tagged as personal data are masked for roles without a recorded purpose	Masking policy generated from tags	Query time in the warehouse	Values masked; access logged	Platform team with DPO
POL-005 (Example)	Data products emit lineage events for every job run	Lineage completeness report per product	Daily scan	Product flagged in catalogue; steward notified	Platform team
POL-006 (Example)	Retention periods are set on every table with personal data	Table property check against the retention schedule	Deployment; weekly scan	Deployment blocked; finding raised	Domain data owner
POL-007 (Example)	Breaking contract changes carry a new major version and a notice period	Contract diff in CI compares old and new schema	Pull request	Merge blocked until version bumped and notice recorded	Data product owner
[POL-nnn]	[Statement]	[Check]	[Point]	[Action]	[Owner]

6.3 Example policy definition

The format below is illustrative, for an organisation's own policy repository; adapt it to the policy engine your platform uses.

id: POL-003
title: Every column has a classification
version: 1.2.0
owner: governance-lead
scope:
  artefact: odcs-contract
  paths: ["contracts/**/*.yaml"]
rule:
  for_each: schema[].properties[]
  require: classification in [public, internal, confidential, restricted]
severity: blocking
exception_process: DR-011
references:
  - data/data-classification-policy

6.4 Enforcement flow

The sequence shows where global policies run for a typical change: in the pull request, at publication to the catalogue, and at query time in the warehouse.

6.5 Exceptions

Exceptions follow DR-011. Each exception names the policy, the scope, the compensating control, the risk owner and an expiry date no longer than 12 months (Example). Expired exceptions fail the check again automatically. Report open exceptions to the council every month.

7. Standards register

ID	Standard	Document	Scope	Owner	Status	Enforcement
STD-001 (Example)	Data product specification	Data Product Specification (`data/data-product-specification`)	Every data product	Governance lead	Approved	POL-001
STD-002 (Example)	Data contracts	Data Contract (`data/data-contract`)	Every output port	Governance lead	Approved	POL-002, POL-007
STD-003 (Example)	Data quality	Data Quality Standard (`data/data-quality-standard`)	All shared data	Governance lead	Approved	Contract quality checks
STD-004 (Example)	Data classification	Data Classification Policy (`data/data-classification-policy`)	All data	CISO with governance lead	Approved	POL-003, POL-004
STD-005 (Example)	Retention and deletion	Data Retention and Deletion Standard (`data/data-retention-deletion-standard`)	All data with a retention duty	Records manager	Approved	POL-006
STD-006 (Example)	Semantic model and metrics	Semantic Model Specification (`data/semantic-model-specification`) and Metric Definition (`data/metric-definition`)	Shared metrics	Analytics engineering lead	In review	Semantic layer CI
STD-007 (Example)	Transformation code	dbt Project Standard (`data/dbt-project-standard`)	All dbt projects	Analytics engineering lead	Approved	Lint and tests in CI
STD-008 (Example)	Pipelines	Data Pipeline Specification (`data/data-pipeline-spec`)	Every production pipeline	Platform lead	Approved	Deployment checklist
STD-009 (Example)	Master data	Master Data Management Design (`architecture/master-data-management-design`)	Customer, product, currency	Customer domain owner	Approved	Matching and survivorship rules
STD-010 (Example)	Allowed custom properties and controlled lists	[Internal catalogue guide]	Catalogue metadata	Governance lead	Draft	Schema lint
[STD-nnn]	[Standard]	[Document]	[Scope]	[Owner]	[Status]	[Check]

8. Governance forums and processes

8.1 Forums

Forum	Members	Cadence	Inputs	Outputs
Governance council	See section 4	Example: Monthly	Proposed standards, exception requests, metrics, escalations	Decisions logged in the decision register
Domain data forum	Domain data owner, stewards, data product owners	Example: Every two weeks	Quality issues, access requests backlog, new products	Local decisions, escalations to council
Steward community	All data stewards	Example: Monthly	Glossary proposals, shared quality patterns	Glossary updates, guidance
Executive review	Sponsor, CDO, council chair	Example: Quarterly	Metrics, roadmap progress, risks	Funding and priority decisions

8.2 Core processes

ID	Process	Trigger	Steps (summary)	Decision right
PRC-001 (Example)	New data product onboarding	Domain proposes a product	Specification, contracts, classification, policy checks pass, catalogue entry	DR-005
PRC-002 (Example)	Standard change	Any role proposes	Draft, consultation with domains for 2 weeks, council decision, platform check updated	DR-002
PRC-003 (Example)	Exception request	Policy check cannot be met	Request with compensating control, council decision, expiry set	DR-011
PRC-004 (Example)	Data issue escalation	Quality or definition issue not resolved by the domain	Steward triage, domain forum, council if cross-domain	DR-004 or DR-009
PRC-005 (Example)	Data incident	Data defect with consumer impact	Follow the data incident process; severity SEV1 to SEV4; Data Incident Postmortem (`data/data-incident-postmortem`) for SEV1 and SEV2	Domain data owner
[PRC-nnn]	[Process]	[Trigger]	[Steps]	[Decision right]

Keep a decision register with an ID, date, decision, rationale, decision right used and review date for each council decision.

9. Metrics

ID	Metric	Definition	Source	Baseline	Target	Review
GOVM-001 (Example)	Ownership coverage	Share of shared datasets with a named domain data owner	Catalogue	40%	100%	Monthly
GOVM-002 (Example)	Classification coverage	Share of columns with a classification level	Catalogue and contracts	30%	98%	Monthly
GOVM-003 (Example)	Contract coverage	Share of output ports with a valid contract	Policy engine	20%	100%	Monthly
GOVM-004 (Example)	Policy pass rate	Share of policy evaluations passing on first attempt	Policy engine	Not measured	90%	Monthly
GOVM-005 (Example)	Access lead time	Median business days from request to grant for non-restricted data	Access portal	15	2	Monthly
GOVM-006 (Example)	Data product objective attainment	Share of products meeting all service level objectives in the month	Observability	Not measured	95%	Monthly
GOVM-007 (Example)	Data incidents	Count of SEV1 and SEV2 data incidents	Incident tool	6 per quarter	At most 2 per quarter	Quarterly
GOVM-008 (Example)	Open exceptions past expiry	Count of exceptions beyond their expiry date	Exception register	Not measured	0	Monthly
GOVM-009 (Example)	Consumer trust	Share of consumers who agree they trust the data they use, in a short annual survey with no personal data kept	Survey	Not measured	75%	Annual
[GOVM-nnn]	[Metric]	[Definition]	[Source]	[Baseline]	[Target]	[Cadence]

Governance metrics use the GOVM- prefix so they are never confused with business metrics, which carry MET-<AREA>-NNN IDs in a Metric Definition (data/metric-definition). Baselines and targets above are illustrative. Measure the baseline before agreeing a target, and keep survey and usage measurement aggregate and free of personal identifiers.

10. Maturity assessment and roadmap

10.1 Maturity scale

Level	Name	Description
1	Initial	Ad hoc, depends on individuals, not documented
2	Repeatable	Practised in some domains, partly documented
3	Defined	Documented standard used by all domains, owners named
4	Managed	Measured with metrics, mostly enforced automatically
5	Optimising	Improved continuously from metrics and feedback

This scale is generic and original to this template; it is not a certified maturity model.

10.2 Assessment

ID	Capability	Current	Target (12 months)	Gap and evidence
CAP-001 (Example)	Ownership and stewardship	2	3	Owners named for 40% of datasets
CAP-002 (Example)	Data products and contracts	1	3	Two pilot products, no contract standard in use
CAP-003 (Example)	Metadata and catalogue	2	4	Catalogue deployed, metadata incomplete
CAP-004 (Example)	Data quality management	2	3	Tests in some dbt projects, no shared vocabulary
CAP-005 (Example)	Classification and access	1	4	Manual approvals, no tags
CAP-006 (Example)	Retention and deletion	1	3	No retention properties on tables
CAP-007 (Example)	Business glossary and metrics	2	3	Conflicting revenue definitions
CAP-008 (Example)	Lineage	2	4	Lineage for dbt models only
[CAP-nnn]	[Capability]	[1 to 5]	[1 to 5]	[Gap]

10.3 Roadmap

Phase	Window	Deliverables	Capabilities	Exit criteria
Foundation (Example)	Months 1 to 3	Council constituted, domain register, classification policy, first three policies as code (POL-001 to POL-003)	CAP-001, CAP-005	Owners named for 80% of shared datasets
Products (Example)	Months 4 to 6	Orders and Checkout products with contracts; contract and product checks in CI	CAP-002, CAP-003	Two products live with objectives measured
Scale (Example)	Months 7 to 9	Masking from tags, retention checks, semantic model for revenue	CAP-005, CAP-006, CAP-007	GOVM-002 at 90%; one revenue definition used
Optimise (Example)	Months 10 to 12	Metrics review, exception clean-up, maturity reassessment	All	Targets in section 10.2 met or replanned
[Phase]	[Window]	[Deliverables]	[CAP-nnn]	[Criteria]

11. Risks and dependencies

ID	Risk or dependency	Likelihood	Impact	Mitigation	Owner
RSK-001 (Example)	Stewards have no time allocated	High	High	Time allocation agreed with line managers and tracked	CDO
RSK-002 (Example)	Platform cannot automate checks in time	Medium	High	Prioritise POL-001 to POL-003; manual review as a temporary control with expiry	Platform lead
RSK-003 (Example)	Domains resist ownership of legacy datasets	Medium	Medium	Council assigns owners; retire datasets nobody wants	Council chair
RSK-004 (Example)	Governance seen as a blocker	Medium	High	Measure and publish access lead time; keep global rules few	CDO
[RSK-nnn]	[Risk]	[L]	[I]	[Mitigation]	[@owner]

12. Glossary and references

12.1 Glossary

Term	Meaning in this document
Data governance	The exercise of decision rights and accountability over data, supported by standards, processes and controls
Domain	An area of the business that owns a set of data and the products built from it
Data product	A unit of data, code, metadata and contracts owned by a domain and offered to consumers
Federated computational governance	A model where a council of domain and platform representatives agrees global rules that the platform enforces automatically
Policy as code	A rule expressed in machine-readable form and evaluated automatically at a defined enforcement point
Exception	A time-limited, approved deviation from a standard with a compensating control
Steward	A person responsible for the day-to-day definition and quality of a set of data

12.2 References

Reference	Version or date checked	Use
DAMA-DMBOK: Data Management Body of Knowledge, DAMA International	2nd Edition Revised (2024)	Named only as a widely used reference for data governance; no content used
Zhamak Dehghani, "Data Mesh Principles and Logical Architecture", martinfowler.com	2020-12-03; checked 2026-10-24	Names of the four principles
Zhamak Dehghani, Data Mesh: Delivering Data-Driven Value at Scale, O'Reilly	2022	Cited by name only
ISO/IEC 38505-1, Governance of data (application of ISO/IEC 38500 to the governance of data)	ISO/IEC 38505-1:2017 withdrawn in 2026; second edition (2026, retitled "Governance of data, Part 1") under publication at the time of writing; check iso.org/standard/87195.html	Named only for alignment with board-level governance of data
Bitol Open Data Product Standard (ODPS) and Open Data Contract Standard (ODCS), github.com/bitol-io	ODPS v1.1.0 and ODCS v3.2.0, released 2026-09-08	Schemas validated by POL-001 and POL-002
[Internal policies]	[Version]	[Security, privacy and records policies]

Standard and licence note

Structure aligned with the data governance concepts named in DAMA-DMBOK (2nd Edition Revised, 2024) and with the four data mesh principles as named by Zhamak Dehghani (martinfowler.com, 2020, and the O'Reilly book, 2022). These works are copyrighted and are cited by name only; no text, figure, table or framework content from them is reproduced. ISO/IEC 38505-1 is named only; check its current edition at iso.org. The Bitol ODPS and ODCS specifications are Apache-2.0 and referenced by name and URL. The maturity scale, RACI, policies and examples are original, and Corvid Commerce is fictional. This template is original text written for this collection. Check the current official versions of the works cited before use. Template licence: MIT.