Data Governance: Catalog, Ownership, Classification & Compliance

Data governance defines how data assets are discovered, owned, classified, retained, and protected across an organization. This skill produces governance frameworks that enable trust in data, regulatory compliance, and scalable self-serve data access.

Principio Rector

Datos sin dueño son datos sin calidad. El modelo de ownership se establece ANTES de catalogar. La clasificación determina la protección — no al revés. Privacy by design no es un afterthought sino el punto de partida de cada pipeline. Cada activo de datos tiene un dueño con nombre y apellido, un nivel de clasificación, y una política de retención vinculada a regulación específica.

Inputs

The user provides an organization or data domain as $ARGUMENTS. Parse $1 as the organization/domain name used throughout all output artifacts.

Parameters:

• {MODO}: piloto-auto (default) | desatendido | supervisado | paso-a-paso
  • piloto-auto: Auto para inventario y clasificación, HITL para ownership assignments y privacy decisions.
  • desatendido: Cero interrupciones. Catálogo, clasificación y políticas generados automáticamente. Supuestos documentados.
  • supervisado: Autónomo con checkpoint en classification taxonomy y retention policies.
  • paso-a-paso: Confirma cada asset, clasificación, owner y política de retención.
• {FORMATO}: markdown (default) | html | dual
• {VARIANTE}: ejecutiva (~40% — S1 catalog + S3 classification + S5 privacy compliance) | técnica (full 6 sections, default)

Before generating governance artifacts, detect the data landscape:

!find . -name "*.sql" -o -name "*.py" -o -name "*.yaml" -o -name "*.json" -o -name "schema*" | head -30

Use detected schemas, pipelines, and data sources to tailor catalog structure, classification rules, and ownership recommendations.

If reference materials exist, load them:

Read ${CLAUDE_SKILL_DIR}/references/governance-frameworks.md

Framework Comparison

Select or combine based on organizational context. These are complementary, not mutually exclusive.

Practical recommendation: Use DAMA DMBOK as the knowledge base, DCAM to assess maturity, and supplement with ISO/COBIT for regulatory or board-level requirements.

Governance Maturity Model

Assess current state before prescribing solutions. 5-level model aligned with DAMA DMBOK and CMMI.

Assessment method: Score each criterion (policy documentation, ownership coverage, classification completeness, automation ratio, compliance incident rate) from 1-5. Average determines level. Target: advance one level per 6-12 months.

When to Use

• Building or improving a data catalog with metadata management
• Establishing data ownership and stewardship across domains
• Classifying data by sensitivity (PII, PHI, financial, confidential)
• Designing retention and lifecycle policies for regulatory compliance
• Mapping privacy requirements (GDPR, CCPA, LGPD) to data assets
• Implementing federated governance in a data mesh architecture

When NOT to Use

• Designing data pipelines and ETL/ELT architecture (data-engineering skill)
• Validating data quality rules and monitoring (data-quality skill)
• Enterprise-wide capability mapping (enterprise-architecture skill)
• Infrastructure and storage design (infrastructure-architecture skill)

Delivery Structure: 6 Sections

S1: Data Catalog & Discovery

Maps data assets across the organization.

Catalog platform selection criteria:

Includes:

• Asset inventory: databases, tables, files, APIs, streams, reports
• Metadata strategy: technical (schema), business (definitions), operational (freshness, usage)
• Auto-cataloging: crawlers, schema detection, tag inference
• Lineage integration: source-to-consumption tracing, impact analysis

Key decisions:

• Active vs passive cataloging: crawl-on-schedule vs event-driven registration
• Lineage granularity: table-level (fast) vs column-level (precise) vs row-level (expensive)
• Catalog scope: start with critical data elements, expand iteratively

S2: Ownership & Stewardship Model

Defines who is accountable for data assets and who maintains them.

Includes:

• Domain ownership model: each business domain owns its data products
• Steward role: responsibilities, authority, time commitment (minimum 20% allocation)
• RACI matrix: data owner, steward, consumer, platform team, compliance
• Escalation paths: quality issues, access disputes, classification disagreements
• Governance council: composition, cadence (monthly), decision authority

Key decisions:

• Centralized vs federated ownership: single governance team vs domain autonomy
• Owner authority: can owners restrict access, define SLAs, deprecate assets?
• Steward capacity: dedicated role vs part-time (dedicated required at Level 4+)
• Accountability metrics: ownership coverage %, issue resolution time (target: <48h)

S3: Classification & Sensitivity

Assigns sensitivity tiers enabling proportional security and handling.

Includes:

• Taxonomy: Public, Internal, Confidential, Restricted, Highly Restricted
• PII detection rules: name, email, SSN, phone, address, biometric, IP address
• Automated tagging: regex patterns for structured PII, ML classifiers (Presidio, Google DLP, AWS Macie) for unstructured
• Handling rules per tier: encryption requirements, masking rules, access control, audit logging
• Reclassification triggers: schema changes, new regulations, data repurposing

Key decisions:

• Granularity: table-level vs column-level classification (column-level required for GDPR Article 30 compliance)
• Automation vs manual review: automate detection, human-approve classification changes
• Cross-border sensitivity: data classified differently in different jurisdictions
• Derived data: classification of aggregated or anonymized datasets (anonymization must be irreversible to downgrade classification)

S4: Retention & Lifecycle

Governs how long data is kept, when archived, when purged.

Includes:

• Retention policy matrix: data type x regulation x business need = retention period
• Archival strategy: cold storage tiers, compression, retrieval SLAs
• Purge procedures: hard delete vs soft delete, verification, audit trail
• Legal hold management: litigation hold process, scope definition, release
• Cost modeling: storage cost per retention tier, projected growth, optimization targets

Key decisions:

• Default retention: conservative (keep longer, higher cost) vs minimalist (delete sooner, privacy-friendly)
• Archival accessibility: hours-to-restore tolerance for archived data
• Purge verification: who approves irreversible deletion? (minimum: data owner + compliance)
• Regulatory conflicts: when retention and privacy requirements conflict, document resolution with legal counsel

S5: Privacy & Compliance

Maps privacy regulations to data assets and operationalizes compliance workflows.

Regulation mapping (specific provisions):

Includes:

• Consent management: purpose-based consent, granular opt-in/out, consent lifecycle
• DSAR workflows: discovery, extraction, redaction, response within regulatory timeframe
• DPIA: trigger criteria, assessment template, risk scoring
• Audit trail: who accessed what, when, for what purpose, immutable logging

Key decisions:

• Privacy by design vs retrofit: build into pipelines (strongly preferred) or apply after
• Anonymization vs pseudonymization: irreversible (lower classification) vs re-identifiable with key (maintains classification)
• DSAR SLA: regulatory maximum is the ceiling; target 50% of regulatory window for internal processing

S6: Computational Governance & Data Products

Applies governance as executable code in federated architectures.

Data product thinking: Each dataset treated as a product with:

• Owner and consumer contracts (SLOs for freshness, completeness, accuracy)
• Published schema with semantic versioning
• Discovery metadata (description, tags, lineage, usage statistics)
• Quality score (composite metric visible in catalog)

Computational policies (policy as code):

• OPA/Rego: General-purpose policy engine for access control, metadata validation, lifecycle state transitions. Evaluate at query time or in CI/CD gates.
• Cedar (AWS): Authorization policy language for fine-grained access control.
• Schema validation in CI/CD: Block non-compliant data products at deploy time. Validate naming conventions, required metadata fields, classification tags.
• Automated PII detection on publish: Scan new/changed columns with Presidio, DLP API, or regex; tag, mask, or reject based on classification policy.
• SLA enforcement: Freshness, completeness, accuracy checks run continuously; breach triggers escalation per data-quality SLA tiers.

Global vs local policy boundary:

• Global (non-negotiable): Classification taxonomy, privacy rules, naming conventions, minimum metadata requirements, PII handling
• Local (domain-decides): Schema design, refresh cadence, tool selection, access approval workflow

Key decisions:

• Policy maturity progression: manual checklists (Level 2) -> automated gates (Level 3) -> continuous compliance (Level 4) -> predictive governance (Level 5)
• Central team scope: enablement (tooling, training, templates) vs enforcement (blocking gates)
• Cross-domain data products: ownership of joins/aggregations follows the consumer-creates-derived-product model

Trade-off Matrix

Assumptions & Limits

• Assumes organizational commitment to data governance exists (executive sponsor identified)
• Classification taxonomy requires domain expert input — AI can propose, humans must validate
• Retention policies must be reviewed by legal counsel; this skill provides structure, not legal advice
• Maturity model assessment is point-in-time; re-assess quarterly for accuracy
• Cross-cloud governance assumes catalog tooling supports multi-cloud metadata federation

Casos Borde

Decisiones y Trade-offs

Knowledge Graph

graph TD
    subgraph Core["Core: Data Governance"]
        CAT[Data Catalog & Discovery]
        OWN[Ownership & Stewardship]
        CLS[Classification & Sensitivity]
        RET[Retention & Lifecycle]
        PRIV[Privacy & Compliance]
        COMP[Computational Governance]
    end

    subgraph Inputs["Inputs"]
        SCHEMA[Schemas & Sources]
        REG[Regulatory Requirements]
        ORG[Organizational Structure]
        EXIST[Existing Policies]
    end

    subgraph Outputs["Outputs"]
        CATOUT[Data Catalog Design]
        RACI[RACI Matrix]
        TAX[Classification Taxonomy]
        POLICY[Retention & Privacy Policies]
    end

    subgraph Related["Related Skills"]
        DQ[data-quality]
        DENG[data-engineering]
        SEC[security-architecture]
        ENT[enterprise-architecture]
    end

    SCHEMA --> CAT
    REG --> PRIV
    ORG --> OWN
    EXIST --> RET
    CAT --> OWN --> CLS --> RET --> PRIV --> COMP
    COMP --> CATOUT
    COMP --> RACI
    COMP --> TAX
    COMP --> POLICY
    DQ --> CLS
    CATOUT --> DENG
    CLS --> SEC
    COMP --> ENT

Output Templates

Evaluacion

Umbral minimo: 7/10.

Validation Gate

Before finalizing delivery, verify:

• Data catalog covers critical data elements with technical and business metadata
• Every data domain has an identified owner and steward
• Classification taxonomy defined with clear tier boundaries and handling rules
• Retention policies map to specific regulatory requirements with business justification
• Privacy workflows (DSAR, consent) are operationalized with SLAs, not just documented
• Federated governance defines global vs local policy boundaries explicitly
• At least one computational policy implemented or specified (schema validation, PII detection)
• Escalation paths clear for disputes and incidents
• Cost implications of retention and storage quantified
• Framework phased for incremental adoption (target: advance one maturity level per 6-12 months)

Output Format Protocol

Default output is Markdown with embedded Mermaid diagrams. HTML generation requires explicit {FORMATO}=html parameter.

Output Artifact

Primary: A-01_Data_Governance_Framework.html -- Data catalog design, ownership model, classification taxonomy, retention matrix, privacy compliance workflows, data mesh governance strategy.

Secondary: Classification taxonomy document, RACI matrix, retention policy matrix, DSAR workflow diagram, OPA/Rego policy templates, catalog evaluation scorecard.

Autor: Javier Montaño | Última actualización: 12 de marzo de 2026