Blog

Inspections After QSIT: An Auditor's Read of FDA's New Playbook

By Frank Clay, CSQE · November 9, 2026

Most quality teams I work with know FDA inspections changed this year. Fewer have thought hard about how the inspection itself now moves. Since February 2, 2026, investigators no longer use the Quality System Inspection Technique (QSIT). They work from Compliance Program 7382.850, Inspection of Medical Device Manufacturers, and the shape of a week on site is different. I also work as a lead auditor for ISO 13485, ISO 9001 and AS9100D, so I read the new program with an auditor's eye.

I covered the records side of the change, including management review, in QMSR Inspections: Your Management Review Is Now Evidence. This post is about the mechanics.

What QSIT did, and what replaced it

QSIT organized an inspection around subsystems. Investigators typically began with management controls, worked through a defined set of major subsystems, and used sampling tables to decide how many records to pull. Many teams learned to prepare one subsystem at a time.

The new program is built around six QMS areas plus the other applicable FDA requirements: medical device reporting, corrections and removals, tracking and UDI. At FDA's April 2026 QMSR town hall, the agency described the program as aligned with ISO 13485 because both rest on a process approach. Published commentary on the program notes there are no sampling tables and no set number of records. Investigators choose records based on product risk and their own experience.

How investigators plan and scope the visit

The program names seven inspection types and groups them into two models. Model 1 covers non-baseline surveillance, compliance follow-up, for-cause, Specific Product Risk Assignment and PMA postmarket inspections. The investigator identifies product risks, then selects at least one element in each QMS area and the other applicable requirements. Model 2 covers baseline surveillance and PMA preapproval inspections, where the investigator evaluates a defined minimum set of elements in every area.

Both models start with the same general items: registration and listing, marketing authorizations, prior 483 observations or compliance issues, and anything in the assignment itself.

The bigger shift is where scope comes from. Investigators review your risk management documentation throughout the inspection and use it to decide what to examine. Your risk file is not one exhibit among many. It is the map they navigate by. For a software-heavy device, that means the hazards tied to software failure, the risk controls implemented in software and the security risks you documented are natural places to start pulling a thread.

How the inspection moves

There is no required order. Investigators can take the QMS areas in whatever sequence the evidence suggests, and if they find an objectionable condition or cannot adequately assess something, they may select more elements. On a software-driven device, I expect trails like these:

  • A complaint or MDR leads to the risk file, to check whether postmarket feedback actually updated the risk estimate.
  • That hazard's risk control leads to design outputs and verification, often a software requirement and its test evidence.
  • A field fix leads to change control: was the software change assessed for risk, verified and released under control?
  • A third-party or SOUP component in the chain leads to outsourcing and purchasing controls.
Diagram titled How an inspection moves after QSIT. Six numbered steps under Compliance Program 7382.850: 1 Prepare, reviewing registration and listing, marketing authorizations, prior 483s and the assignment; 2 Identify product risks from the firm's risk management documentation; 3 Select elements, at least one per QMS area in Model 1 or a defined minimum set in Model 2; 4 Follow the evidence in no fixed order, choosing records by risk rather than sampling tables; 5 Expand where needed when objectionable conditions are found; 6 Close out with Form FDA 483 observations and a later NAI, VAI or OAI classification. A lower panel shows a typical trail on a software-driven device: complaint or MDR, risk file update, software risk control, design verification, change control, supplier or SOUP.
Under Compliance Program 7382.850, the firm's risk documentation sets the route and the investigator follows the evidence across QMS areas.

At the town hall, FDA gave examples of conditions that can support an Official Action Indicated (OAI) classification. Two of them sit at the end of exactly these trails: failing to establish risk management processes for product realization under ISO 13485 clause 7.1, and failing to use postmarket feedback as an input to risk management under clause 8.2.1.

An auditor's comparison

If you have hosted a good ISO 13485 certification audit, the flow will feel familiar. A process-approach auditor also follows a sample across interfaces instead of reading procedures in isolation. MDSAP audits follow their own defined sequence, and FDA said at the town hall that investigators will not follow the MDSAP audit approach for QMSR inspections.

The differences still matter:

  • Output. A registrar grades nonconformities, usually major or minor, against a certificate. An FDA investigator lists observations on Form FDA 483, and the inspection is later classified NAI, VAI or OAI.
  • Consequence. A major nonconformity puts a certificate at risk. An OAI classification means FDA recommends regulatory action.
  • Purpose. A certification audit confirms conformity to maintain a certificate. An inspection checks compliance with the law, and a clean close-out is not a certificate or an endorsement.
  • Response. You can annotate the 483 at close-out and respond in writing afterward. Write that response for a reader who was not in the room.

Hosting from the auditor's chair

Front room and back room still work, but the back room's job changes. Now it has to assemble a trail quickly and in order: complaint, risk file, design output, verification, change record. Before any inspection, I ask clients to rehearse three or four trails that start from their highest-severity hazards.

Answer the question that was asked. An investigator following a trail usually asks a narrow question, and a sprawling answer opens new threads. Bring the record, confirm what it shows and stop.

Prepare your software and risk owners to speak to their own files. One person should be able to explain the software architecture, the IEC 62304 safety classification and how a software anomaly gets assessed for risk.

Practitioner note: As an auditor, the most revealing moment is rarely a missing document. It is the moment I ask how a complaint changed the risk file and the room goes quiet, because the complaint team and the risk team have never read each other's records. I have watched that same moment from the host's chair. The teams that handled it well had already walked that trail themselves, found the gap and could show a correction underway. That is the habit the new program rewards.

Closing perspective

Compliance Program 7382.850 does not ask for anything ISO 13485 did not already require. What it changes is how an investigator finds you: through your own risk documentation, following the evidence wherever it leads. Teams that already run internal audits as trail-following exercises will find these inspections far less surprising. If you would like an auditor's read of your trails before FDA reads them, reach out at softwarequality.guru/contact.

Put this into practice

My free templates (SOUP evaluation, SBOM and premarket cybersecurity checklist, software FMEA, change impact analysis) are built from the same approach.

You're in

Thanks, you're in. Check your inbox.

Cookies on this site

Essential storage keeps the site working and remembers this choice. With your OK, I'd also use HubSpot to see which articles and tools are useful, and to show my booking calendar on the contact page. Nothing optional loads until you choose, and you can change your mind anytime from Cookie settings at the bottom of every page.

What each option does
Accept all
Essential storage, the HubSpot booking calendar, and HubSpot analytics cookies.
Essential only
Essential storage and the HubSpot booking calendar, which sets its own cookies when it loads on the contact page. No analytics.
Deny
Only what's needed to remember this choice. No analytics, and the booking calendar stays off until you click to load it.

Privacy policy: cookies and analytics