GMP Data Governance and Data-Integrity Risk Management

Reliable GMP decisions depend on data that are complete, consistent, accurate, trustworthy, and available throughout their lifecycle. Technical controls are important, but software alone cannot ensure data integrity. Effective control also requires clear accountability, suitable procedures, trained personnel, adequate resources, supplier oversight, and management review.

Data governance is the organizational framework used to establish these responsibilities and controls. It defines:

• which data are critical;
• who owns the data and associated processes;
• which records are authoritative;
• how data move between systems and organizations;
• how risks are assessed and controlled;
• how control effectiveness is monitored; and
• how weaknesses are investigated, remediated, and prevented from recurring.

Data governance should apply to paper, electronic, hybrid, manually entered, automatically generated, transferred, calculated, reported, and archived data. It should be integrated into the pharmaceutical quality system rather than treated as a separate computerized-system initiative.

Management Accountability

Senior management is accountable for establishing an environment in which reliable data are expected, protected, and used appropriately. Management responsibilities include:

• approving the data-governance policy;
• assigning process, data, and system ownership;
• providing suitable systems, staffing, training, and technical support;
• ensuring that commercial targets do not encourage improper data practices;
• establishing channels for reporting errors and concerns;
• reviewing significant data-integrity risks and incidents;
• approving remediation priorities;
• evaluating residual risk;
• monitoring the effectiveness of the governance program; and
• holding responsible functions accountable for agreed actions.

The MHRA GxP Data Integrity Guidance emphasizes senior-management accountability for systems and procedures that minimize data-integrity risk. FDA has similarly emphasized that management’s role is critical in creating a quality culture that supports reliable GMP data.

Management accountability cannot be satisfied merely by approving a policy. Management review should use meaningful information about control performance, unresolved risks, recurring failures, supplier performance, and remediation progress.

Governance Structure

The governance structure should connect management direction with operational ownership and independent quality oversight. Depending on organizational size and complexity, governance may be managed through an existing quality-management forum or a dedicated data-integrity steering committee.

The governance body should include appropriate representation from:

• senior management;
• the Quality Unit;
• manufacturing;
• laboratories;
• engineering;
• information technology;
• computerized-system validation;
• records management;
• regulatory affairs; and
• supplier or service-management functions.

Its responsibilities should include:

• establishing governance standards;
• defining ownership expectations;
• approving risk-assessment methods;
• prioritizing cross-functional remediation;
• reviewing significant investigations;
• monitoring program metrics;
• resolving ownership disputes;
• coordinating supplier oversight;
• reviewing systemic or recurring risks; and
• reporting governance effectiveness to senior management.

The structure should remain practical. Creating several committees without clear authority, decisions, or follow-up does not provide effective governance.

Process, Data, and System Ownership

Process ownership, data ownership, and system ownership are related but distinct responsibilities.

Process Owner

The process owner is accountable for the regulated business process. Responsibilities normally include:

• defining the process and its intended outcomes;
• identifying regulated decisions and records;
• establishing process requirements and controls;
• identifying credible failure scenarios;
• approving procedures;
• ensuring users are qualified;
• reviewing process performance; and
• accepting process-related risk.

For example, the laboratory process owner determines how samples are received, tested, reviewed, approved, investigated, and reported.

Data Owner

The data owner is accountable for the meaning, criticality, control, and authorized use of defined data. Responsibilities may include:

• identifying critical data and metadata;
• defining the authoritative record source;
• establishing data standards and definitions;
• approving access and permitted uses;
• defining retention requirements;
• resolving conflicting values between systems;
• approving data transformations;
• ensuring that data remain understandable and retrievable; and
• confirming that data-quality controls remain effective.

Data ownership may align with process ownership, but the responsibilities should still be explicitly defined.

System Owner

The system owner is accountable for the controlled operation and lifecycle of the computerized system. Responsibilities generally include:

• maintaining system documentation;
• controlling configuration and access;
• managing technical support;
• coordinating validation;
• reviewing changes and supplier releases;
• monitoring incidents and performance;
• ensuring backup and recovery;
• maintaining the controlled baseline;
• supporting periodic review; and
• managing retirement.

System ownership does not replace data ownership. A system owner can maintain an application without having authority to redefine the meaning, source, or retention of the business data stored in it.

Quality Unit

The Quality Unit should provide appropriate independent oversight of:

• governance standards;
• risk assessments;
• significant incidents;
• investigations;
• remediation plans;
• residual-risk acceptance;
• supplier controls;
• periodic reviews; and
• management reporting.

Critical Data and Metadata

Not all data require identical controls. Governance should identify data whose failure could affect:

• patient safety;
• product identity, strength, quality, purity, or safety;
• manufacturing or laboratory control;
• material or product disposition;
• batch release;
• regulatory submissions;
• investigation conclusions;
• traceability; or
• demonstration of GMP compliance.

Critical data may include:

• raw analytical results;
• manufacturing parameters;
• specifications;
• formulas and recipes;
• calculations;
• sample and batch identifiers;
• material status;
• equipment calibration status;
• environmental-monitoring results;
• deviations and investigations;
• approval decisions;
• audit trails; and
• electronic signatures.

Metadata provide the context required to understand and reconstruct the data. Relevant metadata may include:

• user identity;
• date and time;
• instrument or equipment identity;
• method and version;
• units;
• calculation parameters;
• sample relationships;
• processing history;
• record status;
• electronic signatures; and
• audit-trail entries.

A displayed result or printed report may be incomplete if important metadata, processing parameters, audit trails, or dynamic content remain in the originating system. The complete regulated record should therefore be defined before retention, migration, reporting, or archival controls are established.

The relationship between data and metadata is addressed further in ALCOA+ Data-Integrity Principles and System Controls.

Data Flows and Authoritative Sources

A data-flow assessment should follow critical data from creation through processing, review, reporting, retention, and disposition. The assessment should identify:

• where data originate;
• whether data are entered manually or captured automatically;
• which users or devices create them;
• which systems receive them;
• what mappings or transformations occur;
• which calculations are applied;
• where data can be modified;
• where exceptions are recorded;
• which data support decisions;
• which records are transferred to third parties;
• where the complete record is retained; and
• which source is authoritative.

The authoritative source is the controlled location relied upon as the official data or record. It may be the originating system, an approved repository, a validated receiving system, or a defined combination of records.

A report, exported file, dashboard, or downstream copy should not automatically be designated as authoritative. It may omit metadata, audit trails, processing history, rejected transactions, attachments, or electronic signatures.

Where the same data can be changed independently in several systems, governance should define:

• which system controls the value;
• which direction synchronization occurs;
• how conflicts are detected;
• how rejected transfers are handled;
• how reconciliation is performed; and
• who approves corrections.

Data Lifecycle Governance

Data-integrity controls should operate throughout the complete data lifecycle:

1. creation or capture;
2. processing;
3. review;
4. approval;
5. reporting;
6. transfer;
7. storage;
8. retrieval;
9. archival or migration; and
10. controlled disposition.

Controls should address both expected activities and exceptional situations, including:

• incorrect entries;
• aborted or incomplete runs;
• repeated testing;
• reprocessing;
• rejected interface transactions;
• temporary system outages;
• restored records;
• data corrections;
• migration exceptions;
• obsolete formats; and
• system retirement.

The lifecycle assessment should also identify points where data can be unintentionally lost, improperly changed, disconnected from metadata, duplicated, overwritten, or made unavailable.

Requirements for electronic-record retention and archival are covered further in Electronic Records Lifecycle, Retention, and Archival.

Governance Standards

The organization should establish a controlled hierarchy of data-governance requirements. This may include:

• a corporate data-integrity policy;
• a data-governance standard;
• data-ownership procedures;
• data-lifecycle and retention standards;
• computerized-system governance procedures;
• access-control requirements;
• audit-trail review procedures;
• backup and recovery standards;
• interface-control requirements;
• supplier and cloud-service requirements;
• investigation procedures;
• risk-assessment methods; and
• remediation and effectiveness-check procedures.

The standards should define mandatory expectations while allowing controls to be scaled according to intended use, data criticality, system complexity, failure impact, detectability, and supplier capability.

Standards should apply consistently across departments and sites. Local procedures may implement the requirements differently, but unexplained differences in fundamental controls can create governance gaps.

Data-Integrity Risk Assessment

Data-integrity risk assessment should identify how data could become incomplete, inaccurate, misleading, unavailable, or disconnected from their context.

The assessment should consider:

• data criticality;
• intended use;
• lifecycle stage;
• manual intervention;
• opportunity to change or delete data;
• user privileges;
• shared or generic accounts;
• system limitations;
• audit-trail capability;
• interface complexity;
• calculations and transformations;
• reliance on procedural controls;
• ability to detect failure;
• supplier involvement;
• record-retention period;
• cybersecurity threats; and
• consequences of unavailable or unreliable information.

Representative failure scenarios include:

• an analyst deleting an unacceptable result;
• an incorrect formula producing an approved value;
• an interface associating a result with the wrong batch;
• missing metadata preventing reconstruction of an activity;
• administrator access allowing untraceable record changes;
• a backup excluding audit-trail information;
• a supplier update changing system behavior;
• a cloud provider becoming unable to return regulated records; or
• a retired system no longer producing readable records.

Risk should be evaluated using scientific knowledge and process understanding. A numerical score can support prioritization, but it should not be the sole basis for declaring a risk acceptable or excluding a necessary control.

The selected controls should be traceable to the identified failure scenarios and should include an appropriate combination of prevention, detection, review, recovery, and oversight.

Preventive and Detective Controls

Preventive controls reduce the opportunity for data-integrity failure. Examples include:

• unique user accounts;
• role-based access;
• segregation of duties;
• validated calculations;
• controlled master data;
• input restrictions;
• protected configuration;
• automated data capture;
• interface validation;
• electronic signatures;
• approved methods;
• controlled templates; and
• independent approval workflows.

Detective controls identify failures that preventive controls do not stop. Examples include:

• audit-trail review;
• exception reports;
• interface reconciliation;
• privileged-activity review;
• review of aborted or repeated activities;
• data-quality checks;
• trend analysis;
• backup monitoring;
• security alerts; and
• periodic access review.

A procedural review should not automatically be accepted as an effective mitigation. The reviewer must receive enough information to detect the relevant failure, perform the review at the appropriate time, document the result, and escalate exceptions.

Outsourced Services and Quality Agreements

Outsourcing an activity does not transfer accountability for the integrity, availability, or regulatory accessibility of the resulting data. Suppliers may include:

• contract laboratories;
• contract manufacturers;
• cloud and SaaS providers;
• hosting providers;
• archiving services;
• data-processing organizations;
• calibration services;
• application-support providers; and
• subcontractors used by the primary supplier.

Supplier assessment should consider:

• development and quality practices;
• security and access controls;
• data ownership;
• data location;
• backup and restoration;
• change notification;
• incident reporting;
• audit rights;
• subcontractor oversight;
• inspection support;
• business continuity;
• data export;
• service termination; and
• supplier failure.

Contracts and quality agreements should define:

• data ownership and permitted use;
• record accessibility;
• retention responsibilities;
• required metadata;
• security responsibilities;
• supplier and subcontractor access;
• incident-notification timelines;
• investigation cooperation;
• change notification;
• audit and inspection access;
• backup and recovery;
• data-return format;
• termination assistance; and
• deletion authorization.

The contracting organization should retain sufficient knowledge and access to review supplier performance and retrieve complete regulated records.

Further guidance is provided in Computerized System Supplier Assessment and Evidence Leverage and Cloud and SaaS Systems in GMP Environments.

Monitoring and Metrics

Data-governance monitoring should demonstrate whether controls are functioning, not merely count completed activities. Useful indicators may include:

• overdue audit-trail reviews;
• inappropriate or excessive privileged access;
• access-review exceptions;
• repeated tests or aborted runs;
• interface failures;
• unreconciled transactions;
• missing records or metadata;
• backup failures;
• unsuccessful restoration tests;
• data-related deviations;
• recurring investigation causes;
• overdue corrective actions;
• supplier incidents;
• delayed supplier notifications;
• unsupported systems;
• overdue periodic reviews;
• training completion; and
• remediation effectiveness.

Metrics require context. A reduction in reported incidents may indicate improvement, but it may also indicate underreporting. High deviation counts may reflect weak controls or a healthy reporting culture.

Governance review should therefore evaluate:

• the significance of events;
• recurrence;
• detection source;
• reporting delays;
• affected processes and sites;
• systemic causes;
• remediation status; and
• evidence of sustained effectiveness.

Investigations

Suspected data-integrity failures should be investigated promptly and objectively. The investigation should determine:

• what happened;
• which data, products, batches, studies, or decisions were affected;
• when the failure began;
• whether similar events occurred elsewhere;
• whether the issue was intentional, accidental, technical, procedural, or systemic;
• which controls failed;
• whether management or cultural factors contributed;
• whether reported records can still be trusted;
• what immediate containment is required; and
• whether regulatory notification or market action must be considered.

The investigation should not be limited to the individual who performed the activity. Root causes may involve:

• unsuitable system design;
• excessive workload;
• inadequate training;
• poorly defined ownership;
• inappropriate privileges;
• weak supervisory review;
• unrealistic performance expectations;
• incomplete supplier oversight; or
• failure to correct known system limitations.

Significant findings should be assessed across comparable processes, systems, departments, products, and sites.

Remediation Programs

A formal remediation program may be necessary when weaknesses are widespread, longstanding, or systemic. The program should include:

• defined scope;
• governance and leadership;
• qualified resources;
• immediate containment;
• historical data assessment;
• product-impact evaluation;
• system and process remediation;
• prioritized corrective actions;
• interim controls;
• supplier actions;
• milestones and accountable owners;
• escalation criteria;
• independent review;
• effectiveness checks; and
• management reporting.

Remediation should address both individual failures and the conditions that allowed them to occur.

Retrospective review should be scientifically justified and sufficiently broad to determine whether past records and decisions remain reliable. Sampling may support the assessment, but the sample should reflect the failure mode, time period, affected systems, users, products, and opportunities for recurrence.

A remediation item should not be closed solely because a procedure was revised or personnel were retrained. Effectiveness should be demonstrated through observed behavior, reliable system controls, monitoring results, and absence of recurrence over an appropriate period.

Inspection Readiness

Inspection readiness means that the organization can explain and demonstrate how critical data are governed. The organization should be able to provide:

• the data-governance policy and standards;
• governance roles and meeting records;
• system and data inventories;
• critical-data assessments;
• data-flow diagrams;
• authoritative-source definitions;
• risk assessments;
• supplier and quality agreements;
• monitoring results;
• significant investigations;
• remediation plans;
• management-review evidence;
• effectiveness checks; and
• complete, readable regulated records.

Personnel should understand their actual responsibilities. Inspection readiness should not depend on a small number of specialists who alone can locate or explain the records.

Management Review

Management review should periodically evaluate whether the governance program remains effective and adequately resourced. Inputs should include:

• significant and recurring incidents;
• critical and overdue risks;
• governance metrics and trends;
• supplier performance;
• regulatory observations;
• audit findings;
• remediation progress;
• overdue actions;
• unsupported or obsolete systems;
• cybersecurity and availability risks;
• resource constraints;
• changes in processes or technology; and
• results of effectiveness checks.

Management decisions, assigned actions, due dates, and accepted residual risks should be documented.

Continuing Improvement

Data governance should evolve as processes, systems, suppliers, regulations, and risks change. Continuing improvement should use information from:

• deviations and investigations;
• internal audits;
• regulatory inspections;
• audit-trail reviews;
• user feedback;
• supplier notifications;
• cybersecurity events;
• system changes;
• periodic reviews;
• restoration tests;
• migration projects;
• industry guidance; and
• governance metrics.

Improvements may include:

• clarifying ownership;
• simplifying workflows;
• removing unnecessary manual transcription;
• strengthening access controls;
• improving audit-trail review;
• automating reconciliation;
• replacing uncontrolled applications;
• improving supplier agreements;
• modernizing obsolete systems;
• revising training;
• improving investigation methods; or
• changing metrics that no longer reveal meaningful risk.

The objective is not to eliminate every theoretical possibility of error. It is to understand critical data and credible failure scenarios, establish effective controls, detect problems promptly, make informed risk decisions, and maintain confidence in the records used for GMP decisions.