Data Governance Is a Security Control, Not a Compliance Checkbox

I've spent years fixing broken Glue jobs and Lake Formation permissions as an AWS support engineer, then moved to pre-sales architecture for banking data platforms. One pattern shows up in almost every migration: teams build IAM policies and a data catalog as two separate workstreams, run by two separate teams, that never talk to each other. Then six months post-launch, someone asks, "Who can see the SSN column in the gold layer?" and nobody can answer without a week of manual auditing.

That gap isn't a process problem. It's an architecture problem. This article walks through why classification and access control need to be the same system, with the actual policy constructs to make that work on AWS, and where teams get this wrong.

The Failure Mode

A typical lakehouse migration goes like this:

1. Data engineering builds the pipeline: source → Bronze → Silver → Gold.
2. A separate governance initiative (often 6-12 months behind) builds a catalog: Collibra, DataHub, Purview, whatever.
3. Security writes IAM policies against S3 prefixes and Glue databases — because that's what exists at go-live.

The catalog knows column cust_ssn is PII. IAM doesn't. So access control is granted at the table or prefix level, which means anyone with table access sees every column, including the ones the catalog explicitly flagged as sensitive. The classification work becomes documentation instead of enforcement.

This is exactly the gap that tag-based access control was built to close, and most teams don't use it because it requires governance and security to share a data model, which is an org problem more than a technical one.

Tag-Based Access Control: The Actual Mechanism

On AWS, Lake Formation's LF-Tags let you attach classification metadata directly to catalog resources — databases, tables, even columns — and write IAM-style policies against the tags instead of the ARNs.

Tagging a column as sensitive:

aws lakeformation add-lf-tags-to-resource \  --resource '{
    "TableWithColumns": {
      "DatabaseName": "credit_risk_gold",
      "Name": "customer_360",
      "ColumnNames": ["cust_ssn", "cust_dob"]
    }
  }' \  --lf-tags '[{"TagKey": "data_classification", "TagValues": ["pii_restricted"]}]'

Granting access by tag, not by table name:

aws lakeformation grant-permissions \  --principal '{"DataLakePrincipalIdentifier": "arn:aws:iam::111122223333:role/RiskAnalystRole"}' \  --permissions "SELECT" \  --resource '{
    "LFTagPolicy": {
      "ResourceType": "TABLE",
      "Expression": [
        {"TagKey": "data_classification", "TagValues": ["public", "internal"]}
      ]
    }
  }'

The RiskAnalystRole above gets SELECT on anything tagged public or internal — automatically, across every current and future table with that tag. It gets nothing on pii_restricted columns unless a separate grant explicitly adds it. New tables inherit policy from their tags at creation time, not from a security team manually reviewing each new dataset.

Databricks Unity Catalog does the equivalent with attribute-based access control and dynamic views:

CREATE VIEW customer_360_masked AS
SELECT  cust_id,  CASE    WHEN is_account_group_member('risk_pii_readers') THEN cust_ssn    ELSE 'REDACTED'  END AS cust_ssn,  cust_dob,  account_balance
FROM customer_360_raw;

Same principle: the masking rule reads from group membership, which is governed centrally, not hardcoded per consumer.

Where This Actually Breaks in Practice

Three failure points I've seen repeatedly on migration engagements:

Classification lag. Auto-classification tools (Macie, Purview's classifiers) run periodically, not on write. A new column with SSNs can sit unclassified — and therefore unprotected by tag policy — for hours or days. Mitigation: enforce classification as a CI/CD gate on schema changes, not a background scan.

Derived data breaks lineage. A gold-layer aggregate table built from a PII source doesn't automatically inherit the source's tags unless your ETL explicitly propagates them. I've seen teams tag Bronze meticulously and leave Gold completely untagged because "it's aggregated, so it's safe" — until someone adds a customer_email passthrough column six months later during a "quick fix."

Vector stores are an ungoverned blind spot. RAG pipelines embed source documents into vector DBs. The embeddings are technically an obfuscation, not encryption, and can leak source content back out under adversarial querying. If your governance program stops at the relational catalog, your embedding store has none of these controls at all — this is the fastest-growing gap I see on client engagements right now.

What to Actually Do About It

If you're an architect on a migration, the ordering matters more than the tooling:

1. Classification runs before or during pipeline design, not after go-live. Build it into the migration assessment.
2. One tag taxonomy, enforced everywhere — Bronze, Silver, Gold, and vector stores alike. If your classification schema doesn't apply to your RAG pipeline, it's incomplete.
3. Policy grants reference tags, never table/prefix names. This is the difference between a policy that scales and one that needs manual review for every new table.
4. Audit logs (CloudTrail, Unity Catalog audit, Lake Formation permissions history) get mapped to your actual compliance controls (SR 11-7, GDPR Article 30, DPDP) as a standing report, not a one-time audit exercise.

None of this is exotic. It's mostly discipline about doing classification first and wiring access policy to read from it, instead of treating them as two projects run by two teams on two timelines.

References

• AWS Documentation – Lake Formation Tag-Based Access Control
• Databricks Documentation – Unity Catalog attribute-based access control and dynamic views
• NIST SP 800-53 Rev. 5 – Security and Privacy Controls for Information Systems
• Federal Reserve SR 11-7 – Guidance on Model Risk Management
• DAMA International – DMBOK2