Computerised system validation without the paperwork spiral

Validation has a reputation problem in manufacturing, and it is largely deserved. Ask an engineer what CSV means in practice and you will often get a description of a document set rather than of an activity: protocols written to a template, screenshots of every field, a signature page thicker than the test it certifies.

That is not what the guidance asks for. GAMP 5 is explicit that effort should be proportional to risk, complexity and novelty — and that critical thinking, not volume, is what makes a validation defensible. The gap between that principle and common practice is where most of the cost sits.

What "risk-based" actually means

Closing that gap starts with being clear about which risk is meant. Risk here is patient risk, product quality and data integrity — not project risk. A function that calculates a dispensing quantity carries risk. A function that lets a user change the colour of a chart does not. Testing both to the same depth is not thoroughness; in practice it is a failure to prioritise, and it pulls attention away from the parts that matter.

Applied properly, this changes the shape of the package. High-risk functions get detailed specification, thorough testing and explicit traceability. Low-risk functions get proportionate coverage. The saved effort goes into the areas an inspector will actually probe.

A validation package that treats every function as equally critical tells an inspector that nobody assessed which ones were.

Leverage the supplier instead of re-testing them

The risk assessment says what deserves testing. The second question is who has already tested it. One of the largest sources of waste is re-testing what the supplier has already tested, and GAMP 5 anticipates this: where a supplier has a mature quality system and can evidence its own development and testing, that evidence can be leveraged rather than duplicated.

That leverage has to be earned, not assumed. A supplier assessment worth relying on establishes:

• whether there is a documented development lifecycle, and evidence it is followed
• how changes are controlled, tested and released
• what the supplier tests, and whether that testing is retained and auditable
• how defects are tracked, and how customers are notified of the ones that matter

Where the answers are good, your testing concentrates on configuration and on your own process. Where they are not, you test more — and you now have a documented reason for doing so, which is itself a stronger position than testing everything by default.

Test the process, not the software

With scope set by risk and by the supplier, what remains is how to test what is left. The most useful validation testing exercises the intended use, not the feature list. A protocol that confirms a field accepts numbers tells you little. A protocol that runs a representative batch through the system — including a deliberate out-of-range value, a corrected entry, and a second-person review — tells you whether the process is actually enforced.

This is also where the architecture shows. If in-process values arrive from a process historian with their origin timestamp rather than being typed, a whole class of transcription test cases stops being necessary — the failure mode has been removed rather than tested for.

What risk-based does not excuse

None of this is licence to go lighter where it counts. A proportionate approach is not a lighter one on the critical parts, and some things stay non-negotiable regardless of how the risk assessment came out:

1. Requirements that are specific enough to test. "The system shall be user-friendly" cannot be verified and should not pass review.
2. Traceability from requirement to test, so coverage is demonstrable rather than asserted.
3. Evidence that the data integrity controls work — audit trail, electronic signature, access control — because these are what an inspection tends to open with.
4. A documented rationale for the scope you chose. The decision to test less is defensible; an undocumented decision to test less is not.

Validation does not end at go-live

Even a proportionate, well-justified package only holds while the system stays in the state it was validated in. The validated state is a condition to be maintained, not a milestone to be passed. Most findings in this area are not about the original package at all — they are about what happened afterwards: a configuration changed without assessment, a supplier patch applied without regression testing, a periodic review that was scheduled and never performed.

Systems help here in a way that documentation cannot. A hash-chained audit trail of configuration changes turns "we control changes" from a claim in an SOP into something an inspector can inspect. Role-based permissions make the access control statement verifiable rather than aspirational.

Where to start if the current approach is too heavy

Do not begin by rewriting templates. Begin with one system and one honest risk assessment, and see how much of the existing package that assessment would have justified. The answer is usually uncomfortable, and it is the most persuasive argument available for changing the approach.

From there, the scope question fits naturally into the phases of a digitisation roadmap, and the systems most often in scope — the electronic batch record among them — belong to a wider digital compliance posture rather than to a one-off validation exercise.