Risk-based validation: how much testing is enough?

"How much testing is enough?" is the question that decides the cost and the quality of almost every computerised system validation. Regulators do not give a number. They ask you to justify your answer with a documented risk assessment. This article shows what the main texts say, where the pressure points are, and how to write a justification that holds up.

What the rules ask for

The current EU GMP Annex 11 (2011) states the principle in its first clause. Risk management should be applied throughout the lifecycle of the computerised system, taking into account patient safety, data integrity and product quality. Decisions on the extent of validation and data integrity controls should be based on a justified and documented risk assessment (Annex 11, clause 1). Clause 4.1 repeats the point for the project phase: manufacturers should be able to justify their standards, protocols, acceptance criteria, procedures and records based on their risk assessment.

Notice the two words that carry the weight: justified and documented. The rule does not say "test less". It says that whatever you decide, you must be able to explain it to an inspector from a written record.

The US rule for finished pharmaceuticals points the same way. 21 CFR 211.68(b) says that the degree and frequency of input and output verification shall be based on the complexity and reliability of the computer or related system.

Complexity and criticality, in the regulators' words

The UK MHRA's data integrity guidance gives two useful tests. First, data criticality: it may be determined by considering how the data is used to influence the decisions made (section 4.1). Second, inherent risk: the risks to data are determined by its potential to be deleted, amended or excluded without authorisation, and by the opportunity to detect that happening (section 4.2).

The same guidance draws a clear line on proportionality. Simple electronic systems with no configurable software and no electronic data retention, such as pH meters, balances and thermometers, may only require calibration. Complex systems require validation for intended purpose, and validation effort increases with complexity and risk (section 4, page 6). So "how much testing" has a floor and a ceiling, and where a system sits between them depends on what it does and how configurable it is.

What the draft Annex 11 adds

A revised Annex 11 was released for consultation by the European Commission and PIC/S between 7 July and 7 October 2025. The consultation is closed, and as of 9 November 2026 the Commission's EudraLex Volume 4 page still lists the 2011 text as the current Annex 11. The revision is therefore a draft, and nothing in it is a requirement today. It shows where inspectors' thinking is heading, so it is worth reading.

The draft makes risk management more explicit about test depth:

The validation strategy and effort should be determined by the intended use of the system and the potential risks to product quality, patient safety and data integrity (draft section 4.3).
The scope and extent of qualification and validation should rest on a justified and documented risk assessment of individual requirements, not only of the system as a whole (draft section 9.2).
Increased focus should go on key functional requirements, on functionality that makes sure activities are carried out according to GMP, and on functionality designed to ensure data integrity. The list includes access privileges, audit trails, calculations, error handling, boundary and negative testing, and restore from backup (draft section 9.6).

The draft also says evidence should take the form of executed test scripts and, where relevant, screen dumps (draft section 9.4). That matters for the next section, because it means a risk-based approach under the EU draft is not a licence to skip evidence.

A model of the thinking: FDA's software assurance guidance

In February 2026 FDA issued final guidance on computer software assurance for production and quality management system software. Its scope matters: it covers computers and automated data processing systems used in the production or quality management system for medical devices. It is not a pharmaceutical GMP guidance, and it does not replace Annex 11 or 21 CFR Part 211 for drug manufacturers. It is still the clearest regulator-written description of risk-based assurance, so it is useful as a model for the way of thinking.

Its main ideas are these:

Assurance is a risk-based approach to establishing and maintaining confidence that software is fit for its intended use, and the burden of validation should be no more than necessary to address the risk (section V).
It describes a feature as high process risk when failure to perform as intended may result in a quality problem that foreseeably compromises safety. Examples include functions that determine whether product is acceptable with limited or no additional human review (section V).
For high process risk functions, manufacturers may choose more rigour, such as scripted testing or a mix of scripted and unscripted testing. For functions that are not high process risk, unscripted methods such as scenario testing, error-guessing or exploratory testing may be suitable (section V).
The choice is not mechanical. The guidance says unscripted testing may suit even a high-risk function, and that automated scripted testing may be efficient for a low-risk one.
Manufacturers may take account of validation work done by suppliers and other entities, after a risk-based assessment of the vendor.

Put the EU draft and the FDA guidance side by side and a consistent message appears. Effort follows risk, and you must be able to show your reasoning. The sources differ on how much of the evidence has to be scripted, so check what your regulator and your own procedures require before you copy a method from a different sector.

Where the risk assessment goes wrong

In my experience, people do not use the impact assessment and risk analysis properly. The assessment is completed as a form, filed, and then ignored when the test plan is written. The test plan ends up following habit: the same protocol template and the same number of test cases for every system, or the most effort on the system that is most visible to management.

A real risk assessment changes the test plan. If it says a function has no effect on product quality, patient safety or data integrity, that function gets lighter testing, and the saving is spent where the assessment says the risk is highest. If the assessment and the plan could be swapped between two very different systems without anyone noticing, the assessment is not doing its job.

Turning a risk ranking into a test approach

Our CSV 101 course teaches this in the Project phase of the lifecycle (Concept, Project, Operation, Retirement). The risk assessment looks at four areas: system process, system security, data integrity and regulatory compliance. Functions with a direct effect on patient safety, product quality or data integrity are tested with scripted, formally approved protocols. Functions with low GxP impact can be verified with unscripted testing by a qualified subject matter expert. A simple version looks like this:

What the function or system does	Reasonable starting approach
Simple instrument with no configurable software and no data retention	Calibration and a documented rationale (MHRA, section 4)
Low GxP impact function in a larger system	Lighter, unscripted testing by a qualified person, with a short record of what was done and why
Function that affects product quality, patient safety or data integrity	Scripted, approved protocol with traceable requirements and recorded results
Data integrity functions: access, audit trail, backup and restore	Give them particular attention, because the draft Annex 11 singles them out for increased focus in testing (draft section 9.6)

Treat the table as a starting point for discussion with your quality unit, not a rule. Your own procedures and your regulator's expectations come first.

Writing the justification

When an inspector asks why you tested a system the way you did, the answer should be a short, written chain: the intended use, the risks to product quality, patient safety and data integrity, the controls you chose, and the testing that follows from them. Annex 11 clause 4.1 expects exactly that. Keep these points in the validation plan or summary report:

The intended use of the system and the GMP decisions it supports.
The risks you identified for each requirement or function, and how you ranked them.
The test approach chosen for each rank, with the reason.
Anything you relied on from the supplier, and your assessment of that supplier.
Any residual risk you accepted, and who approved it.

Key takeaways

Annex 11 asks you to base the extent of validation on a justified and documented risk assessment. The rule is about reasoning, not about doing less.
The MHRA ties validation effort to complexity and risk, and says simple instruments without configurable software may only need calibration.
The draft Annex 11 is still a draft, but it signals more attention to individual requirements and to data integrity functions such as audit trails and restore from backup.
FDA's February 2026 software assurance guidance is a good model of risk-based thinking, but its scope is medical device production and quality system software.
If the risk assessment never changes the test plan, it is not working.
Write the chain of reasoning down: intended use, risk, control, test.