Safety and compliance solutions for medical devices under QMSR and EU MDR

What safety and compliance solutions need to solve

Safety and compliance solutions for medical device organizations can no longer function as simple document repositories. They need to connect design inputs, risk controls, supplier evidence, cybersecurity artifacts, complaints, vigilance activity and audit records across the device lifecycle. As of September 10, 2026, that lifecycle view matters because the U.S. FDA Quality Management System Regulation is in effect, the EU MDR and IVDR continue to drive structured technical documentation and postmarket expectations, and cybersecurity is now a routine part of safety evidence for connected devices. The practical question is not whether a team has compliance documents. It is whether the team can show timely, traceable and reviewable evidence when a regulator, notified body or internal quality leader asks for it. For more updates in this area, see our safety and compliance coverage.

This article uses safety and compliance solutions in a broad industry sense: processes, governance, software systems and evidence workflows that help manufacturers, developers, suppliers and regulatory teams manage obligations. It does not describe a specific commercial product or replace regulator-specific legal advice.

The current regulatory baseline favors connected lifecycle evidence

The FDA states that QMSR became effective on February 2, 2026, amending 21 CFR Part 820 and incorporating ISO 13485:2016 by reference for medical device quality management systems. The agency also says it withdrew the Quality System Inspection Technique on the same date and moved to the updated Inspection of Medical Device Manufacturers Compliance Program 7382.850. (fda.gov)

The European Commission states that Regulation (EU) 2017/745 on medical devices has applied from May 26, 2021, and Regulation (EU) 2017/746 on in vitro diagnostic medical devices has applied from May 26, 2022, with transition provisions for certain devices. The Commission also states that the first four EUDAMED modules became mandatory to use from May 28, 2026, after the publication of Commission Decision (EU) 2025/2371. (health.ec.europa.eu)

Compliance area	What changed or matters now	Evidence a solution should organize
Quality management	QMSR aligns U.S. device quality system expectations more closely with ISO 13485:2016.	Quality manual or procedures, process maps, design and production controls, CAPA, complaints and management review records.
Inspection readiness	FDA inspections after February 2, 2026 use the newer inspection process rather than QSIT.	Process evidence, audit trails, responsible owners, training status and records that show requirements are implemented.
Risk management	ISO 14971:2019 defines a process for identifying hazards, estimating and evaluating risks, controlling risks and monitoring control effectiveness across the lifecycle.	Risk management plan, hazard analysis, benefit-risk rationale, control verification, residual risk evaluation and postmarket feedback links.
Cybersecurity	FDA final cybersecurity guidance issued in February 2026 addresses device design, labeling and premarket submission documentation for devices with cybersecurity risk.	Threat modeling, security risk analysis, software bill of materials, vulnerability management, update strategy and user-facing security information.
EU market access	EU MDR and IVDR place continuing pressure on technical documentation, postmarket surveillance and structured registration data.	Technical documentation, declarations, UDI data, EUDAMED module data, PMS plans, vigilance files and notified body correspondence.

The common theme is traceability. A safety requirement should connect to a risk control. A risk control should connect to verification. A production or supplier issue should connect to nonconformity handling and CAPA where appropriate. A complaint trend should feed risk review and postmarket surveillance, instead of remaining isolated in a customer service system.

What a practical solution stack should cover

A mature compliance stack usually combines procedures, trained people, controlled records and fit-for-purpose digital tools. The exact mix depends on device class, technology, markets and organizational size, but the core capabilities are broadly consistent.

Document and record control

Document control should cover more than approval workflows. Teams need version history, effective dates, role-based access, training linkage and retirement of obsolete documents. In medical device organizations, uncontrolled templates and duplicated spreadsheets can become inspection problems because they make it difficult to show which requirements were effective at a specific point in design, release or complaint handling.

Design control and medical device file structure

Design evidence should be organized by device or device family. A practical structure links user needs, intended use, design inputs, design outputs, verification, validation, risk controls, labeling and change history. The purpose is not to create extra paperwork. It is to make the design story defensible when a reviewer asks why a safety control exists and how its effectiveness was confirmed.

Risk management integration

ISO 14971:2019 is especially important because risk management is not a one-time design activity. The ISO description emphasizes hazard identification, risk evaluation, risk control and monitoring effectiveness throughout the lifecycle, including software as a medical device and in vitro diagnostic devices. (iso.org)

In practical terms, safety and compliance solutions should prevent risk files from becoming static PDFs. They should connect risk acceptability criteria, hazard-related harms, controls, verification evidence, labeling mitigations, residual risks, benefit-risk decisions and postmarket signals.

Supplier and production quality

Medical device organizations rarely control every critical activity in-house. Components, sterilization, software libraries, packaging, calibration, logistics and complaint intake may involve suppliers. A useful compliance workflow classifies suppliers by risk, ties supplier qualification to purchasing controls, tracks supplier changes and escalates quality issues into nonconformance or CAPA processes when needed.

Cybersecurity evidence for connected devices

For connected, software-driven or networked devices, cybersecurity needs to be treated as part of safety and effectiveness rather than as a separate IT checklist. FDA describes its February 2026 final cybersecurity guidance as covering design, labeling and premarket submission documentation for devices with cybersecurity risk, and as addressing section 524B of the FD&C Act for cyber devices. (fda.gov)

A compliance solution should therefore support a living security file: threat model, vulnerability assessment, third-party component inventory, update process, coordinated vulnerability disclosure process, security testing evidence and postmarket vulnerability triage. These artifacts should link back to device risk management and change control.

How to connect risk, requirements and postmarket signals

The strongest value from modern compliance systems is closed-loop learning. A team can meet a narrow documentation requirement and still miss a safety signal if complaints, service data, software defects and supplier deviations are reviewed in separate workstreams.

A practical closed-loop model includes five connections:

• Requirement to risk: Each safety-critical requirement should show which hazard or hazardous situation it controls.
• Risk to verification: Each risk control should have evidence that it was implemented and verified.
• Verification to release: Release decisions should show unresolved deviations, residual risks and acceptance rationale.
• Postmarket signal to risk review: Complaints, adverse events, service findings and vulnerability reports should be assessed for risk impact.
• Risk review to CAPA or change control: Trends and confirmed issues should trigger proportionate action, not informal fixes outside the QMS.

FDA explains that Medical Device Reports are valuable but limited because incidence, prevalence or causation cannot be determined from that passive reporting system alone. The agency also states that manufacturers must report when they learn that a device may have caused or contributed to a death or serious injury, and when a malfunction would be likely to cause or contribute to a death or serious injury if it recurred. (fda.gov)

Reporting workflows therefore should not be treated as a data dump. They should support triage, medical review where needed, regulatory assessment, timing control, supplemental information, trend review and feedback into the risk management file. Section 522 postmarket surveillance is another example of active lifecycle oversight: FDA describes it as active, systematic, scientifically valid collection, analysis and interpretation of data or other information about a marketed device for certain class II or class III devices when ordered. (fda.gov) See also: clinical equipment.

U.S. QMSR implications for inspections and management review

The shift to QMSR does not mean every manufacturer starts from zero. FDA has said the previous Quality System regulation and QMSR are substantially similar when considered overall, and a comparative analysis may help demonstrate how earlier documents and records meet QMSR requirements. (fda.gov)

However, teams should not underestimate the evidence impact. FDA’s QMSR FAQ states that investigators may review QMS records created before February 2, 2026. It also states that QMSR gives FDA authority to inspect management review, quality audit and supplier audit reports, and that the previous exceptions in the older QS regulation are not maintained. (fda.gov)

That makes management review more operationally important. A useful review package should show quality objectives, audit outcomes, supplier performance, complaint trends, CAPA status, process metrics, risk signals, resource needs and leadership decisions. A slide deck without action tracking is weak evidence. A meeting record connected to metrics, owners, due dates and effectiveness checks is much stronger.

EU MDR and EUDAMED implications for cross-market teams

For teams selling into both the United States and the European Union, safety and compliance solutions should avoid creating separate evidence worlds. Some requirements are jurisdiction-specific, but many underlying controls overlap: design evidence, risk management, clinical evaluation or performance evidence, labeling, supplier control, complaint handling, vigilance and postmarket surveillance.

EU MDR and IVDR add pressure for structured technical documentation and market-facing data. The EUDAMED rollout is a good example. With the first four modules mandatory from May 28, 2026, teams need cleaner governance for device, economic operator, UDI and certificate data. Even where some modules remain under development, poor master data can create delays when registration, certificates or vigilance workflows depend on consistent identifiers.

A cross-market solution should map each evidence object once, then identify how it supports different submissions, audits or inspections. For example, a risk control may support ISO 14971 risk management, FDA design control evidence, EU technical documentation and cybersecurity documentation. The same evidence may need different formatting, but its source of truth should be controlled.

Selection criteria for safety and compliance solutions

Before selecting software or redesigning workflows, teams should define the problem in regulatory and operational terms. The best solution is rarely the one with the longest feature list. It is the one that fits the device risk profile, current markets, future market plans, process maturity and audit burden.

• Market and device scope: Confirm device classes, product codes, intended markets, software involvement, sterile status, implant status and service model.
• QMS alignment: Map procedures to ISO 13485:2016, QMSR, EU MDR or IVDR obligations and any local requirements.
• Traceability: Require links between requirements, risks, controls, tests, changes, complaints and CAPA records.
• Data governance: Control device master data, UDI data, supplier data, document metadata and user permissions.
• Cybersecurity lifecycle: Support security risk management, SBOM control, vulnerability triage and update documentation for cyber devices.
• Audit readiness: Ensure records can be retrieved by process, device, date, owner, requirement and status.
• Change control: Connect design, production, supplier, software and labeling changes to risk review and regulatory assessment.
• Postmarket intelligence: Bring complaints, service reports, adverse events, recalls, field actions and literature signals into periodic review.
• Scalability: Avoid systems that work only for one product team and break when the organization adds markets, suppliers or product families.

A practical 90-day implementation roadmap

A 90-day roadmap is not a regulatory deadline. It is a practical way to move from scattered records to a controlled improvement plan.

1. Days 1 to 30: Build a requirements map. Identify applicable markets, device categories, standards, procedures, records and owners. Create a gap list focused on evidence that would be difficult to retrieve during an inspection or audit.
2. Days 31 to 60: Prioritize lifecycle links. Connect design controls, risk files, supplier controls, complaint handling, cybersecurity evidence and CAPA. Remove duplicate trackers where possible and define the controlled source of truth.
3. Days 61 to 90: Test the system with audit scenarios. Ask whether the team can prove that a risk control was verified, a supplier issue was evaluated, a complaint was assessed for reportability, a software vulnerability was triaged or a management review action was closed.

The most useful outcome is a living compliance operating model: clear responsibilities, controlled records, reviewed metrics and evidence that safety signals can move from detection to decision without disappearing between departments.

Frequently asked questions

Are safety and compliance solutions the same as an electronic QMS?

Not always. An electronic QMS is often part of the solution, but safety and compliance work also includes regulatory intelligence, risk management, cybersecurity evidence, supplier quality, postmarket surveillance and management review. The value comes from how these elements are connected.

Does QMSR make ISO 13485 certification mandatory for every U.S. medical device manufacturer?

FDA QMSR incorporates ISO 13485:2016 by reference into 21 CFR Part 820, but ISO notes that certification to ISO 13485 is not itself a requirement of the standard. Manufacturers should evaluate their regulatory obligations and market expectations rather than assuming certification alone satisfies all compliance needs. (committee.iso.org)

Should cybersecurity be handled outside the quality system?

For devices with cybersecurity risk, treating cybersecurity as an isolated technical activity is risky. Security requirements, threat analysis, vulnerability handling, software updates and labeling should connect to risk management, design control, change control and postmarket processes.

What is the biggest mistake when implementing compliance software?

The biggest mistake is digitizing a weak process without improving accountability or traceability. If requirements, risks, tests, complaints and CAPA remain disconnected, the organization may have faster workflows but still lack reliable compliance evidence.

How should smaller manufacturers approach safety and compliance solutions?

Smaller teams should start with a clear applicability map, controlled procedures and traceable records before adding complex automation. The solution should be proportionate to device risk and market scope, but it still needs to support retrieval, review, escalation and lifecycle learning.