GxP in pharma is shorthand for the good-practice regimes (manufacturing, laboratory, clinical, distribution and others) that regulate medicines work. For software, GxP compliance rests on two expectations. Regulators expect GxP data and records to be attributable, legible, contemporaneous, original, accurate, complete, consistent, enduring and available (ALCOA+). They also expect each computerised system to be validated for its intended use and maintained in a validated state. The requirements below apply those two ideas in more detail: data integrity, and validation scaled to risk and kept current after go-live.

Whether a particular system falls inside GxP scope is a separate question, covered in our piece on what counts as a GxP system. This article starts from a system that is in scope and asks what compliance demands of it.

What GxP compliance requirements look like for a computerised system

PIC/S lists the areas where GxP compliance evidence is essential for computerised systems: data capture and integrity, data filing and processing, networks, process control and monitoring, electronic records, archiving, retrieval, printing, access, change management, audit trails, and decisions tied to any automated GxP activity. Grouped by the question an inspector asks, the requirements look like this.

Requirement	What the system and its owners must show	Where regulators state it
ALCOA+ data integrity	Records are attributable, legible, contemporaneous, original, accurate, complete, consistent, enduring and available across the whole data lifecycle	MHRA 2018, WHO TRS 1033 Annex 4, PIC/S PI 041-1
Audit trail	A secure record of creation, modification and deletion that captures who, what, when and why without obscuring the original	MHRA 2018, WHO 2021
Individual access	No shared logins for systems that generate, amend or store GxP data; access matched to job role	MHRA 2018, FDA 2018 Q&A
Validation for intended use	Documented evidence, scaled to complexity and risk, that the system works in the user’s own process	MHRA 2018, EU Annex 11
Controlled change	Changes, including configuration changes, made only through a defined procedure	EU Annex 11
Periodic evaluation	Regular confirmation that the system remains valid and GMP-compliant	EU Annex 11, PIC/S PI 041-1
Documentation	Controlled, versioned lifecycle documents available for inspection	PIC/S PI 011-3

ALCOA+, audit trails and access: the data integrity core

The FDA defines data integrity in its 2018 CGMP question-and-answer guidance as the completeness, consistency and accuracy of data, which should be attributable, legible, contemporaneously recorded, original or a true copy, and accurate. MHRA’s 2018 guidance adds the “+” attributes (complete, consistent, enduring, available) and is explicit that the expectation is the same whichever acronym a company uses. It is better read as a set of design requirements, because each attribute maps onto something the software has to do.

Attributable, per WHO, means data traceable to an individual, for example through unique user logons or electronic signatures. Contemporaneous means electronic data are automatically date- and time-stamped at the moment they are generated. The FDA gives a concrete case: chromatographic data should be saved to durable media after each step or injection, not at the end of an injection set. For enduring and available data, WHO notes that electronic data are normally only readable through the original application, sometimes only a specific version of it.

What audit trails have to do

An audit trail is metadata that records creation, additions, deletions and alterations of a GxP record without obscuring or overwriting the original, so the history can be reconstructed, including the “who, what, when and why” of each action. MHRA expects changes to be dated and time-stamped (with time zone where applicable) and the reason for the change recorded. Audit trails identified as required by risk assessment should be switched on, users should not be able to amend or switch them off, and if an administrator does so a record of that action should be retained.

WHO goes a step further: GxP-relevant audit trails should be enabled at installation, there should be evidence of enabling them, and their continued enablement should be verified periodically. Having an audit trail is not enough on its own. EU Annex 11 expects audit trails to be convertible to an intelligible form and regularly reviewed. WHO ties review frequency to the criticality of the system and the category of audit trail information.

Access and segregation of duties

The FDA states that when login credentials are shared, a unique individual cannot be identified and the system does not conform to the CGMP requirements in parts 211 and 212; shared read-only accounts are acceptable only for viewing data. PIC/S expects role-based access on a least-privilege basis and no administrator rights for normal users. Systems should be able to produce a list of users and their roles for periodic access reviews. One shared “admin” login undoes attribution for every privileged action, including the audit trail settings themselves.

Does 21 CFR Part 11 apply to our system?

Part 11 applies to electronic records that are created, modified, maintained, archived, retrieved or transmitted under any FDA records requirement, and to electronic records submitted to the agency. The FDA’s scope and application guidance then narrows that. It says the agency interprets Part 11 narrowly and will exercise enforcement discretion over the Part 11 requirements for validation, audit trails, record retention and record copying, while still enforcing the underlying predicate rules.

The practical test is whether a record is required by a predicate rule (the GMP, GLP or GCP regulation itself) and whether you keep it electronically in place of paper, or keep it in both forms but rely on the electronic version to perform regulated activities. The guidance also notes that actual business practice can decide whether you are using electronic records instead of paper. Keeping a paper printout does not take a record out of scope if the electronic version is relied on to perform regulated activities.

Enforcement discretion does not make Part 11 controls optional. The FDA states it will continue to enforce, among others, limiting system access to authorised individuals, operational, authority and device checks, training of the people who develop, maintain or use the systems, written accountability for electronic signatures, controls over systems documentation, and the electronic signature requirements. Validation does not disappear either: the guidance says firms must still meet predicate rule validation requirements, and recommends basing the decision to validate, and its extent, on a justified, documented risk assessment of the system’s effect on product quality, safety and record integrity.

The FDA’s 2018 data integrity guidance still points to this scope document as current thinking pending the agency’s re-examination of Part 11.

How much validation is enough? Scale it to complexity and risk

Validation effort should follow the system’s complexity and risk. MHRA puts this plainly: simple electronic systems with no configurable software and no electronic data retention (pH meters, balances, thermometers) may only need calibration, while complex systems require validation for intended purpose, with effort rising according to software functionality, configuration, the opportunity for user intervention and data lifecycle considerations. The FDA’s 2018 Q&A treats a CGMP workflow, such as creating an electronic master production and control record, as an intended use to be checked through validation, with the extent of validation commensurate with the risk posed by the automated system. EU Annex 11 asks for risk management across the lifecycle, taking patient safety, data integrity and product quality into account when deciding the extent of validation.

FDA’s General Principles of Software Validation (2002) defines validation as confirmation, through objective evidence, that software specifications conform to user needs and intended uses and that the requirements implemented in software can be consistently fulfilled. That definition makes the requirements specification the baseline: the same guidance says validation cannot be completed without an established software requirements specification. EU Annex 11 expects user requirements to be based on documented risk assessment and GMP impact, and traceable through the lifecycle. That is where validation parts from verification testing (see validation vs verification): a test pack without traced user requirements does not establish fitness for intended use.

The FDA says testing alone will not get you there. Its 2002 guidance states that the complexity of most software prevents exhaustive testing, and that testing by itself is in most cases not sufficient to establish confidence that software is fit for its intended use; a mix of defect prevention and detection methods is needed. Risk ranking is how that mix gets prioritised: PIC/S asks for validation scope to rank GxP criteria by product quality and data integrity criticality, so attention goes to the systems and features with the highest potential for harm if they fail.

The industry framework for doing this is ISPE’s GAMP 5, now in a second edition, which presents a risk-based approach to compliant GxP computerised systems and updates it for service providers, iterative development and greater use of software tools and automation. The second edition also discusses FDA’s Computer Software Assurance work and links to ISPE guidance on data integrity.

Does off-the-shelf software or a spreadsheet need validating?

Yes, when it is used for a GxP purpose, though the effort should match its risk. The FDA’s 2002 guidance, written for medical device production and quality system software, states that such software, even if purchased off the shelf, should have documented requirements defining its intended use against which test results can be compared. The same guidance says an off-the-shelf operating system need not be validated as a separate program, but system-level testing of the application should cover the operating system services it uses.

A commercial product does not arrive validated for your intended use. MHRA states that accepting vendor-supplied validation data in isolation from system configuration and the user’s intended use is not acceptable, because vendor testing outside the real process and IT infrastructure is likely to be limited to functional verification. Spreadsheets fall under the same logic. MHRA expects electronic worksheets used in automation to be version controlled, with changes documented and verified. WHO lists validation and control over formulae for calculations among the controls for critical data. For a spreadsheet that calculates a release result, its formulae, locking and versioning fall within the validation scope.

Who owns the validation evidence when a supplier built the software?

The regulated company does. PIC/S PI 011-3 states that regulated users have ultimate responsibility for ensuring documented validation evidence is available to GxP inspectors. FDA’s 2002 guidance makes the same point for device manufacturers: regardless of contractual arrangements or who supplied the components, the manufacturer retains ultimate responsibility for ensuring the software is validated. PIC/S also leaves performance qualification with the regulated user: acceptance testing in the operating environment against a user requirements specification that covers the controlled pharmaceutical process, not only the software.

The evidence an inspector reads (traced requirements, risk assessment, test records, change history) is an engineering output. TechnoLynx builds this validation evidence as engineering output through AI engineering for life sciences and healthcare, not as policy advice or certification.

Supplier quality still matters to the assurance of the software. PIC/S attributes the reliability of a supplier’s software to the quality of its engineering processes (design, coding, verification testing, integration, change control) and expects customers to evaluate that methodology, with a documented supplier audit where more assurance is needed. For cloud or virtual services, MHRA expects attention to data ownership, retrieval, retention and security, a technical agreement ensuring timely access to data, metadata and audit trails for the data owner and regulators, and arrangements to restore the system to its original validated state.

Staying validated after go-live: change control and periodic evaluation

Once a system is validated, any change means its validation status needs to be re-established. EU Annex 11 requires that any change to a computerised system, including configuration changes, be made only in a controlled manner under a defined procedure. It also requires periodic evaluation to confirm the system remains in a valid state and GMP-compliant, covering where appropriate the current range of functionality, deviation records, incidents, problems and upgrade history.

FDA’s own data show the risk that changes carry. Its 2002 guidance reports that of 3,140 medical device recalls analysed between 1992 and 1998, 242 (7.7%) were attributable to software failures, and 192 of those (79%) came from defects introduced by changes made after initial production and distribution. Those figures come from medical devices, not pharma manufacturing systems, but the mechanism carries over: the FDA notes that a seemingly small local change can have a significant global impact, so a validation analysis should assess the change’s effect on the whole system and drive an appropriate level of regression testing.

What a change control record should contain

PIC/S PI 011-3 sets out what a formal change control procedure should record:

1. The proposed change and the reasoning for it.
2. System status and the impact on controls before the change is made.
3. How the change is reviewed and authorised.
4. The review outcome (approval or rejection).
5. How the change status of documentation is shown.
6. How the full impact is assessed, including regression analysis and regression testing as appropriate.
7. How change control interfaces with configuration management.

Security patches fall under change management too. PIC/S PI 041-1 expects operating system and network patches to be applied in a controlled, timely manner under change management principles. Upgrades carry a data integrity risk of their own: when system software is installed or updated, the user should confirm existing and archived data can still be read, converting it or keeping the old software available where needed.

Periodic evaluation checklist

PIC/S PI 041-1 describes periodic evaluation as a check that data integrity controls still work, with frequency set by risk and by the cumulative effect of changes since the last review. Drawn from that guidance and its regulator counterparts, a periodic review of a GxP system should confirm:

• deviations, changes (including their cumulative effect), upgrade history, performance and maintenance have had no detrimental effect on data integrity controls;
• audit trails that should be enabled are still enabled;
• the user list, with names and roles, has been used in a periodic user review;
• backup and restoration still work, verified by periodic restores for completeness and accuracy of data and metadata;
• a risk-based sample of system logs and audit trails shows GMP/GDP-relevant information is reported accurately.

The European Commission’s 2025 consultation drafts a revised Annex 11 with stronger lifecycle and supplier oversight requirements, and a new Annex 22 foreseeing continuous oversight of AI systems (change control, model performance monitoring, human review), the ground covered by AI/ML validation and retraining control under GAMP 5.

A validated system still needs data integrity controls

Validation alone does not guarantee that records are adequately protected. MHRA warns that using a validated system may lower but not eliminate data integrity risk, and that where people influence what data is recorded, reported or retained, over-reliance on the system’s validated state can increase risk. PIC/S PI 041-1 makes the same point from the other side: validated systems can still lose or alter records by accidental or malicious means, so validation should be supplemented by administrative and physical controls and user training.

A validation package shows the system performed satisfactorily when it was tested. Showing that it still does, and that the people around it have not routed around its controls, is the job of audit trail review, access reviews and periodic evaluation.

FAQ

What is GAMP 5 in pharma?

GAMP 5 is ISPE’s guidance for a risk-based approach to compliant GxP computerised systems, aimed at systems that are fit for intended use and compliant with applicable regulations. Its second edition adds material on service providers, evolving approaches to software development and FDA’s Computer Software Assurance work.

What does CSV stand for in the pharmaceutical industry?

CSV stands for computer system validation (or computerised system validation in EU usage): the documented process of showing a computerised system is fit for its intended GxP use.

What is the goal of validation?

The FDA defines software validation as confirmation, by examination and objective evidence, that specifications conform to user needs and intended uses and that the implemented requirements can be consistently fulfilled.

What criteria are used to assess data integrity risk?

PIC/S PI 041-1 uses two: data criticality (impact on decisions and product quality) and data risk (the opportunity for alteration or deletion, and how likely routine review is to detect it). Control measures are then set in proportion to both.