Data Governance Framework: Policies, Tools, and Implementation

In This Guide

• 1. What Data Governance Actually Means
• 2. The Five Pillars of Data Governance
• 3. Data Catalog — Know What You Have
• 4. Data Quality — Trust Your Data
• 5. Data Lineage — Know Where It Came From
• 6. Access Control and Privacy
• 7. Implementation Roadmap
• 8. Frequently Asked Questions

dbt Data Quality Tests

# schema.yml — declarative data quality checks
version: 2

models:
  - name: orders
    description: "Order data from the e-commerce platform"
    columns:
      - name: order_id
        tests:
          - unique
          - not_null
      - name: customer_id
        tests:
          - not_null
          - relationships:
              to: ref('customers')
              field: customer_id
      - name: amount
        tests:
          - not_null
          - dbt_utils.accepted_range:
              min_value: 0
              max_value: 100000
      - name: status
        tests:
          - accepted_values:
              values: ['pending', 'confirmed', 'shipped', 'delivered', 'cancelled']

    # Table-level tests
    tests:
      - dbt_utils.recency:
          datepart: hour
          field: created_at
          interval: 24    # Fail if no data in 24 hours
      - dbt_utils.expression_is_true:
          expression: "count(*) > 0"

Stripe API  ──→  Raw Payments (Bronze)  ──→  Clean Payments (Silver)  ──→  Revenue Report
    │                                              │                              │
    │         Shopify API  ──→  Raw Orders  ──→  Clean Orders  ──→─────────────────┘
    │
    └── When Stripe changes their API schema, lineage tells you:
        • Which downstream tables are affected
        • Which dashboards will break
        • Who owns each step in the pipeline
        • What the blast radius is

Data Classification and Access Tiers

Classification Tiers:

🔴 RESTRICTED (Level 4)
   PII: SSN, Aadhaar, credit card numbers, health records
   Access: Named individuals only, audit logged, encrypted at rest + transit
   Masking: Always masked in non-production environments

🟠 CONFIDENTIAL (Level 3)
   Business: Revenue data, employee salaries, contracts
   Access: Department heads + approved analysts
   Masking: Masked in dev/staging

🟡 INTERNAL (Level 2)
   Operations: Product catalog, user activity (non-PII), internal metrics
   Access: All employees
   Masking: None needed

🟢 PUBLIC (Level 1)
   Marketing: Published content, public APIs, documentation
   Access: Anyone
   Masking: None

-- SQL implementation: Row-level security
CREATE POLICY customer_access ON customers
    USING (region = current_setting('app.user_region'));

-- Column masking for PII
CREATE VIEW safe_customers AS
SELECT id, name,
       regexp_replace(email, '(.)(.*)(@.*)', '\1***\3') AS email_masked,
       'XXX-XXX-' || right(phone, 4) AS phone_masked
FROM customers;

Related Articles