MDR customer feedback requirements are met through EN ISO 13485:2016+A11:2021 clause 8.2.1, which requires a documented procedure for collecting and monitoring information from post-production activities as part of the quality management system, and clause 8.2.2, which requires a documented procedure for handling complaints. The two clauses together form the operational entry point for the post-market surveillance system required by MDR Articles 83 to 86 and Annex III, and for the vigilance obligations that follow from it. A startup that builds these two procedures well satisfies the feedback layer of the QMS, feeds the PMS system the data it needs, and closes the loop into CAPA and risk management.

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

TL;DR

  • EN ISO 13485:2016+A11:2021 clause 8.2.1 requires a documented procedure for the feedback process that collects and monitors information from post-production activities and feeds it into risk management and product realisation.
  • EN ISO 13485:2016+A11:2021 clause 8.2.2 requires a documented procedure for handling complaints, including timely processing, investigation, reporting to regulatory authorities where required, and corrective action.
  • MDR Articles 83 to 86 and Annex I rely on this feedback layer — the PMS system cannot function without the inputs that clauses 8.2.1 and 8.2.2 produce.
  • A structured intake procedure, a trained classifier, a written escalation rule, and honest records are enough to meet both clauses in a small team.
  • Feedback records are the raw material for trend analysis, CAPA, CER updates, and risk file updates. A feedback system that does not drive those downstream outputs is broken.

Why customer feedback is a QMS obligation, not a support function

The reflex at most startups is to treat customer feedback as a support or product problem. Tickets come in, the support lead reads them, the ones that look like bugs go to engineering, and the rest get a thank-you reply. Under MDR this reflex is a compliance gap. Customer feedback is a named QMS obligation with a specific procedure requirement, specific content requirements, and specific downstream connections into PMS, vigilance, and CAPA.

The obligation sits in two places in EN ISO 13485:2016+A11:2021. Clause 8.2.1 covers the broader feedback process — the monitoring of information from post-production activities across the device lifetime. Clause 8.2.2 covers complaint handling specifically — the subset of feedback that describes a problem. Both clauses require documented procedures. Both clauses require records. Both clauses feed upward into MDR Articles 83 to 86, which establish the PMS system, and into Annex I, which requires the manufacturer to address general safety and performance throughout the device lifetime.

A startup that understands this structure stops asking "should we treat this ticket as a complaint?" and starts asking "did the feedback process capture this input, classify it, and route it to the right next step?" The first question is philosophy. The second question is auditable.

Clause 8.2.1 — monitoring of feedback as a QMS input

Clause 8.2.1 of EN ISO 13485:2016+A11:2021 is the broader of the two. It requires the organisation to document procedures for a feedback process that gathers data from production and post-production activities. The gathered data is an input to risk management under clause 7.1 and to monitoring of product realisation. The clause names the process explicitly as a source of input to the QMS, not an after-the-fact reporting exercise.

What this means in practice. The feedback process is active, not passive. It does not wait for a complaint to arrive. It actively monitors every source that could carry information about how the device is performing in the field — support channels, clinical advisory interactions, sales conversations with users, distributor reports, literature on comparable devices, user forums where that is appropriate, and social listening where the device has a consumer-facing surface. All of these are feedback sources within the meaning of clause 8.2.1.

The procedure required by clause 8.2.1 must describe who monitors which source, at what cadence, against which criteria, and where the monitored information is recorded. For a startup, the procedure does not need to be long. It needs to be real. A two-page procedure that names the channels, the owner, the cadence, and the record format is enough to satisfy clause 8.2.1 if the procedure is actually followed.

The feedback process under clause 8.2.1 also has a specific output direction the clause requires. Information gathered must feed into risk management and into corrective or preventive action where appropriate. A feedback process that never produces a risk file update, a CAPA input, or a design change input across the lifetime of a device is a feedback process that is not doing its job — and an auditor will press on that absence.

Clause 8.2.2 — complaint handling as a documented procedure

Clause 8.2.2 of EN ISO 13485:2016+A11:2021 narrows to complaints specifically. It requires a documented procedure for handling complaints that covers, at minimum, timely receipt and processing, determination of whether the feedback constitutes a complaint, investigation, determination of the need for action including correction or corrective action, reporting to regulatory authorities where required, and record-keeping.

The clause leaves the depth of each element to the manufacturer to define, proportionate to the risk class and the device. It does not leave whether each element exists to the manufacturer. All of them must be in the procedure. All of them must produce records.

The distinction between clause 8.2.1 and clause 8.2.2 is worth making cleanly because startups often conflate them. Clause 8.2.1 is about monitoring the whole feedback stream — including information that is not a complaint at all, like a user telling you the device worked perfectly and they love it. Clause 8.2.2 is about the subset of that stream that describes a potential or actual problem. Every complaint is feedback; not every piece of feedback is a complaint. The procedure under clause 8.2.2 determines, as its first step, whether a given piece of feedback rises to a complaint in the regulatory sense. That determination is itself a documented decision, not an implicit one.

The word "complaint" in clause 8.2.2 carries the ISO 13485 definition — any written, electronic, or oral communication alleging deficiencies related to the identity, quality, durability, reliability, usability, safety, or performance of a medical device that has been released from the organisation's control, or related to a service that affects the performance of such a device. That definition is wider than most founders assume. A user saying "the strap gets uncomfortable after two hours" is a complaint under the ISO 13485 definition even if nothing is medically wrong.

The two clauses of EN ISO 13485:2016+A11:2021 do not sit in isolation. They feed directly into the PMS system required by MDR Articles 83 to 86.

MDR Article 83 requires every manufacturer to plan, establish, document, implement, maintain, and update a post-market surveillance system proportionate to the risk class and appropriate for the type of device. The system is required to actively and systematically gather, record, and analyse relevant data on the quality, performance, and safety of a device throughout its entire lifetime. The active gathering the article describes is, at the operational level, exactly what clauses 8.2.1 and 8.2.2 require the QMS to do.

MDR Annex III paragraph 1.1(a) spells the connection out further. The PMS plan must describe the processes for collecting and using information in particular from complaints and reports from healthcare professionals, patients, and users on their experience with the device. The ISO 13485 clauses are how the QMS does the collecting. The PMS plan describes the using.

MDR Articles 84, 85, and 86 then build on the collected data. Article 84 requires the PMS plan to be part of the technical documentation. Article 85 requires Class I manufacturers to prepare a PMS report summarising the results and conclusions of the analysis of the PMS data. Article 86 requires Class IIa, IIb, and III manufacturers to prepare a periodic safety update report with similar analytical content. Both the PMS report and the PSUR draw their raw material from the feedback and complaint records that clauses 8.2.1 and 8.2.2 produce.

The vigilance obligations in MDR Articles 87 to 92 are the regulatory escalation path for the subset of complaints that describe serious incidents. Complaint handling under clause 8.2.2 is where a potential serious incident is first recognised, classified, and routed into vigilance reporting. MDCG 2023-3 Rev.2 is the current operational guidance on vigilance terms and concepts. For the deep walkthrough of complaint triage and vigilance timelines, see the companion post on customer complaint handling under MDR.

A structured intake procedure

The intake procedure is where most feedback systems stand or fall. A procedure that satisfies both clause 8.2.1 and clause 8.2.2 has a small number of defined elements and does not need more.

One intake form, used by every channel. Whether the feedback arrived by support email, in-app message, phone call, sales conversation, distributor report, clinical advisory board note, or social media mention, the person who received it opens one intake record with a defined set of fields: unique ID, date of receipt, receiving channel, reporter details where available, device identification including UDI and lot or serial where known, a verbatim description of what the reporter said, and the name of the intake owner.

One classifier with defined competency. EN ISO 13485:2016+A11:2021 clause 6.2 requires personnel performing work affecting product quality to be competent on the basis of education, training, skills, and experience. The classifier who decides whether a piece of feedback is a complaint within the meaning of clause 8.2.2 must meet this competency requirement. In a startup this is typically the regulatory affairs lead or a trained operations lead with a documented escalation path.

One decision output. For each intake record, the classifier records one of three outcomes: non-complaint feedback that is logged and monitored under clause 8.2.1, a complaint that enters the clause 8.2.2 handling workflow, or a potential serious incident that is triaged immediately to vigilance under MDR Article 87. Each outcome has a defined next step and a defined owner.

One service-level target for classification. The procedure names a target time between receipt and classification — for most startups, within one business day — so that potential serious incidents cannot sit in an intake queue while the vigilance clock runs.

That is the structured intake procedure. No CRM integration project, no six-figure complaint-management platform, no custom workflow engine. A shared form, a trained person, a written decision rule, a time target.

Escalation criteria — when feedback becomes a vigilance case

The escalation criteria from complaint to vigilance are the single most time-critical element of the entire feedback system. Clause 8.2.2 requires the procedure to describe reporting to regulatory authorities where required. The reporting in question is the vigilance reporting under MDR Articles 87 to 92, and the timelines it triggers are fixed.

The escalation criteria must be written in a form that the classifier can apply in the moment. MDCG 2023-3 Rev.2 walks through the distinction between an incident, a serious incident, a user or use error, and a non-complaint feedback item. The criteria the procedure uses should mirror that guidance directly, so that a classifier applying the procedure arrives at the same answer the guidance would.

Four questions, answered in order. First, does the report describe a malfunction or deterioration in the characteristics or performance of the device, an inadequacy in information supplied, a user or use error, or an undesirable side effect? Second, did the event lead to or could it have led to death, a serious deterioration in state of health, or a serious public health threat? Third, is there a plausible link between the device and the reported outcome? Fourth, when does the manufacturer's awareness clock under Article 87 start running on this record?

If the four questions together indicate a potential serious incident, the procedure routes the record immediately into the vigilance workflow. The complaint record remains open in parallel, cross-referenced to the vigilance case file, so that the clause 8.2.2 investigation and corrective action steps run alongside the regulatory report.

Records required by both clauses

EN ISO 13485:2016+A11:2021 clause 4.2.5 requires the organisation to maintain records to demonstrate conformance to requirements and effective operation of the QMS. For clauses 8.2.1 and 8.2.2, the required record set is specific.

For feedback monitoring under clause 8.2.1, the records include the list of monitored sources, the monitoring cadence, the monitoring results by period, and the onward routing decisions where feedback triggered a risk file review, a CAPA input, or a product change. These records are the evidence that the feedback process is active rather than passive.

For complaint handling under clause 8.2.2, the records include the intake record with the verbatim description and the classification decision, the investigation record with the methods used and the conclusions reached, the action record with the corrective action taken and the effectiveness verification, and the closure record with the sign-off. Where a complaint was triaged to vigilance, the record includes cross-references to the vigilance case file.

The medium does not matter. Spreadsheet, lightweight database, structured issue tracker, document management system — all acceptable if the records are traceable, versioned, and retrievable. What matters is that an auditor can pull any record at random and read the full story without reconstruction.

Common mistakes startups make

  • Treating clause 8.2.1 as optional because "we already have complaint handling." Clause 8.2.1 is the broader monitoring obligation and is required alongside clause 8.2.2. A complaint procedure alone does not satisfy the monitoring requirement.
  • Letting support triage complaints without training. The classifier who decides whether feedback is a complaint must meet the clause 6.2 competency requirement. An untrained support agent making this decision is a clause 6.2 nonconformity waiting for an auditor.
  • One channel per record, no central log. Feedback scattered across Intercom, Zendesk, email threads, and Slack DMs cannot be trended, cannot be audited, and cannot be used as a PMS input. The central log is non-negotiable.
  • Closing non-complaint feedback without monitoring. Clause 8.2.1 requires the broader feedback stream to be monitored for patterns over time. Closing a piece of feedback as "not a complaint" and deleting the record breaks the monitoring obligation.
  • No link from feedback records to the risk file or the CER. Clauses 8.2.1 and 8.2.2 both feed downstream into risk management and, via PMS, into clinical evaluation. A feedback system that never drives a risk file update or a CER update has lost its downstream connection.
  • Procedure without actual operation. A written procedure that nobody in the team follows is worse than no procedure at all, because the gap between paper and reality is itself an audit finding.

The Subtract to Ship angle

The Subtract to Ship framework for MDR applied to customer feedback produces a short list. Every element must trace to clause 8.2.1 of EN ISO 13485:2016+A11:2021, clause 8.2.2 of EN ISO 13485:2016+A11:2021, or an MDR article in the range 83 to 86 or 87 to 92. If an element cannot be traced, it is overhead and comes out.

What survives the pass. A short written feedback procedure covering both clauses. One intake form used by every channel. One central log. One trained classifier with a defined escalation path. One decision rule documented in the procedure. One service-level target on classification time. One record format per outcome — monitored feedback, investigated complaint, vigilance-triaged complaint. One quarterly loop into the risk file, the CAPA log, and the CER update cycle. One annual review of the feedback procedure against actual operation.

What does not survive. A custom complaint management platform that nobody has time to configure. A twelve-page procedure nobody has read end to end. A taxonomy of complaint categories so detailed that classification takes longer than investigation. A dashboard of feedback metrics that no one uses for decisions. Every one of these is subtraction bait dressed as diligence.

The result is a feedback layer a three-person team can run without drowning. It satisfies clause 8.2.1 and clause 8.2.2 cleanly. It feeds the PMS system the data it needs under MDR Articles 83 to 86. And it survives a Notified Body audit because every element of it traces to a specific clause or article that the auditor can read in the same document the manufacturer used to build the procedure.

Reality Check — Where do you stand?

  1. Do you have a documented procedure that covers clause 8.2.1 (feedback monitoring) and clause 8.2.2 (complaint handling) as two distinct but linked processes, or does one stand in for the other?
  2. Can you name the classifier who decides whether an incoming piece of feedback is a complaint, and can you point to the training records that demonstrate clause 6.2 competency?
  3. Does every channel in your company funnel feedback into one central log, or are some channels still untracked?
  4. If a potential serious incident arrived in your inbox right now, how long until the classifier sees it and the vigilance clock under Article 87 is acknowledged?
  5. Does your most recent risk file update reference feedback data from the same period, and does your most recent CER update do the same?
  6. Have you performed the annual internal review of the feedback procedure against actual operation, and did the review find gaps between paper and practice?
  7. Have you read MDCG 2025-10 and MDCG 2023-3 Rev.2 end to end, or have you only skimmed them?

Frequently Asked Questions

What is the difference between clause 8.2.1 and clause 8.2.2 of EN ISO 13485:2016+A11:2021?

Clause 8.2.1 covers the broader feedback monitoring process — active collection and monitoring of information from post-production activities across all channels, feeding into risk management and product realisation. Clause 8.2.2 covers complaint handling specifically — the subset of feedback that describes a problem. Both are required and both need documented procedures.

Does every piece of customer feedback need to be logged as a complaint?

No. Every piece of feedback must be captured under the clause 8.2.1 monitoring process, but only the subset that meets the ISO 13485 definition of a complaint — alleging deficiencies in identity, quality, durability, reliability, usability, safety, or performance — enters the clause 8.2.2 handling workflow. The classifier decides which is which.

How does clause 8.2.2 connect to MDR vigilance reporting?

Clause 8.2.2 requires the complaint procedure to cover reporting to regulatory authorities where required. That reporting is the vigilance obligation under MDR Articles 87 to 92. A complaint that is classified as a potential serious incident is routed immediately into the vigilance workflow, with the timelines fixed by Article 87 and the terms clarified by MDCG 2023-3 Rev.2.

Who in a startup should run the feedback procedure?

The feedback procedure can be owned by the regulatory affairs lead or by a trained operations lead with a defined escalation path to regulatory. The critical requirement is that the person performing classification under clause 8.2.2 meets the competency requirement in clause 6.2 — education, training, skills, and experience appropriate to the decision being made.

Does the feedback system need to feed into the clinical evaluation report?

Yes. MDR Article 61(11) requires the clinical evaluation to be updated throughout the device lifetime with data from the PMS system, and the feedback stream captured under clauses 8.2.1 and 8.2.2 is a primary PMS input. A CER update that does not reference feedback data from the same period is a CER update that missed its required inputs.

What records must the feedback procedure produce?

At minimum: the list of monitored sources and cadence, the intake records with verbatim descriptions and classification decisions, the investigation and action records for complaints, and the cross-references to vigilance cases where applicable. Clause 4.2.5 of EN ISO 13485:2016+A11:2021 governs the record-keeping obligation across the QMS, and the feedback records are a named subset.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Articles 83 to 86 (post-market surveillance system, plan, PMS Report, and PSUR) and Annex I (general safety and performance requirements). 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.2.5 (control of records), clause 6.2 (human resources — competence), clause 8.2.1 (feedback), clause 8.2.2 (complaint handling).
  3. MDCG 2025-10 — Guidance on post-market surveillance of medical devices and in vitro diagnostic medical devices. Medical Device Coordination Group, December 2025.
  4. MDCG 2023-3 Rev.2 — Questions and Answers on vigilance terms and concepts as outlined in Regulation (EU) 2017/745 and Regulation (EU) 2017/746. Medical Device Coordination Group, first publication February 2023; Revision 2, January 2025.

This post is part of the Quality Management Under MDR series in the Subtract to Ship: MDR blog. Authored by Tibor Zechmeister and Felix Lenhard. Clauses 8.2.1 and 8.2.2 of EN ISO 13485:2016+A11:2021 are the operational entry point for everything the PMS system does afterward — get these two procedures right and the rest of the feedback-to-action loop has a foundation to stand on.