510(k)-Exempt Does Not Mean QMSR-Exempt

A conversation we have several times a year starts the same way. A company sells a powered therapeutic device. It is Class II. Someone competent established years ago that it does not require a premarket submission, and that conclusion was correct. The product has shipped for a decade without incident.

Then a customer requests a quality agreement, or a distributor asks for the technical file, or an auditor schedules a visit, and the company discovers that "we didn't need a 510(k)" was answering a completely different question than the one now being asked.

Exemption from premarket notification is a decision about what you file before you sell. It is not a decision about the quality system behind the product.

Two separate decisions that sound like one

Premarket notification and quality system requirements are established under different parts of the regulation and answer different questions. The first asks whether FDA reviews your device before it reaches the market. The second asks whether you built and maintain a system capable of producing that device safely and consistently.

A device can be exempt from the first and fully subject to the second. FDA states the point directly: exemption from 510(k) does not mean a device is exempt from compliance with labeling or quality system requirements. A separate and much narrower exemption from most GMP requirements does exist, but it applies only to device types specifically annotated as such in FDA's exemption list, and even then general recordkeeping and complaint file requirements still apply. The great majority of exempt Class II devices carry no such annotation.

So for most companies in this position the exemption removes a submission and nothing else. It does not remove design controls, document control, process validation, supplier oversight, complaint handling, CAPA, or the records that demonstrate all of it happened.

A worked example: a powered heating pad is classified under 21 CFR 890.5740 as Class II with special controls, and the regulation exempts it from premarket notification subject to the limitations in 21 CFR 890.9. That sentence is the entire exemption. Nothing in it touches the quality system.

This is not a technicality that only matters during an inspection. The quality system requirements exist because the failure modes they prevent are real, and a device being simple enough to skip premarket review says nothing about whether it can burn someone.

Why outsourcing makes this worse

If you designed and built the product yourself, the evidence tends to exist somewhere even when it is disorganized. Someone ran the tests. Someone approved the drawings. The records are in a shared drive with unhelpful file names, but they exist.

When the product is designed or built by a contract manufacturer overseas, that assumption fails in a specific way. The factory has records. Those records are in the factory's system, in the factory's format, often in Chinese, structured around the factory's ISO 13485 certification rather than around your device's regulatory obligations. The factory is not doing anything wrong. It is maintaining exactly the records its own quality system requires.

The problem is that your obligations do not transfer with the manufacturing. As the specification owner or labeler, you remain responsible for the finished device, and a contract manufacturer is treated as an extension of your process rather than a replacement for your accountability. Both parties are responsible for the activities they actually perform, and a written agreement between you is normally where that division is established.

So when an auditor asks who validated the sealing process, the answer cannot be "the factory handles that." It can be "the factory performed the validation under protocol X, which we reviewed and approved on this date, and here is the report." Those sound similar in a meeting. Only one of them is a defensible answer.

What people actually get wrong

The confusion rarely announces itself. It shows up as a set of specific absences that nobody noticed accumulating:

• No design file for a product that has shipped for years. The device was developed before anyone treated it as a medical device, or it was developed by the factory and the design record stayed there.
• Risk documentation that stops at the hazard. A list of things that could go wrong, with no traceable connection to the design features that control them or the tests that verify those controls work.
• Process validation that was never performed, or was performed once and never repeated after a process change. The factory moved a line, changed a supplier, or replaced a machine, and the validation that justified the original process quietly stopped describing reality.
• Supplier controls that consist of holding a certificate. An ISO 13485 certificate on file is evidence that a certification body audited the factory's system. It is not evidence that the factory is building your device the way your specifications require.
• Change control that runs through email. The factory proposes a component substitution, someone approves it in a reply, and the design file never learns about it.
• Complaints handled as customer service. Returns get replaced and refunded. Nobody evaluates whether the pattern indicates a design or process problem, and no record connects the complaint to an investigation.

Each of these is individually fixable. Together they describe a company that believed a premarket exemption settled a question it never addressed.

The QMSR transition raised the stakes

FDA's Quality Management System Regulation took effect on 2 February 2026, amending Part 820 to incorporate ISO 13485:2016 by reference. On the same date FDA stopped using the Quality System Inspection Technique and began inspecting under the updated compliance program 7382.850. For companies whose quality systems were built around the old Part 820 structure, two things changed at once: the framework the inspector works from, and the vocabulary your documentation is expected to speak.

Worth noting what did not change for a Class II specification owner: design and development requirements, now expressed as ISO 13485 clause 7.3, apply to every Class II and Class III device, along with certain specified Class I devices. There is no size threshold, no exemption for simple products, and no carve-out for devices whose engineering was done by someone else.

The underlying obligations largely carried over. If you had a well-run system before, you still have one. But a checklist organized around the old subpart structure now maps imperfectly onto how your system will be examined, and a stale index is worse than no index because it creates confidence without coverage. We wrote separately about crosswalking a legacy checklist without losing the work already done.

A short self-assessment

You do not need a consultant to find out whether this applies to you. Pick your highest-risk failure mode, the one that would hurt someone if it occurred, and try to walk the chain:

1. Is that hazard identified in a risk document?
2. Does a specific design feature control it?
3. Is that feature captured as a design input or requirement?
4. Is there a verification test proving the feature performs?
5. Did that test run against the design you actually ship today?
6. Does a production test or inspection confirm it on every unit or lot?
7. Would the factory's records show it, and could you produce them this week?

If the chain breaks at step three or four, you have a documentation gap. If it breaks at step five or six, you may have a product problem, and the paperwork is the smaller half of it. If it breaks at step seven, you have a responsibility gap between you and your manufacturer, which is usually the hardest of the three to close because neither party believes it is theirs.

What to do about it

The instinct is to start writing procedures. That is usually the wrong first move, because it produces a system that describes an idealized company rather than the one that exists, and an auditor reads the gap between the two immediately.

Start instead with an honest inventory: what records exist, where they live, who owns them, and which requirements they actually satisfy. Separate procedures from the evidence those procedures were supposed to produce. They are not the same thing, and conflating them is the most common way a document count creates false confidence. Then write down, explicitly, which obligations are yours and which are the factory's.

That document, the responsibility matrix between the specification owner and the manufacturer, is the one most outsourced programs are missing, and the one that resolves the largest number of downstream arguments.