Scaling security: ABAC, tags & automatic policies with Unity Catalog

Anyone trying to make sensitive data usable on a modern analytics platform today quickly notices: classic one-off grants don't scale well. This is exactly where ABAC in Unity Catalog comes in. Instead of maintaining permissions object by object, you can align security logic more strongly with data classification, context, and reusable rules. That's not just more elegant – above all, it's more reliable.

For many teams, the problem creeps in gradually. First there are a few tables, a few groups, and a few grants. Then new domains, self-service use cases, external partners, data products, and sensitive attributes get added. At that point, what I like to call "grant spaghetti" emerges: a permission model that has grown historically but can barely be explained, maintained, or audited cleanly anymore.

This is particularly delicate in SAP-adjacent organizations. They're rightly used to data provisioning being reliable, traceable, and controlled. But modern platforms also need agility. So the art isn't pitting security against usability. The art is designing security so that it puts usability on a stable foundation in the first place.

Why ABAC scales – and grant spaghetti doesn't

Many permission models start role-based and end up improvised. That's not a sign of incompetence – it's often simply a growth problem. As long as few teams work with few data objects, direct grants still work reasonably well. But as platform maturity increases, the model tips over.

Typical symptoms of grant spaghetti are:

• Individual rights at the table or column level with no clear system
• One-off exceptions for special cases that never get cleaned up again
• Unclear ownership between the platform team, business unit, and security
• High manual maintenance effort
• Difficult auditability
• High uncertainty around changes

ABAC stands for Attribute-Based Access Control. In the Databricks context, put simply, this means: access isn't granted only through rigid roles, but is controlled more through attributes, classifications, and rules. These attributes can relate to data objects, user context, or organizational characteristics.

Importantly: attribute-based access control in Databricks is not a replacement for every role-based model. ABAC is more the scaling logic layered on top of the base structure. Roles remain useful. But if every exception is solved with yet another grant, the model grows like a basement where you've been "just quickly storing something" for ten years.

RBAC is the starting point. ABAC is often the scaling mechanism.

A pragmatic way to picture it:

• RBAC answers: which role is fundamentally allowed to do what?
• ABAC answers: under which conditions, on which data, in which context?

This is especially valuable when you work with sensitive data, such as:

• personal data
• financial data
• internal or confidential information
• country-restricted data
• domain-specific data products

In such environments, it's more efficient to define reusable rules than to handle every table individually.

Why this is critical for self-service

Self-service rarely fails purely because of technology. It often fails because of missing security logic. If every new data release triggers a manual coordination process with ten special cases, self-service quickly turns into "a support ticket with hope attached."

ABAC helps resolve this contradiction:

• more standardization
• less case-by-case maintenance
• better traceability
• more consistent enforcement
• lower residual risk as the platform grows

Governed tags in Unity Catalog: What they do and how to use them effectively

If ABAC is the logic, then governed tags are an important part of the language. Tags help classify data objects consistently and derive reusable security rules from that classification.

A tag is initially just an attribute. The difference comes from governance: who is allowed to assign tags? Which values are permitted? Which policies are attached to them? And how is it verified that classification is complete and consistent?

This is exactly why tags in Unity Catalog are more than just pretty labels. Used correctly, they become the link between data classification, the security model, and auditability.

Typical governed tags

Sensible examples of governed tags are:

• PII – for personal or personally identifiable data
• financial – for financially relevant data, such as actuals, forecasts, margins, or planning data
• internal – for internally usable data not intended for external partners or open use

Other useful tags might include:

confidential, restricted, public, country_scope=CH, country_scope=DE, retention_class=7y, domain=finance, domain=supply_chain

Good tags aren't arbitrary

A common mistake: teams start with too many free-form tags and later wonder about chaos in new packaging. At that point, you no longer have grant spaghetti – you have tag spaghetti. That's not progress.

Pragmatic rules for governed tags:

• a few, clearly defined classification categories
• defined owners
• documented meaning
• mandatory naming convention
• clear policy mapping
• regular quality checks

An SAP-adjacent translation aid

For SAP-experienced teams, here's how to frame it: governed tags aren't a 1:1 equivalent to familiar authorization objects, but they serve a similar purpose at the modern platform level: they standardize the classification of data so that security decisions don't have to be reinvented every time.

Put differently: instead of one-off special cases per object, you build a reliable classification logic for data provisioning.

Governed tag reference (compact)

Tag policy templates: From tags to row filters and column masking

The real value doesn't come from tags alone, but from connecting tags and policies. Only once classification becomes an automatically enforceable rule does the model actually scale.

For that, you need policy templates – reusable patterns that define what should happen for specific tags.

Why templates are better than case-by-case rules

A template creates:

• consistency
• reusability
• lower maintenance effort
• better auditability
• faster rollout across multiple domains

If, for example, every PII column is handled individually, the error rate rises. If, instead, a standardized template defines how PII is masked, security becomes more predictable.

Typical policy patterns

Sensible policy patterns include:

• PII → column masking
• financial → access only for defined groups or contexts
• internal → exclusion of external use
• country_scope → access based on regional context
• restricted → additional approval or a narrower access path

Pseudocode: Tag policy templates

Note: the following examples are deliberately written as pseudocode. They serve to illustrate the security logic, not exact product syntax.

POLICY TEMPLATE mask_pii_columns
IF column.tag == 'PII'
THEN
  APPLY MASKING RULE
  ALLOW FULL VALUE ONLY FOR user.role IN ('privacy_admin', 'authorized_analyst')
  OTHERWISE RETURN masked_value()
END

POLICY TEMPLATE finance_access
IF table.tag == 'financial'
THEN
  ALLOW SELECT ONLY IF user.department IN ('Finance', 'Controlling')
  OR user.role IN ('cfo_office', 'finance_data_steward')
END

POLICY TEMPLATE internal_only
IF object.tag == 'internal'
THEN
  DENY ACCESS IF user.context == 'external_partner'
END

Pseudocode: Row filter

Row filters make sense when not all users should see all records, even though they access the same table.

ROW FILTER regional_scope_filter
ON table sales_orders
IF table.tag == 'financial'
THEN
  RETURN rows WHERE region = user.region_scope
END

Example: a user responsible for Switzerland only sees records for CH. This is especially useful when organizational responsibilities are separated regionally or by entity.

Pseudocode: Column masking

Column masking is suitable when tables should remain broadly usable, but sensitive columns need to be protected.

COLUMN MASK customer_email_mask
ON table customers.email
IF column.tag == 'PII'
THEN
CASE
WHEN user.role IN ('privacy_admin', 'customer_service_lead') THEN email
ELSE 'masked'
END

COLUMN MASK salary_mask
ON table payroll.salary
IF column.tag == 'financial'
THEN
  CASE
    WHEN user.role IN ('hr_finance_lead', 'cfo_office') THEN salary
    ELSE NULL
  END

The point isn't the exact syntax, but the logic: classification → policy → automatic enforcement. This is exactly how you elevate security from a collection of individual grants to a scalable operating model.

When to use row filters vs. column masking

A simple rule of thumb:

• Column masking, when the table should be broadly usable but individual fields are sensitive
• Row filters, when the same dataset should be restricted differently depending on user context
• both combined, when records and columns need to be protected at the same time

This is often the point where security grows up. No longer "is someone allowed to access the table?" but rather: exactly what is this person allowed to see, in which context?

Auditability in practice: System tables, audit queries, and compliance reporting

Security models often look clean on slides. In operation, it becomes clear whether they hold up. That's why: ABAC without audit is just a nice promise.

If you work with tags, policies, filters, and masking, you need answers to questions like:

• What sensitive objects do we actually have?
• Where are tags set, and where are they missing?
• Which policies apply where?
• Who has accessed sensitive data?
• Where are there exceptions or gaps?

This is exactly where audit telemetry, system tables, and analyzable logs come into play. Depending on your available platform and audit configuration, you can use this information for governance and compliance reporting.

Example audit analyses

The following examples are illustrative audit queries. They show what kind of analysis makes sense.

Which objects carry sensitive tags?

SELECT
  catalog_name,
  schema_name,
  object_name,
  tag_name,
  tag_value
FROM governance_tag_inventory
WHERE tag_name IN ('PII', 'financial', 'internal', 'restricted')
ORDER BY catalog_name, schema_name, object_name;

Benefit: transparency about classified data objects, a foundation for stewardship and control lists, a starting point for policy coverage.

Which sensitive objects don't yet have a documented policy mapping?

SELECT
  object_name,
  tag_name
FROM governance_tag_inventory t
LEFT JOIN policy_mapping p
  ON t.tag_name = p.tag_name
WHERE t.tag_name IN ('PII', 'financial', 'internal')
  AND p.policy_name IS NULL;

Benefit: makes gaps in the security logic visible, prevents a false sense of security, important for rollout and quality assurance.

Who has accessed PII-related objects?

SELECT
  event_time,
  user_name,
  object_name,
  action_type
FROM audit_access_events
WHERE object_name IN (
  SELECT object_name
  FROM governance_tag_inventory
  WHERE tag_name = 'PII'
)
ORDER BY event_time DESC;

Benefit: trace access to sensitive data, detect anomalies, provide evidence for internal audits or security reviews.

Where were masking or filters applied?

SELECT
  event_time,
  user_name,
  object_name,
  policy_name,
  enforcement_type
FROM policy_enforcement_events
WHERE enforcement_type IN ('COLUMN_MASK', 'ROW_FILTER')
ORDER BY event_time DESC;

Benefit: make the effectiveness of the security logic visible, verify that policies are being enforced, provide a foundation for compliance reporting.

Which user groups access classified data particularly often?

SELECT
  user_group,
  tag_name,
  COUNT(*) AS access_count
FROM classified_data_access_summary
GROUP BY user_group, tag_name
ORDER BY access_count DESC;

Benefit: identify usage patterns, question special exceptions, prioritize security measures based on risk.

Compliance reporting: From gut feeling to fact-based control

Many companies treat compliance reporting as an annoying obligatory exercise. That's understandable, but shortsighted. Good reports aren't just for auditors. They also help data stewards, platform teams, and security owners steer the state of the platform based on facts.

Useful compliance reports include, for example:

• An overview of all sensitive data objects by classification
• Policy coverage per tag category
• Access to sensitive data by user group
• Special exceptions and documented deviations
• Objects without complete classification
• Changes to security rules over time

Example: Policy coverage by classification

SELECT
  tag_name,
  COUNT(*) AS classified_objects,
  SUM(CASE WHEN policy_attached = 'Y' THEN 1 ELSE 0 END) AS objects_with_policy
FROM governance_policy_coverage
GROUP BY tag_name;

This kind of analysis quickly shows whether your security architecture actually scales or just sounds good.

Example: Exceptions and special approvals

SELECT
  object_name,
  exception_reason,
  approved_by,
  valid_until
FROM security_exceptions_register
ORDER BY valid_until;

This is especially important because exceptions often become blind spots. At first they're temporary, then permanent, and eventually no one remembers why they exist.

Why reporting also helps operationally

Compliance reporting isn't just evidence – it's a steering instrument:

• Data stewards spot classification gaps
• SecOps sees suspicious access patterns
• Platform teams identify technical inconsistencies
• Leadership gets transparency without a security novel

In short: reporting translates security logic into leadership capability.

7-step rollout plan

Successfully introducing ABAC isn't a switch you flip. It's a controlled build-up of classification, rules, ownership, and evidentiary capability. A pragmatic rollout can look like this:

1. Define protection goals and scope

• Goal: clearly determine which data classes and risks should be addressed first.
• Typical pitfall: starting too broadly and trying to secure everything at once.
• Recommendation: begin with 2–3 clear protection classes, such as PII, financial, and internal.

2. Define data classes and governed tags

• Goal: create consistent classification.
• Typical pitfall: too many tags or inconsistent terminology.
• Recommendation: introduce a small number of clearly defined tags with documented meaning and ownership.

3. Clarify responsibilities

• Goal: clean collaboration between data stewards, the platform team, security, and the business unit.
• Typical pitfall: no one feels responsible for classification or maintenance.
• Recommendation: explicitly assign tag ownership and policy responsibility.

4. Design policy templates

• Goal: define reusable security patterns.
• Typical pitfall: building individual rules instead of templates.
• Recommendation: first define a few standard patterns, such as masking for PII and access restriction for financial.

5. Select and test a pilot area

• Goal: validate the security logic under real conditions.
• Typical pitfall: rolling out company-wide immediately.
• Recommendation: start with a domain that's relevant but manageable – for example, finance reporting or customer analytics.

6. Set up audit and compliance reporting

• Goal: make impact and gaps visible.
• Typical pitfall: only thinking about audit after the rollout.
• Recommendation: define early which evidence, reports, and control queries you'll need regularly.

7. Scale the rollout and establish an operating model

• Goal: transition ABAC into steady-state operations.
• Typical pitfall: a good pilot solution without an operating model.
• Recommendation: firmly anchor approval processes, review cycles, exception handling, and reporting routines in the operating model.

Security operating model: Why technology alone isn't enough

Perhaps the most important point: ABAC is not purely a technology project. It's an operating model.

• If tags aren't maintained, policies lose their foundation.
• If policies aren't reviewed, false security emerges.
• If audit information isn't analyzed, there's no steering.
• If ownership is unclear, security becomes a bottleneck.

A resilient model distributes responsibility functionally:

This doesn't have to be a rigid org chart. But it must be clear who decides, who reviews, and who provides evidence. Otherwise "automated security" very quickly turns into "automated ambiguity."

An SAP-adjacent perspective

For SAP-experienced teams, here's a translation:

ABAC is the scalable answer to a world in which many one-off grants are no longer manageable. Governed tags bring standardization to classification. Audit reporting provides the evidence that data provisioning is not just regulated, but also controlled.

In other words: fewer special cases, more reliable security mechanics.

If you don't want to reinvent your classification and policy logic every time, download our tagging policy template now. It helps you:

• define governed tags cleanly,
• build policy mappings in a structured way,
• roll out ABAC pragmatically,
• and factor in audit and compliance requirements from the start.