GxP-compliant software without the overhead: risk-based validation

In pharma, MedTech and care delivery, software that supports GxP-relevant processes must be validated. Many teams experience this as an end in itself: test scripts, signatures, evidence for every function, and with each small change the mountain of paperwork starts over. The way out is not an exception to the rule but the rule itself — the risk-based approach the relevant guidelines have described for years.

What validation really requires

GxP stands for the good practices of the regulated world — good manufacturing practice (GMP), for instance. Computerised system validation (CSV) is the documented evidence that a system is fit for its intended use and reliably does what it is meant to do. The measure is fitness for purpose, not completeness for its own sake. Testing every conceivable function to the same depth confuses volume with assurance — and ties up time that is then missing at the critical points. The question is never “how much can we document?” but “what must be evidenced for us to rely on the system?”.

The risk-based approach is the standard, not the exception

ISPE’s GAMP 5 guide (Second Edition, 2022) is built entirely on this idea. It scales the assessment effort to the risk, follows quality risk management under ICH Q9, and puts critical thinking, patient safety and product quality at the centre — not the mere avoidance of audit findings. The GAMP software categories reflect this: non-configured standard software needs less first-party evidence than configured systems, and those need less than custom development.

EU GMP Annex 11 “Computerised Systems”, in force since 2011, expressly anchors risk management across the entire lifecycle of a system. The draft revision released for consultation in 2025 (consultation until October 2025, final version still pending) sets out risk management and the quality system more firmly still and aligns with GAMP 5. Both versions carry the same core message: effort may, and should, follow the risk.

An example: two systems, two depths

A spreadsheet macro that computes a figure for an internal report and a system that controls batch release are not to be treated alike. For the first, lean evidence that it calculates correctly and is protected against accidental change is enough. For the second, where an error touches product quality or patient safety, deep assessment is appropriate. Laying the same scope of testing over both creates overhead for one and a false sense of security for the other. The dividing line follows not from the technology but from what an error would, at worst, set in motion.

How to proceed: let the effort follow the risk

1. Set down the intended use and GxP relevance: what does the system do, and which decision or data point depends on it?
2. Assess the risk — following ICH Q9: what happens on a malfunction, how likely is it, how well could it be detected?
3. Determine the software category under GAMP 5: standard, configured or custom — the greater the bespoke share, the more evidence required.
4. Align testing depth and evidence with that, and use the supplier’s work rather than repeating it.
5. Document only what carries the evidence — traceable, not as extensive as possible.

The US authority, the FDA, takes the same route. Its guidance “Computer Software Assurance” (final version 2025) places risk-based assurance above mere documentation and permits less burdensome forms of testing where the risk is low. Internationally, regulation is moving in the same direction.

Where this does not apply

Risk-based does not mean “less validation” but “effort where it carries”. Where the risk is high — a direct effect on product quality, patient safety or data integrity — the depth of assessment stays high; cutting corners here would be negligent. The approach does not replace the quality system either: without clean requirements, change control and supplier assessment it has no foundation. And it does not release you from data integrity — lean evidence is not incomplete evidence. Where a supervisory authority expects more in a given case, its standard applies.

Conclusion

GxP compliance and lean processes are not mutually exclusive. Assess the risk honestly and align the effort with it, and you meet the expectations of the guidelines while keeping documentation manageable. The mountain of paperwork arises not from the rules, but from the refusal to apply them in a risk-based way.