# Data Governance

> When to activate: data governance, data catalog, data dictionary, data lineage, data ownership, data quality, data classification, retention policy, data steward

- Skill: `mattakushi432/data-governance` (Agent Skill)
- Install (CLI): `npx skillmds@latest add mattakushi432/data-governance`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mattakushi432/data-governance/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Mattakushi432 (https://skillmd.com/u/mattakushi432)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mattakushi432/data-governance

---


# Data Governance

## Framework Components

A complete data governance program covers:

1. **Policies** — rules for how data is managed (classification, retention, access)
2. **Standards** — technical specifications (naming conventions, formats, quality thresholds)
3. **Processes** — how governance is executed (request handling, data quality remediation)
4. **Roles** — who owns, stewards, and uses data
5. **Technology** — catalog, lineage, quality tooling
6. **Metrics** — how governance health is measured

## Data Classification Tiers

| Tier | Label | Examples | Default handling |
|------|-------|----------|-----------------|
| 1 | Public | Press releases, marketing content, public docs | No controls needed |
| 2 | Internal | Internal policies, employee directories, meeting notes | Internal use only, not for external sharing |
| 3 | Confidential | Customer PII, financials, contracts, source code | Encrypted at rest and in transit; access-controlled |
| 4 | Restricted | Health records, payment card data, credentials, trade secrets | Strict need-to-know; regulatory controls apply |

### Classification Decision Tree
```
Does it contain PII, PHI, PCI, credentials, or trade secrets?
  Yes → Restricted
Does it contain customer data, financial data, or internal IP?
  Yes → Confidential
Is it intended for internal use only?
  Yes → Internal
Otherwise → Public
```

## Data Catalog Structure

A data catalog entry should include:

| Field | Description |
|-------|-------------|
| Asset name | Technical name of the table/dataset/API |
| Display name | Human-readable name |
| Description | What the asset contains and its purpose |
| Owner | Business owner (accountable for the data) |
| Steward | Technical steward (maintains quality and definitions) |
| Classification | Public / Internal / Confidential / Restricted |
| System of record | Authoritative source for this data |
| Consuming systems | Downstream systems that use this data |
| Tags | Domain, subject area, regulation tags |
| Last updated | Date metadata was last verified |

## Data Dictionary Template

For each field in a dataset:

| Field name | Data type | Description | Example | Owner | PII? | Nullable | Source |
|-----------|-----------|-------------|---------|-------|------|----------|--------|
| customer_id | UUID | Unique identifier for a customer | 550e8400-... | Data Platform | No | No | CRM |
| email_address | VARCHAR(255) | Customer email | user@example.com | Marketing | Yes | No | Sign-up form |
| date_of_birth | DATE | Customer date of birth (YYYY-MM-DD) | 1985-03-22 | Compliance | Yes (Sensitive) | Yes | KYC flow |

## Data Lineage Documentation

### Lineage Levels
- **Column-level** — tracks individual field transformations (gold standard)
- **Table-level** — tracks which tables feed which tables
- **System-level** — tracks data flows between systems

### Lineage Capture Methods
| Method | Effort | Coverage |
|--------|--------|----------|
| Manual documentation | High effort, low accuracy | Legacy systems |
| ETL metadata parsing | Medium effort | ETL-based pipelines |
| Query log analysis | Medium effort | SQL-based transformations |
| Automated scanners (OpenMetadata, DataHub, Atlan) | Low ongoing effort | Modern stacks |

### Minimum Lineage Record
```
Source: [System/Table/Column]
Transformation: [Description of logic applied]
Destination: [System/Table/Column]
Frequency: [Real-time / Hourly / Daily / Weekly]
Owner: [Team responsible for the pipeline]
Last validated: [Date]
```

## Data Ownership RACI

| Activity | Data Owner | Data Steward | Data Consumer | Governance Team |
|----------|-----------|-------------|---------------|----------------|
| Define data policies | A | C | I | R |
| Maintain data dictionary | I | A/R | I | C |
| Approve access requests | A | R | I | C |
| Resolve data quality issues | A | R | I | C |
| Classify new data assets | A | R | I | C |
| Conduct data audits | I | R | I | A |

R = Responsible, A = Accountable, C = Consulted, I = Informed

## Data Quality Dimensions

| Dimension | Definition | Measurement |
|-----------|-----------|-------------|
| Completeness | No missing required values | % non-null for required fields |
| Accuracy | Values correct and reflect reality | Spot check vs source system |
| Consistency | Same data, same value across systems | Cross-system reconciliation |
| Timeliness | Data available when needed | Lag from event to availability |
| Uniqueness | No unintended duplicates | Duplicate record count |
| Validity | Values conform to defined formats/ranges | % values passing validation rules |

### Quality Threshold Example
| Dimension | Target | Alert threshold |
|-----------|--------|----------------|
| Completeness | ≥ 99% | < 95% |
| Accuracy | ≥ 99.5% | < 98% |
| Timeliness | ≤ 1 hour lag | > 4 hours |
| Uniqueness | 0 duplicates | Any duplicates |

## Retention Policy by Data Type

| Data type | Retention period | Basis | Disposal method |
|-----------|-----------------|-------|----------------|
| Customer PII | Duration of relationship + 7 years | Legal/contractual | Secure deletion |
| Financial records | 7 years | Tax/audit | Secure deletion |
| Employee records | Employment + 7 years | Employment law | Secure deletion |
| System logs | 12 months (hot) + 24 months (cold) | Security/PCI | Secure deletion |
| Marketing data | Until opt-out + 30 days | CCPA/GDPR | Secure deletion |
| Backup data | 90 days | Operational | Encrypted overwrite |
| Contracts | Term + 10 years | Legal | Secure archival |

## Governance Committee Charter

### Purpose
Oversee enterprise data governance program; resolve cross-domain data disputes; approve policies.

### Membership
- Chief Data Officer (chair)
- Representatives from: Legal, Compliance, IT Security, Finance, Product, Analytics
- Data stewards from key domains (rotating)

### Meeting Cadence
- Monthly governance committee meeting
- Quarterly data quality review
- Annual policy review

### Decision Authority
| Decision | Authority level |
|----------|----------------|
| New data classification policy | Committee approval |
| Access to Restricted data | Data owner + Compliance |
| New data retention schedule | Committee approval |
| Data quality remediation plan | Steward (inform committee) |
| Cross-border data transfer | Legal + Compliance |

## Data Incident Process

### Severity Classification
| Severity | Definition | Response time |
|----------|-----------|---------------|
| P1 | Restricted data exposed externally | Immediate (< 1 hour) |
| P2 | Confidential data accessed without authorization | < 4 hours |
| P3 | Data quality issue affecting decisions | < 24 hours |
| P4 | Policy violation, no data exposure | < 1 week |

### Response Steps
1. Detect and contain the incident
2. Assess scope — what data, how many records, who affected
3. Notify: Data Owner → Governance Team → Legal/Compliance (if P1/P2)
4. Preserve evidence (logs, access records)
5. Remediate root cause
6. Document lessons learned
7. Update controls to prevent recurrence