25.21 — GxP Computer System Validation

A client asks you to add a field to a form. In your normal world that is twenty minutes and a deployment. Here it is: a change request, an impact assessment, an updated requirement, an updated design document, an updated test script, a test execution witnessed and signed, an updated traceability matrix, a review, an approval, a training update, and a release record.

The instinct is to call this bureaucracy. It is not — or rather, it is bureaucracy only when done thoughtlessly, and doing it thoughtlessly is the industry's most expensive habit. What the rules actually ask for is narrower and more reasonable than what most companies do, and the gap between the two is where a good engineer earns their reputation.

This chapter is what validation genuinely requires, how the modern risk-based approach differs from the old ritual, and how ordinary engineering practice maps onto it.

What validation means, precisely

Validation is documented evidence providing a high degree of assurance that a system consistently does what it is intended to do.

Three words carry the load. Documented — the evidence must exist in a form somebody else can examine years later. Consistently — not once, on a good day. And intended — which means somebody has to state the intention first, in writing, before the system is built or bought.

That last point is why validation starts with requirements. You cannot demonstrate a system does what it should if nobody wrote down what it should do.

The first question: is it even GxP?

Not every system in a life sciences company is regulated, and treating them all as if they were is the most common way validation budgets are wasted.

The assessment asks whether the system creates, modifies, stores or transmits records supporting a GxP activity, and whether a failure could affect patient safety, product quality or the integrity of regulated data.

In scope, almost always: manufacturing execution, laboratory systems, electronic data capture and other clinical systems, safety databases, quality management systems, document management, training records, batch release, environmental monitoring, serialisation.

Out of scope, usually: finance, human resources, marketing, and general office tools — unless they hold GxP records, which is exactly what happens when a spreadsheet on a shared drive starts calculating a release decision.

And the answer is recorded, not assumed. "We decided this was not GxP" is a legitimate position with a written justification, and an indefensible one without.

The chain: specify, build, verify, and prove they line up

The traditional model is drawn as a V, and even where modern practice reshapes it, its logic still governs what evidence must exist.

Down the left side, specifications get progressively more detailed.

The user requirements specification, the URS, is written by the business: what the system must do, in the users' language, each requirement uniquely numbered and testable. "The system shall record the identity of the person performing each step" is a requirement. "The system shall be user-friendly" is not, because nothing can verify it.

Then a functional specification — how the system will meet those requirements — and a design specification for how it is built, configured or customised.

Up the right side, each specification is verified by a corresponding test.

Installation qualification confirms the system is installed correctly in its environment. Operational qualification confirms the functions work as specified, including error handling and limits. Performance qualification, often run as user acceptance testing, confirms it works for the actual business process, with real users and realistic data.

And across the middle sits the traceability matrix: every requirement mapped to its specification and to the test that proves it, and every test mapped back to a requirement. Its purpose is to answer two questions instantly — is every requirement tested, and is every test there for a reason. A requirement with no test is a gap. A test with no requirement is waste. Inspectors read the matrix first because it exposes both.

GAMP 5: the framework everyone actually uses

GAMP 5, published by ISPE and now in its second edition, is not a regulation. It is the industry's practical guide, and regulators are familiar with it, so speaking its language makes conversations shorter.

Its most useful contribution is the software category system, because it determines how much work is justified.

Category	What it is	Validation effort
1	Infrastructure software	Qualify the platform
3	Used as supplied, not configured	Verify intended use
4	Configured to your process	Verify configuration
5	Custom-developed code	Full lifecycle evidence

The principle behind the table is that you verify what you introduced. Nobody tests whether the operating system's file handling works. For a commercial product used as delivered, you test that it does what you need in your environment, and you rely on the supplier's own development and testing — verified through a supplier assessment or audit — for the rest. For configuration you test your configuration. For custom code, everything you wrote is yours to prove.

The second edition leaned much harder on two ideas that matter for modern work.

Critical thinking — decide what to test and how deeply on the basis of risk and knowledge, rather than executing a template because it exists. Regulators have said repeatedly that they want this; it is companies' own internal procedures that usually prevent it.

And explicit support for iterative and Agile development, service providers and cloud platforms, which the earlier editions handled awkwardly.

Risk-based effort, and the guidance that made it official

The idea underneath everything modern is that validation effort should follow risk, and risk here has a specific meaning: what happens to a patient, to product quality, or to data integrity if this function fails and the failure is not detected.

A function that calculates a dose, sets a release decision, or writes an audit trail is high risk. A function that sorts a list or exports a report for internal convenience is not.

The American formalisation of this is Computer Software Assurance. The FDA issued the final guidance, "Computer Software Assurance for Production and Quality System Software", on 24 September 2025, following a 2022 draft, with an updated version issued on 3 February 2026. It applies to software used in production and in the quality system — not to software that is itself a medical device, which follows Chapter 25.16.

What it actually says, in plain terms. Start by identifying the intended use and whether the software's failure could affect product quality or patient safety, directly or indirectly. Apply assurance effort proportional to that risk. Use the testing method that gives the most useful information for the least burden — including unscripted and exploratory testing, ad-hoc testing and error-guessing, which for lower-risk functions can be more revealing than a scripted script. Keep records proportionate: the record of an unscripted test can be a short statement of what was done, who did it, and the outcome, rather than twenty annotated screenshots. And take credit for the supplier's own testing where it is appropriate and assessed.

The guidance also addresses cloud explicitly, covering software delivered as a service and the underlying platforms — which is the question every engineer asks first.

Two implications are worth carrying into client conversations. First, a great deal of what companies do today is not required and never was; it comes from internal procedures written defensively twenty years ago. Second, the guidance does not reduce the requirements around records themselves — assurance effort should focus on the features relevant to record integrity and the Part 11 requirements applicable to those records. Lighter testing of a low-risk feature is supported; lighter controls over a regulated record are not.

The paperwork, and what each document is for

A validation package for a substantial system typically contains the following, and knowing why each exists prevents you from producing it as ritual.

Validation plan — scope, approach, roles, deliverables, acceptance criteria, and who signs. Written and approved before work starts, because a plan written afterwards proves nothing.

Risk assessment — what could go wrong, its impact, and how the testing effort is distributed accordingly.

Specifications — as above.

Supplier assessment — evidence that the vendor's development and support practices are adequate, from a questionnaire for low-risk products up to an on-site audit for critical ones.

Test protocols and executed evidence — pre-approved, executed with dated signatures, with any failure recorded as a deviation and resolved rather than quietly re-run.

Traceability matrix.

Validation summary report — what was done, what deviations occurred, what remains open, and a clear statement that the system is fit for its intended use.

And release for use, after which the system is live and every change goes through change control (Chapter 25.17).

Then the parts everyone forgets until an inspection. Periodic review — a scheduled reassessment, typically every one to three years depending on risk, asking whether the system is still validated: what changed, what incidents occurred, whether the user list is still correct, whether the audit trail is being reviewed, whether the supplier is still supported. And decommissioning — a system may be switched off, but its records must remain retrievable for their full retention period, which for clinical and manufacturing data can be decades. Data migration and archive readability are validation activities in their own right, and they are the single most neglected part of the lifecycle.

Doing this with modern engineering practice

The honest position is that Agile development and continuous delivery are entirely compatible with validation, and that most of the friction comes from procedures rather than regulations. Here is how the mapping works in practice.

Requirements live in your backlog, not in a separate document. A user story with acceptance criteria is a requirement, provided it is uniquely identified, versioned, approved by the business, and traceable. The tool becomes part of the regulated system, which means the tool itself needs controlled access, audit trail and a qualification appropriate to its role.

Testing evidence can be automated. An automated test that runs on every build produces better evidence than a human clicking through a script once a year — provided the test framework is qualified, the results are retained, and it is clear which version of the code the results belong to. This is the strongest argument you can make to a sceptical quality group, and it is now well supported by both GAMP and the assurance guidance.

Definition of done includes the evidence. A story is not finished when the code works; it is finished when the requirement, the test, the result and the traceability exist. Retrofitting evidence at the end of a project is what makes validation feel like an obstacle.

Releases are gated by electronic approvals, which your pipeline can enforce and record — with the approval itself meeting the signature requirements of Chapter 25.20 when it is signing a regulated release.

And infrastructure as code is a gift to qualification, because the environment's configuration is itself a versioned, reviewable, testable artefact rather than something reconstructed from memory.

The one thing that does not translate is speed of change without assessment. Every change to a validated system needs an impact assessment before it ships. That assessment can be fast, proportionate and largely automated for low-risk changes — but it cannot be absent, and a pipeline that deploys without it is the problem, not the solution.

Cloud and vendors: who is responsible for what

A client will ask whether a cloud service is "validated". The correct answer is that no service is validated in the abstract — validation is always against an intended use, which the provider does not know.

What is true is a division of responsibility. The provider qualifies its infrastructure and can supply evidence — certifications, audit reports, qualification summaries. The regulated company remains responsible for the intended use, the configuration, the data, access control, and the overall validated state. That responsibility cannot be transferred by contract, exactly as in Chapter 25.9.

So what you need from a vendor is concrete: their development and testing evidence, their change notification process, their incident and backup arrangements, their data export and retention terms, their audit rights, and their support for the record controls of Chapter 25.20. A vendor who cannot describe how a customer reviews the audit trail is not ready for this market, whatever their certifications say.

The traps, listed

These are the mistakes that make validation expensive and useless at the same time.

Testing the vendor's product instead of your use of it. Category 3 and 4 software does not need its internals re-proved.

Screenshot theatre — hundreds of annotated images proving that a button is where the specification said it would be, while the calculation that decides a batch release is tested once.

Requirements written after the system is built, which produces a traceability matrix that traces nothing.

Big-bang validation at the end of a two-year project, discovering the requirements were wrong when it is most expensive to find out.

Uncontrolled spreadsheets, the single most common regulated system in the industry and the least often validated.

And the "validated forever" fallacy — treating a validation report as a permanent certificate rather than a statement about a system that is now drifting through changes, patches, new users and new integrations. Validation is a state to be maintained, which is precisely why change control and periodic review exist.

Next: Chapter 25.22, what happens after a product reaches patients — pharmacovigilance, the reporting clocks, and the largest outsourced function in the entire industry.