Data Governance Roles and Career Paths: Owner, Steward, Custodian, and the Digital Quality Function

Data governance fails for one of two reasons. Either nobody owns the data, so when an audit trail review slips or a system goes out of validation no single person is accountable, or everybody “owns” it, which is the same thing wearing a suit. The owner/steward/custodian model exists to fix that. It assigns named accountability for each GxP data set and the systems that hold it, so that when an inspector asks “who is responsible for the integrity of this chromatography data,” there is a name, a job description, and a signature behind the answer.

This article defines the three governance roles as they are actually used in pharma and biotech, shows how they map onto a digital quality function, and lays out the career ladder. It is written for someone who has to set up these roles, sit in one of them, or interview for one. By the end you should be able to draft a role description, build the RACI, defend the model to an inspector, and know which job to aim for next.

Why governance roles exist: the regulatory basis

No regulation contains a clean table that says “appoint an owner, a steward, and a custodian.” The roles are an industry response to requirements that demand accountability for data integrity without prescribing the org chart. You assemble the model from several sources.

EU GMP Chapter 4 (Documentation) and the PIC/S PI 041-1 “Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments” (2021) are the most direct. PI 041-1 states that senior management is responsible for establishing a data governance system and for ensuring it is resourced and embedded in the quality system. It explicitly ties data integrity to defined responsibilities and to a culture where staff are not afraid to report problems. Boiled down, PI 041-1 treats data governance as the entire collection of safeguards a company relies on to keep its records dependable, so that whatever path a piece of information travelled, whether it was first captured, written down, worked on, stored, retrieved, or put to use in a decision, the record left at the end still hangs together and still tells you something you can rely on from the point it is created to the day it is finally disposed of.

MHRA “GxP Data Integrity Guidance and Definitions” (2018) says the same in fewer words: there should be a data governance system that is part of the overall quality management system, with clearly defined roles and responsibilities, and management is accountable for it.

WHO Technical Report Series, Annex on data integrity (TRS 1033, Annex 4, 2021) reinforces the management-accountability point and the need for designated responsibilities.

For computerized systems specifically, EU GMP Annex 11 requires that responsibilities for system management be defined, that there be a documented agreement between the customer and any third party (the basis for the IT/vendor custodian split), and that data be secured against unauthorized changes by people with defined access rights. 21 CFR Part 11 drives the same access-control and accountability logic on the US side, and the FDA “Data Integrity and Compliance With Drug CGMP” guidance (2018) points back to the predicate rules in 21 CFR 211, including 211.68 (computer controls) and 211.194 (laboratory records).

The risk rationale underneath all of this: data integrity controls only work if a specific person is responsible for running them. An audit trail that nobody reviews, a user list that nobody recertifies, a backup that nobody confirms restored cleanly, these are the classic gaps. The owner/steward/custodian split exists so each of those controls has an accountable name.

On management responsibility, PIC/S PI 041-1 places the burden at the top of the house: the senior leaders are the ones who have to put in place the systems and procedures that hold data integrity risk down to the lowest level that is reasonably achievable, and they are also the ones expected to recognize, accept, and keep watching whatever risk is left once those measures are working, reasoning about that leftover risk through ordinary quality risk management thinking.

See also data-governance-framework for the program that these roles sit inside, and di-program-architecture for how the pieces connect.

The three core roles, defined

The model separates accountability for the content of data from responsibility for the system that holds it. That separation is the whole point. A lab director can be accountable for the meaning and quality of test data without knowing how to administer the server it lives on, and an IT administrator can keep the system running without being expected to judge whether a result is scientifically valid.

Data Owner

The data owner is accountable for a defined set of data, usually aligned to a business process or a system’s primary purpose. This is a business or quality role, not an IT role. The owner is typically a department head or process leader: the head of QC for laboratory data, the head of manufacturing for batch records, the head of clinical operations for trial data.

What the owner is accountable for:

• The data set exists for a legitimate, defined purpose and is fit for that purpose.
• Data criticality and risk for that data set are assessed and kept current (links to data-criticality-and-data-risk).
• Access is appropriate: who should be able to read, enter, change, approve, and the owner approves the access matrix.
• Retention and archival requirements are defined and met.
• Controls (audit trail review, periodic review, reconciliation) are happening, even if delegated.
• Decisions about the data set, new uses, migrations, decommissioning, get owner sign-off.

The owner does not personally perform every control. The owner is the accountable single name. In RACI terms the owner is usually Accountable.

Data Steward

The steward is responsible for the day-to-day quality and governance of the data on the owner’s behalf. This is the operational governance role and the one most data-governance jobs actually are. A steward translates the owner’s accountability into running activity.

What the steward does:

• Maintains data definitions, metadata standards, and naming conventions for the data set.
• Runs or coordinates the periodic audit trail reviews and flags anomalies (see operationalizing-audit-trail-review).
• Performs user access recertification, confirming each active account still needs its privileges.
• Monitors data quality: completeness, consistency, ALCOA+ attributes, and raises deviations when something is off.
• Coordinates with the custodian on backups, archival, and system changes that affect the data.
• Is the first point of contact for questions about that data set during an inspection.

Stewards sit close to the process. In a QC lab the steward might be a senior analyst or a QC systems specialist. In clinical it might be a data manager. In RACI terms the steward is usually Responsible.

Data Custodian

The custodian holds and operates the system or infrastructure that stores the data, and safeguards it technically. This is the IT or system-administration role. The custodian does not decide what the data means or whether access requests are legitimate; the custodian executes the technical controls that the owner approved and the steward governs.

What the custodian is responsible for:

• Physical and logical safekeeping of the data: storage, servers, databases, cloud tenancy.
• Backups, restores, and verified recoverability (links to backup-restore-disaster-recovery-validation).
• Provisioning and de-provisioning accounts per approved requests; technical enforcement of access controls and segregation of duties.
• System availability, patching, security hardening, and disaster recovery.
• Maintaining the technical configuration baseline and supporting change control.
• Time synchronization and clock control on the systems (see time-stamps-and-system-clock-control).

The custodian is frequently a third party: an internal IT department, a cloud or SaaS provider, or a managed-service vendor. When it is external, Annex 11 and the underlying quality agreement define the split (see cdmo-oversight-quality-agreements and cloud-saas-validation). In RACI terms the custodian is usually Responsible for the technical activities and Consulted on others.

The critical line between the roles

The single most important design rule: the custodian must not be able to make undetectable changes to the data they hold, and must not approve their own access. If the IT administrator can edit a result, delete an audit trail entry, or grant themselves elevated rights without an independent approval, the segregation has collapsed and you have a classic data integrity finding waiting to happen. Custodian privileges (system admin) and data-entry/approval privileges (business roles) must be held by different people, and admin actions must themselves be logged and reviewed by someone outside IT, usually the steward or QA.

The three roles at a glance

When someone confuses the roles, this compact comparison resets the distinction fast.

The line that ties them together: the owner is accountable, the steward runs it, the custodian holds it, and none of them may quietly become the others. The custodian in particular must never be able to make undetectable changes or approve their own access.

Data governance roles versus GAMP 5 system roles: two families, one confusion

A validation team and a data governance team can each build a perfectly correct role table for the same system and still produce two different lists of names. That happens because they are answering two different questions. GAMP 5’s role set (Process/Business Owner, System Owner, Quality Assurance, Validation Lead, and the rest, covered in full in the GAMP 5 / CSV framework) answers “who is accountable for the validated state of this system.” The owner/steward/custodian model described above answers “who is accountable for the integrity of the data this system holds.” The two questions overlap heavily but are not the same question, and a program that only ever asks one of them has a gap the other question would have found.

How the two role families line up

Reconciling the two role sets for one system

1. Pull the GAMP 5 role assignment from the validation plan or summary report.
2. Pull the data governance role assignment from the role assignment register (see the role assignment register template).
3. Confirm the Process/Business Owner and the Data Owner are the same name. If they differ, document why in the system inventory; a silent mismatch is the finding, not the difference itself.
4. Confirm the System Owner and the Data Custodian are the same name, or have a documented, quality-agreement-backed handoff, common when the System Owner is internal IT and the custodian function is split with a hosting vendor.
5. Confirm a Data Steward is named even where the validation documentation never uses the word.
6. Record both role sets side by side in the system inventory, so an inspector, or a new hire, can see the reconciliation in one place rather than pulling two documents and comparing them by hand.

Acceptance criteria: every GxP system’s GAMP 5 role table and data governance role table trace to the same names, or the system inventory documents a reason they differ; every system carries a named steward regardless of whether the validation package ever used that word; the reconciliation is visible from the inventory, not reconstructed on demand.

Worked example: a chromatography data system’s validation summary names the Head of QC as Process/Business Owner and the IT Applications Manager as System Owner. The data governance register independently names the Head of QC as Data Owner (matches) and the same IT Applications Manager as Data Custodian for the application layer, with a hosting vendor named as a second custodian for the underlying infrastructure per the quality agreement. The register additionally names a QC Systems Specialist as Data Steward, a role that never appears anywhere in the validation package because GAMP 5 does not call for one. Reconciled, the two role sets tell one consistent story; unreconciled, an inspector asking “is your process owner the same as your data owner” would get two different answers depending on which document was pulled first.

Common mistake pattern: a project team treats “System Owner maintains it” as covering ongoing data governance and never separately assigns a steward. Six months after go-live, audit trail review is happening inconsistently because nobody outside the original validation team was ever told they were accountable for it going forward. This is not a validation failure; validation closed correctly. It is a governance gap that opened the moment the project ended and nobody carried the role past go-live.

Interview angle. “How does the data owner relate to the GAMP 5 process owner?” They are usually the same person looked at through two different lenses: process owner for the system’s validated, intended use, data owner for the integrity of the data that use produces. Where an organization splits process ownership from business ownership, the data owner accountability follows whichever of the two actually controls access and retention decisions, not whichever one holds the budget.

Data classification and criticality: how tiering sets the depth of governance

The role-to-data mapping above assumes every data set gets the same weight of governance: a named owner, a named steward, a named custodian, all formally documented. In practice that is the right model for the data that actually drives a regulatory decision and the wrong, resource-draining model for data that does not. Criticality tiering decides which is which, and it is worth being explicit about because two vocabularies for the same idea circulate in the industry, and practitioners moving between employers trip over the difference.

Two label sets, one idea

Some organizations tier data High / Medium / Low, scored against the methodology in data criticality and data risk and operationalized in the data criticality classification SOP and its assessment form. Others use a plain-language three-band label set: GxP-critical (drives a batch disposition, a safety decision, or appears on a regulatory submission), GxP-relevant (supports or verifies a GxP decision without being the decision itself), and non-GxP (no GxP impact at all). The two vocabularies describe the same underlying judgment: GxP-critical maps to High, GxP-relevant maps to Medium, and non-GxP maps to Low or “out of scope” rather than a floor of the same scale. What changes between employers is the label, not the logic, and a candidate who insists a prior company’s exact vocabulary is the only correct one is signaling inflexibility rather than expertise.

How the tier sets the governance role model, not just the control depth

The data criticality SOP already sets audit trail review frequency and access rigor by tier. What it does not fully spell out, and what belongs here, is how the tier should scale the governance role model itself.

Under-tiering is the more dangerous error in practice. A spreadsheet-based hybrid process that quietly grows into feeding a batch disposition decision gets waved through as “non-GxP” because nobody re-examined it after it stopped being a convenience tool, and it ends up with none of the governance weight a GxP-critical stream requires. Over-tiering has a cost too: applying full owner-acceptance-and-board-visibility rigor to a facility comfort-monitoring log burns governance bandwidth a real GxP-critical system needed.

Acceptance criteria: every data set in the role assignment register carries a criticality tier; the tier is visible next to the role assignment, not filed in a separate document; the governance weight (owner level, dedicated versus shared steward, formal acceptance, board visibility) actually matches the table above rather than being applied uniformly regardless of tier.

Worked example: a biologics site tiers its finished-product potency assay as GxP-critical: department-head owner, dedicated steward, signed acceptance on file, standing board visibility. Its environmental monitoring trend data is GxP-relevant: a supervisory-level owner, a steward who also covers two other medium-tier systems, no individual board agenda item, just an aggregate metric. Its internal meeting-room booking system is non-GxP: an informal IT contact, no governance documentation at all. The same site would waste real governance capacity running a full owner-acceptance workflow for the room booking system, and would be exposed running the room-booking level of rigor on the potency assay.

Interview angle. “How do you decide how much governance rigor a data set needs?” Start from criticality tiering, not a fixed template applied to every system. The tier should visibly change four things: how senior the named owner needs to be, whether the steward is dedicated or shared, whether formal signed acceptance is required, and whether the system gets individual attention at the governance board or only shows up in an aggregate metric.

A worked role-to-data mapping

Abstract definitions do not survive contact with an inspector. You need a concrete inventory that maps each GxP data set to a system, an owner, a steward, and a custodian. Below is a sample for a mid-size biologics site. This is the kind of table you would keep in your data governance framework and pull up when asked “who owns this.”

Note that the owner is always a named role on the business side, never “IT,” and the custodian is the only column where an external vendor appears. When a CDS is hosted by a vendor, the custodian splits: the vendor is custodian of the infrastructure, internal IT is custodian of the application layer, and the quality agreement says exactly who does what.

Acceptance criteria for the mapping itself: every GxP system in your validated system inventory appears at least once; every row has all four roles filled with a real role title (not “TBD”); no person sits as both custodian admin and approver of their own access on the same system; and the table is under change control so it stays current.

How to build a digital quality function

The roles above are the atoms. A digital quality function is the organization that holds them together and gives the owners, stewards, and custodians a place to escalate, a common methodology, and an inspection-facing front. Here is how to stand one up, in sequence.

Step 1: Get a sponsor and a charter

Digital quality lives at the seam between QA, IT, and the operating functions. Without an executive sponsor it gets squeezed. Write a one-page charter: scope (GxP computerized systems and the data in them), mandate (data integrity, computer system validation, system lifecycle governance), and reporting line. Most functions report into Quality, with a strong dotted line to IT. PI 041-1’s management-accountability requirement is your lever to get the sponsor; data governance is explicitly a senior-management responsibility.

Step 2: Inventory systems and classify

You cannot govern what you have not listed. Build or refresh the validated system inventory: every GxP computerized system, its GxP impact, its GAMP category (see gamp5-csv-framework), its data criticality, validation status, and current owner/steward/custodian. This inventory is the spine of everything else. Classify by data criticality so you spend effort where the risk is (see data-criticality-and-data-risk).

Step 3: Assign the roles and ratify them

For each system, name the owner, steward, and custodian. Have the owners formally accept accountability in writing, using something like the data owner accountability acceptance form rather than a spreadsheet cell nobody signed. This sounds bureaucratic; it is the difference between a model on paper and one an inspector believes. Ratify the assignments through your governance board.

Step 4: Stand up a governance board

A cross-functional data governance or computerized systems governance board, chaired from Quality, with IT, the major process owners, and validation represented. It meets on a defined cadence (monthly is common), reviews the system inventory, approves new systems and major changes, reviews data integrity metrics, and adjudicates issues that cross functional lines. It is the escalation path for stewards. Minute it; the minutes are inspection evidence. See the data governance board charter template for the mandate, membership, standing agenda, and a filled specimen of what a real meeting and its minutes look like.

Step 5: Write the procedures

The function needs a small, coherent procedure set: a data governance policy, a computer system validation procedure (see gamp5-csv-framework and computer-software-assurance-fda), an audit trail review procedure (see audit-trail-design-and-review), an access management procedure, a periodic review procedure (see validation-master-plan-and-periodic-review), and an electronic records/signatures procedure (see electronic-signatures-implementation). The role definitions live in the data governance policy and are referenced by the others.

Step 6: Build the metrics and the review cadence

Define data integrity and digital quality metrics: percentage of systems with current periodic review, audit trail reviews completed on time, open access-recertification actions, data integrity deviations by category, time to remediate. Report them to the governance board and to management review (see management-review-q10 and quality-metrics-and-kpis). Metrics are how you prove the governance system is working, which is exactly what PI 041-1 expects management to be able to demonstrate.

Step 7: Train, then run

Train owners, stewards, and custodians on their specific responsibilities, not generic data integrity slides (see training-program-gxp). Then operate, and let the metrics and the board surface what is not working.

Acceptance criteria for the function: a ratified charter with a named sponsor; a current system inventory with all roles assigned; a governance board with minuted meetings on cadence; the procedure set approved and in effect; metrics reported to management review; and role-specific training records on file.

A maturity ladder for the role model itself

The DI program maturity scorecard rates the whole data integrity program: inventory, tiering, data-flow mapping, governance, periodic review, metrics. The ladder below is a narrower cut of the same idea, scoped specifically to the owner/steward/custodian role model, useful as a quick self-check before reaching for the fuller scorecard or the data integrity culture assessment, which rates behavior rather than mechanics.

Rate each of the following against the ladder using evidence rather than impression, and report the lowest-rated dimension as the honest headline rather than an average across dimensions, the same discipline the fuller program scorecard uses.

Worked example: a mid-size site rates role coverage, formal acceptance, and RACI discipline at Managed, but escalation resolution at Ad hoc, because no disagreement between an owner and a steward has ever been formally logged, not because disagreements never happen but because nobody had a record to log one on. The honest overall stage to report is Ad hoc, driven by the escalation gap, not the average of several strong dimensions. That is uncomfortable to report and exactly the point: an inspector’s question about how a disagreement gets resolved would expose the same gap a self-assessment average would have hidden.

Who runs it: the Data Integrity Lead or Data Governance Lead scores the dimensions, QA reviews the evidence, and the result goes to the governance board, the same audience the charter already routes metrics to.

Interview angle. “How would you assess whether a data governance role model is actually mature, not just documented?” Look for formally signed acceptance, not just names in a register; a RACI that survives an audit of “exactly one A per row”; segregation of duties that is evidenced, not assumed; and a real, used escalation path. A program that has never had to log a disagreement has either never had one, which is unlikely at any real scale, or has been resolving disagreements informally, which is the gap to report.

RACI: making “who does what” auditable

A role model is only useful if it resolves real questions. RACI (Responsible, Accountable, Consulted, Informed) is the tool. Build one RACI for the data governance activities and keep it as a controlled document. Here is a worked example for the recurring data integrity controls.

Two rules keep a RACI honest. First, exactly one Accountable per row; if two functions both think they are accountable, the work falls between them. Second, the Accountable cannot be the same person performing a control that needs independent oversight; that is why audit trail review is Accountable to the owner but the owner is not the one quietly approving their own data changes. Note that data integrity deviation investigation can carry a dual A (owner for the data, QA for the quality decision); when you do that, document who decides what so it is not ambiguous.

For the broader role framework across GxP, see gxp-roles-responsibilities.

When the owner and the steward disagree: escalation and decision rights

A RACI tells you who is Accountable and who is Responsible when everyone agrees on what to do. It does not, by itself, say what happens when the Accountable owner and the Responsible steward reach different conclusions about the same fact, and that gap is where informal, undocumented decisions creep in. Three disagreements come up often enough to plan for: the steward flags an access request as inappropriate and the owner wants to grant it anyway; the steward classifies an audit trail entry as a reportable exception and the owner, often under schedule pressure, wants to treat it as routine; or the owner, steward, and custodian disagree about whether a system change is minor enough to skip a revalidation trigger.

Default decision rights

The owner holds formal accountability, so in an ordinary disagreement the owner’s decision generally stands once the steward’s concern has been heard and recorded. That default has one hard exception: where the disagreement touches a control Quality Assurance is independently responsible for (audit trail exception handling, segregation-of-duties determinations, a data integrity deviation classification), QA holds an independent stop-the-line authority that does not defer to the owner, consistent with the quality unit’s independent authority under GMP. An owner cannot instruct QA to accept a segregation-of-duties gap; QA can, and should, hold the line regardless of what the owner prefers.

The escalation path

Acceptance criteria: every disagreement that reaches escalation is documented with both positions, not just the outcome; the decision and its rationale are dated and signed; QA’s independent authority on segregation-of-duties and audit-trail-exception matters is exercised, not deferred to the owner, when those specific controls are what is in dispute; the escalation record is reviewed at the governance board so a recurring pattern is visible rather than each instance treated as isolated.

Worked example: ahead of a tight production schedule, the Head of Manufacturing (owner) wants to grant an operator elevated MES access so the operator can cover for an absent supervisor. The MES super-user (steward) flags that this would let the same operator both execute and approve their own batch record entries, a segregation-of-duties breach. The disagreement does not resolve directly within the two-day window; it escalates to QA, who holds the line: access denied as requested, with a documented alternate workaround (a second qualified approver from another line covers the approval step for the affected shift) implemented instead. The escalation record shows the owner’s operational rationale, the steward’s segregation concern, and QA’s decision and reasoning, dated and signed. That record is what an inspector reads if the same access pattern is ever questioned later.

Common mistake pattern: a disagreement gets resolved by whoever is more senior or pushes harder in a hallway conversation, with nothing written down. Months later, neither the access grant nor the reasoning behind it can be reconstructed, and the segregation-of-duties gap it created is discovered only when something goes wrong. A second pattern: QA’s independent stop-the-line authority exists on paper in the RACI but has never actually been invoked, which on inspection reads as decorative rather than real.

Interview angle. “The data owner wants to grant access the steward believes is inappropriate. What happens?” Give the steward’s concern a documented, timeboxed attempt at direct resolution with the owner first. If it does not resolve, it escalates to QA, and where the disagreement is specifically about a segregation-of-duties or audit-trail-integrity control, QA’s decision governs regardless of the owner’s preference, because that authority is independent of the owner’s accountability for the data set. The one thing that must never happen is an informal resolution with nothing recorded.

See the Form: Role Conflict / Escalation Decision Record for a ready-made record to capture exactly this.

Common mistakes and inspection-finding patterns

These are the patterns regulators cite, described generically. If your governance model does not prevent them, it is decorative.

No defined ownership. A system is in use, validated, generating GxP data, and when asked “who owns this data,” the site cannot name a person, or three people give three answers. This reads to an inspector as an absent data governance system, which is a direct hit against PI 041-1 and the MHRA guidance.

Custodian with unchecked admin rights. The IT administrator (or a vendor) holds an account that can modify or delete records and audit trails, with no independent review of admin activity. This is one of the most cited data integrity weaknesses. The fix is segregation: admin actions logged and reviewed by someone outside IT, and admins barred from data-entry/approval roles on the same system.

Audit trail review assigned to nobody, or assigned to the person who created the data. If the steward role is undefined, audit trail review tends to either not happen or be done by the analyst reviewing their own work. Reviews must be independent and the responsibility named.

Owner accountability never formally accepted. Names appear in a spreadsheet, but the owners were never told and never agreed. When questioned, the “owner” disclaims responsibility. Formal acceptance closes this.

Stale access lists. No recertification means accounts of leavers and movers persist, terminated employees retain logins, contractors keep elevated rights. This is both a Part 11/Annex 11 access-control finding and evidence the steward role is not operating.

Vendor custodian with no quality agreement. A hosted or SaaS system where the supplier holds the data and there is no documented agreement defining responsibilities. Annex 11 requires that agreement. Its absence is a finding and a real risk, because nobody can say who is responsible for backups, audit trails, or breach notification.

Governance board that does not meet, or meets without minutes. A board on the org chart but with no evidence of activity. Inspectors ask for minutes; “we meet sometimes” is not an answer.

Roles defined but not trained. People hold the title without knowing the specific tasks. Generic data integrity training does not discharge a role-specific responsibility.

For how these surface in inspections and warning letters, see fda-warning-letters-patterns and quality-culture-di-failures.

Where data governance meets data privacy: the DPO boundary

A company running clinical trials that touch EU or UK data subjects is very likely also operating under data protection law that requires a separate role: a Data Protection Officer (DPO), commonly required under EU GDPR Article 37 for organizations whose core activities involve large-scale processing of special-category data, which patient-level clinical and health data generally is. The DPO sits alongside the data owner/steward/custodian model, not inside it, and the two mandates answer different questions. The DPO’s brief is lawful basis for processing, data subject rights (access, correction, erasure, portability), and breach notification, legal and privacy obligations. The data owner’s brief under this article’s model is GxP data integrity: ALCOA+, audit trail review, retention for regulatory purposes. Confusing the two, or assuming one role covers the other, produces gaps on both sides.

The place the two collide most often in practice is retention and erasure. A data subject’s request to erase their personal data runs into the regulatory requirement to retain a locked clinical record for the trial’s defined retention period; GxP retention obligations generally take precedence for data that is part of the regulated record, though the specific legal basis and any fields outside the regulated data set still route through the privacy process. Getting that right is a joint call, not a unilateral one from either side.

Practical governance point: for any clinical trial data set, name the liaison point between the Data Owner (commonly the Head of Clinical Data Management) and the DPO or privacy office explicitly, so a data subject access or erasure request touching a regulated record gets a joint disposition instead of either function acting alone. This is a short line in the role assignment register, not a separate governance structure.

Interview angle. “How does the DPO relate to your data governance model when you handle patient-level data?” They are separate roles with separate mandates, the DPO for lawful processing and data subject rights, the data owner for GxP integrity, and the two need a defined liaison so a privacy request touching a regulated clinical record gets a joint decision rather than the DPO or the data owner acting without the other knowing.

This is a boundary point, not a privacy law primer. Treat GDPR compliance itself as its own specialist domain and bring in privacy counsel for the actual legal analysis.

Where the jobs are: career paths in digital quality

This is the part most articles skip. The owner/steward/custodian model maps onto real job titles and a real ladder. Here is the terrain.

Entry and adjacent points

Most people arrive at digital quality from one of three directions, not from a “data governance” degree.

• From the lab or shop floor. A QC analyst, manufacturing associate, or microbiologist who became the local super-user for the LIMS, CDS, or MES, learned where the data integrity risks live, and moved into a systems or steward role. This is the most common path and arguably the strongest, because process knowledge is the scarce part.
• From IT. A system administrator or business analyst who learned GxP and validation and moved into computer system validation or custodian-side quality roles. The gap to close is regulatory and quality thinking.
• From QA. A quality professional who specialized in computerized systems, data integrity, and validation. Strong on the quality framework, learning the technical depth.

If you are trying to break in, see breaking-into-gxp-quality and career-guide-gxp-validation.

The titles and what they mean

Title inflation and inconsistency are real across companies, but these are the common rungs:

The owner role in the governance model usually sits with operating-function leaders (head of QC, head of manufacturing), so “data owner” is rarely a job title you apply for; it is a hat that a department head wears. The steward and custodian roles, by contrast, map directly onto specialist and engineer jobs. The digital quality leadership roles are what the steward/SME track grows into.

Compensation bands: general and directional

The ranges below are general and directional, drawn from typical US pharma and biotech job postings and industry compensation surveys. They are not a guarantee for any specific role, region, employer, or year, and they move a great deal with geography (a Boston, Bay Area, or New Jersey/Philadelphia pharma corridor role commonly runs well above a smaller regional market), company size, whether the role is site-based versus corporate, and bonus or equity structure layered on top of base pay. Use them to sanity-check an offer, not to set an expectation in stone.

Two things move a number inside a level more than the title does: whether the role has ever defended a system in front of a regulator, and whether the candidate can speak concretely about a real audit trail exception or a real remediation, not a hypothetical one. Title inflation across companies means a “lead” at one company is a “senior specialist” at another; compare scope of decision authority, not the title, when negotiating.

Skills that actually differentiate

Hiring managers in this space consistently value:

• Real data integrity depth, not slideware: ALCOA+ applied to specific systems, audit trail review done in anger, data lifecycle thinking (see ALCOA+ in detail and data-lifecycle-and-metadata).
• CSV/CSA fluency: GAMP 5 second edition, the FDA Computer Software Assurance for Production and Quality Management System Software final guidance (current version issued 3 February 2026), risk-based testing (see gamp5-csv-framework and computer-software-assurance-fda).
• System-specific knowledge of the platform categories: CDS, LIMS, MES/EBR, EDMS, QMS, EDC. Knowing how audit trails and access controls work in a real LIMS or CDS is worth more than any certificate.
• Inspection experience, having defended a system or a data set to FDA, EMA, or MHRA. Even one inspection moves you up a rung.
• The ability to write a procedure, a risk assessment, or a remediation plan that holds up (see technical-writing-for-gxp).

Increasingly, fluency with AI/ML governance and validation is becoming a differentiator as those systems enter GxP scope (see validating-ai-gxp-systems and gxp-ml-model-lifecycle).

Certifications and credentials worth having

None of these substitute for real system and inspection experience, and none are a requirement to get hired into this field. They are differentiators on a resume once the experience is behind them.

• ASQ Certified Quality Auditor (CQA). A broadly recognized quality-auditing credential from the American Society for Quality. Not data-governance-specific, but a common, well-understood differentiator for internal audit and inspection-facing roles across pharma quality generally.
• RAPS Regulatory Affairs Certification (RAC). Offered by the Regulatory Affairs Professionals Society, with separate drug (RAC-Drugs) and device (RAC-Devices) designations. Signals regulatory fluency and shows up more at senior SME and leadership levels than at entry level.
• DAMA International’s Certified Data Management Professional (CDMP). The closest thing to a dedicated data-governance credential, based on the DAMA-DMBOK body of knowledge, offered at Associate, Practitioner, and Master levels depending on years of experience. It is written for the general data-management field, not pharma specifically, so it pairs well with GxP experience rather than replacing it.
• ISPE GAMP training and certificate programs. Not a personal certification body in the ASQ or RAPS sense, but a widely recognized training credential for CSV/CSA-facing roles, and a natural companion to the credentials above for anyone working the system side of this field.

A certificate gets a resume a second look. A specific, well-told story about a real audit trail exception, a real access recertification finding, or a real inspection defense is what actually moves a hiring decision, and that story is worth more preparation time than any single credential.

What good looks like at each level

A strong IC closes audit trail reviews on time and catches real anomalies. A strong lead designs a review program that scales and survives an inspection. A strong leader can stand in front of an inspector and explain, without notes, who owns what data, how the governance system works, and how they know it is working. That last sentence is, in practice, the job interview for the top roles.

Interview questions and how to answer them

These are the questions that actually get asked for digital quality and data governance roles, with the shape of a strong answer. Use them to prepare; an inspector asks variants of the same things.

“Explain the difference between a data owner, a data steward, and a data custodian.” The owner is the business/quality role accountable for a defined data set: its purpose, criticality, access approval, and retention. The steward operates the governance day to day on the owner’s behalf: data definitions, audit trail reviews, access recertification, data quality monitoring. The custodian holds and safeguards the system technically: storage, backups, provisioning, security, and is often a third party. Close with the critical line: the custodian must not be able to make undetectable changes or approve their own access; segregation of duties between custodian admin and business approval is mandatory.

“Who is responsible for data integrity in your organization?” The honest, regulation-aligned answer is layered: senior management is accountable for the data governance system overall (PI 041-1, MHRA guidance), data owners are accountable for their specific data sets, stewards run the day-to-day controls, custodians safeguard the systems, and every user is responsible for their own records. Avoid the trap of saying “QA” or “IT” alone; that signals you do not understand distributed accountability.

“How would you set up data governance for a new GxP system?” Walk the sequence: classify the system (GxP impact, GAMP category, data criticality), assign owner/steward/custodian and have the owner formally accept, define the access matrix and segregation of duties, configure and verify audit trail and time controls, put it under change control and periodic review, and register it in the system inventory and on the governance board. Mention that the role assignment goes on the controlled RACI.

The same setup as a controlled path:

“An inspector asks who owns the chromatography data. What do you say?” Name the role (head of QC as owner, the QC systems specialist as steward, the application administrator as custodian), and be ready to show the controlled document where that mapping lives. The point of the question is whether the accountability is real and documented or improvised on the spot.

“How do you make sure the IT administrator cannot tamper with data?” Segregation of duties: admins do not hold data-entry or approval roles on the same system; admin actions are captured in the audit trail; and that admin activity is reviewed independently by the steward or QA, not by IT itself. Privileged access is granted on the approved access matrix and recertified. If the custodian is a vendor, the quality agreement and Annex 11 define and constrain their rights.

“What metrics tell you your data governance is working?” Periodic reviews and audit trail reviews completed on time, open access-recertification actions, data integrity deviations by category and trend, time to remediate, percentage of systems with assigned and accepted owners. Tie it back: management needs these to demonstrate the governance system is effective, which the guidance expects.

“What is the regulatory basis for the owner/steward/custodian model?” Be precise: there is no single regulation that names those three roles. The model is assembled from PIC/S PI 041-1 (2021), the MHRA GxP Data Integrity Guidance (2018), WHO TRS 1033 Annex 4 (2021) on management accountability and defined responsibilities, and EU GMP Annex 11 plus 21 CFR Part 11 for system-management responsibilities, access control, and the customer/third-party agreement. Showing you know it is an industry construct built on those requirements, rather than reciting a fictional clause, is what separates a strong candidate.

“How does the data owner relate to the GAMP 5 process owner?” They are usually the same person looked at through two different lenses: process owner for the system’s validated, intended use, data owner for the integrity of the data that use produces. The system owner (often IT) is the closer analog to the data custodian, though not identical, since system owner in GAMP 5 usage covers the whole validated state while custodian is narrower, the technical safekeeping of the data. The data steward has no GAMP 5 counterpart at all; it is a data-governance-only role that has to be added deliberately or a project stops at validated-state coverage and never assigns anyone to ongoing operational governance.

“The data owner wants to grant access the steward believes is inappropriate. What happens?” The steward’s concern gets a documented, timeboxed attempt at direct resolution with the owner first. If it does not resolve, it escalates to QA, and where the disagreement is specifically about a segregation-of-duties or audit-trail-integrity control, QA’s decision governs regardless of the owner’s preference, because that authority is independent of the owner’s accountability for the data set. The one thing that must never happen is an informal resolution with nothing recorded.

For broader interview prep, see gxp-quality-interview-preparation.

Practical tips

• Make owner acceptance a signature, not a spreadsheet cell. A short acknowledgment that the named owner signs converts a paper model into a real one and removes the “I never agreed to that” defense.
• Keep the role-to-data mapping under change control and review it at every governance board meeting. People move; the mapping decays in months if untended.
• Do not let “data custodian” quietly become “data decision maker.” The most common drift is IT making judgment calls (granting access, deciding retention) because the business owner is disengaged. Push those decisions back to the owner.
• Right-size for your company. At a small company one person may wear two hats (steward and custodian), which is fine as long as the incompatible combination, custodian admin plus self-approval of access or data changes, is never held by one person. Document the rationale.
• Map the model onto the systems you actually run. A generic policy is worthless until each LIMS, CDS, MES, and QMS has named roles. Inspectors test the specific, not the policy.
• Use the governance board minutes as inspection evidence. They prove the system is alive. No minutes, no proof.
• Tie the roles to access management. The steward’s access recertification and the custodian’s provisioning are where the model touches reality most often; if those run well, the rest tends to follow (see csv-cybersecurity-access-control).
• Reconcile the GAMP 5 role table and the data governance register for every validated system. Two different names sitting in the two places for the same system is a finding waiting to happen, and it is cheap to catch during the reconciliation step and expensive to catch during an inspection.
• Put decision rights in writing, not just responsibility. A RACI says who does the work; it does not say what happens when the owner and the steward disagree. Log that path before you need it live in front of an inspector, not while the inspector is standing there.

Related articles

• data-governance-framework: the program these roles operate inside
• di-program-architecture: how the data integrity pieces connect
• data-criticality-and-data-risk: classifying data so governance is risk-based
• gamp5-csv-framework: the computerized-system role family (Process/Business Owner, System Owner) this article’s roles are often confused with
• gxp-roles-responsibilities: the wider GxP role framework
• audit-trail-design-and-review and operationalizing-audit-trail-review: the steward’s core control
• csv-cybersecurity-access-control: access management and segregation of duties
• breaking-into-gxp-quality and career-guide-gxp-validation: getting in and moving up
• gxp-quality-interview-preparation: broader interview practice