Aleksei Aleinikov

Posted on Jul 20 • Originally published at alekseialeinikov.com on Jul 20

Data Governance on GCP in 2026: Who Can See This Data?

#datagovernance #googlecloud #bigquerycolumnlevels #policytags

“Who can see this data?” sounds like a one-line question. In a real organization it is four questions wearing a trench coat, and if you cannot answer all four, you do not have data governance — you have a spreadsheet of good intentions.

Every regulated audit, every “can marketing query the customer table” ticket, every data breach post-mortem comes back to the same four things:

What data do we even have?
Where inside it is the sensitive stuff?
Who is allowed to see it?
Can it leave?

The good news on Google Cloud is that each question has a dedicated, mature answer — and the trick is knowing which service answers which question, and how they snap together. This is a practical, up-to-date map for platform and data engineers who have to ship governance, not just talk about it.

The Foundation: IAM Is Not Governance (But Everything Sits On It)

Before the four questions, one reminder: Identity and Access Management is the floor, not the building. IAM decides who can call which API and touch which dataset. It is necessary, it is where every access decision ultimately resolves — and it is far too coarse on its own. “Grant the analytics team the BigQuery Data Viewer role on this dataset” is an all-or-nothing grant: they see every column, including the ones with national IDs in them.

Governance is what you build on top of IAM to make access precise, discoverable, classified, and contained. So let’s build.

Question 1 — What Data Do We Have? (Knowledge Catalog)

You cannot govern what you cannot see. The first pillar of any governance program is a catalog : a single, searchable inventory of every table, view, stream, and file across the estate, enriched with business meaning.

On Google Cloud that is Knowledge Catalog — the service formerly known as Dataplex Universal Catalog (renamed in April 2026; the gcloud dataplex commands, APIs, and IAM names are unchanged, so existing setups keep working). It automatically ingests technical metadata from BigQuery, Spanner, Bigtable, Pub/Sub, Cloud Storage, AlloyDB, Cloud SQL, Vertex AI, and more, and gives you:

A searchable catalog with faceted and natural-language search across the whole estate.
A business glossary so “Lifetime Value” or “active customer” means one thing, defined once.
Automatic data quality and profiling — rules that check whether shipping addresses are complete or a column’s values drift.
End-to-end data lineage — a graph of how a column in a dashboard traces back through every transformation to its source table, which is gold for both debugging pipelines and proving compliance.

The lineage graph is the piece people underestimate. When an auditor asks “where did this number come from?” or an engineer asks “what breaks if I drop this column?”, lineage answers in seconds instead of a week of archaeology.

Question 2 — Where Is the Sensitive Data? (Sensitive Data Protection)

A catalog tells you a customers table exists. It does not tell you that the free-text notes column is full of phone numbers and the odd credit-card number a support agent pasted in. Finding that is a different job, and it belongs to Sensitive Data Protection — the service formerly called Cloud DLP (the API is still the Cloud Data Loss Prevention API).

It has three jobs worth knowing:

Discovery generates data profiles across an organization, folder, or project — a continuously updated map of which tables and columns hold sensitive, high-risk data, scored by sensitivity. This is the scan you run first.
Inspection does a deep scan of one resource for specific infoTypes (SSN, email, credit-card number, and hundreds more), reporting the exact location and count of each match. Useful for unstructured text where PII hides intermittently.
De-identification obfuscates the data itself — masking, redaction, bucketing, date-shifting, or tokenization — so you can create a safe-to-share copy or de-identify at query time.

The reason this pillar matters for access control is the handoff: Sensitive Data Protection’s column data profiles tell you exactly which columns need to be locked down. You do not guess which columns are sensitive; you let discovery find them, then you tag them. Which is Question 3.

Question 3 — Who Can See It? (BigQuery Column-Level Security)

Here is the heart of “who can see this data.” In BigQuery you enforce column-level access with a taxonomy of policy tags plus IAM.

The workflow is four steps:

Define a taxonomy and policy tags. A data steward creates a classification hierarchy — for example a Business criticality taxonomy with High and Medium nodes, and leaf tags like employee_ssn. A taxonomy can be up to five levels deep.
Assign policy tags to columns. In the table schema, attach a policy tag to each sensitive column. A column can carry exactly one policy tag.
Enforce access control on the taxonomy so the restrictions become active.
Manage access with IAM. Grant the Data Catalog Fine-Grained Reader role (datacatalog.categoryFineGrainedReader) on each policy tag to the groups allowed to read those columns.

The enforcement is the important part. Column-level access is checked in addition to the dataset ACL — a user needs both dataset permission and the fine-grained reader role on the tag. If they have dataset access but not the tag, a SELECT * fails with an error that lists exactly which columns they cannot read, and they have to either exclude them (SELECT * EXCEPT (ssn)) or request access.

Here is the schema annotation that ties a column to a policy tag:

[

  { "name": "customer_id", "type": "STRING", "mode": "REQUIRED" },

  { "name": "email", "type": "STRING", "mode": "NULLABLE" },

  {

    "name": "ssn",

    "type": "STRING",

    "mode": "NULLABLE",

    "policyTags": {

      "names": [

        "projects/PROJECT_ID/locations/us/taxonomies/TAXONOMY_ID/policyTags/POLICYTAG_ID"

      ]

    }

  }

]

Terminal window

# Apply the schema (with the policy tag) to an existing table

bq update PROJECT_ID:dataset.customers schema.json

# Grant a group fine-grained read on the "High" policy tag

gcloud data-catalog taxonomies policy-tags add-iam-policy-binding POLICYTAG_ID \

  --taxonomy=TAXONOMY_ID --location=us \

  --member="group:pii-approved@example.com" \

  --role="roles/datacatalog.categoryFineGrainedReader"

Dynamic data masking is the softer sibling. Instead of a hard error, you can configure a masking rule on a policy tag so unauthorized users receive a NULL, a default, or a hashed value in place of the real one. That is what lets a fraud analyst see a hashed card number for joins without ever seeing the real digits — partial access instead of all-or-nothing. Every read of a tagged column is written to Cloud Logging, so auditors can reconstruct who accessed which class of sensitive data.

Question 4 — Can It Leave? (VPC Service Controls)

The first three questions govern access inside your project. The last one is about the wall around it. Even with perfect IAM and perfect policy tags, one stolen service-account key or one over-broad grant can let someone copy a whole dataset to a personal project. VPC Service Controls exists to make that impossible.

It draws a service perimeter around your Google-managed resources (BigQuery, Cloud Storage, and many more). Inside the perimeter, communication is free; across it, everything is denied by default. Concretely, it blocks exactly the exfiltration moves IAM would allow:

A bq copy or gcloud storage cp to a bucket or table outside the perimeter fails.
A client using stolen credentials from an unauthorized network is refused, because access is tied to network origin and context, not just identity.
Ingress and egress rules and access levels (via Access Context Manager) let you open precise, context-aware holes — this IP range, this identity, this device posture — without dropping the wall.

The mental model Google recommends is defense in depth : IAM is identity-based access control; VPC Service Controls is context-based perimeter control. You want both. And you can roll it out safely with dry-run mode , which logs what would be blocked without actually blocking, so you find every legitimate data flow before you enforce.

The Whole Picture, One Table

Each pillar answers a different question. Here is how they line up:

Governance question	Service	What it does	Enforcement point
What data do we have?	Knowledge Catalog (formerly Dataplex)	Catalog, business glossary, data quality, lineage	Metadata / discovery (not a gate)
Where is the sensitive data?	Sensitive Data Protection (formerly Cloud DLP)	Discovery profiles, inspection, de-identification	Classification + optional masking of copies
Who can see it?	BigQuery policy tags + IAM	Column-level access via taxonomy; dynamic masking	At query time, in addition to dataset ACLs
Can it leave?	VPC Service Controls	Service perimeter, ingress/egress rules	At the API boundary, independent of IAM
(Foundation)	IAM	Identity → role → resource access	Every API call

Notice the division of labor: the catalog and the profiler inform, IAM and policy tags authorize, and the perimeter contains. Skip any one and you have a visible gap — an uncataloged data lake, unclassified PII, all-or-nothing columns, or an open door to exfiltration.

Where to Start (A Decision Guide)

You do not deploy all four at once. Governance is a maturity path, and the right first move depends on what hurts most today.

“We don’t even know what we have.” Start with Knowledge Catalog. Turn on automatic metadata ingestion, get the estate into one searchable place, and switch on lineage. Everything else is easier once you can see the map.
“We know our tables but not where the PII is.” Run Sensitive Data Protection discovery across the org. Let it profile every table and surface the high-risk columns. Now you have a prioritized list of what to protect.
“Access is all-or-nothing and audit hates it.” Implement BigQuery column-level security. Build a small taxonomy (start with two or three classification levels), tag the columns discovery flagged, and grant fine-grained reader to the right groups. Add dynamic masking where partial access is useful.
“Our real risk is data walking out the door.” Stand up VPC Service Controls in dry-run mode, map every legitimate flow, then enforce. This is the control that survives a stolen key.

Most teams end up doing all four, in roughly that order — because you have to see data before you can classify it, classify it before you can restrict it precisely, and restrict it before a perimeter is anything more than a blunt wall.

The Honest Verdict

Data governance on Google Cloud is not a product you buy; it is a posture you assemble from IAM, Knowledge Catalog, Sensitive Data Protection, BigQuery policy tags, and VPC Service Controls. The platforms are mature and they interlock cleanly — the discovery profiler literally hands the access layer a list of columns to protect, and the perimeter backs up IAM when IAM inevitably has a bad day.

The mistake I see most is treating governance as a single access-control task — “just set the IAM roles.” That answers one of the four questions. Answer all four, wire them to your corporate identity through SSO and groups, and “who can see this data?” stops being a scramble before every audit and becomes a property of the platform. That is the whole point.

If you liked this, the companion pieces on secure-by-default GKE and user-level MCP tool permissions apply the same “control follows identity” idea to compute and AI tooling.

Originally published at alekseialeinikov.com

DEV Community