The eight most common post-market surveillance mistakes in MDR startup audits are: a PMS plan written once and never updated, PMS disconnected from risk management, complaint handling that cannot feed trend analysis, a PSUR that is late or missing the Article 86 content elements, proactive PMS methods absent so the system is purely reactive, PMS data that never informs clinical evaluation updates, marketing and website claims drifting without PMS monitoring, and a PMCF plan that exists on paper but is never executed. Each one violates a specific MDR article. Each one is fixable in days if you know which article to anchor the fix to.

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

TL;DR

  • The eight mistakes below show up in almost every first PMS audit of a startup's system. They are not rare. They are the default failure modes.
  • Every mistake maps to a specific MDR article. Articles 83 to 86 for the PMS core, Articles 87 to 92 for vigilance linkage, Annex III for the plan, and Annex XIV Part B for PMCF.
  • The fixes do not require more headcount. They require tracing each PMS activity back to the article that obligates it and cutting everything that does not trace.
  • MDCG 2025-10 (December 2025) is the current operational guidance and should be the reference every startup reads before building or repairing a PMS system.
  • A PMS system that runs on paper but not in practice will not survive a notified body surveillance audit under EN ISO 13485:2016 + A11:2021.

Why these mistakes matter

Post-market surveillance is the safety mechanism that catches what pre-market evidence cannot. When it works, it catches problems small and fixable. When it does not work, the problems grow until they catch the company instead.

We have seen both ends of this. A sleep-monitoring device with an arm strap passed every lab biocompatibility test before market. Weeks into real-world use, skin irritations began appearing. A textile-polymer interface that behaved differently against perspiring skin worn continuously for weeks than it had against any lab protocol. The only reason the problem was caught, traced, and fixed before it escalated was that a real PMS system was actually running: logging complaints, trending them, flagging the correlation, and triggering a material specification change. The system did what Article 83 says a PMS system is for. That device stayed on the market.

The eight mistakes in this post are the ones we see when the system is not actually running. When it exists as a binder but not as a practice. The fixes are small. The cost of not fixing them is large.

For the full starter guide, see what is post-market surveillance under MDR. This post assumes you already know what PMS is and focuses on the failure modes.

Mistake 1: A PMS plan written once and never updated

What it looks like: The PMS plan was drafted before CE marking as part of the Annex III technical documentation, signed off, and then filed. Twelve months later, nothing in it has been touched. New data sources exist that are not in the plan. Trigger criteria that turned out to be wrong are still written as they were. The plan describes activities the team no longer performs and does not describe the activities they actually perform.

What the MDR requires: Article 83(1) requires the manufacturer to plan, establish, document, implement, maintain, and update a post-market surveillance system. The verb "update" is not decorative. Article 84 makes the PMS plan a mandatory component of the technical documentation, with the content elements specified in Annex III. A plan that no longer matches what the company does is a plan that no longer satisfies Article 84. Because Annex III asks for the processes in use, not the processes written down years ago.

The fix: Treat the PMS plan as a living document. On a defined cadence. At minimum whenever the PMS system changes, and at minimum once per report cycle. Walk the plan against reality. If an activity in the plan is not being performed, either start performing it or cut it from the plan with a documented rationale. If an activity is being performed that the plan does not describe, add it. MDCG 2025-10 (December 2025) describes the plan as a central element of the PMS system that evolves with the system.

Mistake 2: PMS disconnected from risk management

What it looks like: The PMS system collects data. The risk file exists. Neither knows the other is there. Complaints arrive, get logged, get closed, and are never compared against the risk analysis. New hazards that the PMS data reveals never make it into the risk file. The risk file still reflects the pre-market estimate of occurrence and severity, even though the post-market data says otherwise.

What the MDR requires: Article 83(3) lists the specific uses the PMS findings must be put to, including updating the benefit-risk determination. EN ISO 14971:2019 + A11:2021 is the harmonised standard for risk management throughout the device lifecycle, which means the risk file is not a pre-market deliverable. It is a living document fed by post-market data. A PMS system that does not feed the risk file is a PMS system that violates Article 83(3).

The fix: Define a single explicit loop. PMS data is reviewed on a defined cadence. Each signal is assessed against the risk file. If the signal represents a new hazard, a higher occurrence rate, or a higher severity than the risk file assumed, the risk file is updated and any consequent risk control measures are triggered. Document the loop in the PMS plan itself so an auditor can see that the loop exists and is running. The sleep arm strap case above is exactly this loop working correctly.

Mistake 3: Complaint handling not structured to feed trend analysis

What it looks like: Complaints are received through email, phone calls, customer support tickets, and sales conversations. Each channel has its own log format or no format at all. Nothing in the logs is standardised. The same complaint described two different ways in two different channels cannot be aggregated. Trend analysis becomes impossible because the underlying data is not comparable.

What the MDR requires: Annex III requires the PMS plan to describe the methods and protocols for managing events subject to trend reporting under Article 88, including the methods and protocols for identifying any statistically significant increase in frequency or severity of incidents. Article 88 itself governs trend reports for non-serious incidents and expected side effects that show a statistically significant increase. Without structured complaint intake, neither the Annex III obligation nor the Article 88 obligation can be met.

The fix: Define a minimum complaint data schema. Device identifier, user type, reported event in controlled vocabulary, severity classification, date, and status. And apply it across every intake channel. One log, one schema, every channel converges. Then define the trend analysis cadence and the statistical rule that triggers escalation under Article 88. The tool does not have to be sophisticated; a spreadsheet with version control beats a fancy system that nobody fills in correctly.

Mistake 4: PSUR not timely or missing Article 86 content

What it looks like: The PSUR for a Class IIa device was last updated 30 months ago. Or the PSUR exists but it is a copy of last year's document with a new date. Or the PSUR is current but it does not contain the Article 86 content elements. The benefit-risk conclusions, the main PMCF findings, the sales volume, the population estimate, the usage frequency.

What the MDR requires: Article 86(1) sets out what a PSUR must contain: the results and conclusions of the analyses of the PMS data gathered under the PMS plan, the rationale and description of any preventive and corrective actions taken, the conclusions of the benefit-risk determination, the main findings of the PMCF, and the volume of sales of the device plus an estimate of the size and other characteristics of the population using the device and, where practicable, the usage frequency of the device. Article 86(1) also sets the update cadence: at least annually for Class IIb and Class III devices, and at least every two years for Class IIa devices. For Class III devices and implantable devices, Article 86(2) requires the PSUR to be submitted via the electronic system to the notified body involved in the conformity assessment.

The fix: Build the PSUR as a structured document where each Article 86 content element is a named section, and populate each section from the PMS system output rather than from last year's text. Put the PSUR cycle on the company calendar at the class-specific cadence. For Class I devices the equivalent is the PMS Report under Article 85. The fix is the same, the document just has a different name and a lighter content scope.

Mistake 5: Proactive PMS methods absent. Only reactive

What it looks like: The PMS system responds to complaints. It does not go looking for data. No literature monitoring. No similar-device monitoring. No proactive user surveys. No trend analysis on low-level signals before they escalate. The system only runs when someone outside the company forces it to run.

What the MDR requires: Article 83(1) defines PMS as a system that actively and systematically gathers, records, and analyses relevant data. The word "actively" is the key. Annex III reinforces this by requiring the plan to describe the processes for collecting information from multiple sources. Complaints and reports from healthcare professionals, patients, and users; information from similar devices on the market; publicly available information about similar devices and state-of-the-art evaluations; and relevant data on serious incidents. A purely reactive PMS system satisfies none of these requirements.

The fix: Add at least two proactive methods to the PMS plan and run them on a defined cadence. The cheapest pair for a startup: a literature search on a defined set of databases with a defined search string, run quarterly and documented; and a similar-device monitoring routine that tracks known competitors' field safety notices and vigilance reports. Neither requires additional headcount. Both satisfy the Annex III obligation and turn the PMS system from reactive to proactive.

Mistake 6: PMS data not informing CER updates

What it looks like: The clinical evaluation report was written before CE marking. PMS data has accumulated since. The CER has not been updated with any of it. When the notified body asks at surveillance audit how the PMS findings fed the CER update, the answer is silence.

What the MDR requires: Article 61(11) requires the clinical evaluation and its documentation to be updated throughout the lifetime of the device with clinical data obtained from the implementation of the manufacturer's PMCF plan and post-market surveillance plan. Annex XIV Part B sets out the PMCF requirements and the feedback into clinical evaluation. Article 83(3) lists updating the clinical evaluation as one of the required uses of PMS findings. A CER that does not reflect post-market data is out of date in a way that the Regulation specifically prohibits.

The fix: Define a CER update cadence in the PMS plan itself. When PMS signals meet defined thresholds, the CER update is triggered; in any case the CER is reviewed at the PSUR cadence. Document the assessment each cycle even if the conclusion is that no CER update is warranted. "No change needed" is a legitimate conclusion only if it is documented and justified against the data reviewed.

Mistake 7: Website and marketing claims drifting without PMS monitoring

What it looks like: The technical file describes a specific intended purpose and a specific set of performance claims. Over months or years, the website evolves. New claims appear. The product page says things the technical documentation does not support. Nobody in the company notices because the marketing team and the regulatory team are not connected, and the PMS system does not monitor marketing claims at all.

What the MDR requires: Article 2(12) defines the intended purpose as the use for which a device is intended according to the data supplied by the manufacturer on the label, in the instructions for use, or in promotional or sales materials or statements, and as specified by the manufacturer in the clinical evaluation. Promotional and sales materials are explicitly part of the intended purpose. Article 83 obligates the PMS system to monitor whether the device as actually placed on the market continues to match the device the technical file authorises. Drifting claims are a PMS signal by definition, because they change the very thing the evaluation was built against. Annex III requires the PMS plan to cover publicly available information about the device, and claims on the manufacturer's own website fall within that scope.

The fix: Add a claims-alignment check to the PMS plan. On a defined cadence. At minimum before each PSUR or PMS Report cycle. Compare the current website, IFU, labelling, and marketing materials against the authorised intended purpose in the technical file. Any drift is logged as a PMS finding. Either the claims come back into line with the file or the file is updated through the change control process, which in most cases means re-evaluating classification and clinical evidence. This is cheap insurance against one of the easiest ways to turn a clean CE marking into a non-compliance finding.

Mistake 8: PMCF plan present but never executed

What it looks like: The technical file contains a PMCF plan, because Annex III requires one. The plan is well-written. Nothing in it has been executed. No real-world data has been collected. No literature reviewed under the PMCF search string. No follow-up investigation started. The plan exists as a document, not as an activity.

What the MDR requires: Annex XIV Part B requires the manufacturer to proactively collect and evaluate clinical data from the use in or on humans of a device which is CE marked and placed on the market, with the aim of confirming the safety and performance throughout the expected lifetime of the device, identifying previously unknown side-effects, monitoring the identified side-effects and contraindications, identifying and analysing emergent risks, ensuring the continued acceptability of the benefit-risk ratio, and identifying possible systematic misuse or off-label use. Article 61(11) connects PMCF back to the clinical evaluation update cycle. A PMCF plan that is not executed satisfies none of this.

The fix: Either execute the PMCF plan as written, or rewrite the plan to describe what the company can actually do and then execute that. If PMCF is genuinely not applicable. And this is rare, but it happens for some low-risk legacy devices. Document the justification against Annex XIV Part B specifically. "We do not have the resources" is not a justification. "The device is a legacy device with extensive prior clinical experience, and a targeted literature review on the defined cadence is sufficient to maintain the clinical evaluation" can be a justification, if the reasoning holds and the literature review is actually performed.

The Subtract to Ship angle

The Subtract to Ship framework applied to the eight mistakes above produces a single rule: for every element of your PMS system, you should be able to name the specific MDR article, annex, or MDCG 2025-10 section that requires it. If you cannot, it comes out. If you can, but the element is not actually running, it gets fixed or it comes out.

The mistakes in this post are not the result of startups doing too little. They are often the result of doing too much of the wrong thing. Writing an elaborate plan that nobody executes, building complaint forms that nobody can trend, producing PSURs that copy-paste the previous cycle. The fix is subtraction plus execution. Strip the plan to what the articles require. Execute every element that remains. Every line of the plan traces to an article. Every article traces to an activity the team actually performs.

This is a lean PMS system. It is not a token PMS system. It survives an audit because every activity has a reason, and every reason has a citation.

Reality Check. Where do you stand?

  1. When was the last time your PMS plan was updated? If the answer is "at CE marking," start there.
  2. Can you trace a specific PMS finding from the last review cycle into a specific update of the risk file or the clinical evaluation? If no updates happened, can you document that none were warranted?
  3. If someone aggregated every complaint from every intake channel over the last six months into one table, could you run a trend analysis on it? If not, the intake is not structured.
  4. Does your current PSUR or PMS Report contain every Article 86 or Article 85 content element by name, populated from real data? Is the cadence correct for your device class?
  5. Name two proactive PMS methods in your plan that you actually ran in the last cycle. If you cannot name two, your system is reactive-only.
  6. When was the last time your CER was updated with PMS findings, or documented as reviewed with no update warranted? If the CER has not been touched since CE marking, this is a finding waiting to happen.
  7. When was the last time you compared your live website and marketing materials against the authorised intended purpose in your technical file? "Never" is the most common answer and the most dangerous one.
  8. For your PMCF plan: which activities have actually been executed in the last 12 months, with documented evidence? If the answer is none, either start executing or rewrite the plan honestly.
  9. For each activity currently in your PMS plan, can you cite the specific MDR article, annex, or MDCG guidance that requires it?
  10. Have you read MDCG 2025-10 end-to-end, or only skimmed the executive summary?

Frequently Asked Questions

Which of these eight mistakes is the most common?

Mistake 1. A PMS plan written once and never updated. Appears in roughly every first audit we see with a startup. It is almost universal. The second most common is Mistake 8, the PMCF plan that exists but is not executed. Together these two account for a large share of PMS-related non-conformities.

Which mistake is the most dangerous?

Mistake 2. PMS disconnected from risk management. Is the one that allows real patient harm to go undetected. The sleep arm strap case was caught because that loop was closed. Had it not been, the skin irritation problem would have scaled with the install base until it became a field safety issue.

Can a small startup run a PMS system that avoids all eight mistakes?

Yes. A three-person company can run a PMS system that satisfies every Article 83 to 86 obligation, if the system is built lean and executed consistently. Volume of documentation is not the requirement. Traceability to the articles and consistent execution are the requirement. See the Subtract to Ship angle above and the minimum viable PMS walkthrough for the practical shape of a lean system.

Does MDCG 2025-10 override any of these requirements?

No. MDCG 2025-10 is guidance, not legislation. It is the Medical Device Coordination Group's operational interpretation of how PMS systems should work in practice, published in December 2025. The Regulation itself is the binding source. MDCG 2025-10 is the document notified bodies use to assess whether a PMS system is running correctly, and it is worth reading in full before a surveillance audit.

If my PMS system has several of these mistakes, where do I start?

Start with Mistake 1. Update the PMS plan. Because every other fix depends on having a current plan to fix against. Then close the risk management loop (Mistake 2) and the CER loop (Mistake 6), because these are the highest-leverage connections. Then structure complaint handling (Mistake 3) so trend analysis becomes possible. Then address the proactive methods (Mistake 5), the PSUR content (Mistake 4), the claims drift (Mistake 7), and the PMCF execution (Mistake 8). The order is not strict, but anchoring to the plan update first makes every subsequent fix traceable.

Is the vigilance reporting under Articles 87 to 92 a separate system from PMS?

No. Vigilance under Articles 87 to 92 is the regulatory reporting channel that the PMS system feeds when specific thresholds are crossed, including the reporting of serious incidents under Article 87 and field safety corrective actions. MDCG 2023-3 Rev.2 (January 2025) is the Q&A guidance on vigilance terms and concepts. A PMS system that cannot reliably surface events meeting the vigilance thresholds is also a PMS system that violates Article 83. The two obligations are connected at the hip. See what is vigilance under MDR for the vigilance side of the system.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 2(12) (intended purpose), Article 61 (clinical evaluation, including Article 61(11) on lifecycle update), Articles 83 to 86 (post-market surveillance system, plan, PMS Report, and PSUR), Articles 87 to 92 (vigilance reporting of serious incidents, trend reports, FSCAs, and related obligations), Annex III (technical documentation on post-market surveillance), and Annex XIV Part B (post-market clinical follow-up). Official Journal L 117, 5.5.2017.
  2. MDCG 2025-10. Guidance on post-market surveillance of medical devices and in vitro diagnostic medical devices. Medical Device Coordination Group, December 2025.
  3. 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.
  4. EN ISO 13485:2016 + A11:2021. Medical devices. Quality management systems. Requirements for regulatory purposes.
  5. EN ISO 14971:2019 + A11:2021. Medical devices. Application of risk management to medical devices.

This post is part of the Post-Market Surveillance & Vigilance series in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. Every mistake in this list has been observed in real startup audits. Every fix is anchored to the specific MDR article that makes the mistake a non-conformity.