Skill Hub — DAMA / Data

Data Governance Working Skill

Diagnose missing data ownership, undefined rules, and unenforced policies. Produce a governance action plan with named owners, decision rights, and enforcement mechanisms.

What this skill is for

This skill turns vague complaints like "our data is a mess" into a structured governance action plan. It helps you identify who should own which data, what rules should exist, where enforcement is missing, and what decisions must be made before any tool or automation is introduced. The output is a working document that a project team or data steward can act on immediately.

When to use this skill

A data quality initiative has stalled because no one can agree who fixes bad data.
A new system is being integrated and there is no agreed data ownership model between source and target.
Master data changes require three emails and two meetings to approve.
Reports from different systems show different values for the same metric and no one owns the reconciliation.
An audit or compliance review requires documented data ownership, retention rules, or access policies.
You are preparing for AI or automation and need to know which data is trustworthy and who vouches for it.

Real work situations

Example 1: Customer master ownership gap

A sales team creates customers in a CRM. Finance maintains tax data in SAP. The integration breaks when tax numbers are updated in SAP but not in CRM. Neither team accepts ownership of the end-to-end customer record. Orders are blocked. The skill produces an ownership matrix that assigns business ownership to Sales, technical ownership to IT, and data stewardship to a named person.

Example 2: Post-merger data chaos

Two companies merge. Both have product codes, supplier codes, and chart of accounts. The integration team proposes a mapping, but no one has decision rights over which code set survives. Projects stall. The skill surfaces the decision rights gap and produces a governance council charter with voting rules.

Example 3: Unenforced retention policy

A regulation requires customer data to be deleted after seven years. IT has a policy document. The database has no automated deletion. The policy is ignored. The skill identifies the missing enforcement mechanism and produces a rule with a technical owner, a validation query, and a review cycle.

Example 4: Report reconciliation dispute

Finance and Operations both publish "revenue" numbers. They differ by 12%. Each team claims their number is correct. There is no agreed definition, no system of record, and no reconciliation owner. The skill produces a data element register with definitions, sources, owners, and a reconciliation procedure.

Inputs required

List of data domains or data elements in scope (e.g., customer, product, financial transaction).
System inventory showing which systems create, modify, and consume each data domain.
Organizational chart or contact list for business and technical stakeholders.
Existing policies, standards, or guidelines (even if outdated or ignored).
Recent data quality incident log or ticket history (optional but valuable).
Compliance or audit requirements that apply to the data (optional).

Questions to ask

Who is fired if this data is wrong? If no one, ownership is missing.
Which system is the source of truth for this data element, and who certified it?
What rule should prevent this defect, and where is it enforced?
Who approves a change to this data definition, and how long does that take?
What happens when two systems disagree on the value of this field?
Is there a documented policy for this data, and is it technically enforceable?
Who reviews access to this data, and when was the last review?

Working method

Scope the data domain. List the data elements, tables, or objects in scope. Do not try to govern everything at once. Pick one domain with visible pain.
Map the system landscape. For each data element, identify: source system, consuming systems, transformation points, and the system of record.
Identify stakeholders. For each data element, name: business owner (accountable for quality), technical owner (accountable for systems), data steward (day-to-day caretaker), and consumer representatives.
Surface ownership gaps. Flag data elements with missing owners, conflicting owners, or owners who lack authority. Document each gap with business risk.
Catalog existing rules. Collect policies, standards, validation rules, and access controls. Note which are enforced technically, which are enforced by process, and which exist only on paper.
Identify enforcement gaps. For each rule, ask: where is this checked? What happens when it fails? Who is notified? If any answer is missing, the rule is unenforced.
Define decision rights. For each data domain, document who can: create, update, delete, approve changes, approve access, and define rules.
Produce the governance action plan. Combine ownership matrix, rule catalog, enforcement gaps, and decision rights into a single document with priorities and owners.
Validate with stakeholders. Walk through the plan with named owners. Confirm they accept the role and the authority. Adjust if they refuse.
Set review cycle. Define how often ownership, rules, and enforcement are reviewed. Assign a review owner.

Decision rules

If ownership is unclear, produce an ownership matrix before proposing automation.
If a rule exists only in a policy document and is not enforced technically, classify it as "process-dependent" and flag the risk.
If two systems both claim to be the source of truth for the same data element, escalate to architecture; do not guess.
If a data steward is named but lacks system access or decision authority, the ownership is ceremonial; surface the gap.
If a compliance requirement has no technical enforcement, treat it as a high-priority gap regardless of current incident count.
If a data element has no consumers, question whether it should be governed at all; governance has a cost.
If a rule is enforced in one system but not in another that receives the same data, the rule is porous; document the bypass.

Deliverables

Data Ownership Matrix — data elements, owners, stewards, systems, and gap flags. See Artifact Templates.
Rule Catalog — rules, enforcement mechanisms, failure actions, and gap status.
Governance Action Plan — prioritized actions, owners, deadlines, and success criteria.
Decision Rights Charter — who decides what for each data domain.

Templates

Data Ownership Matrix (compact)

| Data Element | System of Record | Business Owner | Technical Owner | Data Steward | Consumers | Ownership Gap |
|--------------|------------------|----------------|-----------------|--------------|-----------|---------------|
| Customer.TaxNumber1 | SAP BP | Sales Director | IT Data Lead | (vacant) | CRM, BW | Steward vacant; no one reviews daily changes |
| Product.MaterialGroup | MDG | Product Manager | IT MDG Admin | Maria K. | S/4, PLM, EDI | None |

Rule Enforcement Check

| Rule | Applies To | Enforcement Point | Failure Action | Review Frequency | Gap |
|------|------------|-------------------|--------------|------------------|-----|
| Tax number required for DE customers | Customer.TaxNumber1 | MDG workflow validation | Block creation | Monthly | None |
| Customer name max 40 chars | Customer.Name1 | API schema | Reject payload | Quarterly | Not enforced in manual SAP GUI entry |

Quality checklist

Every data element in scope has a named business owner and technical owner.
Every owner has been asked and has not refused the role.
Every rule has a documented enforcement point and failure action.
Every enforcement gap has a business risk statement and a proposed closure action.
Decision rights are documented and validated with at least one stakeholder per domain.
The governance action plan has priorities, owners, and deadlines.
No automation or tool purchase is proposed before ownership is clear.

Common mistakes

Mistake: Proposing a data governance tool before ownership is defined. Consequence: The tool enforces nothing because no one configures or maintains the rules.
Mistake: Naming a business unit as owner without naming a specific person. Consequence: Accountability diffuses; decisions stall.
Mistake: Treating a policy document as governance. Consequence: Rules are ignored because there is no enforcement, no review, and no consequence for violation.
Mistake: Defining governance for all data at once. Consequence: The effort collapses under scope; nothing gets implemented.
Mistake: Ignoring informal data caretakers who already do the work. Consequence: The formal owner lacks operational knowledge; the caretaker resists the new structure.

Agent instructions

When using this skill, an AI agent must:

Gather context first. Ask for: the data domain in scope, the systems involved, the stakeholders by name and role, and any existing policy documents. Do not proceed with generic assumptions.
Separate facts from assumptions. If an owner is named but not confirmed, label it "proposed." If a rule is described but not verified in a system, label it "claimed."
Produce artifacts, not summaries. Output a Data Ownership Matrix and a Rule Catalog in the formats provided. Do not produce a narrative essay.
Flag gaps explicitly. For every missing owner, unenforced rule, or unclear decision right, produce a gap statement with business risk. Do not hide gaps in general recommendations.
Avoid generic language. Do not write "data governance is important." Write "Customer.TaxNumber1 has no steward; tax reporting risk is unowned."
Link to Atlas diagnostics when relevant. If the governance gap involves SAP master data, link to SAP Master Data Quality or Master Data Governance Failure Modes.
Handle missing information. If stakeholders or systems are unknown, produce a discovery checklist instead of guessing. Ask the user to fill gaps before proceeding.

Related skills

Data Quality Root Cause — when governance gaps cause recurring defects.
Master Data Management — when the governance scope is master data domains.
Metadata Management — when definitions, lineage, and catalogs are part of the governance gap.
Stakeholder Analysis — when stakeholder mapping precedes ownership assignment.

Related Atlas pages

SAP Master Data Quality — diagnostic patterns for SAP master data defects.
Master Data Governance Failure Modes — common governance breakdowns in SAP landscapes.
SAP MDG Governance Patterns — governance structures that work in SAP MDG contexts.
Data Contracts — formal agreements at system boundaries.

Verification status and limitations

This skill is a public working interpretation of data governance practice. It is not official DAMA-DMBOK documentation. It has been applied in SAP-centric enterprise contexts but may need adaptation for cloud-native, decentralized, or heavily regulated environments.

Limitations: This skill does not cover privacy engineering, data security architecture, or advanced AI governance. It focuses on operational ownership, rules, and enforcement. For legal or regulatory compliance, consult specialized counsel.