Data Governance And Stewardship

Why this matters for Data Architects

Data governance and stewardship ensure the data platform is trusted, compliant, and usable. As a Data Architect, you define guardrails: who owns which data, how it is classified, how changes are approved, how access is granted, and how quality and auditability are maintained. Strong governance unlocks faster delivery because teams can self-serve safely.

What you'll be able to do

• Define stewardship roles and RACI for data domains.
• Design and implement access policies (row/column-level, masking, least privilege).
• Classify data (Public/Internal/Confidential/Restricted) and tag PII fields.
• Set up approval workflows for schema and policy changes.
• Standardize metadata and naming across the platform.
• Write data quality SLAs and implement tests/monitors.
• Mark datasets as Certified and communicate trust levels.
• Ensure auditability across data movement and access.

Who this is for

• Data Architects shaping platform standards.
• Analytics Engineers and Data Engineers implementing policies.
• Data Stewards and Product Owners responsible for domains.

Prerequisites

• Intermediate SQL and basic data modeling (star schemas, slowly changing dimensions).
• Familiarity with a data warehouse or lakehouse (e.g., concepts of schemas, tables, roles).
• Basic Git workflow (branch, PR, review).

Learning path

1. Establish roles and ownership — Define domain owners and stewards, plus a simple RACI. Document decisions in version control.
2. Classify data and tag PII — Create a 3–4 level classification model and tag columns accordingly.
3. Design access policies — Implement role-based access, row/column security, and masking based on classification.
4. Approval workflow — Standardize how schema and policy changes are proposed and reviewed (templates + PR reviewers).
5. Metadata & naming — Adopt naming, lineage, and documentation standards that tools and people can follow.
6. Quality SLAs and monitors — Define expectations (freshness, completeness, accuracy) and wire up tests/alerts.
7. Certification & trust — Mark high-quality datasets as Certified, with visible criteria and ownership.
8. Auditability — Ensure access, change, and data movement are logged and queryable.

Worked examples

-- Conceptual SQL for a warehouse that supports masking policies
CREATE MASKING POLICY mask_email AS (email STRING) RETURNS STRING ->
  CASE
    WHEN CURRENT_ROLE() IN ('DATA_STEWARD', 'PRIVACY_OFFICER', 'PII_READ') THEN email
    ELSE REGEXP_REPLACE(email, '(^.).+(@.+$)', '\\1***\\2')
  END;

-- Apply to a column
ALTER TABLE prod.customers MODIFY COLUMN email SET MASKING POLICY mask_email;

-- Postgres-style RLS example
ALTER TABLE sales.orders ENABLE ROW LEVEL SECURITY;

CREATE POLICY orders_region_policy ON sales.orders
USING (
  region = current_setting('app.user_region', true)
);

-- At session start, set user's region attribute (done by app/BI proxy)
-- SELECT set_config('app.user_region', 'EMEA', true);

{
  "table": "prod.customers",
  "classification": "Restricted",
  "pii_columns": [
    {"name": "email", "tags": ["PII", "Contact"], "masking": "mask_email"},
    {"name": "phone", "tags": ["PII", "Contact"], "masking": "mask_phone"}
  ],
  "retention_days": 3650,
  "owner": "domain:customer",
  "steward": "user:alice.steward"
}

-- Freshness (should be <= 2 hours old)
SELECT
  CASE WHEN MAX(ingested_at) > now() - interval '2 hours' THEN 1 ELSE 0 END AS fresh_ok
FROM analytics.fact_orders;

-- Completeness (no null customer_id)
SELECT COUNT(*) AS null_customer_id
FROM analytics.fact_orders
WHERE customer_id IS NULL;

-- Accuracy proxy (referential integrity)
SELECT COUNT(*) AS missing_customers
FROM analytics.fact_orders f
LEFT JOIN prod.customers c ON f.customer_id = c.id
WHERE c.id IS NULL;

# change_request.yml (submitted via PR)
change_type: schema_change
proposed_by: "user:bob.engineer"
affected_objects:
  - table: analytics.fact_orders
    change: add_column
    column: is_preorder BOOLEAN DEFAULT false
risk: low
backout_plan: "ALTER TABLE analytics.fact_orders DROP COLUMN is_preorder;"
owner_ack: "domain_owner:sales"
steward_ack: "steward:alice.steward"
controls_checked:
  - data_quality_tests_updated: true
  - access_policies_reviewed: true
  - documentation_updated: true

-- Example generic audit schema
-- audit.events(event_time, actor, action, object, details)

-- Who viewed Restricted data yesterday?
SELECT actor, COUNT(*) AS views
FROM audit.events
WHERE action = 'SELECT' AND details->>'classification' = 'Restricted'
  AND event_time >= now() - interval '1 day'
GROUP BY actor
ORDER BY views DESC;

-- What changes were made to access policies last week?
SELECT event_time, actor, action, object, details
FROM audit.events
WHERE action IN ('CREATE_POLICY', 'ALTER_POLICY', 'DROP_POLICY')
  AND event_time >= now() - interval '7 days'
ORDER BY event_time DESC;

Drills and exercises

• Map a domain and assign Owner and Steward. Write a one-paragraph RACI.
• Classify 10 representative columns across two tables; tag which are PII.
• Draft a masking policy for emails and phones and apply to a test table.
• Implement a row-level rule for region or department; test with two user roles.
• Write a change_request.yml for adding a sensitive column; include backout plan.
• Define three SLAs (freshness, completeness, accuracy) for one dataset and add tests.
• Choose criteria for “Certified” and certify one dataset; document the criteria.
• Run two audit queries: a) who queried a Restricted table; b) recent policy changes.

Common mistakes and how to fix them

Practical mini project: Govern one high-impact dataset

Goal: Take a critical dataset (e.g., fact_orders) from ad-hoc to governed.

1. Define Owner and Steward and publish RACI for the dataset.
2. Classify columns and tag PII; implement masking policies for PII.
3. Add row-level security if needed (e.g., by region or business unit).
4. Create quality SLAs (freshness <= 2h, completeness >= 99.5%, no orphan keys) and implement tests.
5. Set up an approval workflow template; submit a PR for a schema change to test the process.
6. Document metadata (owner, steward, purpose, dependencies, SLAs, classification).
7. Certify the dataset after it meets criteria; announce in release notes.
8. Validate audit logs show policy changes and recent access events.

Subskills

• Ownership And Steward Roles — Define who decides, who implements, who is accountable.
• Policies For Data Access — Role-based, row/column-level, masking, and least-privilege patterns.
• Data Classification And PII Tagging — Tier data sensitivity and mark PII for automated controls.
• Approval Workflows For Changes — Standard templates, reviewers, and backout plans.
• Metadata Standards — Naming, ownership, lineage, and machine-readable tags.
• Data Quality SLAs — Define measurable freshness, completeness, and accuracy expectations.
• Certified Datasets And Trust Levels — Signal reliability and readiness for broad use.
• Auditability Requirements — Log access and changes; make them queryable.

Next steps

• Complete the drills, then ship the mini project for one domain.
• Socialize the standards; invite feedback from stewards and analysts.
• Scale to more domains using the same templates.