Qualification and Validation.
Qualification provides the evidence for everything that stays in place and can be touched: for the facilities, systems and equipment of manufacturing. Validation provides the evidence for the process that this equipment carries. Which act applies is therefore decided by the object of evidence, not by the label a system happens to carry. In production systems the two run inside one another: the manufacturing process is validated, the system runs along with it, and still has to be demonstrated in its own right. Keep the two apart and you neither test twice nor leave a gap.
The object of evidence decides which act applies.
The three terms look interchangeable. They are not. They differ by how changeable their object of evidence is. The more stable that object, the more the evidence can rest on a single point in time; the more it moves, the more it has to be laid out as a continuous line of evidence.
Annex 11 puts the split in one sentence: the application is validated, the IT infrastructure is qualified. Our page on IT infrastructure qualification shows what that infrastructure line looks like; this page is about the systems that sit directly in production.
Systems that sit between plant and application.
Examples from our projects, standing in for the system classes we have supported for more than two decades. Each of these classes carries two perspectives at once, and both are correct:
| System class | Role in the process | Seen from the system |
|---|---|---|
| Weighing and dispensing systems | qualified equipment in the dispensing step | weighing technology qualified, control software verified, dispensing application validated in its process |
| Labeling and serialization systems | qualified equipment in the packaging step | printer and camera technology qualified, data flow for code assignment verified, application validated |
| Line integration and checkweighing | qualified equipment for in-process control | checkweighers qualified, integration software verified, data path into batch documentation validated |
| Environmental monitoring | qualified instrumentation in cleanroom operation | measurement technology qualified, monitoring software verified, alarm handling and trending validated in the process |
| Manufacturing execution (MES) | carries the manufacturing process that sits in the authorization dossier | infrastructure qualified, software verified, whole system validated against its intended use |
| Laboratory information systems (LIMS) | runs the test methods as submitted | infrastructure qualified, software verified, whole system validated in the laboratory process |
On the right stands the system view, in the middle the role in the process. They describe the same object, and neither of the two replaces the other.
Does a system with software fall under Annex 11 or Annex 15?
Both, and Annex 15 says so explicitly: computerized systems used in medicinal product manufacture are also to be validated according to the requirements of Annex 11. The PIC/S recommendation draws the same line from the other side: it does not cover the validation of computerized systems and points to Annex 11 instead, while keeping the principles of the areas it excludes present in its own text. Read only the demarcating wording and you take it for an either-or, and you leave one of the two lines undone. The route to evidence has five steps:
- 1
Understand the process
The process comes first, ahead of any equipment. It sets the intended use that validation is later measured against, and with it which evidence is needed at all. Only then does the requirements specification take shape.
- 2
Qualify the equipment
The stable side is qualified: plant technology, instrumentation, utilities, IT infrastructure. Results from factory and site acceptance testing may reduce your own testing scope as far as it is justified that transport and installation do not affect the function tested.
- 3
Verify the software
The moving side is checked against its specification: application, configuration, interfaces, recipe and master data logic. Scope follows risk and the effect on product and data. Where the software sits inside the equipment itself, in the control system, the operator interface, the recipe handling, it needs no validation project of its own. Specification and verification belong in the same engineering project that qualifies the equipment, and are carried in its documentation. Standalone systems such as MES or LIMS keep a system validation of their own.
- 4
Validate the process
The manufacturing process is validated because GMP requires it; that it sits in the authorization dossier ties it to the variations regime on top. Whether through validation batches, as continuous verification or as a hybrid of the two, the system involved is exercised along with it and covered on that route. You may draw on that evidence; it does not replace the system's own.
- 5
Hold the state
After release the real standing task begins. The validated state holds only through ongoing verification. Every change to equipment, software, configuration or process runs through change control, and every one of them is assessed to see whether it touches the evidence.
One word carries it: also.
The interface between the two worlds of evidence does not live in the secondary literature. It sits in Annex 15 itself, and it is worded additively:
"Computerised systems used for the manufacture of medicinal products should also be validated according to the requirements of Annex 11."
EU GMP Annex 15 (Qualification and Validation), version in force since 1 October 2015, section "Principle".
The word "also" carries the whole statement: in addition, not instead. The PIC/S recommendation on qualification and validation frames the same interface as a boundary. Validation of computerized systems is expressly outside its scope and belongs to Annex 11, yet the principles of the excluded areas are reflected in its own text as well. Read the two texts side by side and the order becomes visible: the two are separated by their object of evidence and still belong together.
QFINITY has supported production systems for more than two decades, in daily practice between plant and application. We know both worlds of evidence from our own projects.
One system, two correct names.
The word system appears in both sets of rules, and it does not mean the same thing in each. Annex 15 lists facilities, systems and equipment as the object of qualification. Annex 11 takes it to mean a unit made up of software and hardware components whose application is validated in its process. The GAMP industry guide draws the term wider still and brings process and roles into it. Software engineering calls this polymorphism: one term, a different shape depending on context.
Anyone coming from production sees a qualified system inside the manufacturing process. Anyone coming from the systems side sees a validated application on qualified infrastructure. Both are describing the same MES, and the same word stands for it in either case. Asking which name is the correct one therefore leads nowhere; the question that holds up is what is being demonstrated against what.
On a project we settle the object of evidence first and the label second. Our page on software validation shows how the same logic works for pure software systems.
What you can check in your own organization.
In our projects, gaps rarely come from missing knowledge. More often two departments list the same system under different names, and each assumes the other produced the evidence. These points make the situation visible:
Frequently asked questions.
Qualification shows that a stable object such as a facility, a piece of equipment or the infrastructure is installed correctly and works as intended. Validation shows that a process, or a computerized system in its process context, meets its intended use reproducibly. What separates them is the object of evidence.
Yes, implicitly. The manufacturing process is validated and the system carries out what the process requires, so it is exercised along with it, whether through validation batches, continuous verification or a hybrid of the two. It still needs evidence of its own, because process validation only exercises the functions that the validated run actually uses.
No. Separate objects of evidence do not bring duplicated evidence with them. Evidence from the supplier may reduce the scope of your own qualification, and qualification results may reduce the scope of process validation. Both cases need a documented justification and traceability showing which evidence carries which claim: for factory and site acceptance testing, evidence that transport and installation leave the function untouched; for the step into process validation, a risk assessment.
Because the GMP annex on qualification and validation defines every qualification stage as documented verification. Qualification of software is how the equipment side says evidence against the specification. The term is common in the market and is not wrong at its core, as long as it stays clear that the evidence refers to the specification and not to the process.
The split stands; the weight of the operational phase grows. The draft from the 2025 consultation turns the validated state into a standing task across the lifecycle and builds the periodic review into an assessment program of its own. What that means for your systems is covered on our page on the Annex 11 revision.
Give every piece of evidence its object before an inspection does it for you.
With production systems, gaps usually open where two departments each rely on the other. We walk your system landscape with you, assign its evidence to every system, and show which of it you already hold, which can be credited toward your own scope, and where a gap genuinely remains. To start: a free initial conversation of about 30 minutes in which we take stock of where you stand.
Arrange an initial conversation
