Software validation under GxP: what teams have to evidence

“We have to validate the system” is a sentence that triggers panic or a shrug in projects – rarely clarity. Yet the process is easy to describe. This deep dive walks through it step by step: what is planned, tested, documented and released, and what happens afterwards.

1. What exactly is being evidenced

Validation demonstrates that a system is fit for its defined intended use – documented, traceable and in the actual operating environment. Three points follow directly:

• Without a defined intended use, validation cannot be performed, because the reference point is missing.
• Validation happens at the operator, not at the vendor. A product can provide prerequisites, nothing more.
• The evidence applies to one version. After changes it has to be maintained or renewed.

2. The process at a glance

3. The validation plan

The plan is written before testing and defines what counts as evidence. It should contain: scope and boundaries, risk assessment, planned qualification steps, responsibilities, how deviations are handled, supplier assessment, retention and the criteria for release.

A common mistake is too broad a scope. Including everything looks thorough but makes validation expensive and sluggish. A clear boundary – what is not in scope – is as important as the inclusion list.

4. Requirements and specification

Requirements are the reference point for everything else. Marking them by GxP relevance helps: not every requirement is regulatorily significant, and that distinction saves considerable effort. Every requirement needs a stable identifier, a testable wording and a link to design, test and release – see traceability.

5. Qualification: IQ, OQ, PQ

Automated tests cover the OQ area particularly well – provided environment, test data and logging are controlled. PQ usually remains partly manual, because that is where the interplay with people and processes is tested.

6. Deviations and assessment

Deviations are normal. What matters is that they are documented, assessed and decided on – and do not vanish through a quiet adjustment of the test case. A sound approach covers:

• a description of the deviation and the affected test case,
• an assessment of the impact on product quality, patient safety and data integrity,
• a decision: fix and retest, accept with justification, or restrict the intended use,
• approval of that decision by the responsible role.

7. Report and release

The validation report summarises what was tested, with what result, which deviations occurred and how they were assessed. It ends with a clear statement on fitness for the defined intended use – with restrictions where applicable. Release is given by the roles named in the plan, in particular the quality unit acting independently of development.

8. Maintaining the validated state

After release the longer part begins. It includes:

• Change control for every change to system, configuration or environment,
• periodic review at defined intervals – do the processes still run as described, is the evidence still there?
• handling defects and security updates, including assessing their relevance to validation,
• decommissioning with a defined data migration and readability across the retention period.

9. Keeping the effort realistic

Three levers lower the effort without lowering the quality of the evidence:

1. Use the risk basis consistently. Do not test everything to the same depth.
2. Credit the supplier's work instead of re-evidencing standard functions.
3. Generate evidence automatically instead of writing it – see evidence by design.

Checklist: a validation project

Conclusion

Validation is not a documentation project but a testing project with retained results. Define the intended use sharply, plan on a risk basis, credit the supplier's work and generate evidence automatically, and you reach a far more solid result with far less effort.

The expensive part is rarely the testing itself. It gets expensive when requirements are vague, evidence is missing, or the validated state is not maintained after the first update.