How the EU MDR Changed the Landscape of Process Validation

EU MDR did not invent process validation. It did not invent test method validation either. But it did make both harder to ignore.

That is probably the more honest way to describe what happened. The EU MDR did not suddenly create the need to validate manufacturing processes. It did not introduce the idea that test methods need to be suitable for their intended use. Those expectations existed long before MDR became the regulatory topic everyone was talking about.

Still, something changed.

Under MDR, weak validation files became easier to challenge. Missing rationales became harder to explain away. Technical documentation had to tell a more complete story. And manufacturers who had treated process validation as a checkbox started feeling the pressure.

So yes, EU MDR changed the landscape. Not because it invented process validation, but because it raised the visibility of evidence.

Process validation is not new.

The medical device industry has been working with the concept for decades. The basic idea has always been straightforward: if the result of a process cannot be (or is not) fully verified by later inspection or testing, the process needs to be validated.

In plain English: if you cannot reliably inspect the quality of the product at the end, you need evidence that the process consistently produces the required result.

That is why process validation matters for activities such as sterile barrier sealing, sterilization, cleaning, bonding, welding, coating, molding, heat treatment, aseptic processing, and other processes where failures may not be fully visible during final inspection.

The concept sounds simple. The execution is usually where things become messy.

A process may be running for years. Product may be shipping. Everyone may believe the process is "stable." But when someone asks for the validation, the documented evidence is sometimes thin: unclear scope, weak acceptance criteria, incomplete worst-case justification, missing test method validation, or no clear connection between risk, process parameters, and product requirements.

That is not an MDR invention. That is an old problem under stronger light.

MDR changed the pressure around process validation in three practical ways.

First, it increased the importance of technical documentation. The file needs to be clear, organized and convincing. Validation evidence cannot be scattered, assumed or explained only in meetings.

Second, it strengthened the expectation that safety and performance claims are supported by evidence. If a process affects safety or performance, the validation behind that process becomes part of the story.

Third, it made the lifecycle perspective harder to avoid. Validation is not something to complete once and forget. Product changes, process changes, supplier changes, equipment changes and new information can all affect whether the original validation is still valid.

That is where many manufacturers feel the difference.

Under previous habits, a validation file might have been accepted because the process looked familiar and the product had a long history. Under MDR, reviewers are more likely to ask whether the evidence is complete, current and linked to the applicable requirements.

The question is no longer only, "Did you validate this process?"

It is also, "Can your documentation prove that the validation is still suitable for this device, this process and this regulatory claim?"

This sentence is not exactly wrong in everyday conversation, but it is misleading.

MDR expects manufacturers to demonstrate conformity. Process validation may be part of that demonstration when manufacturing processes affect safety, performance or product conformity. But the underlying quality management expectation already existed through ISO 13485 and long-standing process validation guidance.

So the better statement is this:

MDR did not create process validation. MDR made poor process validation harder to defend.

That distinction matters.

If a company believes MDR created a new requirement, it may treat validation as an emergency documentation project. The team rushes to create protocols, collect old data and write rationales after the fact.

If the company understands the real issue, it takes a better approach: process validation becomes part of the quality system, connected to design transfer, risk management, production controls, supplier controls, change control and technical documentation.

That is where it belongs.

The same misunderstanding often appears around test method validation.

A manufacturer performs a process validation. The protocol includes tests. The report concludes that the process passed. Then a reviewer asks a simple question:

How do you know the test method was capable of detecting what you needed it to detect?

That is where the conversation changes.

Test method validation is not about making the file heavier for fun. It is about confidence. If a test method is used to generate evidence for process validation, design verification or product release, the method needs to be suitable for its intended use.

For some methods, this may require a formal TMV study. For others, a documented rationale, method verification or reference to a standardized method may be appropriate. The level of effort depends on risk, method complexity, intended use and the consequences of a wrong result.

The mistake is assuming that a passed test automatically means the validation is strong. A process validation is only as convincing as the method used to measure the result.

MDR did not invent that logic. It simply made weak links in the evidence chain more visible.

The problem is rarely that nothing exists.

More often, something exists, but it does not fully answer the question.

Common gaps include:

• the scope of validation is unclear

• the process family is too broad for the selected representative product

• worst-case selection is not justified

• acceptance criteria are not linked to product requirements

• process parameters are not clearly defined

• IQ, OQ and PQ are treated as templates rather than evidence

• test methods are used without adequate validation or justification

• sample sizes are not explained/justified

• deviations are closed without discussing impact

• re-validation triggers are vague

• the validation report does not clearly conclude what is validated

None of these issues is glamorous. They are also exactly the kind of issues that can slow down a technical documentation review or create audit findings.

A good validation file does not just show that testing happened. It shows why the validation approach was appropriate.

A stronger process validation file does not need to be beautiful. It needs to be traceable.

A reviewer should be able to follow the logic without calling the original project team:

• Which process is being validated?

• Why does this process require validation?

• Which product, product family or configuration is covered?

• Which requirements does the process need to meet?

• Which risks are controlled by the process?

• Which parameters are critical?

• Which worst-case or representative conditions were selected, and why?

• Which test methods were used, and are they suitable?

• How are sample sizes justified?

• What acceptance criteria were defined?

• What deviations occurred, and how were they assessed?

• What exactly is the conclusion?

• What changes would trigger reassessment or revalidation?

This is the difference between having documents and having evidence.

Documents fill a folder. Evidence supports a claim.

Before EU MDR, some companies could get surprisingly far with experience-based arguments.

"We have used this process for years."

"We never had complaints."

"The supplier has always done it this way."

"Our production team knows the process."

Those statements may be true. They may even be useful context. But they are not a replacement for validation evidence.

Under EU MDR, the file needs to stand on its own. Experience can support the rationale, but it should be translated into objective evidence: historical data, process monitoring, capability analysis, justified acceptance criteria, documented risk assessment, controlled change history or a clear revalidation decision.

The problem is not that people do not know their process. Often, they do.

The problem is that the file does not always show what they know.

Before technical documentation review or an audit, it is worth asking a few uncomfortable questions:

• Do we know which processes require validation and why?

• Is the validation scope clearly defined?

• Are product families and representative samples justified?

• Are worst-cases documented instead of assumed?

• Are acceptance criteria linked to product requirements?

• Are test methods validated, verified or otherwise justified?

• Is the sample size rationale documented?

• Are deviations assessed for product and process impact?

• Are revalidation triggers clear?

• Does the final report state exactly what has been validated?

• Can the validation evidence be found easily in the technical documentation?

If the answer is "sort of," the file probably needs work.

The EU MDR did not invent process validation. It did not invent test method validation either.

But it did change the environment around both.

Manufacturers now face stronger expectations for documentation, traceability and lifecycle control. A validation file cannot rely on tradition, verbal explanations or old assumptions. It needs to show why the process required validation, how the validation was performed, why the methods were suitable and how the conclusion supports safety, performance and compliance.

That is not just a regulatory exercise.

Good process validation protects product quality. Good test method validation protects the credibility of the evidence. Together, they make the technical documentation easier to defend.

SIFo Medical supports medical device manufacturers with process validation, test method validation, validation gap assessments, MDR technical documentation and practical ISO 13485 implementation.

If EU MDR has exposed gaps in your validation files, SIFo Medical can help you turn scattered documents into a clear, defensible validation story.

Need support with process validation or TMV? Contact SIFo Medical and make your validation evidence clear, compliant and audit-ready.

Further helpful links and resources: 

Newsletter: Join our community and be the first to receive updates and news.

Free Resources: Get free access to checklists & templates.

TMV Guide: Your practical guide to perform test method validation (incl. templates & videos).

TMV Online Course: Become an expert in Test Method Validation.

SIFo AIRA – AI Risk Analysis: Use SIFo AIRA to create your risk analysis within hours, instead of weeks – structured, fast, and MedTech-compliant.