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 lives.
What "risk-based" actually means
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; it is a failure to prioritise, and it dilutes 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
One of the largest sources of waste is re-testing what the supplier has already tested. 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
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
A proportionate approach is not a lighter one where it counts. Some things stay non-negotiable regardless of how the risk assessment came out:
- Requirements that are specific enough to test. "The system shall be user-friendly" cannot be verified and should not survive review.
- Traceability from requirement to test, so coverage is demonstrable rather than asserted.
- Evidence that the data integrity controls work — audit trail, electronic signature, access control — because these are what an inspection tends to open with.
- 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
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 a 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.
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.
