28.10.26

How to Hire a Data Governance Consultant Who Can Actually Build a BCBS 239 or GDPR Framework

Data governance hiring is one of the few technical recruitment categories where a CV can look flawless and still hide a candidate who has never written a policy, never faced a regulator, and never had to defend a data quality control to a business stakeholder. Anyone can list "BCBS 239," "GDPR," and "Unity Catalog" on a CV. Far fewer can explain how a critical data element gets prioritised, how a tagging policy gets enforced at scale, or why a data governance consultant needs to be comfortable in the room with engineers, not just policy documents. This guide sets out how we screen for the difference, drawn from the same technical probing we use in live consultant screenings for fintech, banking, and insurance clients.

Prerequisites

Before you start screening, get these in place:

• A clear view of whether you need policy-writing capability, technical implementation capability (Unity Catalog, tagging, access control), or both — the brief shapes every question that follows.

• Confirmation of your regulatory driver: BCBS 239, GDPR, Section 166, or a combination — this determines which follow-up questions are relevant.

• Knowledge of your current platform stack (Databricks/Unity Catalog, Snowflake, Azure Fabric, Collibra) so you can test platform-specific depth rather than generic governance theory.

• A structure for who the consultant will work alongside — typically a data governance engineer handling technical translation into DQ rules, while the consultant owns business definitions and policy.

Step 1: Separate "Has Written Policy" From "Has Reviewed Policy"

Start by asking the candidate to walk through how they actually created a governance policy from scratch — not how they followed one. A consultant who has genuinely written policy will describe a process: understanding what the organisation needs the policy for, speaking to stakeholders to define the objective, drafting the document, then routing it through a DPO or governance team for business-level review. This is materially different from a candidate who inherited an existing framework and made incremental updates — which is still valuable experience, but a different skill. One candidate we screened for a BCBS 239 risk data aggregation project at NatWest was explicit about this distinction: policies existed before she arrived, and her contribution was reviewing and enhancing them where change was needed, not authoring from a blank page.

Ask directly: "Talk me through the last policy you wrote, start to finish. Who did you speak to before you wrote a single line?" A candidate who can't name the stakeholders they consulted is describing a template, not a policy.

Step 2: Test Regulatory Fluency Against the Specific Framework, Not the Acronym

Don't accept "I've worked on BCBS 239" or "I've done GDPR" as evidence of depth. Push into the mechanics.

For BCBS 239 and risk data aggregation, a candidate with real depth should be able to describe:

• How they identified and prioritised critical data elements (CDEs) across the business.

• How they built or maintained a business glossary and mapped it to data lineage.

• How they defined data quality control metrics, thresholds, and dimensions for each element — and which of the standard dimensions (completeness, accuracy, validity, conformity) the business actually prioritised, since most organisations only track two or three, not all six.

• How data quality controls were embedded as a gate in the change delivery process, so teams couldn't progress a project without meeting data standards.

For GDPR specifically, listen for classification and access control language tied to privacy level and PII — a consultant who has done this work will talk about ensuring data is classified by sensitivity and privacy level as part of the same exercise that identifies critical data elements, not as a separate compliance bolt-on.

If a candidate can only repeat the framework name without describing this level of mechanism, that's a signal to probe further before shortlisting.

Step 3: Probe CDE Prioritisation Logic Specifically

This is one of the sharpest ways to separate surface-level exposure from real ownership. Ask: "How did you decide what counted as a critical data element?" A candidate who has actually run this process at scale will typically describe a small number of concrete criteria rather than a vague answer about "importance." In one screening, a consultant broke CDE prioritisation into three specific drivers: which data elements affected regulatory returns, which affected business or board KPIs, and which data owners themselves flagged as operationally critical. That's a structured, repeatable answer. A candidate who says "the important fields" or "whatever the business flagged" without a framework behind it likely hasn't owned this end-to-end.

Step 4: Test Databricks and Unity Catalog Depth, Not Just Familiarity

Unity Catalog claims on a CV need to be pressure-tested, because "exposure" and "ownership" are very different things.

Ask these three questions in sequence:

1. "Which cloud is Unity Catalog running on in your deployment, and did that change how you configured it?" A candidate with real experience will answer specifically — AWS, Azure, or another platform — and connect that to practical setup decisions, since Unity Catalog is the governance layer within Databricks but its implementation detail shifts by cloud environment.

2. "How did you handle tagging — was it automated or manual, and why?" Genuine hands-on candidates will tell you where automation fell short. One consultant described exactly this: automated tagging didn't produce usable results, so significant manual tagging work and manual tagging policy creation followed. That kind of honest, specific answer is a stronger signal than a candidate who claims a fully automated, frictionless rollout.

3. "How did you structure domains and map data sets to them?" Look for a described sequence — data mapping first, understanding the data sets, then mapping those sets into business domains — rather than a one-line answer.

Be alert to candidates who describe Unity Catalog work that was actually building a knowledge hub or training resource on top of Databricks, rather than configuring the governance layer itself — both are legitimate experience, but they answer different parts of your brief.

Warning: Some strong data governance consultants will be honest that they haven't used Unity Catalog specifically but have deep experience with a functionally similar catalog tool — Collibra, Azure Fabric, or another metadata platform. Don't disqualify on tool-name matching alone; test whether they understand what the tool needs to do — enforce governance rather than just document it, and shape how CDEs and ownership get modelled — and whether they could transfer that understanding.

Step 5: Check Whether They Can Actually Work With Engineers

A recurring marker of real governance depth versus superficial exposure is comfort working directly alongside data engineers on the physical data model. As one experienced governance consultant put it, most people who move into data governance enter the field "because they thought it makes money," without ever having worked as a data architect or understood conceptual, logical, and physical data models — but the engineers are the ones transforming the data, and governance's job is to set the standard, embed it, and assure it's being followed.

Ask: "Describe a time you had to push back on an engineer's implementation because it didn't meet a governance standard." A candidate who has genuinely done this will describe a specific standard, a specific pushback, and a resolution — not a general statement about "collaboration."

Step 6: Test Stakeholder Translation Ability Separately From Technical Ability

Writing policy and enforcing technical controls are only half the job. The consultant also needs to translate governance risk into language that data stewards and business SMEs — who often have little or no technical understanding of the data they handle — can act on. Ask the candidate to describe a specific moment they had to explain the downstream impact of bad data to a non-technical stakeholder, ideally tied to regulatory reporting consequences. Strong candidates will describe walking a steward through the actual chain: where the data comes from, who has access, what transformation happens to it, and what breaks in the regulatory return if it's wrong. A generic answer about "communication skills" without a concrete scenario is a gap, not a strength.

Step 7: Confirm Training and Rollout Experience Where the Role Requires It

If your brief includes rolling out a new governance platform or framework across the business — not just designing it — check for role-based training delivery experience. Look for candidates who have created training material tailored to different audiences: ownership matrix training for owners and stewards, and separate training for the wider business when a new policy or procedure launches. Data literacy should come up as a named pillar of their approach, not an afterthought.

Tips & Best Practices

• Weight the CDE prioritisation question heavily. It's one of the fastest ways to distinguish a consultant who has run governance end-to-end from one who has only supported it, because the answer requires a structured framework, not a description.

• Don't treat "no Databricks experience" as an automatic disqualifier. Test transferability from Snowflake, Azure Fabric, or Collibra instead, since the underlying governance logic — classification, lineage, ownership — transfers across platforms even when the tool name doesn't.

• Listen for named tools, not category descriptions. Candidates who can name the specific system they used to track data issues, or the specific catalog platform they configured, are more likely to have hands-on ownership than those speaking only in generalities.

• Separate the policy-writing skill from the technical implementation skill in your scoring. A candidate can be excellent at one and thin on the other — decide upfront, based on your brief, which one carries more weight for this specific hire.

Troubleshooting

The candidate's CV lists BCBS 239 and GDPR, but every answer stays at the framework level with no mechanism detail. This is the single clearest red flag in governance screening — move on unless the role is genuinely entry-level.

The candidate has deep policy experience but has never touched a cloud governance platform. This may still be a strong hire if your engineer or technical governance partner can own the platform layer — confirm this division of labour matches your brief before proceeding.

The candidate can describe Unity Catalog conceptually but gives vague answers about tagging or domain mapping. Push for the automation-failure story specifically — candidates with real hands-on time almost always have one, because manual tagging correction is a near-universal pain point.

Summary

Screening a data governance consultant for a BCBS 239 or GDPR framework build isn't about matching keywords on a CV — it's about testing whether the candidate can describe the mechanics of CDE prioritisation, the specifics of a Unity Catalog tagging rollout, and the stakeholder conversations that make a policy stick. The consultants who clear this bar can talk fluently about business glossaries, data quality gates in change delivery, and the difference between documenting governance and enforcing it. Build these questions into your next screening call, and you'll separate the candidates who have written and implemented governance frameworks from those who have only sat near one.