GLP and GMP Compliance Requirements for Laboratory Software

Understanding the Regulatory Landscape

Good Laboratory Practice (GLP) and Good Manufacturing Practice (GMP) are regulatory frameworks that govern different stages of the product lifecycle. GLP applies to non-clinical safety studies used to support regulatory submissions, while GMP governs the manufacturing of pharmaceuticals, medical devices, and similar products. Both have significant implications for the software systems used in these environments.

Understanding where your organization falls on this spectrum determines which requirements apply and how stringently they must be implemented.

GLP Requirements for Software

GLP regulations (21 CFR Part 58 in the US, OECD Principles of GLP internationally) focus on the integrity of non-clinical study data. Software used in GLP studies must support several core principles.

Study Reconstruction

The fundamental GLP requirement is that a study can be fully reconstructed from its records. For software, this means:

• Every data point must be traceable to its source (instrument, observer, calculation)
• The complete history of data modifications must be preserved
• Study protocols, amendments, and deviations must be linked to the data they affect
• Raw data, whether captured electronically or on paper, must be preserved in its original form

Standard Operating Procedures

All computer systems used in GLP studies must be covered by SOPs that describe:

• System operation and intended use
• Data entry and modification procedures
• Backup and recovery procedures
• Security and access controls
• Change control processes

These SOPs must be current, approved, and available to all users.

System Validation

GLP requires that computerized systems be validated for their intended purpose. The validation must demonstrate that the system:

• Performs accurately and reliably
• Can distinguish valid from invalid data
• Maintains the integrity of data throughout its lifecycle
• Has adequate security controls

Proportionate approach: The depth of validation should match the risk. A system calculating study results requires more rigorous validation than one used for scheduling.

Quality Assurance Oversight

The GLP Quality Assurance (QA) unit must have access to inspect computer systems and their associated records. This means:

• QA must be able to review audit trails independently
• System access for QA must be read-only but unrestricted in scope
• QA should be included in the review process for system changes that affect data integrity

GMP Requirements for Software

GMP requirements for software are defined primarily through EU Annex 11 (Computerised Systems) and FDA guidance on 21 CFR Part 11. They are generally more prescriptive than GLP requirements.

EU Annex 11 Key Requirements

Risk management. A risk assessment must be performed throughout the lifecycle of the computerised system, taking into account patient safety, data integrity, and product quality.

Validation. Computer systems must be validated before use. The validation documentation must cover the entire lifecycle, including change control.

Data. Built-in checks for correct and secure data entry must be implemented. Critical data entered manually requires an additional check by a second person or validated electronic means.

Accuracy checks. For critical data, the means of verifying accuracy must be documented.

Data storage. Regular backups must be taken. Data must be secured by both physical and electronic means against damage. Stored data must be checked for accessibility, readability, and accuracy.

Printouts. It must be possible to obtain clear printed copies of electronically stored data.

Audit trails. Consideration should be given to building into the system the creation of a record of all GMP-relevant changes and deletions (a system-generated audit trail). Changes and deletions must be documented with a reason.

Practical GMP Controls

Electronic batch records must capture every step of the manufacturing process with operator identification and timestamps.

Process parameters collected by automated systems must be validated for accuracy and protected from unauthorized modification.

Deviation management systems must track manufacturing deviations from entry through investigation, root cause analysis, and corrective action.

Overlapping Requirements

Several requirements appear in both GLP and GMP contexts. Getting these right covers significant ground:

Audit Trails

Both frameworks require comprehensive audit trails. Implement trails that capture:

• Who made the change (individual user identification)
• When the change was made (synchronized, reliable timestamps)
• What was changed (previous value, new value, which record/field)
• Why it was changed (user-entered reason, mandatory for result modifications)

Audit trails must be tamper-proof. No user role should be able to modify or delete audit trail entries.

Access Controls

Individual user accounts with role-based permissions. Shared accounts are unacceptable under both GLP and GMP. Implement:

• Unique user identification
• Password policies (complexity, expiration, lockout)
• Session timeout for inactive users
• Privileged access management for administrative functions

Backup and Disaster Recovery

Both frameworks require data preservation. Your backup strategy must include:

• Regular automated backups with verification
• Off-site storage for disaster recovery
• Documented and tested recovery procedures
• Retention aligned with regulatory requirements (often 15+ years for GLP study data)

Change Control

Any modification to a validated system must go through a formal change control process:

1. Change request with description and justification
2. Impact assessment covering functionality, data integrity, and validation status
3. Approval before implementation
4. Testing to verify the change works as intended
5. Documentation of the completed change
6. Re-validation if the impact assessment requires it

Common Compliance Gaps

Based on regulatory inspection findings, the most frequent gaps include:

• Audit trails disabled or incomplete for performance or convenience reasons
• Shared user accounts used for system administration or after-hours access
• Inadequate change control with system updates applied without formal assessment
• Missing or outdated SOPs that do not reflect current system capabilities
• Validation gaps where initial validation was performed but periodic review and re-validation after changes were neglected

Building Compliance Into New Systems

When selecting or developing software for GLP or GMP environments:

1. Include compliance requirements in your user requirements specification from the start
2. Evaluate vendor capability to support your regulatory environment (audit trail, e-signatures, validation documentation)
3. Plan validation as part of the implementation project, not an afterthought
4. Establish change control procedures before the system goes live
5. Train all users on both the system operation and the regulatory context

Bottom line: GLP and GMP compliance in software is not about checking boxes. It is about building trustworthy systems where data integrity is demonstrable at every point. Start with audit trails and access controls, validate proportionately, and maintain the system's compliance state through disciplined change control.