Databricks Data Governance for Banking

The challenge

• One workspace for everyone. No separation between business units, no isolation between production and exploration.
• Access grew by exception. Permissions were granted to individuals during projects and never revoked. There was no authoritative view of entitlements.
• Personal data was over-exposed. Teams that only needed aggregates could read full customer records because that was the simplest way to unblock them.
• Onboarding was slow. Standing up a new analytics team meant manual configuration, repeated inconsistently each time.
• Regulatory pressure. Audit and data-lineage expectations meant “we think it’s fine” was no longer an acceptable answer.

Our approach

Domain discovery. We mapped the bank’s data into business domains — customer, retail credit, risk, finance, marketing — and identified the owner of each. Ownership was the prerequisite: without a named owner, no access decision can be delegated.

Access matrix. For every combination of business role and domain, we defined the level of access genuinely required. A worked example: the retail credit risk team needs full customer records to run scoring models, so it receives unmasked access to the customer domain. The marketing analytics team needs behavioural patterns, not identities, so it sees the same tables through dynamic views with masked identifiers. Same source of truth, two different lenses, no duplicated copies drifting apart.

Blueprint over bespoke. Rather than configuring each team individually, we designed one parameterized pattern that any new team could be instantiated from.

The solution

Tenant isolation. Separate workspaces per business unit, with a shared governed catalog layer underneath. Teams get autonomy in their own space without touching each other’s compute or data.

Unity Catalog as the control plane. Catalog per domain, schema per medallion zone, and permissions granted to groups only — never to individuals. Groups are synced from Entra ID, so joining a team grants access and leaving revokes it automatically.

Column- and row-level controls. Dynamic views apply masking and row filters based on group membership, so sensitive attributes are protected at the source rather than in each downstream report.

Cluster policies. Compute is constrained by policy per tenant — instance types, autotermination, and cost limits — preventing runaway spend and unapproved configurations.

Terraform group blueprint. A reusable module provisions a new tenant: workspace assignment, groups, catalogs, schemas, permissions and cluster policies. Adding a team is a short configuration file and a code review, and the same module can replicate an existing group’s setup exactly.

Results

• Reproducible tenant onboarding. New groups are provisioned from a module instead of assembled by hand, and configurations no longer drift between teams.
• Entitlements that can be audited. Who can access what is defined in version-controlled code, with the reason and approver visible in the change history.
• Personal data protected by design. Masking rules live in the platform, not in individual queries.
• Isolation without duplication. Business units are separated at the compute and workspace level while still reading one governed set of tables.
• Change is now cheap. Adjusting a policy or replicating a group configuration is a code change, which was the bank’s core requirement.
• A foundation for AI. Governed, well-described data means models can be built on data the bank can actually defend.