Introduction

The pharmaceutical industry runs on data.

From the moment a raw material is received to the final release of a batch, hundreds or even thousands of data points are generated. Laboratory results, manufacturing parameters, equipment readings, environmental monitoring records, cleaning records, stability results, validation studies, deviations and CAPA decisions all depend on one thing: reliable data.

But what happens when the data cannot be trusted?

A result may look correct on a certificate of analysis, but if the original laboratory data is missing, the audit trail has not been reviewed, or the result was generated using an uncontrolled process, the reliability of that result becomes questionable.

This is where GxP Compliance and Data Integrity become closely connected.

Data integrity is not simply about keeping records safely. It is about being able to demonstrate that the data represents what actually happened, who performed the activity, when it was performed, what changes were made, and whether the information remained complete and reliable throughout its lifecycle.

This is particularly important because pharmaceutical companies make critical decisions based on their data:

• Should a batch be released?
• Is a process operating within validated conditions?
• Is an analytical method suitable?
• Was a cleaning process effective?
• Is a stability result reliable?
• Was a deviation properly investigated?
• Can a regulatory submission be supported by the available evidence?

If the underlying data is unreliable, the decision based on that data is also placed at risk.

For this reason, data integrity should not be considered only an IT, CSV or laboratory issue. It is a cross-functional quality responsibility involving QA, QC, Manufacturing, Engineering, Validation, IT, Regulatory Affairs, system owners, process owners and senior management.

1. Understanding GxP

GxP is commonly used as an umbrella term for the various “Good Practice” requirements applicable to regulated pharmaceutical and healthcare activities.

The specific requirements depend on the activity being performed.

Although these areas have different requirements, there is a common expectation: decisions affecting product quality, safety, efficacy or patient protection should be supported by trustworthy evidence.

That is the fundamental connection between GxP and data integrity.

2. What Is Data Integrity?

Data integrity can be simply described as the ability to trust data throughout its entire lifecycle.

In a GxP environment, data should remain:

• Accurate
• Complete
• Consistent
• Reliable
• Traceable
• Available
• Secure
• Authentic

Importantly, data integrity applies to both paper and electronic records.

For example, consider an HPLC analysis.

The final report may show an acceptable assay result. However, a complete assessment may require consideration of:

• Sample preparation
• Sequence information
• Raw chromatographic data
• System suitability
• Integration
• Processing method
• Reprocessing
• Reinjections
• Audit trail
• Analyst identity
• Calculations
• Review and approval

The final reported number is only one part of the complete data package.

This is why data integrity should be considered from the perspective of the complete data lifecycle, rather than only the final result.

3. Data Integrity, Data Quality, Data Security and Data Governance — Are They the Same?

These terms are often used interchangeably, but they are not the same.

There is considerable overlap.

For example, a laboratory system may have strong cybersecurity controls, but if five analysts share the same account, the system may still have a significant data attribution problem.

Similarly, a validated system may produce technically accurate results but still have weaknesses in access management, audit trail review or data retention.

4. ALCOA+ — The Foundation of Data Integrity

When discussing pharmaceutical data integrity, one of the first concepts professionals encounter is ALCOA+.

ALCOA represents:

• Attributable
• Legible
• Contemporaneous
• Original
• Accurate

The “+” expands the concept to include:

• Complete
• Consistent
• Enduring
• Available

These principles provide a practical way of asking a simple question:

Can we demonstrate that this data is trustworthy?

4.1 Attributable

The record should identify who performed the activity.

For an electronic system, this normally means using an individual user account rather than a shared account.

Example

An analyst logs into the chromatography data system using their own credentials and performs the analysis.

Potential failure

Several analysts use one generic account.

If a result is subsequently modified, it may be impossible to establish who performed the action.

Good practice

Use:

• Individual user IDs
• Appropriate authentication
• Role-based access
• Controlled administrator privileges

4.2 Legible

Records should remain readable and understandable throughout their required retention period.

For paper records, this means entries should be clear and permanent.

For electronic records, it also means ensuring that the data and associated information remain accessible and interpretable.

4.3 Contemporaneous

The activity should be recorded when it actually occurs.

Consider a manufacturing operator who records a process parameter several hours after the operation based on memory.

Even if the recorded number happens to be correct, the record does not provide the same level of confidence as a contemporaneous entry.

Good practice

Record information:

• At the time of the activity
• Using the approved system or document
• Without relying on memory or informal notes

4.4 Original

The original record, or an appropriately verified true copy where permitted, should be maintained.

In an electronic environment, the original record may include considerably more than a printed report.

For example, chromatographic data may involve:

• Raw data
• Metadata
• Audit trail
• Processing method
• Sequence information
• Instrument information

Printing the final chromatogram does not necessarily replace the original electronic record.

4.5 Accurate

The data should correctly represent what happened.

Accuracy can be affected by:

• Manual transcription
• Incorrect calculations
• Incorrect system configuration
• Unauthorized changes
• Poorly maintained equipment
• Human error

Controls should therefore be designed to prevent and detect errors.

4.6 Complete

Data should not be selectively retained.

This is particularly important in laboratories.

A passing result should not be retained while an earlier failing or suspect result disappears from the record.

The complete history should be available where required.

4.7 Consistent

Data should make sense when reviewed chronologically and logically.

For example:

• The sequence should make sense.
• Dates and times should be consistent.
• Equipment records should align with batch records.
• Laboratory activity should align with sample receipt and testing dates.

4.8 Enduring

Records should remain preserved and usable throughout their required retention period.

This creates additional considerations for electronic systems:

• Database migration
• Software obsolescence
• Backup
• Archiving
• Data restoration
• File formats

4.9 Available

Authorized personnel should be able to retrieve the required data when needed.

A record that technically exists but cannot be retrieved during an investigation or inspection creates a practical data integrity problem.

5. Common Data Integrity Failures

Data integrity failures are not always dramatic.

Sometimes they begin with seemingly small practices that become accepted as “normal.”

Examples include:

• Sharing passwords
• Using generic accounts
• Recording activities later instead of contemporaneously
• Maintaining unofficial worksheets
• Transcribing data unnecessarily
• Deleting unwanted electronic records
• Failing to review audit trails
• Giving users excessive privileges
• Maintaining uncontrolled spreadsheets
• Retaining only printed reports
• Repeating testing without appropriate scientific justification
• Making undocumented changes to records
• Pre-signing documents
• Backdating entries

One important point should be emphasized:

A warning sign is not automatically proof of intentional misconduct.

The correct response is to investigate the situation objectively, determine the facts and assess the potential impact.

6. Data Integrity Is a Lifecycle Requirement

One of the most useful ways of understanding data integrity is to look at the complete lifecycle of data.

Data Creation → Processing → Review → Reporting → Approval → Storage → Retrieval → Archival → Destruction

Controls should exist throughout this journey.

A common mistake is to focus heavily on how data is generated while paying less attention to what happens afterward.

Data integrity does not end when the result is approved.

7. Data Governance in the Pharmaceutical Industry

A strong data integrity program needs clear governance.

A company should be able to answer basic questions such as:

• Who owns this data?
• Who owns the system?
• Who is responsible for reviewing the data?
• Who approves access?
• How long is the data retained?
• How is the data archived?
• Who reviews the audit trail?
• What happens when data integrity concerns are identified?

A typical governance structure may include:

Data Integrity Policy

Defines the organization’s overall expectations.

SOPs and Work Instructions

Describe how activities are performed.

Roles and Responsibilities

Define accountability between QA, business functions, IT and system owners.

Training

Ensures personnel understand both the requirements and the reason behind them.

Risk Assessment

Identifies vulnerabilities in processes and systems.

Monitoring

Determines whether controls continue to work effectively.

Management Review

Ensures that significant risks and trends receive appropriate leadership attention.

8. Data Integrity Risk Assessment

Not all data presents the same level of risk.

A temperature record for a non-critical warehouse area may not have the same criticality as a chromatographic result used for batch release.

A risk-based approach should therefore consider:

• Criticality of the data
• Impact on product quality
• Impact on patient safety
• Possibility of data manipulation
• Ability to detect changes
• Existing controls
• Process complexity

A practical assessment can follow these steps:

Step 1 — Identify the GxP Process

For example:

• QC testing
• Manufacturing
• Stability
• Calibration
• Cleaning
• Validation

Step 2 — Identify Critical Data

Determine which data supports important GxP decisions.

Step 3 — Map the Data Flow

Understand where the data originates, where it goes and where it is ultimately stored.

Step 4 — Identify Vulnerabilities

Ask:

• Can the data be deleted?
• Can it be changed?
• Can users share accounts?
• Can audit trails be disabled?
• Is transcription involved?
• Can data be exported and manipulated?
• Are interfaces controlled?

Step 5 — Evaluate Risk

Consider severity, probability and detectability.

Step 6 — Establish Controls

Examples include:

• Access control
• Audit trails
• Automated interfaces
• Independent review
• System validation
• SOPs

Step 7 — Assess Residual Risk

Determine whether the remaining risk is acceptable.

Step 8 — Monitor

Risk assessment should not be treated as a one-time exercise.

Changes in systems, processes, technology and regulations may require reassessment.

9. Example Data Integrity Risk Assessment

The objective is not to eliminate every theoretical risk.

The objective is to identify important vulnerabilities and put proportionate controls in place.

10. GxP Computerized Systems and Data Integrity

Almost every modern pharmaceutical organization depends on computerized systems.

Examples include:

• LIMS
• MES
• Electronic Batch Records
• ERP
• EDMS
• LMS
• Chromatography Data Systems
• SCADA
• DCS
• PLC-based systems
• QMS
• Stability systems
• Environmental monitoring systems
• Calibration systems
• Warehouse management systems
• Clinical systems
• Pharmacovigilance systems
• Cloud/SaaS applications

The type of risk varies from system to system.

LIMS

Critical data may include:

• Sample registration
• Test assignment
• Results
• Calculations
• Instrument data
• Review
• Approval
• COA information

Potential concerns include:

• Shared accounts
• Result modification
• Excessive privileges
• Inadequate audit trails
• Uncontrolled master data
• Interface failures

MES/eBR

Critical information may include:

• Material dispensing
• Manufacturing parameters
• Equipment status
• Operator activities
• IPC results
• Electronic signatures

Potential concerns include:

• Manual overrides
• Unauthorized changes
• Inappropriate administrator access
• Interface failures
• Inadequate review of electronic records

11. Computerized System Validation and Data Integrity

There is sometimes a misconception that:

“If the system is validated, data integrity is automatically assured.”

That is not necessarily true.

Validation provides assurance that a system is suitable for its intended use based on defined requirements and risk.

But data integrity risks can develop during the operational life of the system.

For example:

• New users are given inappropriate privileges.
• A configuration is changed.
• A new interface is introduced.
• An audit trail is not routinely reviewed.
• A vendor upgrade changes system behavior.
• Data is migrated incorrectly.
• The system becomes obsolete.
• Procedures do not reflect the current configuration.

A robust lifecycle therefore needs to consider:

1. User Requirements
2. Risk Assessment
3. Supplier Assessment
4. Functional/Configuration Requirements
5. Validation or Assurance Strategy
6. Testing
7. Data Migration
8. Interfaces
9. Access Controls
10. Audit Trails
11. Electronic Signatures
12. Backup and Restore
13. Change Control
14. Incident Management
15. Periodic Review
16. Business Continuity
17. Disaster Recovery
18. System Retirement

EU GMP Annex 11 specifically expects computerized systems to be managed using risk management principles that consider patient safety, data integrity and product quality.

12. Audit Trails — More Than Just a System Feature

An audit trail is one of the most important technical controls supporting electronic data integrity.

A useful audit trail should help reconstruct relevant actions.

For example:

Who changed the value?

When was it changed?

What was the original value?

What is the new value?

Why was the change made, where applicable?

However, simply having an audit trail does not automatically demonstrate effective data integrity control.

There is an important distinction between:

Audit Trail Availability

The system records changes.

Audit Trail Review

Appropriately authorized personnel actually review relevant audit trail information.

The organization should establish a justified approach defining:

• What is reviewed
• Who performs the review
• When it is performed
• How exceptions are handled
• How the review is documented

The extent of review should be appropriate to the process and risk.

13. User Access Management

Access management is one of the simplest areas to understand and one of the easiest areas to get wrong.

A good access-management program should include:

• Individual user IDs
• Role-based access
• Least privilege
• Segregation of duties
• Appropriate password controls
• Controlled administrator access
• Periodic access review
• Joiner/Mover/Leaver controls
• Timely account deactivation
• Emergency access procedures

Why are shared accounts a concern?

Suppose five analysts use the same laboratory account.

An audit trail shows:

“User ABC changed the result.”

But who is User ABC?

It could have been any of the five people.

The organization has lost an important element of attribution.

That is why individual accountability is such an important part of electronic data integrity.

14. Electronic Records and Electronic Signatures

As organizations move from paper to digital systems, electronic records have become increasingly important.

Controls may include:

• User authentication
• Unique identification
• Access control
• Audit trails
• Electronic signatures
• Record retention
• Signature linking
• System security

In the United States, 21 CFR Part 11 provides requirements applicable to electronic records and electronic signatures in specified circumstances.

It is important, however, not to treat Part 11 as a substitute for the underlying GxP requirements.

An electronic system may be technically compliant with applicable electronic-record requirements while the underlying business process still has data integrity weaknesses.

15. Electronic Signature vs Digital Signature vs Scanned Signature

These terms are often confused.

A scanned image should not automatically be treated as equivalent to a properly controlled electronic signature.

The regulatory and procedural requirements applicable to a signature should always be considered in context.

16. Paper Records and Data Integrity

The move toward electronic systems sometimes creates the impression that data integrity is mainly an electronic issue.

It is not.

Paper records can present significant integrity risks.

Examples include:

• Manufacturing records
• Laboratory notebooks
• Equipment logbooks
• Cleaning records
• Calibration records
• Temperature records

Good documentation practices generally include:

• Recording information contemporaneously
• Using appropriate permanent writing materials
• Making corrections transparently
• Maintaining the original entry
• Adding initials/signature and date where required
• Documenting the reason for a correction where required
• Avoiding blank spaces
• Prohibiting pre-signing
• Avoiding backdating
• Using controlled forms

The basic principle remains the same:

The record should accurately represent what actually happened.

17. Laboratory Data Integrity

Laboratories generate some of the most important GxP data in a pharmaceutical organization.

Typical systems and instruments include:

• HPLC
• GC
• UV
• FTIR
• Dissolution
• TOC
• pH meters
• Microbiology systems
• Stability systems

Laboratory data may include much more than the final reported result.

It can include:

• Raw data
• Chromatograms
• Sample sequences
• System suitability
• Integration
• Processing methods
• Calculations
• Reprocessing
• Reinjections
• Retesting
• Audit trails
• Analyst information

Testing Into Compliance

One of the most serious laboratory data integrity concerns is the inappropriate practice of repeatedly testing until an acceptable result is obtained.

For example:

A sample produces an unexpected result.

Instead of following the established investigation procedure, the analyst repeats the test several times and reports only the passing result.

This creates a misleading picture of the analytical history.

The appropriate approach is to follow the approved procedure for handling unexpected, suspect, OOS or OOT results and retain the relevant data needed to understand what occurred.

18. Manufacturing Data Integrity

Manufacturing processes generate large volumes of data.

Examples include:

• Batch records
• Material dispensing records
• Equipment parameters
• Process parameters
• IPC results
• Environmental conditions
• Yield calculations
• Equipment status
• Operator actions

Consider a critical process parameter that is manually copied from equipment into a batch record.

Every additional manual step introduces an opportunity for:

• Transcription error
• Wrong value
• Missing value
• Delayed recording
• Retrospective recording

Where appropriate, electronic integration can reduce some of these risks.

However, automation does not eliminate the need for validation, access control, review and change management.

19. Data Integrity in Quality Control

For QC laboratories, data integrity should cover the complete analytical process.

This includes:

• Sample receipt
• Sample preparation
• Testing
• Raw data
• Calculations
• System suitability
• Review
• Approval
• Reporting

Particular attention may be required for:

• OOS investigations
• OOT investigations
• Stability testing
• Retesting
• Reinjection
• Reprocessing
• COA generation

Before relying on a laboratory result for batch disposition, the organization should have confidence not only in the final number but also in the underlying data and review process.

20. Data Integrity in Validation Activities

Validation activities generate GxP records too.

Examples include:

• Equipment qualification
• Process validation
• Cleaning validation
• Analytical method validation
• Computerized system validation
• Calibration
• Continued process verification

Validation evidence should therefore meet the same fundamental data integrity expectations.

For example:

• Test execution should be attributable.
• Results should be recorded contemporaneously.
• Deviations should be documented.
• Original evidence should be retained.
• Changes should be traceable.
• Approvals should be controlled.

A company cannot reasonably expect its operational data to be reliable if the evidence used to demonstrate validation was itself poorly controlled.

21. Cloud and SaaS Systems

Cloud and SaaS solutions are increasingly common in pharmaceutical organizations.

They can offer advantages such as:

• Scalability
• Remote accessibility
• Reduced infrastructure burden
• Faster deployment

But they also introduce questions that need to be addressed from a GxP perspective.

For example:

• Who owns the data?
• Who can access it?
• Who manages backups?
• Where is the data hosted?
• How are upgrades controlled?
• What happens if the vendor changes the application?
• How will data be retrieved if the service ends?
• How will disaster recovery be demonstrated?

The use of a cloud provider does not transfer the pharmaceutical company’s GxP responsibilities to the provider.

Supplier qualification, contracts, service-level expectations, security, data ownership, retention and business continuity should therefore be addressed appropriately.

22. Data Integrity and AI/ML

Artificial intelligence and machine learning are bringing another dimension to the data integrity discussion.

Potential GxP considerations include:

• Source data
• Training datasets
• Data provenance
• Model version
• Model changes
• Algorithm outputs
• Human review
• Model performance
• Traceability
• Change control

For an AI-enabled GxP process, it is useful to understand the complete chain:

Input Data → Processing/Model → Output → Human Review → Decision

The use of AI does not remove the need for accountability.

Where AI/ML is used in a regulated process, organizations should establish appropriate controls based on the intended use, risk and applicable regulatory expectations.

Because regulatory expectations in this area continue to evolve, companies should clearly distinguish established requirements from emerging industry practices.

23. Data Integrity Red Flags During Audits

Experienced auditors often look for inconsistencies rather than simply checking whether a procedure exists.

Some potential warning signs include:

• Shared accounts
• Unexplained changes
• Missing raw data
• Disabled audit trails
• Excessive administrator access
• Unusual timestamps
• Frequent manual corrections
• Repeated testing
• Uncontrolled spreadsheets
• Missing metadata
• Pre-signed documents
• Backdated entries
• Unofficial records
• Inconsistent equipment and batch records
• Poor audit trail review
• Repeated data-related deviations

These indicators should not automatically be interpreted as deliberate data manipulation.

They should instead prompt a structured assessment to understand what happened, why it happened, how widespread it is and whether product or patient impact is possible.

24. Preparing for a Regulatory Inspection

A company should not begin preparing for a data integrity inspection when the inspector arrives.

Inspection readiness should be part of normal operations.

Inspectors may examine:

• Data Integrity Policy
• SOPs
• Training records
• User access
• Audit trails
• Raw data
• Metadata
• System configuration
• Validation records
• Change controls
• Deviations
• CAPA
• Risk assessments
• Periodic reviews
• Supplier controls
• Backup and restoration arrangements

A useful internal test is to ask:

Can we locate the original data?

Can we identify who generated it?

Can we demonstrate when it was generated?

Can we explain every relevant change?

Can we demonstrate that access is controlled?

Can we explain how audit trails are reviewed?

Can we demonstrate that our controls actually work?

These questions are much more meaningful than simply asking whether an SOP exists.

25. Handling a Data Integrity Concern

When a potential data integrity issue is identified, the first reaction should be controlled and evidence-based.

A typical approach may include:

1. Containment

Prevent the issue from continuing.

2. Fact Finding

Understand exactly what happened.

3. Data Impact Assessment

Identify potentially affected records.

4. Product Impact Assessment

Determine whether product quality may have been affected.

5. Patient Impact Assessment

Consider potential patient implications where appropriate.

6. Root Cause Investigation

Look beyond the immediate employee action.

Possible causes may include:

• Poor system design
• Inadequate procedures
• Excessive privileges
• Training gaps
• Workload
• Organizational culture
• Management pressure
• Weak oversight

7. Scope Assessment

Determine whether the problem is isolated or systemic.

8. Historical Review

Perform retrospective review where scientifically and risk-appropriately justified.

9. CAPA

Implement corrective and preventive/systemic actions.

10. Effectiveness Verification

Confirm that the actions actually addressed the problem.

26. Why Retraining Alone May Not Be Enough

Training is important, but it is sometimes used as the default CAPA for almost every problem.

Consider a situation where analysts can delete critical electronic records because they have excessive privileges.

Providing another training session does not remove the technical capability to delete the records.

A stronger CAPA might involve:

• Reviewing user roles
• Restricting privileges
• Improving audit trails
• Introducing monitoring
• Revising procedures
• Training personnel
• Verifying effectiveness

The best CAPA usually addresses the root cause, not simply the person who happened to encounter the problem.

27. Roles and Responsibilities

Data integrity works best when responsibilities are clearly defined.

The exact responsibilities will vary from company to company, but accountability should never be ambiguous.

28. Preventive and Detective Controls

A strong data integrity system needs both.

Preventive controls

Try to stop the problem before it occurs.

Detective controls

Identify the problem when it occurs or after it has occurred.

Neither approach is sufficient by itself.

29. Data Integrity Maturity Model

Organizations are often at different stages of maturity.

Level 1 — Reactive

Problems are addressed after an incident or inspection observation.

Level 2 — Basic Compliance

Policies and procedures exist, but the program is primarily compliance-driven.

Level 3 — Controlled

Ownership is defined, systems are assessed and processes are more consistently controlled.

Level 4 — Risk-Based

Resources are focused on critical data and higher-risk vulnerabilities.

Level 5 — Data Integrity by Design

Data integrity is built into processes and systems from the beginning.

At the highest level, the question changes from:

“How do we fix this data integrity problem?”

to:

“How do we design the process so that this problem is unlikely to occur in the first place?”

30. Practical Data Integrity Implementation Roadmap

A company starting or strengthening its program can consider the following sequence.

Phase 1 — Understand the Current State

Develop:

• System inventory
• Process inventory
• Data inventory
• Existing policy/SOP review
• Initial gap assessment

Phase 2 — Assess Risk

Identify:

• Critical data
• Vulnerabilities
• High-risk systems
• Manual processes
• Weak controls

Phase 3 — Remediate

Address:

• Access issues
• Procedural gaps
• System limitations
• Documentation weaknesses

Phase 4 — Strengthen Controls

Implement, where appropriate:

• Audit trails
• Access controls
• Automated interfaces
• Review mechanisms
• Monitoring

Phase 5 — Train

Training should explain not only what employees must do, but also why the requirement exists.

Phase 6 — Monitor

Use:

• Periodic reviews
• Internal audits
• Audit trail review
• Trending
• Exception monitoring

Phase 7 — Improve

Use inspection observations, investigations, CAPA and lessons learned to continuously strengthen the program.

31. Data Integrity Inspection Readiness Checklist

The following checklist can be used as a starting point for internal assessment.

32. Three Practical Pharmaceutical Examples

Example 1 — Deleted Chromatographic Data

A QC analyst obtains an unexpected result and deletes the chromatographic data before reporting the final result.

The first question should not simply be:

“Who deleted the result?”

A proper investigation should also ask:

• Why was the result deleted?
• What does the audit trail show?
• Was the analyst trained?
• Could the system technically permit deletion?
• Were privileges appropriate?
• Was the procedure clear?
• Are other records affected?
• Could product quality be impacted?

The investigation should look at both individual behavior and system/process weaknesses.

Example 2 — Shared LIMS Account

Several analysts use a common LIMS account.

From an operational perspective, the arrangement may appear convenient.

From a data integrity perspective, however, attribution is compromised.

If a result is changed, the organization may not be able to determine which individual made the change.

The solution should normally involve:

• Individual accounts
• Appropriate access roles
• Controlled privileges
• Access review
• Appropriate authentication
• Updated procedures
• Training

Example 3 — Manual Transcription of Manufacturing Data

An operator reads a critical process value from an equipment display and writes it into a batch record.

This creates a potential transcription risk.

If technically feasible, an automated interface may reduce this risk.

However, the interface itself then becomes a GxP system component requiring appropriate assessment, validation/assurance, change control and monitoring.

The lesson is important:

Automation can reduce certain data integrity risks, but it does not remove the need for control.

33. Common Misconceptions About Data Integrity

“Data integrity is an IT responsibility.”

Not entirely.

IT is responsible for important technical controls, but data integrity also belongs to QA, QC, Manufacturing, Validation, Engineering, system owners, process owners and management.

“A validated system is automatically data-integrity compliant.”

Not necessarily.

A system can be validated and subsequently become vulnerable through poor access management, uncontrolled changes, weak procedures or ineffective monitoring.

“Data integrity only applies to electronic systems.”

Incorrect.

Paper records are equally subject to fundamental data integrity expectations.

“If the audit trail exists, everything is fine.”

Not necessarily.

The audit trail needs to be appropriately configured, protected and reviewed.

“Training is the best CAPA for a data integrity problem.”

Training may be necessary, but it is not always sufficient.

Technical and systemic causes must also be addressed.

“Cloud systems are automatically compliant.”

No.

Cloud deployment changes the technical environment; it does not eliminate GxP responsibilities.

“A scanned signature is the same as an electronic signature.”

Not automatically.

The method, controls and applicable requirements need to be considered.

“The final result is correct, so raw data is not important.”

This is one of the most dangerous assumptions.

The final result must be supported by reliable underlying evidence.

34. The Role of Management in Data Integrity

Data integrity cannot be sustained by SOPs alone.

Management decisions have a significant influence on data integrity culture.

For example, employees are more likely to maintain good practices when:

• Workload is realistic
• Systems are fit for purpose
• Employees can report problems without fear
• Quality concerns receive appropriate attention
• Investigations are objective
• Resources are available
• Production pressure does not override quality requirements

Management should also pay attention to recurring signals.

If several departments repeatedly report:

• Manual transcription
• Shared accounts
• Missing records
• Repeated audit trail issues
• Data-related deviations

the organization should ask whether there is a systemic problem rather than treating every event independently.

35. A Practical Data Integrity Framework

A useful way to remember the overall approach is:

Govern → Identify → Assess → Control → Validate → Monitor → Investigate → Improve

Govern

Define ownership, policy and accountability.

Identify

Understand where GxP data is generated and used.

Assess

Identify vulnerabilities and evaluate risk.

Control

Introduce appropriate preventive and detective controls.

Validate

Ensure computerized systems and processes are suitable for their intended use.

Monitor

Check whether controls continue to work.

Investigate

Respond to concerns based on evidence.

Improve

Use lessons learned to strengthen the overall system.

This approach turns data integrity from a one-time compliance project into a continuous quality activity.

36. Final Thoughts

Data integrity is sometimes presented as a collection of rules:

Don’t backdate. Don’t share passwords. Don’t delete data. Review audit trails.

Those rules are important, but they only represent the surface of the issue.

The deeper question is:

Can the organization demonstrate that the data used to make a GxP decision is trustworthy?

That requires more than an SOP.

It requires appropriate system design, effective validation, controlled access, reliable processes, competent people, meaningful review, good documentation practices and a quality culture that does not tolerate manipulation of data.

The strongest data integrity programs are not built merely to survive regulatory inspections.

They are designed so that, when an important question is asked about a batch, a laboratory result, a process or a computerized system, the organization can confidently show:

What happened.

Who performed it.

When it happened.

What data was generated.

What changes occurred.

Who reviewed it.

And why the final decision can be trusted.

That is the real value of GxP Compliance and Data Integrity.

37. Key Takeaways

1. Data integrity is a fundamental component of GxP compliance.
2. Data integrity applies to paper and electronic records.
3. ALCOA+ provides a practical framework for evaluating data.
4. Data integrity must be managed throughout the complete data lifecycle.
5. Data integrity is not solely an IT or CSV responsibility.
6. Critical GxP data should be identified and assessed based on risk.
7. Validation does not eliminate operational data integrity risks.
8. Audit trail availability and audit trail review are different concepts.
9. Individual accountability is important for electronic systems.
10. Raw data and metadata can be essential to understanding the complete record.
11. Manual transcription creates avoidable risk where suitable automation is possible.
12. Cloud/SaaS systems require appropriate supplier and lifecycle controls.
13. Data integrity investigations should assess systemic causes as well as individual actions.
14. Training is important, but systemic problems require systemic solutions.
15. Management commitment is essential to creating a sustainable data integrity culture.

Reliable data is the foundation of reliable pharmaceutical decisions.

38. Frequently Asked Questions

What is GxP Data Integrity?

GxP Data Integrity is the ability to demonstrate that data generated and used in regulated activities remains trustworthy, complete, consistent, accurate and reliable throughout its lifecycle.

What are ALCOA+ principles?

ALCOA+ stands for Attributable, Legible, Contemporaneous, Original, Accurate, Complete, Consistent, Enduring and Available.

Why is data integrity important in GMP?

GMP decisions such as testing, manufacturing, investigation and batch release depend on reliable data. If the data cannot be trusted, the quality decision supported by that data may also be questioned.

Does data integrity apply to paper records?

Yes. The fundamental principles of attributable, contemporaneous, original and accurate documentation apply to paper as well as electronic records.

What is an audit trail?

An audit trail is a system-generated record that helps reconstruct relevant actions performed on electronic records.

Why are shared user IDs a problem?

Shared accounts can make it difficult or impossible to establish which individual performed a particular action, creating an attribution problem.

What is a Data Integrity Risk Assessment?

It is a structured assessment used to identify how GxP data could be lost, altered, deleted, incorrectly processed or otherwise compromised and to determine appropriate controls.

How does CSV support data integrity?

Computerized System Validation or appropriate assurance activities provide evidence that a system is suitable for its intended use. Data integrity controls must then continue throughout the operational lifecycle.

Does an audit trail guarantee data integrity?

No. The audit trail needs to be appropriately configured, protected and reviewed as part of a broader control strategy.

What is testing into compliance?

Testing into compliance generally refers to inappropriate repeated testing or selective reporting intended to obtain or present an acceptable result rather than following the established scientific and quality process for unexpected results.

What is the role of QA in data integrity?

QA provides governance and oversight and plays an important role in risk assessment, investigations, CAPA, audits, procedures and overall compliance.

What are common data integrity warning signs?

Examples include shared accounts, missing raw data, unexplained changes, excessive privileges, backdated entries, pre-signed records, uncontrolled spreadsheets and inadequate audit trail review.

How does data integrity apply to LIMS and MES?

LIMS and MES may contain critical GxP information and therefore require appropriate access control, audit trails, validation/assurance, change control, review and lifecycle management.

What are data integrity risks in cloud/SaaS systems?

Potential concerns include supplier access, data ownership, backup, disaster recovery, upgrades, data migration, availability, retention and retrieval.

How can AI/ML affect GxP data integrity?

AI/ML introduces additional considerations around training data, data provenance, model versions, model changes, output traceability and human oversightRequirements → Risk Assessment → Validation/Assurance → Operation → Monitoring → Periodic Review

39. Regulatory and Industry References

For publication, regulatory references should preferably be linked to the current official source rather than relying on secondary websites.

Key references include:

• US FDA — Data Integrity and Compliance With Drug CGMP: Questions and Answers
• US FDA — Questions and Answers on Current Good Manufacturing Practice Requirements for Laboratory Controls
• MHRA — Guidance on GxP Data Integrity
• European Commission — EU GMP Annex 11: Computerised Systems
• PIC/S — Good Practices for Data Management and Integrity in Regulated GMP/GDP Environments
• ICH Q9(R1) — Quality Risk Management
• 21 CFR Part 11 — Electronic Records; Electronic Signatures
• ISPE GAMP 5 — A Risk-Based Approach to Compliant GxP Computerized Systems

When citing regulatory requirements in a final published version, always verify the current official version and applicable jurisdiction, because regulatory guidance and expectations can change.

Conclusion

The pharmaceutical industry has moved from paper-based processes to increasingly interconnected digital environments. LIMS, MES, electronic batch records, cloud applications, automated laboratory systems and data analytics have created enormous opportunities to improve efficiency and control.

At the same time, they have introduced new ways in which data can be changed, lost, misunderstood or inadequately controlled.

The answer is not simply more procedures.

The answer is to build data integrity into the way pharmaceutical processes are designed, validated, operated and monitored.

When people understand their responsibilities, systems are appropriately designed, access is controlled, data is reviewed intelligently and management genuinely supports a culture of quality, data integrity becomes part of everyday operations rather than an inspection exercise.

Ultimately, the objective is simple:

When a pharmaceutical company makes a quality decision, it should be able to demonstrate that the data behind that decision can be trusted.

That is the essence of GxP Compliance and Data Integrity.

About the Author

Ramesh Palav is a pharmaceutical Quality Assurance and Validation professional with extensive experience in GxP compliance, computerized system validation, data integrity and quality systems. His professional interests include ALCOA+ principles, pharmaceutical data integrity, CSV/CSA, computerized systems, risk management and regulatory compliance. Through his articles, he aims to share practical industry knowledge and help pharmaceutical professionals strengthen quality, compliance and data integrity across the product lifecycle.