MDR requires post-market surveillance data to feed back into the risk management file, and EN ISO 14971:2019+A11:2021 specifies exactly how. Article 83(3) of Regulation (EU) 2017/745 names "updating the benefit-risk determination" and the design and manufacturing information as required uses of PMS findings. The harmonised standard operationalises this through its production and post-production information requirements: the manufacturer must establish, document, and maintain a system to collect and review information about the device in the production and post-production phases, assess that information for safety relevance, and act on it by updating the risk management file. Annex I of the MDR ties the loop shut by requiring risk management to run throughout the lifecycle as a general safety and performance requirement. A closed CAPA with no corresponding risk-file update is the single most common integration finding at audit.

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

TL;DR

  • MDR Article 83(3) explicitly names updating the benefit-risk determination, the design and manufacturing information, and the clinical evaluation as required uses of PMS findings — the risk feedback loop is written into the Regulation, not borrowed from the standard.
  • EN ISO 14971:2019+A11:2021 requires a production and post-production information system that collects, reviews, and acts on real-world data for safety relevance across the device lifecycle.
  • Annex III of Regulation (EU) 2017/745 requires the PMS plan to describe how findings are used, including for updates that flow into the risk file.
  • Annex I of the MDR establishes risk management as a lifecycle obligation — the risk file is never "done."
  • The four-step loop is: collect, assess for safety relevance, update the risk file, verify the updates took effect in design, labelling, IFU, or controls.
  • Auditors walk the loop from a single complaint to a signed risk-file revision. If any step is missing, the finding is systemic.

The arm strap that forced a risk-file rewrite

A small MedTech company we worked with launched a sleep-monitoring device with a sensor strapped to the upper arm. Biocompatibility was tested against EN ISO 10993-1 before market. The notified body accepted the file. The device shipped. Weeks in, the skin-irritation complaints started arriving — mild at first, then a handful that were not mild. The pattern was consistent: extended wear, perspiration, the specific textile-polymer interface that had never been tested against weeks of continuous contact in real conditions.

The PMS intake logged the complaints. Trend analysis ran. The assessment concluded that a hazard the risk file had rated low — "skin irritation from prolonged contact" — was occurring at a rate meaningfully above the pre-market estimate. That assessment is where the feedback loop actually lives. The risk file under EN ISO 14971:2019+A11:2021 was reopened. The occurrence estimate was revised upward. The severity estimate held. The residual risk for that hazard moved. New risk control measures were added: a revised material specification, an updated instruction for use warning about prolonged wear under perspiration, and a labelling change. The benefit-risk determination under Article 83(3) was refreshed. Effectiveness was verified in the next review cycle when the complaint rate dropped to zero.

One complaint channel. One risk file. One closed loop. This post walks that loop step by step, against the specific MDR and standard provisions that require each step.

What the loop actually is

The risk-management feedback loop is not an abstract diagram. It is a sequence of four operations that the PMS system performs on every signal that arrives from the field, and the sequence is specified across three documents: Article 83 of the MDR, Annex I of the MDR, and the production and post-production clause of EN ISO 14971:2019+A11:2021.

The four operations are collect, assess, update, verify. Each one maps to a specific requirement. Collect is Article 83(2) "actively and systematically" gathering data. Assess is the safety-relevance review that the harmonised standard requires. Update is Article 83(3) "updating the benefit-risk determination" plus the standard's requirement to revise the risk management file when new information changes the risk picture. Verify is the effectiveness check that closes the loop — the updated controls must actually reduce the risk they were introduced to reduce, and that has to be demonstrated, not assumed.

A PMS system that performs three of the four operations and skips the fourth is an open loop. An open loop is a finding waiting to happen. MDCG 2025-10 (December 2025), the current operational guidance on PMS, describes PMS as an interaction between QMS processes and explicitly names risk management as one of the processes PMS must feed. The guidance does not invent the obligation — it reinforces what Article 83(3) and Annex I already require.

What EN ISO 14971:2019+A11:2021 says about production and post-production information

The harmonised standard for risk management is the document that translates the MDR's high-level lifecycle obligation into the specific operational machinery. EN ISO 14971:2019+A11:2021 is named in the condensed regulatory ground truth catalogue as the cornerstone standard for Annex I GSPR 1-9, and Annex I GSPR 3 in particular establishes risk management as a continuous iterative process across the lifecycle.

The standard requires the manufacturer to establish, document, and maintain a system to collect and review information about the device in the production and post-production phases. The information comes from the manufacturer's own channels — manufacturing, servicing, complaint handling, vigilance — and from external channels — published literature, user groups, similar-device recalls, and registries where they exist. The system then reviews this information for safety relevance. The review asks two specific questions: is there new information about the device that affects the risk analysis, and is there information about previously unrecognised hazards, hazardous situations, or harms. If the answer to either is yes, the risk management file is updated.

The update is not a line in a log. It is a formal revision of the risk file: the hazard identification may change, the risk estimate may change, the risk control measures may change, the residual risk evaluation may change, and the overall risk-benefit conclusion may change. Each of these changes has downstream consequences in the technical file, the labelling, the IFU, and sometimes the design itself. The standard specifies that the results of the review shall be fed into the risk management process — which is exactly the loop Article 83(3) names when it lists the required uses of PMS findings.

The production and post-production information clause is the single most cited section of the standard in audit findings related to PMS integration, because it is the bridge. Without it, the PMS system and the risk file are two separate binders that share no data. With it, they are one integrated process.

The data sources that feed the loop

The inputs to the loop come from both the reactive and proactive sides of the PMS system. The distinction matters because the standard's production and post-production clause does not care which side the information came from — it cares whether the information is safety-relevant. The sources are the ones already named in Annex III, Section 1.1 of the MDR and in MDCG 2025-10:

Complaints and user feedback — the reactive channel that most startups build first. Every logged complaint runs through safety-relevance assessment as part of the PMS workflow, and relevant ones trigger a risk-file review. Serious incident and FSCA data — the vigilance stream, which is always safety-relevant by definition. Returns and service records — the under-used channel that often reveals patterns the complaint channel misses. Trend analysis outputs — the statistical layer on top of reactive data, driven by Article 88. Literature surveillance — the proactive source that catches signals the manufacturer's own users have not generated. Similar-device monitoring — recalls and FSCAs on comparable devices, which can change occurrence estimates for hazards the risk file already identified. PMCF data — the clinical arm of proactive PMS under Annex XIV Part B, which feeds both the clinical evaluation loop and the risk management loop. Registry data and user surveys where they apply.

For the reactive and proactive split and how to run both halves in a small team, see proactive vs. reactive PMS. For the vigilance side of the intake, see trend reporting under MDR Article 88. For the integrated PMS-vigilance-CAPA picture that sits next to this risk-management loop, see the PMS, vigilance, and CAPA relationship under MDR.

The update cadence — scheduled and event-driven

Two separate cadences drive the loop, and both have to run.

The scheduled cadence is the review rhythm the PMS plan names under Annex III. For a low-volume Class I device this might be a monthly complaint review and a quarterly consolidated PMS review feeding a risk-file review checkpoint. For a Class IIb or Class III device the cadence increases and ties directly to the annual PSUR under Article 86. On every scheduled review, the question is asked formally: has anything in the PMS data since the last review cycle changed the risk picture, and if yes, what risk-file updates follow. A review with "no changes" as the outcome is a valid outcome — as long as the review actually ran and is documented. A review that never ran is a finding.

The event-driven cadence is the trigger that bypasses the schedule. A single serious incident does not wait for the next quarterly review. A single literature hit that identifies a previously unrecognised hazard does not wait either. The PMS plan has to name the trigger criteria that force an immediate risk-file review outside the scheduled rhythm — typically any serious incident under Article 87, any trend signal crossing the Article 88 threshold, any similar-device FSCA with direct relevance, or any new hazard identification from any source.

Both cadences feed the same risk file. The scheduled cadence catches drift. The event-driven cadence catches shocks. A PMS plan that only describes one of the two is incomplete.

What auditors actually check

A notified body auditor assessing this loop does not read the risk file in isolation or the PMS plan in isolation. The auditor picks a single post-market event — often the most recent complaint or trend signal in the log — and walks it across both documents. Given this event, show me the intake record. Show me the safety-relevance assessment. Show me the decision on whether the risk file needed updating. If it needed updating, show me the revised risk file entry with the date, the author, and the changes. Show me the updated risk controls. Show me the effectiveness verification that the controls actually work. Show me the corresponding updates to the IFU, the labelling, or the design if the controls affected them. Show me the PMS Report or PSUR entry that reflects the update.

If every step produces a linked record, the loop is real. If the complaint log exists but the risk file has not changed in eighteen months despite multiple relevant signals, the loop is not real. If the risk file has been updated but the updates never propagated into the IFU or the design, the loop is not real. If the CAPA closed but the risk file still reflects the pre-event estimates, the loop is not real.

The single most common finding across the certifications we have supported is exactly this: a closed CAPA with no corresponding risk-file update. The CAPA worked in isolation, but the integration point with the standard was never touched. This is a systemic finding, not a document finding, and it is harder to close because it shows the system does not actually run as a system.

Common loop failures

Five patterns repeat across startup PMS files, and each one has a specific fix.

First, the risk file is treated as a pre-market deliverable. The file was built for the notified body, signed off at CE marking, and archived. No scheduled review is written into the PMS plan. Fix: the PMS plan names the risk-file review cadence and the owner, and every PMS Report or PSUR confirms the reviews ran.

Second, safety-relevance assessment exists only in people's heads. Complaints are logged, someone "thinks about" whether they are safety-relevant, and no record of the thinking exists. Fix: the PMS workflow produces a written safety-relevance decision on every complaint, even when the decision is "not safety-relevant."

Third, the risk file is updated but the IFU and labelling are not. A new hazard is recognised, a new control is added — and the control lives in the risk file while the device ships with the old IFU. Fix: the risk-file update checklist includes mandatory propagation entries for IFU, labelling, and design change control.

Fourth, effectiveness verification is skipped. The control is added, the file is updated, and nobody checks whether the control actually reduced the risk. Fix: effectiveness verification is a defined step in the loop with its own evidence requirement and its own review cycle.

Fifth, external signals never enter the loop. Literature hits and similar-device recalls never make it to the safety-relevance assessment because the proactive channel is not actually running. Fix: the proactive PMS programme from proactive vs. reactive PMS runs on a real cadence and feeds the same intake funnel as the reactive channel.

Each of these is cheap to fix before an audit and expensive to fix after a finding.

The Subtract to Ship angle

The Subtract to Ship framework for MDR applied to the PMS-risk loop produces a single rule: run one loop with one cadence, feeding one risk file, with one owner in a small team. Everything that does not trace to Article 83(3), Annex I, Annex III, or the production and post-production clause of EN ISO 14971:2019+A11:2021 is waste. Everything that does trace must actually run.

What subtraction removes: duplicate risk files for different device variants that could share one file, parallel safety-review meetings that re-litigate the same decisions, speculative risk analyses of hazards that cannot occur on this specific device, and elaborate dashboards that summarise data nobody reviews. What subtraction keeps: the intake channel, the safety-relevance decision, the risk-file revision log, the propagation checklist into IFU and labelling, the effectiveness verification, and the confirmation in the PMS Report or PSUR. That is the full loop. A three-person startup can run it. A thirty-person startup without the discipline cannot.

The test is the same test the framework always uses. For every element in the loop, name the specific MDR article, annex, or harmonised standard clause it satisfies. If yes, keep it. If no, cut it. The loop that survives the test is the loop that closes — and the loop that closes is what turns a signal from the field into a safer device on the market.

Reality Check — where do you stand?

  1. Open your PMS plan. Find the section that describes how findings feed into the risk management file. If the section does not exist or says only "findings will be reviewed," the loop is not documented.
  2. When was the last signed revision of your risk management file, and was it driven by a post-market signal or only by a design change?
  3. For the most recent complaint you received, can you produce a written safety-relevance assessment that names whether the risk file needed updating?
  4. Does every closed CAPA in the last twelve months have a corresponding risk-file entry, or are the two systems running in parallel without crossing?
  5. When a new risk control is added, is there a checklist that forces propagation into the IFU, the labelling, and the design change-control process?
  6. Does your PMS plan name both a scheduled risk-file review cadence and the event-driven triggers that force an unscheduled review?
  7. Is literature surveillance output actually reaching the safety-relevance assessment, or does it stop at a log nobody reads?
  8. If a notified body auditor picked one complaint at random and asked you to walk from intake to risk-file revision to effectiveness verification, would every step produce a record?

Frequently Asked Questions

Does MDR require PMS to feed the risk management file?

Yes. MDR Article 83(3) of Regulation (EU) 2017/745 names updating the benefit-risk determination, the design and manufacturing information, and the clinical evaluation as required uses of PMS findings. Annex I establishes risk management as a lifecycle obligation. EN ISO 14971:2019+A11:2021 operationalises the loop through its production and post-production information requirements.

What is the production and post-production information system in EN ISO 14971:2019+A11:2021?

It is the mechanism the harmonised standard requires for collecting and reviewing real-world data about the device during manufacturing and after placing on the market. The system assesses the data for safety relevance and feeds relevant findings back into the risk management file, which is updated when the findings change the hazard identification, the risk estimate, the controls, or the benefit-risk conclusion.

How often does the risk file need to be updated?

There is no fixed calendar in the Regulation. The risk file is updated on two cadences: a scheduled review rhythm named in the PMS plan, and an event-driven trigger for serious incidents, trend signals, or new hazard identifications. Class IIb and Class III devices typically run the scheduled cadence on the annual PSUR rhythm under Article 86.

What is the most common audit finding on this loop?

A closed CAPA with no corresponding update to the risk management file. The corrective action worked, the file was closed, and the risk file still reflects the pre-event estimates. Auditors read this as a systemic integration failure, not as a document gap.

Does every complaint trigger a risk-file update?

No. Every complaint triggers a safety-relevance assessment, and the assessment determines whether a risk-file update is needed. Many complaints resolve as "not safety-relevant" — what matters is that the decision is documented and defensible, not that the risk file changes on every entry.

Sources

  1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 83 (post-market surveillance system of the manufacturer, including Article 83(2) on active and systematic data gathering and Article 83(3) on required uses of PMS findings), Article 84 (post-market surveillance plan), Annex I (general safety and performance requirements including risk management as a lifecycle obligation), and Annex III (technical documentation on post-market surveillance). Official Journal L 117, 5.5.2017.
  2. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices, including the requirements on production and post-production information.
  3. MDCG 2025-10 — Guidance on post-market surveillance of medical devices and in vitro diagnostic medical devices. Medical Device Coordination Group, December 2025.

This post sits inside the Post-Market Surveillance & Vigilance series in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. The risk-management feedback loop is what turns a PMS system from a logging exercise into a safety mechanism — the companion posts in this cluster walk the intake, the assessment, and the integration with the other post-market processes that depend on the same signals.