Process validation under MDR is the documented demonstration that a manufacturing process consistently produces output meeting predetermined specifications, in cases where the output cannot be fully verified by subsequent inspection or testing. The legal anchor is MDR Article 10, which requires manufacturers to establish a QMS covering manufacturing process control. EN ISO 13485:2016+A11:2021 clause 7.5.6 operationalises the obligation: when the resulting output of a production process cannot be, or is not, verified by subsequent monitoring or measurement, the process must be validated. In practice, this applies to sterilisation, injection moulding, welding, heat treatment, bonding, coating, cleaning, and software-driven automation, and the validation is executed as installation qualification, operational qualification, and performance qualification — IQ, OQ, PQ.

By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.

TL;DR

  • EN ISO 13485:2016+A11:2021 clause 7.5.6 requires validation of any production process whose output cannot be fully verified by inspection or testing of the finished product. These are the "special processes" in medical device manufacturing.
  • The legal obligation sits in MDR Article 10, which requires the manufacturer to establish, implement, document, and maintain a QMS covering manufacturing process control. Clause 7.5.6 is the standard that gives presumption of conformity with that obligation for process validation.
  • Validation is executed through installation qualification (IQ), operational qualification (OQ), and performance qualification (PQ). Each stage answers a different question, and skipping any of them leaves an audit finding.
  • A validation report is the deliverable. It has to state the acceptance criteria before testing, the results, the deviations, and the conclusion, and it has to be reviewed and approved before the process is released for production.
  • Revalidation is triggered by changes to equipment, materials, process parameters, software, or environment — and by scheduled periodic review. Revalidation is not optional, and missed revalidations are one of the most common clause 7.5.6 findings.
  • Software used for production, monitoring, or the QMS itself falls under a parallel obligation in clause 4.1.6 — software validation is not the same as process validation, but the two are often confused.

Why process validation exists as a clause at all

Most of a QMS is about making sure good product reaches the patient. Process validation is about a narrower question: when you cannot open the finished device to check what happened inside it, how do you know the process that made it did the right thing?

A sterilised single-use device is the textbook case. You cannot test every unit for sterility without destroying every unit. You cannot see sterility through packaging. The only way to know a sterilisation cycle produced sterile product is to have proven, in advance and through documented qualification, that the cycle reliably achieves the required sterility assurance level under the defined conditions, and then to show that every production cycle ran inside those conditions. The finished-product inspection cannot tell you. The process validation has to.

Injection moulding of a device housing where an internal weld line determines structural integrity is another case. You cannot see the weld line without cutting the part open, and you cannot ship cut-open parts. Heat treatment, bonding of implant components, coating of a drug-eluting surface, automated welding of a surgical instrument — same logic. Each one is a process whose critical quality attributes are established at the moment of manufacture and cannot be recovered by inspecting the output.

This is what clause 7.5.6 exists for. The standard does not demand that every process be validated. It demands that the processes whose output cannot be verified downstream be validated, so that quality is built in rather than inspected in. Every auditor knows this distinction, and every auditor checks it.

What clause 7.5.6 actually requires

EN ISO 13485:2016+A11:2021 clause 7.5.6 — validation of processes for production and service provision — requires the manufacturer to validate any processes for production and service provision where the resulting output cannot be, or is not, verified by subsequent monitoring or measurement and, as a consequence, deficiencies become apparent only after the product is in use or the service has been delivered.

The clause then requires the manufacturer to establish documented procedures for process validation, including: criteria for review and approval of the processes, qualification of equipment and qualification of personnel, use of specific methods, procedures, and acceptance criteria, statistical techniques with rationale for sample sizes, requirements for records, revalidation including criteria for revalidation, and approval of changes to processes.

The clause contains a specific requirement that is frequently under-implemented by startups: the manufacturer must establish documented procedures for the validation of the application of computer software used in production and service provision. Validation of such software and of changes to such software must be performed prior to first use. The specific approach and activities associated with software validation and revalidation must be proportionate to the risk associated with the use of the software. Records must be maintained.

Reading the clause carefully, three things stand out. First, the obligation is conditional — it applies when output cannot be verified, which is why the first step of any validation programme is identifying which processes qualify. Second, the clause demands documented procedures, not just validation records — the how of validation has to be written down before validation begins. Third, the clause treats production software as a first-class subject, which matters more every year as manufacturing lines get more digital.

What counts as a special process

A special process, in QMS language, is a process whose output cannot be fully verified by inspection or testing of the finished product. The term is not used literally in clause 7.5.6, but it is the shorthand most auditors and manufacturers use for the processes the clause applies to.

The common ones in medical device manufacturing are sterilisation (ethylene oxide, gamma, electron beam, steam, vaporised hydrogen peroxide), injection moulding of load-bearing or fluid-path components, welding (ultrasonic, laser, resistance), heat treatment of metal components, bonding and adhesive curing where bond strength determines safety, coating processes (drug-eluting coatings, hydrophilic coatings, anti-microbial coatings), cleaning and passivation of implants and surgical instruments, aseptic filling and aseptic assembly, thermoforming of sterile barrier packaging, sealing of sterile barrier systems, and automated assembly where the critical quality attribute is established by machine parameters rather than human judgment.

Software-controlled production equipment — programmable logic controllers running moulding lines, automated vision systems making pass/fail decisions, data acquisition systems recording process parameters that are later used as release evidence — falls under the clause 7.5.6 software validation requirement in addition to whatever process validation applies to the hardware side.

There are also processes that look like they might be special but usually are not. Machining of a metal part whose dimensions are fully inspected after manufacture is normally verified rather than validated. Assembly of a mechanical device where every critical dimension is measured at final inspection is verified rather than validated. The classification is not about the process type — it is about whether finished-product inspection actually confirms the critical quality attributes. Most manufacturers maintain a documented list of special processes, derived from a risk-based analysis of each production step, and revisit the list whenever the process flow changes.

Qualification — IQ, OQ, PQ in plain language

Process validation is executed in three sequential qualification stages. The stages are not in the standard by name, but they are the industry convention that every Notified Body expects, and they map directly to the clause 7.5.6 requirements for equipment qualification, method qualification, and acceptance criteria.

Installation qualification — IQ — establishes that the equipment has been installed correctly, according to the manufacturer's specifications, in the intended environment, with the correct utilities, calibrations, and supporting documentation. IQ answers: is the equipment the right equipment, installed right, with everything it needs to run? The IQ protocol lists the equipment, the installation requirements, the calibration status of measuring instruments, the operator training records, the utility connections, and the environmental conditions. The IQ report records the verification of each item against the protocol.

Operational qualification — OQ — establishes that the equipment operates according to its specifications across the full operating range, including the worst-case conditions relevant to the intended process. OQ answers: does the equipment do what it is supposed to do, under the conditions it will actually face? The OQ protocol defines the operating ranges, the worst-case conditions, the test methods, and the acceptance criteria. The OQ report records the test results and the demonstration that the equipment behaves within specification across the range.

Performance qualification — PQ — establishes that the process, running the equipment with the actual product under actual production conditions, consistently produces output meeting the predetermined specifications. PQ answers: does the real process, with real product, reliably make conforming output? The PQ protocol defines the product, the production conditions, the sample sizes, the statistical rationale, and the acceptance criteria. The PQ report records the results and the conclusion on whether the process is validated.

The three stages run in order. IQ before OQ before PQ. Skipping IQ because "the equipment was already installed when we bought the company" produces an audit finding — retrospective IQ is possible, but it has to be done, not skipped. Compressing OQ and PQ into a single run because the timeline is tight produces an audit finding — the stages answer different questions and need different evidence.

The validation report — what it has to contain

The validation report is the deliverable that closes out a process validation. It is the document the auditor will ask to see, and the document that will either satisfy the auditor in ten minutes or trigger an hour of follow-up questions.

A complete validation report contains: the scope and purpose of the validation, the process being validated with reference to the applicable procedure and specification, the equipment and software covered, the acceptance criteria — stated before testing, not after — with a clear rationale tied to product requirements, the IQ, OQ, and PQ protocols referenced and summarised, the test results and data, any deviations from the protocol with documented investigation and resolution, the statistical analysis with rationale for sample sizes, the conclusion on whether the process is validated, the approval signatures of the responsible functions (typically production, quality, and regulatory), and the date.

The most common failure mode is acceptance criteria written after the data is in. An auditor who sees acceptance criteria that match the results too cleanly will ask when those criteria were set, and the answer has to be "before testing" with dated evidence in the protocol. Acceptance criteria set after the fact are not acceptance criteria at all — they are reverse-engineered conclusions.

The second most common failure is unresolved deviations. A deviation during a qualification run is not automatically a problem, but it has to be documented, investigated, and resolved before the validation can be closed. A validation report that mentions a deviation and then silently moves to "conclusion: validated" without showing the investigation is a live finding.

Revalidation triggers — when validation is not a one-time event

Clause 7.5.6 requires the manufacturer to revalidate processes when the conditions under which the original validation was performed have changed, or on a planned schedule. Revalidation is not a full rerun of every qualification stage in every case — the scope of the revalidation depends on the nature of the change and the risk it presents.

The common triggers are: equipment changes (replacement, major repair, relocation), material changes (new supplier, new formulation, new lot qualification requirements), process parameter changes (temperature, pressure, time, cycle), software changes to production or control software, environmental changes (new cleanroom, new utilities), changes to the product itself that affect how it interacts with the process, recurring non-conformities that suggest the process is drifting, and scheduled periodic review as defined in the validation procedure.

The revalidation scope decision is a judgment call that has to be documented. A minor parameter change within the validated range might require a limited PQ run. A new injection moulding machine requires full IQ, OQ, and PQ. A supplier change for a critical material often requires a targeted PQ with the new material. The procedure has to describe how the scope decision is made, and the revalidation record has to justify the scope that was chosen.

Missed revalidations are one of the most common clause 7.5.6 findings. An initial validation from four years ago, no periodic review, three documented equipment repairs in the interim, and no revalidation — that is a finding waiting to happen, and it happens regularly.

Common mistakes startups make

  • Treating finished-product inspection as a substitute for process validation. If you cannot fully verify the output, you cannot inspect your way out of the obligation.
  • Running IQ, OQ, and PQ as a single merged exercise with one protocol, instead of three sequential stages with clear hand-offs.
  • Writing acceptance criteria after the data is in, so the criteria match the results too cleanly.
  • Ignoring production software under clause 7.5.6 — validating the physical process but not the programmable logic controller or the automated inspection system.
  • Treating supplier-run processes (outsourced sterilisation, contract moulding) as the supplier's validation problem. Under clause 4.1.5, the process remains the manufacturer's responsibility and the validation evidence has to be available to the manufacturer. See post 300 on supplier control for the clause 4.1.5 mechanics.
  • Missing revalidation triggers. Equipment repairs, supplier changes, and parameter adjustments accumulate silently between audits until one of them shows up as a non-conformity.
  • No documented list of which processes are special. Without the list, the decision of what needs validation is made implicitly, inconsistently, and not defensibly.

The Subtract to Ship approach to process validation

The Subtract to Ship framework (post 65) applied here is not about doing less validation — it is about validating the right processes to the right depth, and not confusing validation with generic documentation volume.

Start with an honest list of production processes. For each one, ask the clause 7.5.6 question: can the output be fully verified by subsequent inspection or testing? If yes, no validation is required — verification is the mechanism. If no, the process is a special process and validation is required. Write the list down, write the reasoning, and make the list a controlled document.

For each special process, apply IQ, OQ, and PQ at a depth proportionate to the risk and complexity. A simple heat-sealing process for a Class I packaging component does not need the same validation depth as an ethylene oxide sterilisation cycle for an implantable. The clause does not prescribe depth — it prescribes that the depth be justified and the evidence be sufficient. Subtraction means cutting the parts of a generic template that do not apply to your process, not cutting the parts of the clause that apply to every process.

The final test is the same test every Subtract to Ship pass ends with. For every validation activity, point to the clause of EN ISO 13485:2016+A11:2021 it satisfies and the product quality attribute it protects. If it does not map to an obligation and a quality attribute, cut it. If an obligation has nothing mapped to it, add the minimum that satisfies it. The resulting validation file is smaller than most startups expect, stronger than most auditors see, and survives every change the process goes through because the reasoning is documented.

Reality Check — Where do you stand?

  1. Do you have a documented list of which production processes are special processes under clause 7.5.6, with the reasoning for each classification?
  2. For each special process, do you have a validation report covering IQ, OQ, and PQ, reviewed and approved before production release?
  3. Were the acceptance criteria in each validation report set before testing began, with dated evidence in the protocol?
  4. For outsourced special processes (sterilisation, contract moulding, coating), do you have access to the supplier's validation evidence and a quality agreement that covers change notification?
  5. Can you produce the revalidation history for each special process over the last three years, including the trigger for each revalidation and the scope justification?
  6. For every piece of production software that makes release-affecting decisions or records release-affecting data, do you have a software validation record under clause 7.5.6 or clause 4.1.6 as applicable?
  7. When a change happens — equipment repair, parameter adjustment, supplier change — does your procedure force a revalidation scope decision before the change goes live?

If any question produced a "not yet," that is where the process validation work is.

Frequently Asked Questions

What is the difference between verification and validation under EN ISO 13485:2016+A11:2021? Verification confirms that specified requirements have been fulfilled by inspection and provision of objective evidence — typically measurement of the finished output. Validation confirms, through objective evidence, that the requirements for a specific intended use or application have been fulfilled. Clause 7.5.6 requires validation specifically when the output cannot be fully verified by subsequent monitoring or measurement — so validation is the answer when verification is not possible.

Do I have to do IQ, OQ, and PQ for every validated process? In practice, yes — each stage answers a different question, and skipping any of them leaves a gap that auditors will find. The depth of each stage is proportionate to the risk and complexity of the process, but the three-stage structure is the industry convention that Notified Bodies expect. Merging stages or skipping IQ because the equipment is already installed produces findings.

If my sterilisation is outsourced to a contract sterilisation provider, is the validation their responsibility or mine? The validation activity can be executed by the supplier, but the responsibility remains with the manufacturer under clause 4.1.5 and MDR Article 10. The manufacturer has to have access to the validation evidence, the supplier has to notify the manufacturer of any changes that could affect the validation, and the manufacturer's technical documentation has to include the validation summary. A quality agreement that covers these points is essential. See post 300 on supplier control for the full mechanics.

How often do I need to revalidate? Clause 7.5.6 requires revalidation when conditions change and on a planned schedule. The schedule is set by the manufacturer based on risk — annual review is common for critical processes, longer intervals for lower-risk processes. Change-triggered revalidation has no schedule: it happens whenever a trigger occurs. Missed scheduled revalidations and unrecognised change triggers are among the most common clause 7.5.6 findings.

Does clause 7.5.6 apply to software I use only in the QMS, not in production? Clause 7.5.6 covers software used in production and service provision. QMS software — document control systems, CAPA systems, training record systems — falls under clause 4.1.6, which is a separate but parallel obligation to validate QMS software proportionate to risk. The two clauses are often confused, but both have to be addressed, and a QMS software validation record is not a substitute for a production process software validation record.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 10 (general obligations of manufacturers, including the requirement to establish, document, implement, and maintain a quality management system covering manufacturing process control). Official Journal L 117, 5.5.2017.
  2. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes. Clause 4.1.5 (control of outsourced processes), clause 4.1.6 (validation of QMS software), clause 7.5.6 (validation of processes for production and service provision). The harmonised standard providing presumption of conformity with MDR Article 10 for process validation.

This post is part of the Quality Management Under MDR cluster in the Subtract to Ship: MDR blog. Authored by Tibor Zechmeister and Felix Lenhard. The MDR is the North Star. EN ISO 13485:2016+A11:2021 clause 7.5.6 is the tool. Process validation is where the discipline of building quality in — instead of inspecting it in — meets the reality of a startup shop floor.