03.11.26

How to Screen a Data Governance Candidate's Experience Identifying Critical Data Elements and Stewardship Programmes

Why CDE Screening Separates Real Data Governance Consultants From Policy-Readers

Most Data Governance job specs ask for "experience identifying Critical Data Elements" as a bullet point. Very few hiring managers know how to test whether a candidate has actually done it. We've screened dozens of Data Governance consultants against live AWS/Databricks and Collibra mandates, and the pattern is consistent: candidates who can recite BCBS 239 or GDPR terminology are common, candidates who can walk you through how they derived a CDE list, assigned real ownership, and got a business to change behaviour are not. This guide gives Heads of Data and Compliance a structured, repeatable way to tell the two apart — based directly on the screening conversations we run before a candidate ever reaches your shortlist.

Who this is for

• Heads of Data, Heads of Compliance, and CTOs hiring Data Governance Consultants into regulated environments (financial services, asset management, insurance, housing associations)

• Hiring managers running AWS/Databricks or Azure/Purview/Collibra governance programmes who need someone to own the business-definitional side, not just the technical tooling

• Teams who have been burned before by a consultant who could talk policy language fluently but couldn't produce a working CDE ownership matrix

Step 1: Ask Them to Define a Critical Data Element — Not List One

Start by asking the candidate for their personal definition of a CDE and the criteria they use to decide whether a data field qualifies. A candidate with genuine experience will give you a specific, repeatable test rather than a generic answer.

One consultant we screened described deciding CDEs against three concrete criteria: whether the field affected regulatory returns, whether it affected business or board KPIs, and whether the data owner themselves judged it operationally critical. Another candidate, working a BCBS 239/GDPR-driven mandate, framed it as identifying "key data elements" needed specifically for regulatory aggregation and reporting, then layering ownership, stewardship, and PII classification on top.

What to listen for:

• A named set of criteria (regulatory impact, KPI impact, owner judgement), not a single vague standard

• Evidence the candidate distinguishes CDEs from "data we happen to store" — the test should exclude fields, not just include them

• A connection between CDE identification and a specific regulatory driver — RDARR/BCBS 239, GDPR, Section 166 — rather than an abstract textbook answer

Red flag: If the candidate can only describe a CDE definition in policy language ("elements critical to the business") without a method for applying it to actual data fields, push further before moving to the next step.

Step 2: Probe the Mapping Process — From Business Model to Domain to CDE

Defining a CDE is one skill; actually deriving the list from a live data estate is another. This is where weaker candidates start to drop off, because it requires describing a multi-stage process rather than a definition.

A strong answer traces a clear sequence: document the conceptual business model to understand how data moves across the organisation and which business processes connect, use that to identify critical business domains, and only then identify the CDEs that sit under each domain. One candidate described doing this practically on an AWS/Databricks estate — building a data map, understanding the available data sets, then mapping those data sets to domains across the organisation before applying the three-part CDE test.

Ask the candidate to walk you through, in order:

1. How they documented or inherited a business process/domain model

2. How they moved from "critical domain" to "specific data elements within that domain"

3. How they handled domains with no existing documentation — did they build it from scratch, or rely on existing material?

A candidate who deployed Unity Catalog on AWS Databricks for a housing association described doing exactly this end-to-end as the sole data governance resource on the account — building the data map, running the domain mapping, then tagging data assets, in some cases manually, because automated tagging didn't produce reliable results. That manual-override detail is a strong signal: it shows the candidate understands tooling limitations rather than assuming automation solves classification by default.

Having tested whether the candidate can build the list, the next question is whether they can make it stick by assigning real ownership.

Step 3: Interrogate How They Actually Assigned Data Ownership

This is the step most candidates fail, because assigning ownership is a change-management exercise, not a data exercise. Ask specifically how they identified owners and how they differentiated owners from stewards.

A candidate with genuine experience will describe identifying potential data owners as individuals with real accountability — typically budget authority, approval rights, and decision rights — usually at head-of-function level, and then running a structured engagement process (workshops in one case, one-to-one interviews in another) to explain the domain and the owner's responsibilities within it. Crucially, they should describe working with owners to nominate data stewards — the people who handle day-to-day operations — as a distinct second layer, with the steward then responsible for breaking the domain down into specific CDEs and defining the business rules and quality dimensions that describe what "good" looks like for each one.

Questions that separate real practitioners from policy-readers:

• "How did you decide who the data owner was, versus who the data steward was?" Listen for a distinction based on accountability and decision rights (owner) versus day-to-day operational responsibility (steward).

• "Did you run workshops or one-to-one interviews to get ownership agreed, and why that format?" One candidate ran six individual interviews rather than a group workshop specifically because of the number of stakeholders involved — a detail that shows deliberate stakeholder-management choice, not a templated process.

• "What happened when an owner disagreed with the domain boundary you proposed?" If the candidate has no answer beyond "it didn't happen," be skeptical.

Another candidate, screened for a near-identical AWS/Databricks fintech mandate, confirmed ownership identification and classification were core, daily responsibilities across a seven-year track record in the space, alongside writing the governance policies that formalised those ownership decisions. The key signal across these conversations is that ownership assignment was never described as a one-off workshop exercise — it was treated as an ongoing stakeholder relationship that the consultant actively managed.

Step 4: Check Whether They Can Write the Policy, Not Just Run the Workshop

A consultant who can facilitate an ownership conversation but can't formalise it into a usable policy document will stall your programme at the documentation stage. Ask for their actual policy-writing process.

Look for an answer that starts with understanding organisational need before drafting. One candidate described their approach as always starting with what the policy needs to achieve within the organisation, working with stakeholders to understand how the policy will affect different parts of the business, and then routing the draft through a formal reviewer — such as the DPO or governance team — for broader business sign-off. This same candidate had drafted policies independently across three consecutive organisations, which is a reasonable bar to ask any CDE-focused hire to meet.

A second candidate described their policies as explicitly aligned to recognised frameworks — DAMA, COBIT 2019, ISO 31000 — covering operating model design, data domain boundary definition, forum design and cadence, and escalation frameworks. If your organisation already operates against one of these frameworks, ask the candidate to map their past policy work directly onto it; a candidate with real experience will do this fluently and specifically, not generically.

Practical interview prompt: "Describe one policy you wrote end-to-end — what triggered it, who you consulted, and who signed it off." A vague answer here, after a strong answer on CDE identification, usually means the candidate worked under someone else's governance framework rather than building one.

Step 5: Test Data Literacy Training Experience Against Specific Audiences, Not a Single Event

Business-wide data literacy training is frequently the weakest part of a CV, because many candidates have only ever delivered a single kickoff session. Ask the candidate to break training into the distinct audiences they've addressed.

A strong answer separates training into at least three tiers: targeted training for data owners and stewards, general training and awareness sessions for the wider business so staff understand what governance work is happening and why, and separate sessions or workshops specifically aimed at securing executive buy-in. The same candidate described treating regular progress reporting to senior leadership — for example, reporting that governance had been embedded in four of ten identified domains — as part of the same change and literacy function, not a separate reporting exercise.

Ask directly:

• "How did you phase your training across the programme — weeks, months, a year?" One candidate described planning training across a six-to-twelve month cycle, with some sessions run regularly and onboarding built in for new starters.

• "How did you tailor the message for data owners versus general staff versus executives?" Listen for three genuinely different content types, not one deck recycled three times.

• "What did you report back to leadership, and how often?" A candidate who treats literacy training as a one-off event, with no ongoing reporting loop, is less likely to sustain a stewardship programme past the first quarter.

With training assessed, it's worth confirming the candidate can also explain how they communicate governance concepts outside formal sessions, day to day.

Step 6: Confirm They Can Translate Technical Governance Into Business Language on Demand

Data owners and stewards are typically business SMEs with little technical grounding in the systems they feed. A candidate who can't translate lineage, access control, and transformation concepts into plain business impact will struggle to get real ownership buy-in.

One candidate described this translation role explicitly: stakeholders such as data stewards often have little technical understanding of lineage, who has access to the data, or what transformations have occurred, so the consultant's job is to explain the consequences of poor data — specifically, the downstream impact on regulatory reporting — in terms the business owner can act on. Ask the candidate for a specific example of a moment they had to explain a technical risk to a non-technical stakeholder, and listen for whether they connect it to a concrete consequence (a regulatory submission, a board KPI, a failed audit finding) rather than an abstract statement about "data quality."

Tips & Best Practices

• Sequence your questions to mirror the real workflow: definition → domain mapping → CDE identification → ownership → stewardship → policy → training. Candidates who have only memorised terminology tend to answer step 4 and step 6 identically, because they don't actually distinguish the stages.

• Ask for the exception, not just the process. Real practitioners can describe what happened when automated tagging failed and they had to manually tag data assets, or when a stakeholder disagreed on domain ownership. Policy-readers describe the happy path only.

• Probe the platform-specific detail. If your programme runs on Unity Catalog in AWS Databricks, ask the candidate exactly how they structured tags and domains, not just whether they've "used Databricks." Genuine hands-on candidates describe the manual tagging workaround alongside the automated approach.

• Separate the business-definitional role from the technical DQ-rule role early. Several of the strongest candidates we've screened for AWS/Databricks fintech mandates work alongside a separate data governance engineer: the consultant owns CDE definition, ownership, and policy, while the engineer translates that into technical data quality rules. Confirm which side of that split your candidate actually owns.

• Ask for a regulatory anchor. Strong candidates tie CDE identification to a specific regulatory driver — BCBS 239/RDARR, GDPR, Section 166 findings — rather than describing CDEs as a generic good-practice exercise.

Troubleshooting Common Screening Gaps

The candidate describes CDEs well but can't describe stewardship. This usually means they worked in an environment where ownership was already assigned before they joined. Ask them to describe a time they had to nominate a steward from scratch and what criteria they used.

The candidate has strong tooling experience (Collibra, Purview, Unity Catalog) but can't explain the business rule behind a CDE. This is a sign of a technically-oriented data governance engineer rather than a business-definitional consultant — valuable, but not the same role your spec is asking for. Clarify which half of the governance split you actually need filled.

The candidate's training experience is limited to a single kickoff workshop. Ask how they planned training over a longer horizon and whether they built in a reporting cadence to leadership — a one-off session with no follow-up reporting rarely sustains a stewardship programme.

Key Takeaways

Screening a Data Governance candidate properly means testing the full chain — definition, domain mapping, ownership assignment, policy authorship, and tiered training — not just confirming they know what BCBS 239 or GDPR stands for. The strongest candidates we've placed into AWS/Databricks and Collibra governance mandates can walk a hiring manager through each stage with specific, sometimes messy detail: manual tagging workarounds, six individual stakeholder interviews instead of a workshop, a policy routed through a DPO for sign-off. If your next Data Governance hire can't answer at that level of specificity, they're reciting policy language, not practising it — and we can tell the difference within a single screening call.