ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
A data governance framework is the structure that turns “we should govern our data” into named people making recorded decisions about specific data assets under written rules — and the reason most frameworks fail is that they are drawn as an organisation chart when they need to be built as five layers that depend on each other.
The DAMA-DMBOK, the reference body of knowledge for data management, places data governance at the centre of its wheel of eleven knowledge areas precisely because governance is what gives the other ten — architecture, modelling, storage, security, integration, content, reference and master data, warehousing, metadata and quality — their decision rights, and the DMBOK is careful to say it is not a prescriptive standard: it describes what governance does and leaves the design to the organisation.
The five layers below are that design: strategy and policy at the top, an operating model of roles and bodies, the standards and processes that carry decisions, the data assets and the metadata that describe them, and the tooling and metrics that make the whole thing observable. This guide sets out each layer with what it contains and what it depends on, maps the layers to the DMBOK knowledge areas, gives a sequence for building the framework in twelve months, and lists the errors that leave a framework as a slide.
The DMBOK defines data governance as the exercise of authority and control — planning, monitoring and enforcement — over the management of data assets, and distinguishes it from data management itself: governance decides, management executes. That distinction is the whole reason for a framework. Without one, the people who execute (IT, analytics, operations) also decide, and every decision is local. With one, decisions about definitions, quality, access, classification and retention are made by accountable business owners, carried out by stewards and custodians, and recorded. Our guide to data governance and the DMBOK covers what the body of knowledge is and is not.
| Layer | What it contains | Depends on | Evidence it exists |
|---|---|---|---|
| 1. Strategy, policy and principles | Why the organisation governs data; the data strategy it serves; a data governance policy approved at executive level; principles such as accountability, data as an asset, quality at source, privacy by design | Executive sponsorship | A signed policy; a charter for the governance body |
| 2. Operating model | The governance council or board; data owners per domain; data stewards; data custodians; the data governance office or lead; escalation paths and decision rights | Layer 1 for its mandate | RACI by domain; appointment records; council minutes |
| 3. Standards and processes | Business glossary standards; data quality rules and dimensions; classification and handling; access request and approval; issue and dispute management; change control for definitions and critical data elements; retention | Layer 2 for owners to approve them | Published standards; process records; issue log |
| 4. Data assets and metadata | Data domains and their boundaries; the inventory of critical data elements; the catalogue; the glossary; lineage; ownership recorded per asset | Layer 3 for the rules that describe assets | Catalogue entries with owners, definitions, classification, quality status |
| 5. Tooling and measurement | Catalogue and glossary platform; quality monitoring; lineage capture; workflow for requests and issues; KPIs and reporting to the council | Layers 3 and 4 for content to manage | Dashboards; quarterly governance reports |
The policy answers the questions every later argument comes back to: what data is in scope, who is accountable, what the organisation expects of owners and stewards, and how disputes are settled. It is short, executive-approved, and points at the standards rather than containing them. The principles are the tie-breakers — when two domains disagree about a definition, “the system of record for a customer is decided by the customer domain owner” ends the argument.
Four roles, one decision-maker. Owners are accountable business leaders who decide who may use data, for what, and what quality is acceptable; stewards are subject-matter experts who define terms, own business rules, monitor quality and triage issues; custodians are the technical teams who store, secure and move data; users consume it within the approved terms. A governance council chaired by the sponsor resolves cross-domain conflicts and approves standards. Our guide to the data steward and the four roles covers the separation that matters most — owner from steward.
The standards are what stewards apply and owners approve: how a business term is defined and where it is recorded; the quality dimensions measured and the thresholds per critical data element; the classification scheme and handling rules; the access request path; the issue process from detection to root cause; and change control for anything that changes a definition or a critical element. Our guide to the six data quality dimensions covers the measurement standard.
Governance is applied to assets, so the assets have to be known. The domain model divides the estate into governable units — customer, product, finance, employee, supplier — each with an owner; the critical data element inventory names the fields whose quality matters to decisions and reporting; the catalogue records each asset’s owner, definition, classification, lineage and quality status; the glossary records the agreed business terms. Our guides to the data catalogue and data dictionary and to data lineage cover the metadata layer.
Tools make the framework observable — catalogue and glossary, quality monitoring against the layer 3 rules, lineage capture, request and issue workflow — and metrics make it accountable: percentage of critical data elements with an owner and a definition, quality scores against thresholds, open issues by age, access requests by turnaround. The council reads the metrics; the sponsor funds on them. Our guide to the data governance maturity model covers how the metrics show progress.
| DMBOK knowledge area | Framework layer it lives in | What governance decides for it |
|---|---|---|
| Data Governance | All five — the centre of the wheel | The framework itself |
| Data Architecture; Data Modelling and Design | Layer 4 (domains) and layer 3 (modelling standards) | Domain boundaries, systems of record, naming standards |
| Data Storage and Operations | Layer 2 (custodians), layer 3 (retention) | Retention, backup and disposal rules |
| Data Security | Layer 3 (classification, access) | Classification scheme, access approval, handling rules |
| Data Integration and Interoperability | Layer 4 (lineage), layer 3 (change control) | Approved sources and flows; change to interfaces that move critical elements |
| Document and Content Management | Layer 3 (classification, retention) | Records rules for unstructured content |
| Reference and Master Data | Layer 4 (domains, systems of record) | Golden-record ownership and match rules; our guide to master data management vs data governance covers the boundary |
| Data Warehousing and Business Intelligence | Layer 4 (certified datasets), layer 5 (metrics) | Which datasets are certified for reporting |
| Metadata | Layer 4 (catalogue, glossary, lineage) | What metadata is captured and who maintains it |
| Data Quality | Layer 3 (rules and thresholds), layer 5 (monitoring) | Dimensions, thresholds, issue handling |
What is a data governance framework?
The structure through which an organisation exercises authority and control over its data assets: a strategy, policy and principles layer; an operating model of council, owners, stewards and custodians; standards and processes for definitions, quality, classification, access, issues and change; the data assets and metadata being governed; and the tooling and metrics that make it observable.
Is there a standard data governance framework?
No prescriptive one. The DAMA-DMBOK describes data governance as a knowledge area at the centre of data management and explicitly does not prescribe tools or methods; ISO/IEC 38505-1 gives governing bodies principles for data; the five-layer design is how organisations structure what the DMBOK describes.
Which layer should we build first?
Strategy, policy and the operating model — sponsor, policy, council, owners and stewards for a few domains — before standards, assets or tools. Tooling first is the most common failure.
How many roles does the framework need?
Four role types — owner, steward, custodian, user — plus a council and a governance lead. The number of people scales with the domains in scope; an owner per domain and a steward per critical data element group is the usual ratio.
How do we know the framework is working?
Layer 5 metrics: critical data elements with owners and definitions, quality scores against thresholds, issue ageing, access turnaround — reported to the council and used in a maturity assessment.
Build the data governance framework top-down through its five layers: a sponsored policy and principles, an operating model with owners who really decide, standards and processes the stewards apply, an inventory and catalogue of the assets being governed, and tools and metrics that show the council what is happening — because the DMBOK says governance is the exercise of authority over data, and a framework is only real where the authority is named and the decisions are recorded.
The data governance policy and council charter, the RACI and role descriptions, the standards for glossary, quality, classification, access and issue management, the critical data element inventory and the governance KPI report are in the Data Governance Toolkit, or start with the free templates.
September 21, 2026
September 20, 2026
September 20, 2026
September 19, 2026
September 19, 2026