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.

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.