Add Your Heading Text Here
FDA QMSR compliance.
Inside Azure DevOps.
On February 2, 2026, Part 820 became the QMSR and the inspection technique FDA had used for decades was withdrawn the same day. The requirements barely moved. The way they get evaluated moved a long way — and your risk documentation is now the route an investigator navigates by.
Modern Requirements4DevOps · Copilot4DevOps · Agents4DevOps — requirements, risk controls, tests and evidence as work items in one project.
Was
QSR, Part 820
Now
ISO 13485:2016 incorporated by reference
Was
QSIT, subsystem sampling
Now
Six QMS areas, four OAFRs, risk-based sampling
Was
Findings cite CFR subparts
Now
Findings cite ISO clauses by number
Was
Audit & management review exempt
Now
Both fully inspectable
The challenge
The requirements held. How an investigator arrives at them did not.
FDA's own final rule describes the old and new requirements as substantially similar. That is accurate, and it is exactly why some teams under-prepared. What changed is the route through your system — and a route that runs on risk documentation exposes a different kind of weakness than a route that ran on subsystems.
QMS areas, every inspection
Under Model 1, at least one element from each of the six areas is examined. No area is skipped outright.
OAFRs verified separately
UDI, device tracking, MDR and corrections and removals. US statutory obligations ISO 13485 does not address.
Certifications against Part 820
ISO 13485 certification is useful evidence of a working system. It is not QMSR compliance, and no certificate speaks to the OAFRs.
Business days to respond
The practical window for a written response with corrections and corrective action plans after a Form 483.
Structure per Compliance Program 7382.850. Confirm the exact response window against the Form 483 you receive rather than against this page.
Risk documentation is the navigation, not a deliverable
The investigator identifies the risks the device could pose to patients, then uses your own risk records to decide where to look next. A risk file that is complete but disconnected sends them straight into the gap.
The loop from the field back into risk
Postmarket feedback that never reaches risk management is named in the compliance program as an example pointing toward an initial OAI. It is a risk failure, not a documentation failure.
Procedures organised by CFR subpart now need translating
Observations arrive referencing ISO clauses. If your SOPs cite 820.30 or 820.100, the citation no longer resolves to anything — and the translation happens under inspection pressure.
Internal audits and management reviews are reviewable
The old exemption is gone. An absence of internal findings can now read as audits that are not looking hard enough, rather than as a system in good health.
Early enforcement
Just over 100 inspections in. One area comes first every time.
At the Food and Drug Law Institute annual conference in May, Keisha Thomas, associate director in CDRH's Office of Product Evaluation and Quality, ranked the top areas for Form 483 observations issued between February and mid-April. Read it as directional — the ordering below the top spot has not settled.
Gestion des risques
The file looks complete but cannot show the connective work: how complaints, nonconformances, service data, field failures and supplier issues feed back into the analysis, who owns those updates, and how control effectiveness is verified over time.
Outsourcing and purchasing
Rarely an empty supplier file. Usually a generic one, with a low-risk packaging vendor and a critical contract sterilizer governed by the same template and the same review cadence.
Complaint handling and feedback
Fails at the handoffs rather than in the procedure. The signal arrives but does not travel upstream.
UDI
One of the four OAFRs, verified separately from anything your certification covers.
Corrective action
Existence of a procedure is not the question. Evidence the action worked is.
Risk, risk, risk, risk. That is the fundamental change to QMSR.Keisha Thomas, associate director, CDRH Office of Product Evaluation and Quality, 2026, as reported by The FDA Group
Risk management came first at all three spring events. Below it the ordering moves — MedCon put outsourcing and purchasing second for the February to March window, while at the RAPS Quality Conference the list ran risk management, corrective action, risk-based approach, complaint handling and purchasing. Thomas added the caveat that matters most: the agency is largely seeing the same citations it saw before the QMSR, in a different order.
How an inspection runs
Two coverage models, and one rehearsal worth running.
Every inspection follows one of two models, and the model sets the minimum amount of your quality system that gets examined. In both, the investigator can add elements whenever conditions warrant — the model is a floor, not a ceiling.
At least one element from each of the six areas
Plus the applicable OAFRs and general items. Every main part of the system is touched, even if only at one element. Applies to non-baseline surveillance, compliance follow-up, for-cause, specific product risk assignments, and PMA postmarket inspections.
Named minimum elements across all six areas
Design and development alone expands to inputs, outputs, review, verification, validation, software validation and transfer. Applies to baseline surveillance and PMA pre-approval inspections, where FDA has no inspection history or an application pending.
The preparation exercise FDA suggested
Asked at the town hall how to prepare, officials pointed at one rehearsal. Start with a single identified patient risk. Follow its controls forward into design inputs, through process validation and production controls, out into complaint handling and postmarket feedback, and back into risk management.
Try it on your own system and one of two things happens. Either the walk completes, and you have your inspection rehearsal. Or it stalls — and where it stalls is diagnostic. In our experience the stall is almost never a missing document. It is a missing link between two documents that live in different systems, maintained by hand, and last reconciled at some point nobody can name.
The platform
Built inside Azure DevOps. Not integrated with it.
Modern Requirements is the backbone of requirements work inside Azure DevOps, where your engineering team already works. When requirements, risk controls, tests and results are work items in the same project, the trace is a by-product of doing the work rather than something reassembled before an inspection.
Bidirectional traceability, queryable at any moment
Walk from hazard to verified test result and back from a complaint to the design input that caused it. Coverage views surface the risk control with no requirement and the requirement with no test.
Immutable baselines at every design milestone
Show what the design looked like at any freeze point and exactly what changed since — versioned and audited, not reconstructed from change logs.
Electronic sign-off where the work lives
Review and approval carry electronic signature, attached to the work items themselves rather than exported into PDFs on a shared drive. Confirm Part 11 scope
Documents generated from live project data
Design and development file output assembled from the current state of the project, so the record and the work cannot drift apart between milestones.
Exigences modernes4DevOps
Author requirements in Azure DevOps and walk the trace in either direction. Review and approval carry electronic sign-off, and every baseline is versioned and audited.
Copilot4DevOps
Ambiguity, missing acceptance criteria and untestable phrasing flagged as the requirement is written — because an input no test can satisfy is the upstream cause of a lot of design control findings. Every suggestion is accepted, edited or rejected by a person.
Agents4DevOps
Gaps surface the day they appear, not the week before an inspection. Every finding arrives with its reasoning attached, and a person accepts or rejects it before anything touches a controlled record.
Compliance4DevOps Coming early Q3
Your evidence, mapped to the clauses it answers. Observations arrive in clause language now. Your proof should speak the same language. Confirm scope & timing
Resources
Read the detail before you talk to anyone.
Two things worth your time if you are working out what QMSR readiness actually requires. No call attached to either.
Field guide · PDF
QMSR Field Guide: how FDA inspects medical device manufacturers now
Thirteen sections and the reference tables — the six QMS areas and their elements, where each OAFR attaches to ISO 13485, both coverage models, the terminology crosswalk, and the five things teams consistently get wrong.
Download the guide →Article
FDA QMSR and ISO 13485 Requirements Governance: What Medical Device Teams Need to Know
For years, medical device makers and sellers in the USA followed 21 CFR Part 820, known as the Quality System Regulation (QSR). Along with them, they were also required to follow ISO 13485, which is the main global standard for quality management systems for medical device companies. So, the real challenge was managing both separately.
Read the article →The questions strong buyers ask
What a quality director wants answered before talking to anyone
Straight answers, including where the honest answer is that something stays in your eQMS.
We're ISO 13485 certified. Doesn't that cover QMSR?
No, and this is the most common misread. Certification and notified body audits are useful evidence of a working system, but there is no certification against Part 820. The four OAFRs — UDI, device tracking, MDR, and corrections and removals — are US statutory obligations that ISO 13485 does not address, so they get verified separately regardless of your certification position. The Subpart B supplements at 820.35 and 820.45 sit outside the standard too.
Do we have to retrofit records created before February 2026?
No. FDA states in its own QMSR FAQ that manufacturers do not need to revise or recreate records created before February 2, 2026, and officials confirmed at the April town hall that older documents do not need ISO 13485 references added and that terms like design history file do not need scrubbing from historical records.
Those records are inspectable, though. What is expected is that you identify where processes need to change and plan those changes. Old records do not need new labels. Old gaps still need closing.
Does Modern Requirements replace our eQMS?
No. Document control, training records, supplier qualification and the wider quality system stay where they are. What we hold is the design record and the traceability chain that runs through it — requirements, risk controls, tests, results and their relationships, as work items in Azure DevOps.
The findings driving early QMSR observations are largely connection failures in that chain, which is why it is worth putting where the engineering work already happens. Confirm eQMS integration positioning with product
If this holds our design record, do we have to validate the tool?
Yes — and any vendor that dodges this question should worry you. Software used in your quality processes needs validation for intended use. Because Modern Requirements runs inside your existing Azure DevOps environment, it inherits a platform your organisation has typically already qualified, which narrows the validation scope to the capabilities you deploy. Confirm validation pack / IQ-OQ documentation offered
Our engineers don't use Azure DevOps. Is this still relevant?
The QMSR material on this page stands on its own, and the field guide is worth reading either way. The platform argument does depend on Azure DevOps, because the whole point is that the trace maintains itself as a by-product of work happening in one system rather than being reconciled across several. If your engineering team works elsewhere, that argument applies in principle but not in our product.
How does AI output stay defensible in a design history file?
Every suggestion is accepted, edited or rejected by a person before it enters the record, and findings from agents arrive with their reasoning attached. Nothing changes a controlled record silently. That provenance is the difference between AI output that functions as evidence and text from a chat window that does not.
Talk to us
See it on a device program shaped like yours
A working session with our MedTech team, in an environment preloaded with hazard analysis, design control structure and review workflows. Your standards, your vocabulary, your artifact types.
- Walk one patient risk end to end — hazard, control, requirement, verification, field feedback, and back
- See coverage views surface the risk control with no requirement, and the requirement with no test
- Watch design and development file output assemble from live work-item data
Prefer to read before you talk? The QMSR Field Guide covers all of this in thirteen sections, including the reference tables. No call attached. Get the field guide →
Request received
Our MedTech team will be in touch within one business day to agree a time and confirm what to preload for your program.
While you wait — read the QMSR Field Guide →
