Pairing QMS Development with Regulatory Submission

Quality system development and regulatory submission preparation usually sit in different places on a project plan. The product team develops the device. Regulatory determines the pathway and begins assembling evidence. The quality management system gets built somewhere alongside that work, or a little behind it.

The more expensive failure is quieter than that. A team assesses the pathway carefully, maps the testing and evidence it will need, sets a submission target, and never asks which quality processes have to be running for that evidence to be generated according to approved procedures. Nothing about the analysis is wrong. It just has a gap where the QMS should be. All aspects of product development must be performed according to documented procedures.

That gap matters because a submission is not a document assembled at the end of development. It is an account of how the device was designed, evaluated and controlled, and the quality system governs how that account gets created, reviewed, approved and preserved. Get the sequence wrong and you finish with work that was done well but cannot be shown to have been done well. In regulatory terms, those are the same thing.

None of which argues for a complete quality system before development starts. It argues for having the right parts of it running before the work they govern begins.

The stakes changed in February

This argument has been true for a long time. It became harder to ignore on February 2, 2026, when FDA’s Quality Management System Regulation took effect.

QMSR amends 21 CFR Part 820 to incorporate ISO 13485:2016 by reference, replacing most of the old Quality System Regulation’s directly written requirements and harmonizing FDA’s framework with the standard other regulators already use. ISO 13485’s process-oriented, risk-based approach is now the baseline for design and development controls, risk management, supplier controls and CAPA (corrective and preventive action) under Part 820.

The practical consequence for anyone planning a submission is that procedures may result in a noncompliant medical device file or quality management system procedures, which can impact the submission timeline.

Additionally, the new regulation changes what FDA can examine during an inspection. Under the previous inspection program, a manufacturer was not required to provide an inspector with internal audit reports, supplier audit reports and management review minutes. These records are now in scope during an FDA inspection.

That widens the definition of what your quality system needs to be able to produce, and it moves the deadline for having those processes running earlier in development rather than later. A comprehensive assessment of your organization’s role in product realization – for example, manufacturer, contract manufacturer, specification developer – and the associated regulatory requirements is critical at the onset to ensure QMS planning is conducted appropriately.

Build the system in the order the product needs it

Not every process has to exist on day one. Several need to exist earlier than teams plan for, because they govern work that is about to happen.

Document and record control, from the start. This is the least glamorous item on the list and the one that causes the most avoidable damage. Specifications get revised, risk documents evolve, protocols change, test reports get approved. Without a controlled process for how those documents are created, reviewed, approved and versioned, you lose the ability to demonstrate what was in effect when a given activity took place. Let’s say a verification protocol gets executed against a specification revision that was never formally approved. The resulting test data points at a document that does not exist in controlled form. The testing may have been perfectly fine. The record of it is not, and the results are only as good as the record.

Design control and risk management, before formal development. Design control is what makes traceability through the design process possible. Design inputs define what the device has to do, design outputs specify how it does it, and design reviews capture the decisions made to progress through design phases. Verification and validation then demonstrate the requirements were met. The design history file serves as a comprehensive record of the various aspects of design and development. Risk management under ISO 14971 is a critical aspect of design control, identifying hazards, defining risk controls and connecting those controls back to the requirements and the evidence that verifies them.

Start these late and you are not simply behind schedule. You are attempting to reconstruct a decision history after the decisions were made, which is the single most common reason a technically sound development program produces a weak submission. Design controls and risk management are lifecycle processes, not retrospective reviews. The evidence exists in fragments. What is missing is the thread connecting inputs to outputs and verification, and that thread is very difficult to lay down retroactively in a way that holds up under review.

Supplier controls, before critical sourcing. If a supplier provides a component, material or service that affects the design or quality of the device, establish how that supplier will be evaluated, qualified and monitored in a risk-based manner before their role is embedded in the product. The timing matters more than it appears. Testing performed with a component from an unqualified supplier raises a question about the evidence itself, not just about the supplier, and requalifying after the fact does not retroactively strengthen data that was already generated.

Post-market processes, before launch. Complaint handling, adverse event reporting, post-market surveillance and feedback processes cannot be designed after the first event that requires them. These also feed back into risk management, since real-world data is what keeps a risk file current rather than frozen at the moment they were created.

The pattern across all four is the same. The quality system has to stay ahead of the work it exists to control.

QMS readiness is often on the critical path, not beside it

The scheduling failure that surprises teams most is not a QMS process gap. It is discovering that quality system certification or assessment sits directly between them and market access.

Canada is the clearest case. Health Canada requires manufacturers of Class II, III and IV devices to hold a valid certificate under the Medical Device Single Audit Program (MDSAP) to obtain or maintain a Medical Device Licence, a requirement in force since January 2019. Generic ISO 13485 certification does not satisfy it. The certificate has to be issued under MDSAP with Canada in scope, and it is a prerequisite to the licence application rather than something that can proceed alongside it. CE marking under the EU MDR carries its own quality system assessment by a notified body. For PMA devices in the United States, manufacturing readiness is evaluated as part of the approval process.

Here is the part that reorders timelines: an auditor cannot assess a system that has not been used. Certification requires records generated under the system, which means the system has to be implemented and operating for a meaningful period before an audit can take place. Writing procedures is the fast part. Running the system long enough to have evidence that it works, then scheduling and completing an audit, is what consumes calendar time that most regulatory schedules do not reserve.

A timeline that accounts for design verification, validation and submission review but treats QMS readiness as a background activity is missing a segment of its own critical path.

When the product is already ahead of the system

Plenty of teams read this and recognize that their device is further along than their quality system. That situation is workable, and the way through it is to stop thinking about the QMS as a whole and start with the specific work in front of you.

Identify what the team is doing right now and what it is about to do, then ask which process has to be operating for that work to produce usable evidence. If formal design decisions are being made, that means document control, design control and risk management. If critical suppliers are being selected, supplier controls. If verification or validation is about to be executed, the processes governing that work need to be established before the protocols run, because evidence generated outside a controlled process is the hardest kind to repair.

Where work has already been completed without the governing process in place, the honest assessment is what can be documented now with a defensible rationale versus what has to be repeated. That determination is worth making deliberately and early. It gets more expensive the longer it waits, and it is considerably better to make it yourself than to have a reviewer make it for you.

A submission asks a team to demonstrate what it did, why it did it and what evidence supports the result. The quality system is what makes that demonstration possible, which is why it belongs on the regulatory timeline rather than beside it.

Build the two together and the story a submission needs is already present in the development record. Build them separately and the work still gets done, but the connective tissue has to be assembled afterward, from fragments, under deadline. That reconstruction is the rework this is meant to avoid.