Data Governance: Catalogs, Classification, and Access Policy

Classify four columns by sensitivity, then run the same query as three different roles and watch access get enforced column-by-column, not table-by-table.

A catalog: every column, classified once

CATALOG = {
    "gold.customers": {
        "customer_id": "public",
        "signup_country": "internal",
        "email": "confidential",
        "ssn": "restricted",
    },
    "gold.daily_revenue": {
        "order_date": "public",
        "country_code": "public",
        "revenue": "internal",
    },
}

def describe_table(table):
    print(f"{table}:")
    for col, classification in CATALOG[table].items():
        print(f"  {col:<16} {classification}")

describe_table("gold.customers")

$ python governance.py
== catalog: every column classified ==
gold.customers:
  customer_id      public
  signup_country   internal
  email            confidential
  ssn              restricted

The classification lives with the column, decided once, independent of who ever asks for it.

Role clearance, defined separately from the catalog

ROLE_CLEARANCE = {
    "analyst": {"public", "internal"},
    "support_agent": {"public", "internal", "confidential"},
    "compliance_officer": {"public", "internal", "confidential", "restricted"},
}

def enforce_access(role, table, requested_columns):
    clearance = ROLE_CLEARANCE.get(role, set())
    schema = CATALOG.get(table, {})
    allowed, denied = [], []
    for col in requested_columns:
        classification = schema.get(col, "unknown")
        if classification in clearance:
            allowed.append(col)
        else:
            denied.append((col, classification))
    return allowed, denied

The same query, three roles, three different results

print("== analyst wants email and ssn ==")
allowed, denied = enforce_access("analyst", "gold.customers", ["customer_id", "email", "ssn"])
print(f"allowed: {allowed}")
for col, classification in denied:
    print(f"DENIED  {col} (classification={classification}) - analyst role lacks clearance")

== access attempt: analyst wants email and ssn ==
allowed: ['customer_id']
DENIED  email (classification=confidential) - analyst role lacks clearance
DENIED  ssn (classification=restricted) - analyst role lacks clearance

print("== compliance_officer, same query ==")
allowed, denied = enforce_access("compliance_officer", "gold.customers", ["customer_id", "email", "ssn"])
print(f"allowed: {allowed}")
print(f"denied: {denied}")

== access attempt: same query, compliance_officer role ==
allowed: ['customer_id', 'email', 'ssn']
denied: []

print("== support_agent, same query ==")
allowed, denied = enforce_access("support_agent", "gold.customers", ["customer_id", "email", "ssn"])
print(f"allowed: {allowed}")
for col, classification in denied:
    print(f"DENIED  {col} (classification={classification}) - support_agent role lacks clearance")

== access attempt: support_agent, one column above clearance ==
allowed: ['customer_id', 'email']
DENIED  ssn (classification=restricted) - support_agent role lacks clearance

One query, one function, three different results — because the decision is made per column against a role’s clearance set, not as a single table-level yes/no. A support agent can see enough to help a customer (email) without ever touching ssn; an analyst gets neither. No one had to write three separate access rules — adding a fourth role only means defining its clearance set once.

Practice

allowed: ['order_date', 'country_code']
DENIED  revenue (classification=internal) - marketing role lacks clearance

DENIED  phone_number (classification=unknown) - analyst role lacks clearance

CATALOG["gold.customers"]["litigation_note"] = "legal_hold"
allowed, denied = enforce_access("compliance_officer", "gold.customers", ["litigation_note"])
print(allowed, denied)

[] [('litigation_note', 'legal_hold')]

Next: data security and PII — what to do with a column a role isn’t cleared to see in full, instead of just denying it outright.