Independent and not affiliated with the FDA, MHRA, ISPE, PDA, or any agency. Get the appgoutham@madhadi.com
madhadi.comData Integrity & GxP Quality
Browse all topics → Articles Templates & Procedures Learning paths GlossaryScenariosToolsRegulatory ReferencesLearning PathsTopics About Start here
Policy Plug-and-play starting point Data Integrity

Policy: GxP Data Governance Program

A plug-and-play charter policy that establishes the data governance program itself: the system inventory, criticality tiering, ownership model, data flow mapping, new-system assessment gate, governance committee, and remediation process, with a filled specimen and the regulations it satisfies.

Document type: Policy

Read and copy the template below into your own quality system. It is a generic starting point for your own internal use, provided as is, with no warranty; see the Terms and License. Adopting it does not by itself create compliance.

This is a ready-to-use policy that establishes the data governance program as an organizational structure, distinct from the data integrity policy that sets the ALCOA+ standard for records themselves. A data integrity policy states what every record must be; this policy states how the organization knows what systems it has, who owns each one, how much oversight each gets, and how gaps get fixed. Replace every <<FILL: ...>> placeholder with your own specifics, set your document numbers and dates, and route it through your normal document control, review, and approval. A worked filled specimen follows the template so you can see how a completed version reads. Verify each cited regulation against the current source before you rely on it.

Document control header

FieldEntry
Document titleGxP Data Governance Program Policy
Document number<<FILL: POL-ID, e.g. POL-QA-014>>
Version<<FILL: version, e.g. 1.0>>
Effective date<<FILL: effective date>>
Supersedes<<FILL: prior version or "New">>
Policy owner<<FILL: role, e.g. Head of Quality / Data Governance Lead sponsor>>
Applies to<<FILL: all sites, functions, and contracted parties in scope>>
Review cycle<<FILL: e.g. every 2 years or on material organizational change>>

1. Purpose

This policy establishes <<FILL: COMPANY NAME>>’s data governance program: the organizational structure that keeps GxP data trustworthy over time, across system changes, personnel turnover, and business growth. It answers three standing questions for every GxP computerized system: what data do we have and where does it live, who is accountable for its integrity at each stage of its lifecycle, and how do we know the controls protecting it still work. This policy governs the program’s infrastructure. It does not restate the record-level ALCOA+ standard, which is set by <<FILL: DOC-ID for the Data Integrity Policy>>; the two are complementary and neither substitutes for the other.

2. Scope

This policy applies to every computerized system that creates, processes, stores, or transmits GxP data at the sites and functions named in the header, across good manufacturing, laboratory, clinical, distribution, and pharmacovigilance practice as relevant to the business, and to the data those systems hold regardless of hosting model. It covers systems operated directly and systems operated by contracted parties on the company’s behalf. It applies equally to conventional software and to artificial intelligence or machine learning systems used for a GxP purpose, whose training data and model versions are themselves governed data.

3. Definitions

  • System inventory: the current, controlled list of every GxP computerized system, with the attributes needed to assess and control it.
  • Data criticality tier: a risk-based classification (commonly Tier 1 Critical, Tier 2 Supporting, Tier 3 Peripheral) set by the worst GxP decision a system’s data can influence, which determines the depth of oversight the system receives.
  • Data owner: the named individual accountable for a system’s data integrity, distinct from the system administrator who implements technical controls.
  • Data flow map: a documented trace of how a data element moves from creation through its final regulated use, with the integrity control at each transfer point identified.
  • New system assessment: the pre-deployment evaluation of a system’s data integrity capability, completed before the system enters GxP use.
  • Governance audit: a periodic, end-to-end walk of one real data flow to test whether the governance controls actually work in practice, distinct from a system-level audit or an audit trail review.

4. Policy statement: the elements of the program

<<FILL: COMPANY NAME>> operates its data governance program through the following elements, each of which is mandatory for every GxP computerized system, scaled to the system’s criticality tier:

  1. A current system inventory. Every GxP computerized system is entered into the inventory before it goes into GxP use and remains current through a change-control trigger. An untracked system is treated as a governance gap the moment it is discovered, not a tolerated exception.
  2. Risk-based criticality tiering. Every system in the inventory carries a documented criticality tier, assigned by the worst GxP decision its data can influence, with the rationale recorded and reviewed by Quality Assurance.
  3. A named data owner for every Tier 1 and Tier 2 system. Ownership is an individual accountability, never a team or department default, and is reviewed at least annually.
  4. Data flow mapping for Tier 1 systems. The path of Tier 1 data from creation to final regulated use is documented, with the integrity control at each transfer point identified and the location of the original record marked.
  5. A data integrity risk assessment for every Tier 1 and Tier 2 system, refreshed at least annually and after any significant change, upgrade, or relevant external finding.
  6. A pre-deployment new system assessment for every system entering GxP use, evaluating audit trail capability, access control, electronic signature support, retention and migration capability, and vendor compliance documentation before purchase or go-live.
  7. A governance committee, meeting at a defined cadence with minuted actions, that reviews the inventory, outstanding findings, new system assessments, and program metrics, and that reports into management review.
  8. A risk-based remediation program that prioritizes gaps by risk rather than convenience, documents interim controls for gaps that cannot close immediately, and tracks every item to closure.
  9. A periodic governance audit, walking at least one complete Tier 1 data flow end to end on a defined cadence, to find drift in the program before an inspector does.

5. Roles and accountability

RoleAccountability under this policy
Executive managementResources the program and reviews its metrics and trends in management review, consistent with ICH Q10.
Policy owner / Data governance leadOwns this policy, maintains the inventory’s currency requirement, coordinates risk assessments, and supports the governance committee.
System owner (data owner)Named individual accountable for a system’s data integrity, distinct from the administrator who implements controls.
Quality AssuranceApproves tiering, reviews risk assessments, and confirms the program’s records support an inspection.
IT / infrastructureImplements technical controls under the direction of system owners, maintains the platforms the inventory depends on.
Department heads with Tier 1 systemsSit on the governance committee and are accountable for their systems’ currency in the inventory.

The detailed activity-level RACI for this program is held in <<FILL: reference to your data governance RACI>>.

6. Compliance and exceptions

Every GxP computerized system is expected to be in the inventory, tiered, and owned. Where a documented, time-bound exception is required, for example during a merger, acquisition, or site transfer, the exception is approved by the policy owner and Quality Assurance, states the compensating interim control, and carries a defined date by which the system is brought into full compliance. An exception with no end date is not an exception; it is an unmanaged gap.

7. Acceptance criteria

This policy is being met when all of the following are true:

  • The system inventory is current, with a change-control trigger keeping it that way, and every entry has a documented criticality tier and a named owner where required.
  • Every Tier 1 system has a documented data flow map and a risk assessment refreshed within the last year or since its last significant change.
  • No system has entered GxP use without a completed pre-deployment assessment on file.
  • The governance committee meets on its defined cadence, keeps minutes, and tracks actions to closure.
  • The remediation plan is current, risk-prioritized, and reviewed by the committee.
  • A governance audit has been performed within the defined cadence and its findings fed back into the risk assessment and remediation plan.

8. References

MHRA, “GXP Data Integrity Guidance and Definitions” (March 2018), section 6.5 on data governance. PIC/S PI 041-1, “Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments” (July 2021). WHO Technical Report Series 1033, Annex 4, “Guideline on Data Integrity” (2021). FDA, “Data Integrity and Compliance With Drug CGMP: Questions and Answers” (December 2018), tied to 21 CFR Parts 210, 211, and 212. EU GMP Annex 11 (Computerised Systems) and 21 CFR Part 11 (Electronic Records; Electronic Signatures). 21 CFR Part 820 (device quality system; QMSR amendments effective February 2026), harmonized to ISO 13485:2016. ICH Q9(R1), Quality Risk Management (2023 revision), for the proportionality principle behind tiering and risk assessment. ICH Q10, Pharmaceutical Quality System, for the management-review and continual-improvement link.

Confirm the current version and clause numbers of each reference before issue.

9. Supporting procedures and records

ElementReference
Data integrity policy (ALCOA+ standard)<<FILL: POL-ID>>
System inventory management<<FILL: SOP-ID>>
Data criticality classification<<FILL: SOP-ID>>
Data governance role assignment<<FILL: reference to your ownership register>>
New system data integrity assessment<<FILL: FORM-ID, e.g. the new system data governance assessment form>>
Governance committee charter<<FILL: reference to your committee terms of reference>>
DI remediation program<<FILL: reference>>

10. Revision history

VersionDateAuthorSummary of change
<<FILL: 1.0>><<FILL: date>><<FILL: author>>Initial issue.

11. Approvals

RoleNameSignatureDate
Author<<FILL>>
Reviewer (QA)<<FILL>>
Approver (Quality Head)<<FILL>>
Endorsed by (Executive sponsor)<<FILL>>

Filled specimen

The following shows the header and a sample of the program elements completed for an illustrative mid-size biologics company, so you can see the level of specificity expected. The company, numbers, and references are illustrative; replace them with your own.

FieldEntry
Document titleGxP Data Governance Program Policy
Document numberPOL-QA-014
Version1.0
Effective date01 September 2026
Policy ownerData Governance Lead, reporting to the VP of Quality
Applies toAll sites, all GxP functions, and contracted CDMOs and testing laboratories
Review cycleEvery 2 years or on material organizational change

Specimen of the program elements as adopted:

This company maintains a system inventory of 61 GxP computerized systems, refreshed through a mandatory change-control trigger, with 14 rated Tier 1. Every Tier 1 and Tier 2 system carries a named owner reviewed each January. A data governance committee, chaired by the VP of Quality and including the heads of QC, Manufacturing, and IT, meets quarterly; its Q2 2026 minutes show 6 tracked actions, 4 closed on time. The most recent governance audit walked the release-testing data flow for the lead product end to end and found one undocumented manual transcription step, now closed under a documented interim control while the permanent interface fix is validated.

That level of specificity, real counts, a real cadence, a real audit finding and its disposition, is what an inspector reading this policy expects to see reflected in the records behind it, not just in the policy text itself.

Common inspection findings this policy prevents

  • A data integrity policy exists, but nothing states who is accountable for knowing what systems exist and who owns each one; the organizational infrastructure was never separately charged to anyone.
  • A governance committee or inventory exists informally, with no policy establishing it as a requirement, so its lapse during a reorganization draws no attention until an inspection.
  • New systems enter GxP use with no consistent pre-deployment gate because no policy makes the gate mandatory.
  • Exceptions to the governance program (during an acquisition, for example) are made informally with no approval, no compensating control, and no end date.
  • Data governance and the ALCOA+ data integrity standard are conflated in a single document, so neither the record-level standard nor the organizational infrastructure is clearly and separately auditable.

How to adapt this policy

  1. Set your document number, owner, effective date, and review cycle in the header.
  2. Point section 1 and section 9 at your actual Data Integrity Policy so the two documents are clearly complementary, not competing or duplicative.
  3. Confirm the scope statement matches your actual GxP footprint and contracted-party relationships.
  4. Fill in every <<FILL: SOP-ID>> or <<FILL: reference>> cross-reference in section 9 with your real supporting procedures and records, including the new system assessment form and the governance committee charter.
  5. Have the executive sponsor endorse the policy so it carries leadership weight, not only a QA signature, consistent with the management-responsibility expectation in the MHRA and PIC/S guidance.
  6. Confirm every regulation in section 8 against the current published version before issue.
Use madhadi.com as an app Full screen, works offline, one tap from your home screen.