Skip to content

CONCEPT Cited by 1 source

Separation of duties (data governance)

What it is

Separation of duties in data governance is the structural distribution of governance responsibilities across specialised roles, each of which holds different permissions on the governance primitives, so that no single role can both define and apply policy end-to-end. The classic three-role split for data-warehouse governance:

Role Holds Cannot do
Governance team / admin Define tag taxonomy + author ABAC policies Apply tags to specific tables; change underlying data
Data steward Apply governed tags to specific tables / columns; exclude classifier false positives Create new tags; change underlying data
Data producer / owner Create + own tables within a governed scope Define tags; author governance policies

Each role does the work it has expertise in. The three together produce protected data; no one alone can produce miscoverage.

Why it matters

Data-governance failures historically follow one of two shapes:

  1. Bottleneck — one team (security or platform) is responsible for both defining policy and applying it across thousands of tables. Can't keep up; coverage drifts; new data sits unprotected.
  2. Free-for-all — no central team. Each domain team makes its own decisions about sensitive-data handling. Policies drift; same sensitive category gets handled differently across teams; audits surface inconsistencies.

Separation of duties resolves the dilemma by distributing the work without distributing the standard. Governance teams set the standard (taxonomy + policies); stewards / producers do the application work within their scope. "Governance shouldn't rely on a single person or a single role. Instead, responsibilities can be distributed across specialized groups that are experts in their area and don't have to depend on others to do their work" (Source: sources/2026-05-13-databricks-abac-row-filtering-and-column-masking-policies-governed-tags).

Distinct from security separation-of-duties

In security operations, separation of duties typically prevents one actor from completing a sensitive action alone (e.g., one admin requests a privileged change, a different admin approves). The data-governance version is structurally different:

Aspect Security separation-of-duties Data-governance separation-of-duties
Goal Prevent any one actor from completing a sensitive action Distribute work without losing consistency
Mechanism Multi-actor approval flows Permission split across primitives
Failure mode if violated Insider threat / fraud Coverage drift / inconsistency
Throughput Inherently slow (gates) High (parallel work in different scopes)

The data-governance version is about scaling effort more than preventing fraud, although the same permission-split mechanism provides defense-in-depth against malicious or sloppy actors.

Architectural enablers

Separation of duties depends on the underlying primitives carrying fine-grained permissions that can be split across roles:

  • Governed tag primitives must support separate MANAGE / CREATE / APPLY permissions — otherwise the governance team can't set the tag taxonomy without also having per-table apply rights on every table.
  • ABAC policies must evaluate against attributes the steward role can apply, not against identity properties only the governance team can set.
  • Data ownership permissions must be distinct from tag-application permissions on the same object — otherwise data producers can retag columns to evade governance policies.

When these three primitives carry orthogonal permissions, the three roles can operate independently within their scope.

Sibling separation-of-duties framings on the wiki

  • CMK Account ↔ Workspace separation — Lakebase's KMS key management is split between account admin (key owner) and workspace admin (data owner) so neither alone can extract data.
  • systems/oracle-wallet — DBA-provisioned wallet file separates the oracle-wallet operator from the database operator.

These are at the infrastructure-secret altitude; the data-governance version is at the schema-attribute altitude. Both inherit the structural property: split a privileged action into permissions that no single role can hold all of.

Operational property: scaling work without scaling standard

The throughput payoff is concrete: one governance team of N people can manage policies that stewards in M domain teams apply across P domain catalogs carrying T tables, where N ≪ M ≪ P ≪ T. Without separation of duties, the governance team would either become the apply-tags bottleneck (T scales beyond N's capacity) or delegate the standard itself (consistency suffers).

Seen in

  • sources/2026-05-13-databricks-abac-row-filtering-and-column-masking-policies-governed-tags — Unity Catalog GA explicitly frames separation of duties as the outcome the three primitives (governed tags, ABAC policies, data classification) enable. "The three capabilities are designed to work together. […] Together, these three capabilities enable a governance model that supports separation of duties." Three named role groups: governance team (taxonomy + policies), stewards (tag application + FP exclusion), data producers (tables within governed scope).
Last updated · 542 distilled / 1,571 read