At first glance, this may seem like a structural issue.

But the real reason runs deeper.

Mapping reinforces a checklist mindset - aligning clauses, matching requirements, and demonstrating coverage. This is how many organizations approached the QS regulation: element by element, requirement by requirement.

ISO 13485, and by extension QMSR, expects something different.

It is built on a process-based model, where activities are interconnected and risk is integrated across the system. Compliance is not demonstrated by mapping requirements, but by how effectively the system operates as a whole.

You can map requirements and call it a gap assessment.

But you cannot map process interactions, risk-based decision making, or system effectiveness.

This is why mapping often creates alignment on paper, but not effectiveness in practice.

FDA also reinforces that ISO 13485 compliance does not automatically mean QMSR compliance. Additional requirements and regulatory expectations still apply, and subtle differences matter.

The implication is clear.

Transitioning to QMSR is not a documentation exercise. It is a shift in how the quality system is designed, managed, and evaluated.

Mapping may help you orient.

But it will not get you there.

So, think about this question and share your opinion in the poll below:

👉How is your organization approaching the transition from QS to QMSR?

This is a guest article by Pujitha Gourabathini.

Lifecycle risk integration has been discussed for years. It appears in standards. It shows up in quality plans. And yet, walk into a typical device company today and you will still find risk management living in a folder, reviewed at milestones, and largely invisible between design transfer and complaint review.

That is not integration. That is documentation with good intentions.

QMSR changes the expectation. To be precise, it does not introduce a new concept. It raises the bar on an old one. Lifecycle risk integration is not new. What is new is that the regulatory framework now expects you to demonstrate it, not merely declare it.

What Lifecycle Risk Integration Actually Looks Like

Let’s start with a few examples that occur in real product programs, often without anyone recognizing them as failures of risk integration.

Example 1: The design input that never connected to a hazard

A development team is designing an infusion pump. They produce a thorough hazard analysis and a strong set of design inputs that capture clinical performance requirements. Both documents exist. Both are approved. Both sit in the design history file.

The problem is that they were written by different people, in different phases, with no formal linkage between them. The hazard analysis identifies occlusion-detection failure as a top risk. But when you trace that back to the design inputs, there is no requirement that explicitly addresses detection sensitivity, response time, or alarm threshold, the very parameters that would control that hazard.

The risk file says the hazard is addressed by design. The design inputs do not say how. At design review, no one notices because no one is looking across both documents at the same time.

This is not a documentation failure. It is an integration failure. Risk management was performed. It just wasn’t connected to the decisions it was supposed to inform.

Example 2: The complaint signal that never reached the risk file

A Class II diagnostic device has been on the market for three years. Complaints are received and handled according to established procedures. They are investigated, closed, and filed away.

For six months, the complaint rate for a specific failure mode has been trending upward: calibration drift that occasionally produces out-of-range results. Each individual complaint is evaluated, deemed not reportable, and closed.

Meanwhile, the risk management file, approved at design transfer, still estimates the probability of that failure mode as “remote” based on pre-launch verification data.

Nobody updates the risk file. Nobody re-evaluates residual risk. Nobody asks whether the benefit-risk conclusion that supported market release is still valid now that three years of real-world evidence exist.

The complaint process is working as designed. The post-market surveillance process is working as designed. The risk management process is not. Why? Because risk management, as practiced, has no mechanism for receiving post-market inputs and no real trigger to update when those inputs arrive.

Lifecycle risk integration means the risk file is a living document. Not living because a procedure says so. Living because it actually changes when the evidence changes.

Example 3: The supplier change that bypassed the risk file entirely

A contract manufacturer substitutes a component, for example a sealant used in a Class III implantable device, citing an equivalent material from a different supplier. The change-control process is followed. A technical assessment is completed. The engineering team reviews biocompatibility data and concludes equivalence. The change is approved.

The risk management file is never consulted. No one checks whether that sealant was identified as a risk factor in the hazard analysis. No one verifies whether the existing residual-risk estimate depended on the specific material properties of the original supplier. The risk file remains unchanged.

Eighteen months later, a field signal emerges. It traces back to a long-term leachable that behaves differently under physiological conditions in the substituted material. The risk file still shows residual risk as acceptable. The actual risk, based on what is now happening in patients, is not.

The change control process didn’t fail. The risk management process did, because it was never meaningfully built into change control in the first place.

What Lifecycle Risk Integration Really Means Under QMSR

Let’s be direct. Much of the industry conversation around QMSR and risk integration has been too polite.

Risk management is not a phase. Treating it like one is a compliance fiction the industry has lived with for decades.

Most risk management files in our industry are snapshots, not systems. They are written for regulatory compliance. They are officially finalized at design transfer, mostly as a check-the-box. After that, they are referenced, but rarely revised. We have been calling this “lifecycle risk management” while practicing phase-gate risk documentation. QMSR calls that bluff.

If your risk management file does not change when your post-market data changes, you do not have a risk management system. You have a risk management record.

That distinction matters. And by aligning with ISO 13485’s full system requirements, QMSR gives FDA a clearer regulatory basis to distinguish between the two during inspection. An investigator asking for evidence that post-market information feeds back into the risk file is no longer unusual. It is the expectation.

Integrated risk management is not a cross-reference in the design history file. It is a decision-making behavior embedded in the quality system.

For too long, we have confused traceability with integration. You can have perfect traceability, requirement to hazard to verification to validation, and still have a risk management process that exerts little or no influence on supplier qualification, change control, CAPA investigations, or complaint trending. Traceability is a record. Integration is a practice.

Your quality system is not risk-based because your procedures say it is. It is risk-based when risk information actually drives decisions.

“Risk-based” may be one of the most overused and under-demonstrated phrases in the industry. Procedures declare a risk-based approach. Policies reference ISO 14971. Training records show completion. And then daily quality-system decisions unfold with no meaningful connection to the risk information that should be informing them. Under QMSR, that disconnect becomes visible in audits, inspections, and eventually outcomes.

QMSR did not create a new obligation. It gave FDA a stronger basis to cite what has long been missing.

The five chronic pain points of FDA inspections - Design Controls, CAPA, Complaints, Supplier Controls, and Nonconforming Product - have often been risk-integration failures in disguise. They were cited under QSR. They can now be cited more explicitly under QMSR because FDA has the language, structure, and cross-reference to make those expectations more direct.

The question QMSR asks is not: “Do you have a risk management file?”

It asks: “Does your risk management process actually govern your quality system, or does your quality system merely acknowledge that risk management exists?”

The Wheel That FDA Drew, and What It’s Really Saying

Look at the FDA’s diagram1 for risk-based medical device inspections. You will notice something immediately.

Risk management is not one of the spokes. It is the hub.

Every element of the quality system – Management Oversight, Design and Development, Production and Service Provision, Change Control, Outsourcing and Purchasing, Measurement and Analysis, and all Other Applicable FDA Requirements – connects to the center. And at the center: Risk Management. With Patients and Users at its core.

That is not decorative. It is structural.

The diagram is a statement about how FDA expects these systems to relate to one another. It is not aspirational. It is descriptive of what FDA now expects to find when it inspects a quality system. Risk management at the center means risk information driving decisions in every direction: upstream into design, downstream into production, outward into suppliers and customers, and back again through post-market data.

That is what lifecycle risk integration means.

Not a file.

Not a phase.

A system that actually turns.

In Part 2 of this series, we will take a recent FDA warning letter and map its observations directly onto this wheel, node by node, to show what lifecycle risk integration failure looks like in regulatory language, and what it costs.

If this framing resonates with you, or challenges something you have long assumed, I would love to hear your perspective in the comments.

Leave a comment

About Pujitha Gourabathini

Pujitha Gourabathini is a quality and patient-safety leader at Becton, Dickinson and Company (BD), where she leads initiatives that strengthen lifecycle safety, elevate engineering-for-safety practices, and build regulatory confidence through robust application of ISO 14971, Safety Assurance Cases, and evidence-based risk frameworks. She is passionate about medical device risk management and patient-safety-first principles, and committed to advancing that conversation across the broader community.

Disclaimer: This article is intended for educational and informational purposes only and should not be interpreted as legal, regulatory, or professional advice. The views expressed here are solely those of the author and do not necessarily represent those of their organization or employer. ChatGPT was used during the drafting and editing process, and the final content was reviewed by the authors to ensure it met our publication standards.

FDA explains that ISO 13485 already embeds expectations for communicating and addressing quality issues through complaints, nonconforming product, and corrective action. But what is especially insightful is where FDA places emphasis next:

Measurement and monitoring apply not only to product nonconformities, but also to process and quality system nonconformities.

This is a major blind spot in many organizations.

Most MedTech firms are reasonably good at identifying product nonconformities. Defects, rejects, complaints, and returned product are visible and tend to get attention quickly.

But process and quality system nonconformities are often treated differently. They are tolerated, normalized, or managed indirectly.

As an example, the focus shifts to closing CAPAs on time rather than ensuring they are truly effective. Recurrence of the same issue is then treated as a new event, rather than evidence that the corrective action process itself may be nonconforming.

Timeliness matters. But timeliness is not effectiveness. A CAPA closed on time but ineffective is not evidence of control. It may be evidence of a weak corrective action process.

FDA’s example makes this point practical. If a molding process historically runs at a 5% rejection rate and that rejection rate increases to 10%, the issue is not only the added defective product. The process itself has drifted out of its expected state and should be investigated and corrected.

That is the essence of a process-based approach described in Clause 0.3.

If you only monitor product failures, you are managing outputs. QMSR expects you to monitor, measure, and improve the processes and quality system conditions that generate those outputs.

This is where Clauses 8.2.5 (monitoring and measurement of processes),
8.2.6 (monitoring and measurement of product), 8.3.1 (control of nonconforming product - general), and 8.5.2 (corrective action) work together.

Product nonconformities matter. But so do process and system nonconformities, and both must be addressed based on risk.

A mature QMS does not wait for defects to prove the process has failed.

It detects when the process itself is drifting out of control.

So, think about this question and share your opinion in the poll below:

👉In your organization, which type of nonconformity receives the most management attention?

It is useful to recognize that the Introduction section in ISO 13485:2016 does not add new requirements. Rather, it provides guidance on how the standard is meant to be understood and implemented.

Clause 0.2 - Clarification of concepts is particularly insightful - is particularly insightful, especially in how it frames the concept of risk.

Most teams in MedTech understand risk through the ISO 14971 lens, in terms of hazards, hazardous situations, severity, probability, and risk control measures. They all center around the risk of harm.

But ISO 13485 takes a broader view.

Risk includes the ability to meet both:

• safety and performance requirements

• applicable regulatory requirements

This is not just conceptual.

In the context of QMSR, Clause 4.1.2(b) makes it operational:

apply a risk-based approach to the control of appropriate processes needed for the quality management system.

Risk, therefore, is not confined to designing and launching safe and effective devices.

It determines:

• how processes are prioritized

• how controls are applied

• how effectiveness is evaluated

• how decisions are made to sustain safety, performance, and regulatory compliance

ISO 14971 remains essential for product risk.

ISO 13485 extends risk into how the system itself is designed and managed to achieve consistent outcomes.

Risk management is not an isolated function.

It is the backbone — and operational logic — of the entire QMS.

So, think about this question and share your opinion in the poll below:

👉In your organization, how is “risk” primarily interpreted in the QMS?

It is a mistake to treat these notes as secondary when developing procedures and work instructions.

They clarify how requirements are intended to be implemented.

While not enforceable, ignoring them often exposes vulnerabilities in execution.

Consider two specific examples:

Clause 6.2: Human resources

This clause focuses on competence of personnel whose work affects product quality, not just their training. The note in this clause adds something that most system ignore:

NOTE: The methodology used to check effectiveness is proportionate to the risk associated with the work for which the training or other action is being provided.

Training completion is not evidence of competence. Effectiveness of training and other actions needs to be demonstrated, and it must be risk-based.

Yet most organizations apply the same training model across all roles. There is little distinction between low-risk operational tasks and high-risk design or decision-making roles.

This is an area of significant vulnerability and FDA is likely to pay close attention to it in future inspections.

Clause 7.1: Planning of product realization

The main requirement in this clause calls out for documenting one or more processes of risk management in product realization.

The note points directly to ISO 14971:

NOTE: Further information can be found in ISO 14971.

This is not accidental.

Even though ISO 13485 (and QMSR) does not mandate ISO 14971, this note makes it clear that risk management in product realization is expected to follow a framework consistent with ISO 14971.

Here is the real insight: the notes in ISO 13485 are doing something subtle but tremendously consequential. They translate requirements into expected behavior:

• The clause tells you what must exist

• The note hints at how it must function

Further, risk-based thinking must extend beyond documentation into how the system operates across people and processes.

Why this matters under QMSR

FDA is not going to assess compliance to the notes in ISO 13485.

But if your system fails to demonstrate effective implementation, the notes are often the clearest indication of what “effective” was supposed to look like.

Checklist compliance may satisfy the clause. It will not sustain the system.

So, think about this question and share your opinion in the poll below:

👉What role do ISO 13485 notes play in your QMS?

Does it mean that FDA does not expect device manufacturers to apply best practices codified in these standards?

This is certainly not true.

Sure, FDA cannot issue a warning letter simply for not implementing ISO 14971. But here is the practical reality:

If you choose not to use a framework of similar rigor, you will have a difficult time demonstrating that your risk management process is effective, or that your risk-based decisions are well-founded.

ISO 13485 requires a risk-based approach across the quality management system. QMSR reinforces that expectation. The burden is on the manufacturer to define, implement, and justify how risk is managed across the lifecycle.

ISO 14971 provides a proven framework to do exactly that. Additionally, FDA has already recognized ISO 14971 as a voluntary consensus standard.

So while FDA is not mandating ISO 14971, it is implicitly expecting outcomes that are consistent with it.

For leadership teams, the question is not which standard you claim to follow.

It is whether your system can consistently support sound, defensible decisions under uncertainty - across design, suppliers, production, complaints, CAPA, and management review.

QMSR does not mandate ISO 14971 for regulatory compliance. It requires what ISO 14971 is designed to achieve within the Quality Management System.

So, think about this question and share your opinion in the poll below:

👉How mature is ISO 14971 implementation in your QMS?

There is a clear desire in industry to obtain a yes/no answer from FDA on equivalence between ISO 13485 and QMSR. But as we have discussed in recent posts, FDA has responded carefully, and consistently.

ISO 13485 compliance is not sufficient for QMSR compliance.

And the reverse is also true: QMSR compliance does not automatically demonstrate compliance in other jurisdictions, even when those systems are grounded in ISO 13485.

But the more important point is this:

The issue is not regulatory equivalence. It is operational integrity.

ISO 13485 was never intended to be a checklist. It rests on two core principles:

• A process-based quality management system

• Risk management integrated throughout the lifecycle

QMSR reinforces both.

If your system truly integrates risk across design, supplier controls, production, complaints, CAPA, and management review, then structural alignment with ISO 13485 follows naturally.

If risk remains siloed - confined to design files or treated as documentation - no amount of clause mapping between standards will produce operational strength to satisfy regulatory expectations.

Regulatory sovereignty will always exist. Certifications will always have jurisdictional boundaries.

Maturity is demonstrated by how risk governs decisions across the system — not by whether two frameworks can be declared equivalent.

QMSR reduces structural differences.

Lifecycle risk integration determines regulatory resilience.

So, think about this question and share your opinion in the poll below:

👉How embedded is lifecycle risk management in your QMS today?

In fact, ISO 13485 is already widely used for regulatory purposes. Under the EU-MDR, conformity assessment by Notified Bodies is grounded in ISO 13485 requirements. Many global manufacturers structure their QMS around it precisely because it supports multi-jurisdictional compliance under MDSAP.

MDSAP audits evaluate ISO 13485 plus applicable regulatory requirements of participating authorities. For those regulators that accept MDSAP, audit results may substitute for routine inspections.

But FDA’s message in Comment #7 is subtle and important.

Acceptance of MDSAP audit results does not eliminate FDA’s authority to conduct for-cause or unannounced inspections. Nor does incorporation by reference reduce FDA’s enforcement discretion.

The signal is clear:

ISO 13485 may be globally harmonized. MDSAP may be accepted in multiple jurisdictions. But under QMSR, ISO 13485 clauses now carry enforceable regulatory weight in the U.S.

This has two practical implications.

First, FDA can cite noncompliance directly to specific ISO 13485 clauses because they are incorporated into regulation. The standard is no longer just a certification benchmark, it is part of U.S. law.

Second, certification does not immunize an organization from FDA scrutiny. MDSAP may replace routine inspections, but it does not replace broad FDA authority.

For manufacturers, this should shift the focus from “Do we have the certificate?” to “Does our QMS operate in a way that withstands regulatory enforcement?”

And this is where a recurring vulnerability appears: lifecycle integration of risk management.

Under QMSR, risk management is not a document set. It is the connective logic across design, supplier controls, production, complaints, CAPA, and management review. Incorporation by reference means FDA can assess whether that integration is real, not merely documented.

ISO 13485 has always been important. Under QMSR, it is now legally enforceable.

So, think about this question and share your opinion in the poll below:

👉How would you feel about lifecycle risk integration if FDA showed up for an inspection tomorrow?

This is more than a procedural clarification.

If you are already ISO 13485 certified, it may be tempting to believe that your Quality Management System (QMS) is automatically compliant with the QMSR.

However, it is important to understand that while ISO 13485 is a harmonized standard and used for regulatory purposes, it is not equivalent to US Law applicable to medical devices.

FDA highlights a couple of subtle, but important, differences in ISO 13485 definitions and limitations in requirements.

Consider the definition of a “device”. ISO 13485 limits it to include products intended for use in human beings. Section 201(h) of the FD&C acts, on the other hand, defines the term “device” as including articles intended for use in man or other animals, and even explicitly includes counterfeit devices within its scope2.

Now consider “labeling”.

FDA has added more requirements for device labeling and packaging controls in Clause 820.45 in the QMSR in the context of Clause 7.5.1 Control of production and service provision in ISO 13485.

As an example, QMSR explicitly requires manufactures to ensure labeling and packaging is examined for accuracy prior to release or storage, and to include specific details to ensure identity and integrity.

The message is clear: ISO 13485 provides the system framework. U.S. law defines the regulatory boundaries.

Certification demonstrates conformity to a standard. Compliance requires alignment with statutory definitions and device-specific FDA requirements.

FDA goes even further in Comment #6, reminding industry that if a device-specific regulation elsewhere in Title 21 conflicts with general Part 820 requirements, the specific rule prevails, but only to the extent of the conflict. The rest of Part 820 still applies.

This is not about complexity. It is about hierarchy.

For leadership teams, the implication is straightforward:

ISO 13485 certification is useful under QMSR, but it is not sufficient to demonstrate U.S. compliance. That requires deliberate interpretation of where FDA’s statutory and regulatory requirements extend beyond the international standard.

So, think about this question and share your opinion in the poll below:

👉In practice, what is most often used internally as evidence of QMSR readiness?

Michelle Lott of contributed to this post.

In a recent Let’s Talk Risk! conversation, we discussed a subtle but consequential shift in FDA’s expectations under QMSR. The short clip below captures the essence of our discussion:

It is no longer just about complying with regulations. That has always been the minimum expectation. Non-compliance creates legal exposure.

But QMSR is signaling something more aspirational.

It is no longer enough to show that procedures exist, that reports were completed, or that findings were closed. FDA now expects organizations to demonstrate that their Quality System actually works, and that it provides ongoing assurance of safety and effectiveness, not just documentation of activity.

And that distinction moves the conversation squarely into leadership territory.

Compliance is the Floor. Assurance is the Aspirational Goal

Compliance answers a narrow question: Did we meet the requirement?

Assurance answers a harder one: Will this system hold under pressure?

Compliance confirms that procedures were followed and reports were completed. Assurance examines whether those procedures consistently lead to expected outcome, especially when timelines tighten, production scales, or unexpected issues arise.

A corrective action can be compliant and still fail to prevent recurrence.
A risk review can be compliant and still fail to influence meaningful decisions.

Compliance can be delegated. Assurance cannot.

That is the cultural shift embedded in QMSR.

QMSR Requirements vs. Intent

Yes, FDA expects you to comply with QMSR. That is non-negotiable. But focusing only on the literal requirements misses the larger point.

Regulatory requirements can be satisfied through documented responsibilities, defined processes, and completed records. With sufficient preparation, organizations can perform well in audits and inspections. Many have done so for years.

But the intent behind QMSR goes further. It is not simply to confirm that a system exists. It is to evaluate whether that system is effective over time, and whether it consistently supports safe and effective products in the real world, not just on inspection day.

Organizations that read QMSR narrowly will prepare for inspection. Organizations that understand its intent will strengthen their operating discipline.

That difference becomes visible in culture.

Culture is the Early Indicator

In a recent QMSR QuickTake, we asked our readers a simple question:

What is the clearest sign of a weak quality culture before audit findings and recalls?

The responses were revealing. Eighty percent selected one of two answers:

• Workarounds become “normal.”

• People are afraid to speak up.

Notice what that means.

The strongest signals of a weak system are not missing documents or late reports. They are behavioral.

When workarounds normalize, discipline erodes. When silence grows, early warning signals are suppressed. When bad news is softened or delayed, leadership loses visibility into emerging risk.

By the time inspection findings appear, assurance has already been compromised.

That is not a documentation problem. It is a leadership problem.

QMSR Preamble is Your Guide to FDA’s Intent

It is tempting to begin a QMSR transition with a clause-by-clause gap assessment. That may address compliance. It will not necessarily address assurance.

FDA’s responses to comments in the QMSR preamble provide critical insights into how the rule will be interpreted in practice. The emphasis is clear: management responsibility, system effectiveness, integration, and risk-based decision-making are not theoretical concepts. They are enforcement priorities.

Investigators are not simply verifying that processes are documented and outcomes recorded. They will evaluate how those processes function together to support consistent and defensible risk-based decisions.

If an investigator follows one issue from complaint intake to corrective action, to supplier oversight, to management review, they are looking for coherence. They are looking for evidence that risk meaningfully informs decisions, not isolated compliance actions.

This is the difference between assurance and compliance.

Why This Shift Feels Uncomfortable

This shift feels uncomfortable because it challenges a long-standing reliance on documentation as proof of control.

For years, many organizations equated robust documentation with robust quality. Detailed procedures, complete records, and successful inspections reinforced that belief.

But documentation demonstrates activity. It does not guarantee effectiveness.

An assurance mindset forces harder questions. Do our decisions consistently prioritize patient safety when tradeoffs arise? Does risk influence timelines and resource allocation appropriately? Are our dashboards reflecting reality, or protecting our current mindset?

Those questions move quality from a functional responsibility to a leadership accountability.

The Leadership Moment

This is the moment for executive teams to look beyond procedural updates and ask more fundamental questions:

• Where does risk truly influence our decisions?

• If a weak signal emerged tomorrow, would it surface quickly?

• Do cross-functional issues tell a coherent story across the system?

• Can we confidently explain why our Quality System works, not just where it is documented?

In the near term, that may mean revisiting how management reviews are conducted, how corrective actions are evaluated for effectiveness, and how leaders model openness to bad news.

It may also mean acknowledging that culture, and not documentation by itself, determines whether assurance is real.

In Closing

QMSR does not simply raise the compliance bar. It raises the leadership bar.

You can meet the requirement and pass inspection. Or you can understand the intent and build a system that withstands pressure.

If an FDA investigator met only your executive team, would they leave confident that your organization delivers ongoing assurance of safety and effectiveness?

That is the leadership question QMSR now places squarely on the table.

Component manufacturers are not required to comply with QMSR. Legal manufacturers of finished medical device are ultimately responsible for regulatory compliance and ensuring safety and effectiveness of their devices.

But FDA’s expectations for component manufacturers are clear. Voluntary compliance with QMSR can provide component manufacturers with a useful framework for achieving quality throughout their organizations. In other words, while QMSR is not mandatory for component manufacturers, FDA clearly views its principles as relevant to the quality and risk profile of components used in finished devices.

This distinction matters because it creates a familiar vulnerability for device manufacturers.

Component manufacturers may operate outside the formal scope of QMSR, yet the parts they produce can directly affect device safety, performance, and clinical outcomes. And when problems arise, FDA’s focus does not shift down the supply chain. The finished device manufacturer remains fully accountable for safety, effectiveness, and QMSR compliance.

So the real question for finished device manufacturers is not whether suppliers are “in scope” for QMSR, but how supplier risk is actively managed.

Common approaches include contractual requirements for ISO 13485 certification, risk-based supplier qualification, and defined quality agreements. But QMSR raises the bar beyond check-the-box controls. If component variability, process drift, or design assumptions can affect finished device risk, then supplier risk information must inform the device-level risk analysis.

That may mean requiring suppliers to share relevant process risk analyses, critical control data, or change-impact assessments that can be integrated into the manufacturer’s overall risk management activities.

Once again, FDA’s intent is subtle but consistent: responsibility follows impact, not organizational boundaries.

For leadership teams, this is a reminder that supply chain strategy and risk governance are inseparable. For QA/RA leaders, it is an opportunity to reposition supplier controls as a core element of lifecycle risk management, not just a procurement or audit function.

So, think about this question and share your opinion in the poll below:

👉How does your organization primarily manage risk from suppliers of safety-critical components?

This is a guest article by Neel Tiwari, MS, PMP.

The Green Metric Lie

Your CAPA dashboard looks healthy. 95% closure rate. 28-day average cycle time. Leadership is satisfied.

But here’s the paradox: if we’re closing issues so fast, why do the same failure modes keep appearing? Why do complaints trend up?

The uncomfortable answer: we aren’t fixing problems faster. We’re redefining problems to be smaller so they can be fixed faster, just to satisfy our performance metric.

This is the hidden vulnerability that remains invisible until it explodes during an FDA inspection.

The Mechanism: Scope Shrinkage

Here’s how it works.

An engineer is assigned a CAPA. The expectation is not always explicit, but generally understood and reinforced by the operating model: “Close this in 30 days.”

They investigate. They find evidence pointing to two possible root causes:

Option A: The extrusion process has a thermal variance that causes intermittent out-of-spec product. Fixing it requires process validation, possibly capital equipment, and cross-functional alignment. Timeline: 3 months minimum.

Option B: An operator on second shift deviated from the work instruction. Fixing it requires retraining and a signature. Timeline: 2 days.

They choose Option B.

The engineer isn’t malicious. They’re responding to incentives and hidden pressures. Option A means a late CAPA, a difficult conversation with their manager, and a red mark on the dashboard. Option B means an on-time closure and a clean metric.

The CAPA closes green. The thermal variance, that is the the actual risk, remains unaddressed.

This is Scope Shrinkage: the systematic narrowing of investigation scope to fit deadline pressure. It’s not a failure of competence. It’s a failure of incentive design.

The Zombie Risk

The consequence is what I call a “Zombie Risk.”

The organization believes the risk is effectively addressed because the CAPA has been closed. But the risk is still present. It’s remains latent in the process, still producing intermittent failures, still accumulating until something triggers a larger event that produces a nonconformance.

The dashboard says “resolved.” The process says otherwise.

Under QMSR, this becomes auditable. FDA’s expectation is explicit: corrective actions must be “appropriate to the effects of the nonconformities encountered.” That’s ISO 13485 Section 8.5.2 language - effectiveness isn’t optional.

When an investigator pulls your CAPA file and asks, “How did you determine this was operator error and not process variation?”, your answer matters. If the answer is “because operator error fit the timeline,” you will likely find it difficult to explain your rationale for effectiveness.

The decision to narrow scope is a risk-based decision. Under QMSR, risk-based decisions require justification. “We needed to hit our KPI” is not a justification.

The Fix: Decouple Scope from Schedule

The instinct is to fix the culture. Train engineers to “do the right thing.” Remind them that quality matters.

That won’t work. You’re fighting incentives with intention. Incentives win.

Instead, fix the process.

One rule: A CAPA deadline should not be set until the scope is locked.

Most organizations start the clock on Day 1, generally by procedure, when the CAPA is opened. This creates immediate pressure to define a closeable scope.

Flip it. Measure two phases separately:

Phase 1: Scoping. From CAPA initiation to scope lock. No deadline pressure. The goal is accurate problem definition, not speed.

Phase 2: Execution. From scope lock to closure. Now the clock runs. The team executes against a defined, justified scope.

This simple change removes the incentive to shrink scope. The engineer can investigate Option A without watching a deadline timer. If the evidence points to thermal variance, they document it, lock the scope, and then the execution clock starts.

You’re not asking engineers to be heroes. You’re redesigning the system so the rational choice is also the right choice.

The Series Ahead

This is Part 1: the vulnerability.

In Part 2, we’ll cover detection: how to spot Scope Shrinkage in your existing CAPA data before FDA does.

In Part 3, we’ll connect this back to Preventive Action, because if your CAPAs are producing Zombie Risks, your PA process is the last line of defense.

For now, one question to ask in your next CAPA review:

“Did we define this scope based on the evidence, or based on the deadline?”

The answer will tell you whether your green metrics are real.

Neel Tiwari is the founder of QMS.Coach and an ISO 13485 Lead Auditor with experience in supplier quality and audit readiness at Medtronic, Edwards Lifesciences, and Endologix.

In adopting ISO 13485, FDA clarifies that manufacturers who require servicing must document those processes and verify that requirements are met. At the same time, FDA explicitly notes that ISO 13485 does not impose the entirety of its requirements on third-party servicers or refurbishers. Therefore, third party servicers and refurbishers are outside the scope of QMSR.

This distinction matters, not because it reduces regulatory exposure, but because it exposes a blind spot for OEMs.

Industry data suggest that third-party servicing and refurbishment are widespread and growing. The AdvaMed report2 on third-party servicing highlights variability in service quality, documentation practices, and feedback loops, and notes that many servicing activities occur outside the manufacturer’s visibility. From a risk perspective, this means a non-trivial portion of device lifecycle exposure may sit beyond the OEM’s direct operational control, yet squarely within its regulatory accountability.

ISO 13485 requires manufacturers to apply risk-based purchasing controls to externally provided processes, products, and services that affect product conformity. Third-party servicing and refurbishment clearly meet that bar. They can alter device performance, invalidate assumptions in the risk file, and introduce failure modes that never existed at release.

FDA’s message in Comment #3 is subtle but firm. QMSR does not require manufacturers to impose full ISO 13485 systems on third-party servicers. But it does expect manufacturers to understand, monitor, and control the risks those activities introduce, using purchasing controls that are commensurate with impact, not convenience.

In other words, outsourcing the activity does not outsource accountability.

For leadership teams, this is a governance issue with real recall and liability implications. For QA/RA leaders, it is an opportunity to reframe purchasing controls as a strategic risk management lever, not a supplier administration exercise.

So, think about this question and share your opinion in the poll below:

👉How are third party servicing risks addressed in your QMS today?

This language matters. FDA is not framing risk management solely as a mechanism to prevent harm or enforce compliance. It is explicitly linking risk management to patient access, technological progress, and innovation in healthcare.

That framing challenges a deeply rooted assumption in many organizations: that risk is inherently negative and that risk management exists primarily to control innovation and ensure compliance. Under QMSR, FDA is signaling a broader intent. Risk management is not just about avoiding failure; it is about enabling confident decisions that balance safety, effectiveness, and timely access to innovation.

Importantly, this does not mean FDA is lowering the bar for safety or relaxing regulatory oversight. FDA’s expectations for compliance with QMSR and ISO 13485 requirements are unlikely to change, and inspections will continue to be grounded in objective evidence and conformance to defined clauses. What FDA appears to be doing here is something different: articulating a higher-level intent, one aimed at encouraging more mature, risk-informed decision making across the industry.

This perspective aligns with emerging innovation domains such as AI/ML-enabled devices, where uncertainty cannot be eliminated upfront and learning continues throughout the product lifecycle. But the signal applies more broadly. Innovation is not limited to technology alone; it also includes advances in clinical practice, workflow, and how care is delivered. Effective risk management supports all of these by providing a structured way to make informed, defensible decisions under uncertainty.

For leadership teams, this represents a meaningful shift. Under QMSR, risk management is positioned not only as a safeguard, but as a strategic capability, one that helps organizations navigate complexity, support innovation, and deliver value to patients responsibly.

For QA/RA leaders, this signal from FDA creates an opportunity. Risk management should be positioned internally as a decision-support function that enables growth, rather than one that simply defends against regulatory exposure.

So, think about this question and share your opinion in the poll below:

👉How is risk management primarily perceived in your organization today?

FDA’s response to Comment #12 in the preamble of the QMSR1, offers a highly counterintuitive perspective by signaling that use error may be a type of nonconformity.

In current industry practice, use error is rarely viewed through this lens. When users deviate from instructions, warnings, or intended use, the prevailing assumption is that the issue lies outside the quality system, often categorized as a training issue, a labeling matter, or simply “user error,” rather than a nonconformity requiring investigation.

There are also situations where users, especially healthcare providers, intentionally choose not to follow manufacturer instructions, not due to malintent, but because they are accustomed to performing a task in a different way. These acts of intentional misuse are often excluded from human factors or usability evaluations. However, ISO 14971 explicitly recognizes such behaviors as part of reasonably foreseeable misuse.

As a result, use error is commonly treated as a risk management concern rather than an operational quality issue. Use errors and intentional misuse may surface through post-market surveillance, but they are rarely processed through nonconformance or investigation workflows.

In its response to Comment 12, FDA is signaling a different expectation. FDA is not redefining nonconformities, nor suggesting that every use error must automatically trigger an investigation. Rather, it is clarifying that automatically excluding use error from nonconformance consideration is itself a risk-based decision, one that should be deliberate, justified, and informed by risk.

That shift moves the conversation away from classification and toward judgment. The question is no longer simply whether an event involved user behavior, but whether that behavior reveals a breakdown in assumptions, controls, or expectations embedded within the system.

So, think about this question and share your opinion in the poll below:

👉How is use-error most commonly handled in your post-market surveillance process?

Here is the key insight - the goal is not to collect as much quantitative data as possible when risk is high. Risk-based decisions always rely on a combination of qualitative judgment and quantitative information. The real question under QMSR is not data type or data volume, but whether the available evidence builds sufficient confidence in the decision, recognizing that some level of uncertainty will always remain.

That uncertainty can be managed. Confidence is built by thoughtfully balancing qualitative and quantitative information in a way that is appropriate to the decision at hand. Higher risk does not demand more data; it demands less tolerance for uncertainty and greater confidence in effectiveness.

This is where the phrase “as appropriate” also becomes important. In its response, FDA points manufacturers to Clause 0.2 of ISO 13485, which clarifies that a requirement is always appropriate when it is necessary to meet product requirements, comply with regulatory obligations, support CAPA actions, or manage risks. FDA’s position is that, in these situations, quantitative information is generally preferred - not because numbers are inherently better, but because they better support monitoring, learning, and sustained confidence in effectiveness over time.

Ultimately, QMSR is not asking manufacturers to eliminate uncertainty. That is neither realistic nor expected. It is asking organizations to understand uncertainty in their decisions, manage it deliberately, and build confidence where it matters most. Evidence that merely satisfies a procedure may close a record, but evidence that sustains confidence is what demonstrates effectiveness.

That is the shift FDA is signaling.

So, think about this question and share your opinion in the poll below:

👉How does your organization decide what type and volume of data is needed to show compliance to regulatory requirements?

In responding to Comment #19 in the preamble of the QMSR1, FDA offers a new perspective that quietly connects risk management effectiveness to sound decision making.

In QMSR QuickTake #7: The Buck Stops at the Top, we explored how QMSR clarifies executive accountability by incorporating the ISO 9000 definition of top management. Leadership is not symbolic. It is defined by responsibility for direction, alignment, and outcomes.

The next question is somewhat uncomfortable, but unavoidable.

On what basis will FDA evaluate whether management decisions are sound?

Taking a closer look at FDA’s response in Comment #19, it is easy to see a link to Clause 4.1.2(b) of ISO 13485:2016, which requires a risk-based approach to be applied to the control of processes in the quality management system.

If leadership is responsible for steering the organization in making ensure continued safety and effectiveness, then risk management is the logic that governs how that steering occurs.

When risk management processes are effective, management can explain:

• why certain priorities were set,

• why trade-offs were accepted,

• and why specific actions, or inaction, were reasonable in light of risk.

When they are not, decisions may still be documented and procedurally compliant, but they become increasingly difficult to defend.

By adopting ISO 13485 into regulation, QMSR gives FDA explicit authority to question whether management decisions demonstrate a genuine risk-based approach, especially when there is ample evidence to suggest otherwise.

This is a subtle but profound shift.

It does not change who is accountable. It changes how accountability can be assessed.

So, think about this question and share your opinion in the poll below:

👉Thinking about the logic used to justify decisions, what most often anchors management decisions on major quality issues in your current QMS?

In responding to Comment #19 in the preamble of the QMSR1, FDA offers a new perspective that quietly, but fundamentally, changes this paradigm.

This language is important. FDA is not asking manufacturers to introduce new risk tools or create more burdensome documentation. Instead, the Agency is emphasizing the integration of risk management and risk-based decision making across the QMS as essential elements of an effective system.

One way to understand this shift is to think of the QMS as a living organism.

In an organism, the nervous system detects signals, but behavior is shaped by the internal logic that interprets those signals and determines how the organism responds. That logic governs priorities, thresholds, and actions.

Under QMSR, risk management plays that role. It is not an add-on or a parallel system. It is the logic that shapes how the QMS behaves when it encounters uncertainty, change, or emerging signals across the product life cycle.

When risk management functions as core logic rather than a standalone procedure, it shows up in subtle but meaningful ways, for example:

• Signals from post-market activities influence prioritization and decision making across functions, not just complying with regulatory requirements.

• Management discussions focus less on audit outcomes and more on whether decisions made sense in light of risk.

These are not new activities. They are familiar QMS moments but viewed through a different lens.

So, think about this question and share your opinion in the poll below:

👉How does risk management most often show up in your QMS decisions today?

The Quality System Regulation (QSR) defined a term Management with executive responsibility, but FDA chose not carry it in QMSR. Instead, in responding to Comment #27 in the preamble of the QMSR1, FDA clarifies that the ISO 9000 definition of top management is incorporated by reference and accurately reflects FDA’s expectation of overall accountability for compliance.

And here is the key point: FDA’s expectations have not changed.

Even though management with executive responsibility appeared to limit accountability to those with authority to establish or change quality policy and the quality system, FDA has always treated executive leadership as accountable for outcomes.

This is why warning letters are almost never addressed to the Head of Quality.
They are addressed to the CEO.

ISO 9000 gives us the missing context: Leadership is not symbolic, but defined as the responsibility to: i) establish unity of purpose and direction; and ii) create the conditions under which people are engaged in achieving the organization’s quality objectives.

This is the essence of a quality culture: clarifying purpose, enabling engagement, and aligning the entire organization toward the mission.

But leadership is also active navigation: Setting the right purpose and direction is only the beginning. A complex system, like a large ship, will drift over time and struggle to stay on course. Priorities shift, market pressures intensify and shortcuts begin to feel normal.

Leadership is the act of staying vigilant throughout the journey, continuously sensing drift and correcting course as the winds shift and currents change.

QMSR’s emphasis on top management is FDA’s reminder that:

Only top management can steer the organization at the scale necessary to sustain safety, effectiveness and compliance.

But we all have a role to play.

A culture of quality is sustained not only by leadership’s direction-setting but by the everyday decisions, vigilance, and integrity of people across the organization.

Leadership sets the course, the organization keeps the ship moving in the right direction.

So, think about this question and share your opinion in the poll below:

👉What is the clearest leadership signal that a company is QMSR-ready?

CAPA, or Corrective and Preventive Action, has long been a pain point in MedTech.

Intended to drive continual improvement through tangible risk reduction, CAPA has instead become a source of frustration for both leaders and individual contributors.

Under QMSR, CAPA will remain a challenge unless we step back and deeply understand FDA’s expectations for an effective process.

Under the QSR, §820.100 blended Corrective Action (CA) and Preventive Action (PA), two fundamentally different concepts, into a single process. Although this was never FDA’s original intent, the outcome was predictable: most CAPA systems became reactive, documentation-heavy mechanisms built to prove that a known problem had been addressed. Preventive Action, the discipline of anticipating and controlling emerging risks, never took root in most organizations.

QMSR reverses this trajectory. By adopting ISO 13485 as a normative reference and reaffirming the separation between CA and PA, FDA restores its intended distinction:

CA and PA are two distinctly different activities - one fixes the past, the other protects the future.

This distinction is not academic; it is essential. CAPA has been the top FDA inspectional observation for more than a decade. Even more striking is the distribution: over 80% of CAPA citations involve inadequate procedures, and another 20% involve documentation gaps; clear evidence of systems built around compliance, not insight or anticipation.

This pattern shows up repeatedly in FDA warning letters. In one case, a CAPA investigation uncovered an “Activation Time Mismatch” error, an unanticipated software issue that introduced a previously unrecognized risk. The firm’s procedure required a Health Hazard Evaluation, yet no HHE was conducted and no preventive action was taken1.

The signal emerged; yet the system did not know how to respond.

Industry research reinforces this gap. The MDIC CAPA maturity model2 shows that that most organizations remain in the early stages of CAPA maturity, focused primarily on documenting corrections rather than detecting weak signals, interpreting emerging risks, or learning from system drift. High-performing organizations treat CAPA not as a paperwork process, but as a learning system - a way of seeing risk before it becomes visible.

QMSR will push the entire industry toward that higher maturity level.

But here is the challenge: most organizations today do not have a working mental model for Preventive Action. They know how to fix problems that have already occurred, but not how to identify and act on risks that are beginning to emerge. They focus on how to prevent recurrence, but not how to prevent occurrence.

This is exactly where companies will succeed - or struggle - under QMSR.

In this article, we address the most common and most important questions emerging from industry conversations:

• Do we need separate procedures for CA and PA, or can they coexist in one CAPA process?

• What actually triggers a Preventive Action?

• How do CA and PA connect to the Risk Management File and post-market surveillance?

• How should effectiveness checks differ between CA and PA?

• What will FDA expect to see in a QMSR inspection?

But here is the deeper insight: QMSR invites QA/RA leaders to elevate their organization’s culture. By reimagining CAPA, leaders can help teams move beyond reactive firefighting and build the confidence to make informed, risk-based decisions every day.

Read more