Nonconforming product control is the ISO 13485 clause 8.3 process for identifying, segregating, deciding on, and documenting product that does not meet specifications. Under MDR it is mandated through Article 10(9) and Annex IX, and it is the same mechanism that escalates into field safety corrective actions under Articles 87 to 92 when nonconformities reach users.
By Tibor Zechmeister and Felix Lenhard.
TL;DR
- MDR Article 10(9) requires a QMS compliant with the state of the art, and EN ISO 13485:2016+A11:2021 clause 8.3 is the harmonised expression of that requirement for nonconforming product.
- Clause 8.3 demands four things for every nonconformity: identification, segregation, a documented disposition decision, and a record retained for traceability.
- In-process nonconformities stay inside clause 8.3. Released product nonconformities cross into MDR vigilance under Articles 87 to 92 and can trigger a field safety corrective action.
- Rework is allowed only where it is foreseen and does not adversely affect the product, and re-verification is mandatory.
- Concessions (use-as-is) require authorisation by a person with assigned responsibility and a justification linked to risk management.
- The bridge from clause 8.3 to FSCA is the single most audited area for startups. Notified bodies want to see how you decide that an internal nonconformity is actually a field signal.
Why this matters
Every startup hits its first nonconformity on the same day it stops pretending the product is perfect. A sensor reads outside tolerance. A sterilisation cycle logs the wrong temperature. A software build ships with a defect that only affects one hospital. What happens in the next hour decides whether you have a quality system or a pile of paper.
Nonconforming product control is where the QMS stops being theoretical. It is the only clause in EN ISO 13485:2016+A11:2021 that forces you to physically stop something, label it, and make a decision you can defend in front of a notified body auditor and, potentially, a competent authority. Get it wrong and you either ship bad product or you paralyse production every time a measurement drifts.
The other reason it matters: nonconforming product control is the bridge between internal quality failures and external regulatory obligations. A nonconformity that stays inside your factory is a clause 8.3 matter. The moment the same failure reaches a user, it becomes an MDR vigilance matter under Articles 87 to 92. The process that gets you across that bridge safely, without either under-reporting or panic-reporting, is clause 8.3 done properly.
What MDR actually says
MDR Article 10(9) requires manufacturers to establish, document, implement, maintain, keep up to date and continually improve a quality management system that ensures compliance with the regulation in the most effective manner. Annex IX references a QMS audit as the basis for conformity assessment for most routes above Class I. The regulation itself does not spell out a nonconforming product procedure. It delegates that operational detail to the harmonised standard.
EN ISO 13485:2016+A11:2021 clause 8.3 sets out the requirements. The standard requires the organisation to ensure that product which does not conform to requirements is identified and controlled to prevent its unintended use or delivery. A documented procedure must define the controls and the responsibilities and authorities for dealing with nonconforming product.
Clause 8.3 breaks the process into sub-clauses covering actions before delivery, actions after delivery, and rework, with an underlying record requirement. Every nonconformity must be identified, evaluated, and dispositioned. The disposition options are limited: rework to meet requirements, accept under concession with justification, reject and scrap, or, for released product, initiate action appropriate to the effects.
Records of the nature of the nonconformity, any subsequent actions, and the justification for concessions must be maintained. If rework is performed, the rework instructions must address any potential adverse effect on the product, be subject to the same authorisation as the original work, and include re-verification.
The sub-clause covering actions after delivery creates the bridge to MDR vigilance. When nonconforming product is detected after delivery or after use has started, the manufacturer must take action appropriate to the effects or potential effects. If issuing advisory notices (field safety notices in MDR terminology) is required, this must be documented. Reportable adverse events and field safety corrective actions are handled under the vigilance requirements of MDR Articles 87 to 92 and the guidance of MDCG 2023-3 Rev.2.
The plain-language translation: you need one procedure that handles everything from a rejected solder joint to a device already in a hospital, with escalation paths that know when to call vigilance.
A worked example
A Class IIa wearable ECG patch manufacturer runs a final functional test on every unit. Over three weeks, twelve patches out of 4,200 fail the battery capacity test at the lower specification limit. Six of the twelve are caught in final test. Three are caught during customer complaint triage after hospitals report short runtime. Three are still unaccounted for.
Clause 8.3 handling:
The six caught at final test. Each unit gets a red nonconformity tag with a unique NCR number. They go into a locked segregation bin that only quality has a key to. The NCR record documents the failure mode (battery capacity 4 percent below lower spec), links to the test record, and flags the affected production lots. Disposition: reject and scrap. Signed by quality manager. The records are retained in the NCR log.
The three returned from hospitals. These are released product, so the actions-after-delivery sub-clause applies in parallel with customer complaint handling. The NCR records are opened immediately and a trend review is triggered. Risk management files are pulled out. The team re-runs the risk assessment for "early battery depletion." The residual risk was classified as low because the patch displays a low-battery indicator before failure. Real-world evidence confirms the indicator works. The benefit-risk balance is preserved.
The three unaccounted for. These are the dangerous ones. The manufacturer assumes worst case: they are in the field, in use, unreported. A field signal evaluation is triggered under the PMS procedure and compared against the vigilance criteria in MDR Article 87. The evaluation concludes that the failure mode does not meet the serious incident threshold because no death, no serious deterioration in health, and no public health threat is plausible. A field safety corrective action is still considered under Article 89. The decision: issue a targeted field safety notice to the affected lots, ask users to return units for replacement, and log the corrective action in Eudamed when the vigilance module is operational for the manufacturer.
Root cause. A supplier changed a battery cell vendor without notifying the manufacturer, violating the supplier agreement. A CAPA is opened covering supplier management, incoming inspection, and the NCR trend threshold that should have triggered earlier escalation.
Three record types, one integrated flow: NCRs for the twelve units, a CAPA for the systemic cause, a vigilance evaluation for the field implications. The auditor in the next surveillance audit will want to trace all three from a single starting point.
The Subtract to Ship playbook
Most startup NC procedures fail because they try to cover every possible scenario in one document. Subtract to Ship says: strip it to the spine, then let operational reality drive the detail.
Step 1. Write one procedure, not five. A single NC procedure covers in-process, final test, released product, returned product, and customer complaints. Cross-reference complaint handling and vigilance, do not duplicate them. Aim for six pages maximum including flowcharts.
Step 2. Define the physical segregation rule on day one. If you cannot segregate by physical location, segregate by label and system status. For software, segregate by build tag and version control branch. An auditor needs to see that a nonconforming item cannot accidentally be shipped. If your operation cannot demonstrate this in 30 seconds, the procedure is failing.
Step 3. Pre-define disposition authority by risk class. Low-risk NCs can be dispositioned by a qualified operator. Concessions must go to quality. Anything affecting released product goes to the PRRC or equivalent regulatory lead. Document this matrix once.
Step 4. Link the NCR form to risk management by mandatory field. The NCR form must force the person writing it to reference the risk management file entry for that failure mode. If there is no entry, the NCR automatically triggers a risk management review. This single design choice catches most of the cases where internal failures should have been field signals.
Step 5. Build the vigilance bridge into the form, not the procedure. Add three yes/no fields to the NCR: "affected product released to users?", "trend detected across lots?", "field signal evaluation required?". Any yes triggers automatic routing to the PMS owner.
Step 6. Run monthly trend reviews. Twelve individual NCRs that look tolerable in isolation can become a reportable trend under MDR Article 88 on trend reporting. Clause 8.3 records are useless if nobody looks at them in aggregate.
Step 7. Make rework the exception, not the default. Rework instructions must be written, approved, and include re-verification. Every rework event is itself an NCR. If you find yourself reworking more than five percent of output, the problem is upstream in process validation, not NC control.
Step 8. Keep records in a format an auditor can read in under a minute. NCR number, date, product identifier, failure description, disposition, authorisation, closure. If a reviewer cannot reconstruct the story from the record alone, the record is incomplete.
Reality Check
- Can you show an auditor, right now, where physically nonconforming product is segregated in your facility?
- Does every NCR in your log link to a specific risk management file entry, or are they orphaned records?
- When was the last time you reviewed NCRs in aggregate for trends, and is there a written record of that review?
- Does your NCR form force the writer to ask whether affected product has been released?
- Who is authorised to sign off a concession, and does the authority match your documented matrix?
- Do your rework instructions include re-verification steps, and can you point to the last rework record that proves it?
- Is there a clear, documented trigger for escalating from clause 8.3 to MDR vigilance under Articles 87 to 92?
- If a notified body auditor picked three random NCRs from last quarter, could you close the loop on each one in under five minutes?
Frequently Asked Questions
Is nonconforming product control the same as CAPA? No. Nonconforming product control under clause 8.3 handles individual items. CAPA addresses the systemic causes. A single NCR does not automatically trigger a CAPA; trend thresholds or risk levels do. Both processes must exist and interact.
Do I need a separate NC procedure for software? No. Clause 8.3 applies to software as it does to hardware. Segregation for software means pulling a build from release, tagging the defective version, and preventing its distribution. The procedure is the same; the implementation details differ.
When does an internal nonconformity become a vigilance matter? When the affected product has reached users and the failure mode meets the reporting criteria in MDR Article 87. The bridge is the field signal evaluation triggered by the clause 8.3 actions-after-delivery sub-clause. Internal nonconformities alone are not reportable.
Can I accept nonconforming product under concession repeatedly? Repeated concessions for the same failure mode are a red flag. Notified bodies read them as evidence that your specifications are wrong or your process is not capable. Fix the underlying issue through CAPA rather than normalising the concession.
What records must I keep for nonconforming product? At minimum: the nature of the nonconformity, the disposition decision, the authorisation, any concession justification, rework records where applicable, and links to associated risk management and CAPA records. Retain for the MDR-required period for the product class.
Is rework treated differently from new production? Rework must be performed under instructions that address potential adverse effects, be subject to the same authorisation and controls as original work, and include re-verification. In practice, rework is tighter than new production, not looser.
Related reading
- CAPA under MDR and ISO 13485 — how systemic corrective action connects to individual nonconformities
- Root cause analysis for MedTech startups — practical RCA methods that feed clause 8.3 and CAPA
- Field safety corrective actions under MDR — the vigilance side of the bridge from clause 8.3
- Serious incidents under MDR — the reporting thresholds that gate escalation from NCR to vigilance
- MDR Articles 87 to 92: vigilance framework — the regulatory context for post-delivery nonconformities
Sources
- Regulation (EU) 2017/745 on medical devices, consolidated text. Article 10(9), Articles 87-92, Annex IX.
- EN ISO 13485:2016+A11:2021, Medical devices — Quality management systems — Requirements for regulatory purposes. Clause 8.3 Control of nonconforming product.
- MDCG 2023-3 Rev.2 (January 2025), Questions and Answers on vigilance terms and concepts as outlined in the Regulation (EU) 2017/745.