Converting a Legacy Part 820 Checklist to the 2026 QMSR

Somewhere in your quality folder is a checklist organized by Part 820 subpart. Design controls under 820.30. Document controls under 820.40. Purchasing under 820.50. Corrective and preventive action under 820.100. It was probably built during a previous audit preparation, it is thorough, and people still refer to it.

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 retired the Quality System Inspection Technique and began inspecting under the updated compliance program 7382.850. The obligations behind that checklist largely survived. Its structure and vocabulary did not.

A stale index is more dangerous than no index, because it produces confidence without producing coverage.

What actually changed, and what did not

The change is less dramatic than the transition anxiety suggested, and the companies most disrupted are the ones that were furthest behind already.

Substantially unchanged: you still need design controls. The design and development requirements, now expressed as ISO 13485 clause 7.3 and its subclauses, apply to all Class II and Class III devices, plus specified Class I devices including those automated with computer software. You still need document control, purchasing controls and supplier evaluation, process validation for processes you cannot fully verify, traceability, complaint handling, CAPA, records, and management responsibility. If you had a genuinely functioning system, you still have one.

What changed: the organizing structure and the vocabulary. A system indexed by Part 820 subpart numbers does not map cleanly onto how it will now be examined. The terminology shifted, and the language of a Design History File and Device Master Record now sits alongside the ISO vocabulary of a Medical Device File and design and development files. And the inspection approach changed, which affects how an inspector navigates your system.

The practical effect: your evidence is probably fine and your map to it is not.

Why renaming folders is the wrong response

The instinctive fix is to restructure the document tree to match the new framework. This is expensive, disruptive, and mostly unnecessary.

Your records do not need to be reorganized. What needs to exist is a crosswalk: a mapping from each requirement in the current framework to the evidence you already hold, wherever it currently lives. The crosswalk is the deliverable. The folder structure can stay where it is.

This matters commercially as well as practically. A reorganization project consumes months and produces no new evidence. A crosswalk takes a fraction of the time and immediately tells you which requirements have nothing behind them, which is the information you actually need.

Building the crosswalk

Step 1: Start from the requirement, not the document

Work down the current framework's requirements. For each one, ask what evidence in your possession satisfies it. This direction matters: starting from your documents and asking "where does this fit" will map everything you have and reveal nothing you lack.

Step 2: Record four things per requirement

Step 3: Distinguish procedure from evidence

A requirement is not satisfied by a procedure describing how you would satisfy it. Most requirements need both: the controlled document stating intent, and the executed records proving it happened. Mark them separately, because a row showing "procedure exists, no records" is a specific and common finding, not a partial success. This is the distinction that hides most audit exposure.

Step 4: Mark which company owns each row

In an outsourced program this column carries more weight than any other. Process validation evidence sits at the factory. Design inputs sit with you. Complaint handling is probably yours; the investigation may require the factory. Incoming inspection records are theirs; supplier approval is yours.

When you finish, this column is your responsibility matrix, and it frequently exposes rows both parties assumed the other one owned. Those rows are where findings come from.

Step 5: Justify every exclusion in writing

Some requirements will not apply to your device. That is legitimate and it must be documented with reasoning. An unexplained blank reads as an oversight; a written justification reads as a decision. The difference costs one sentence and changes how the row is received.

Where the old checklist misleads

A few specific places where a legacy index tends to be quietly wrong:

• Design and development files. The old checklist asks for a Design History File. The current framework's expectations around design and development records and the Medical Device File overlap with, but are not identical to, the DHF and DMR you may have built. Map content to requirements rather than assuming the containers correspond.
• Risk management. Risk expectations run through the standard more pervasively than a subpart-organized checklist suggests. Risk is not one row; it touches design, purchasing, process, and post-market.
• Supplier controls. Evaluation, selection, monitoring, and re-evaluation are ongoing obligations. Legacy checklists often reduce this to a one-time approval record and a certificate on file.
• Feedback and post-market. Feedback is broader than complaints. A checklist row for complaint handling does not cover the obligation to gather and use production and post-production information.
• Management review. Frequently the most neglected row, and an easy one for an inspector to check, because either the records exist with the required inputs or they do not.

What good output looks like

A completed crosswalk should let someone who has never seen your quality system answer three questions in a few minutes: what applies to this device, what evidence satisfies each requirement, and what is missing.

It should be a live document, not a one-time deliverable. The value is not the afternoon you finish it. It is having a maintained map when an audit notice arrives with six weeks of warning, or when a component change forces you to ask what evidence is affected.

That is a large part of why we deliver this work in a shared workspace rather than a spreadsheet. A spreadsheet crosswalk is accurate the week it is written. A workspace that both you and the factory work in keeps the mapping attached to the evidence, so a missing record shows up as a gap when it goes missing, not eighteen months later when someone rebuilds the spreadsheet.

Sequence, if you are starting now

1. Confirm what actually applies to your device, taking classification and applicable requirements first, because scoping errors here waste everything downstream.
2. Inventory what exists, at both companies, separating procedures from executed records.
3. Build the crosswalk requirement-first, marking evidence, location, owner, and state.
4. Sort gaps by risk and by likelihood of examination, not by how easy they are to close.
5. Close them, generating evidence with honest current dates.
6. Keep it current, with a defined trigger for updating it when the product, process, or factory changes.

Most of the value arrives at step three, when the argument about whether you are ready gets replaced by a list.