BigQuery policy tags vs data governance tags: how to choose for sensitive columns

Let's discuss your project →

BigQuery now offers two ways to manage column-level protection: policy tags and data governance tags. The practical question is not which label sounds newer, but which model fits your governance structure, masking needs, and operating scale.

Google Cloud describes data governance tags as a preview feature for BigQuery column-level security, built on IAM Resource Manager and designed to make governance easier to scale across regions and teams. Policy tags, on the other hand, remain the documented mechanism for column-level access control and dynamic data masking, with regional taxonomies. Google Cloud blog, BigQuery masking docs

For small and mid-sized businesses, the decision usually comes down to three questions:

Do we already have a regional taxonomy that works?
Do we need classification and enforcement to span multiple regions or a broader organization model?
Are we ready to evaluate a preview feature instead of a mature default?

What each option is best for

Policy tags are the safer choice when your current BigQuery setup already relies on a regional taxonomy and you need a straightforward way to control access to sensitive columns. Google’s documentation also shows that policy tags are used for dynamic data masking, and that the Datacatalog API must remain enabled for creating and managing the taxonomies involved in masking. BigQuery masking intro, Policy tags best practices

Data governance tags make more sense when the real problem is scale. Google says they are global, support a hierarchy of up to five levels, and separate classification more cleanly from enforcement. That can be useful if your data estate is split across regions, teams, or governance domains and the old regional model is becoming awkward. Google Cloud blog

The key point is that this is not a full replacement story yet. The blog presents data governance tags as a preview and as an evolution in scalability, but the documentation still supports policy tags as a valid and documented path. Most organizations should therefore think in terms of coexistence and gradual adoption, not forced migration. Google Cloud blog, BigQuery masking docs

Prerequisites before you test either model

Before choosing, check these basics:

Existing BigQuery masking flow: where are protected columns classified today?
IAM ownership: who can create, edit, and review tags?
API readiness: if you use policy tags, confirm the Datacatalog API is enabled for taxonomy and masking management.
Location model: are you working in one region, or do you need a global governance structure?
Change tolerance: are you comfortable testing a preview feature in a limited scope?

A practical decision path

Use this simple sequence.

Step 1: inventory the sensitive columns

List the columns that need protection. For example:

customer_email
national_id
salary
payment_token

Step 2: define the access rule

For each column, answer:

who can see the full value?
who should see a masked value?
who should not see the column at all?

Step 3: map the governance model

If the taxonomy is already regional and stable, stay with policy tags. If you need a broader classification hierarchy across multiple locations or business units, evaluate data governance tags in a controlled pilot.

Step 4: test masking behavior

BigQuery documentation shows that masking can be handled with policy tags or data governance tags, and that data policies can also be applied directly to a column in some cases. That makes testing essential: do not assume the chosen model will automatically behave the way your old process did. BigQuery masking docs

Example: a simulated pilot

Simulated input

Table: crm.customers
Protected column: customer_email
Highly restricted column: national_id
Users: support team, finance team, management

Policy tags path

classify columns in a regional taxonomy;
assign tags to each sensitive column;
apply masking so support sees partial data and finance sees full data where allowed;
verify IAM roles against actual job duties.

Data governance tags path

define a global classification hierarchy;
attach governance tags to the same columns;
test whether the global model reduces duplication across regions or teams;
keep policy tags available during the pilot if you need rollback or coexistence.

Expected simulated output

support sees customer_email masked;
finance sees national_id only if authorized;
management reads aggregated reports only.

Acceptance checks

These checks should be done before go-live by the data owner, security owner, and platform team.

Have all sensitive columns been identified? Checker: data owner.
Do IAM roles reflect the real access model? Checker: security or platform owner.
Does masking return the correct value for authorized and unauthorized users? Checker: functional test with separate test accounts.
Is the governance model understandable for the team that will maintain it? Checker: data lead.
If the feature is still in preview, is there a fallback or coexistence plan? Checker: architecture review.

What not to do

Do not treat data governance tags as if they were already a universal drop-in replacement. The official materials do not support that reading. The safer interpretation is that BigQuery now offers an additional path for column-level security, especially where global classification is becoming harder to maintain with regional taxonomies alone. Google Cloud blog

Practical takeaway

If your current policy tag setup is working, keep it. There is no operational prize for changing a governance model that already fits your structure.

If your real problem is multi-region scale, centralized classification, or a more layered hierarchy, then data governance tags are worth piloting in a narrow scope. The right next step is not a big migration. It is a controlled test with clear ownership, checked access rules, and a rollback path.

For teams protecting sensitive columns in BigQuery, the decision should start with the business process, not with the feature name. That is usually the difference between a useful governance change and a rushed one.