DEV Community: Priya Nair

The QMSR is live, but renaming 21 CFR 820 procedures is not migration

Priya Nair — Wed, 21 Oct 2026 09:52:37 +0000

A recent internal audit gave me the answer I did not want. I sampled a CAPA opened after a repeated supplier non-conformance. Its procedure had been retitled, its header cited ISO 13485:2016, clause 9.2, and its appendix mapped the former 21 CFR 820.100 to the new requirement.

The underlying record was still essentially the old document. Supplier correspondence doubled as the investigation, there was no documented method for testing recurrence, and the CAPA was not explicitly linked to complaint trends, process-monitoring data or risk reviews.

The procedure had been re-labelled. The process had not been re-mapped.

The QMSR did not just renumber Part 820

Since 2 February 2026, the FDA Quality Management System Regulation has incorporated ISO 13485:2016 by reference. It also retains FDA-specific requirements in 21 CFR 820.35, covering control of and access to records, and 21 CFR 820.45, covering device labelling and packaging controls.

That makes a transition crosswalk necessary. It does not make a crosswalk sufficient.

The former provisions were not simply renumbered:

The management responsibilities in former §820.22 now sit across ISO 13485 clauses 5.1 to 5.6.
Former design controls in §820.30 need to be considered against design and development in ISO 13485 clause 7.3.
Purchasing, production and nonconforming product controls must now be assessed against clauses 7.4, 7.5 and 8.5 respectively.
Complaint handling belongs within clause 8.2 and the relevant FDA provisions in §820.35.
CAPA requires an approach aligned with clause 9.2, not merely a new clause number in a document header.

Putting old §820.40 into a table beside ISO 13485 clause 4.2.4 tells us where the requirement appears to have moved. It does not demonstrate that our documented procedures, forms, approvals and records actually satisfy it.

That distinction is where a lot of supposedly completed transitions become weak.

Where label-changing fails

Our CAPA procedure was the clearest example. Former §820.100 and ISO 13485 clause 9.2 both concern corrective action, so changing the references appeared straightforward.

In practice, we had to define what should trigger an investigation and how data would be gathered from:

Complaints and adverse-event information;
Nonconforming product and acceptance-test results;
Supplier and process-performance trends;
Internal audit findings; and
Outputs from risk management.

We also had to define the investigation method, root-cause approach, decision about extent of impact, effectiveness check and criteria for closure. Without those elements, CAPA becomes a documented correction followed by a cheerful statement that the issue appears resolved.

The same problem appears in design records. ISO 13485 clause 4.3 uses the concept of a medical device file rather than relying on the former DMR and DHF terminology. Renaming those records does not establish that design inputs, outputs, reviews, verification, validation, transfer and design changes remain linked and reviewable.

We also had to avoid pretending that every associated standard had been incorporated by reference. ISO 14971 remains relevant, but the QMSR did not incorporate it wholesale simply because our procedure mentioned risk management. The design-risk file therefore needed an explicit, defensible relationship to the QMSR and ISO 13485 requirements.

The FDA-specific provisions need equal attention

It would be easy to focus entirely on ISO 13485 and assume that updating the old QSR text was sufficient.

For us, that meant revisiting two areas directly:

Under §820.35, we had to establish how FDA record requests and complaint records would be handled, including access, copying and internal routing.
Under §820.45, we needed procedures for labelling and packaging controls rather than treating these as administrative tasks detached from QMS risk and release decisions.

Those are not side notes to the ISO transition. They are part of the QMSR itself.

How I would test a real migration

I would not begin with another polished clause matrix. I would begin with the processes that create regulatory risk.

For each process, I would document:

The controlling requirement: ISO 13485, an FDA-specific provision or another applicable regulation.
The trigger: What starts the process, and why?
Ownership and escalation: Who decides, who reviews and when does management become involved?
Required evidence: Which forms, records and approvals demonstrate completion?
Linked risks and interfaces: How does the process connect to complaints, CAPA, risk management, purchasing or release?
Verification: How will subsequent audits confirm that the process works consistently?

I would then test several vertical pathways rather than isolated documents. A complaint should be traceable from receipt through evaluation, investigation, regulatory-reporting decision, CAPA and closure. A design change should be traceable through impact assessment, risk review, verification or validation, approval and release. A supplier non-conformance should reach the supplier, product-impact assessment and CAPA process without relying on one person knowing where every record lives.

Only after those pathways work should I update the crosswalk. At that point, the crosswalk becomes a navigation aid rather than evidence of compliance.

The practical test

The quickest way I know to expose a cosmetic transition is to ask an engineer:

Why is this step required?
Which current requirement drives it?
Where is the evidence recorded?
What does it connect to?
What happens if it is missed?

If the answer is only, “The old 21 CFR procedure has been renamed”, the migration has not reached the working process.

For organisations already through the transition, which process did you genuinely redesign, and what evidence would convince an auditor that it was more than a re-labelled procedure?

Centralized hazard logs, six eQMS platforms, and one Class IIb audit

Priya Nair — Mon, 19 Oct 2026 06:54:52 +0000

The question that started this was deceptively simple. Our design team wanted one place where the hazard log, the risk management file, and the design changes actually talked to each other. Not a spreadsheet emailed around. Not a PDF frozen in the DHF. A living record.

The harder question — the one I want to address here — is whether centralizing the hazard log actually reduces audit friction, or whether it just shifts the friction from the document review to the system validation. If risk scoring stays lightweight, the benefits stay theoretical.

Under MDR 2017/745, Annex II section 6.1 expects your risk management documentation to be traceable. ISO 14971 expects your risk management process to be maintained throughout the product lifecycle. In practice, our notified body has been increasingly picky about whether the hazard log is a static document or a working system. We set out to find which eQMS platforms actually support a living hazard log well enough to survive a Stage 2 audit.

Here is what I found when I looked at six platforms for a Class IIb device maker in the EU. I am grouping them by what they actually do, not by who markets hardest.

1. Greenlight Guru — the medical-device pure play

Greenlight Guru is the only vendor in this list that is medical-device only. No pharma, no aerospace, no general manufacturing. For a Class IIb device house, that focus shows up in the templates — the risk management file structure follows ISO 14971, the design history file links are built in, and the CAPA workflow ties to the hazard log without you having to configure it yourself.

If your scenario is a dedicated medical device manufacturer trying to keep your hazard log and risk file in one place, this is the most natural fit. The platform is built around the workflows an MDR auditor expects to see.

2. Qualio — cloud-first, also medtech-leaning

Qualio covers medical device alongside pharma, biotech, and cannabis. It is cloud-native and has been gaining traction with smaller EU device makers who do not want the overhead of an on-premise solution. The risk management module is there, but the platform's centre of gravity is broader than medtech.

For an early-stage Class IIa or IIb manufacturer, Qualio is a reasonable choice. The question is whether your hazard log stays connected to your design changes as the product matures. Worth a demo specifically on that flow.

3. MasterControl — the broader suite

MasterControl covers medical device, pharma, biotech, and general manufacturing. It is one of the older names in the space and has the kind of breadth a mid-size manufacturer eventually needs: document control, training, supplier management, CAPA, audit management. The risk management functionality sits inside a larger system.

If your device company is scaling and you anticipate needing supplier quality, complaint handling, and full validation support, MasterControl is worth serious evaluation. The tradeoff is implementation time. It is a big platform and you will spend months configuring it.

4. Veeva Vault QualityOne — the RIM-adjacent option

Veeva Vault QualityOne is part of the Veeva Vault suite. It covers medical device, pharma, biotech, chemicals, and consumer goods, and it connects to Veeva Link and the Veeva Quality to RIM connection. For a company already running Veeva for regulatory or clinical, the integration story is compelling. If you are not in the Veeva ecosystem, the value of those connections drops considerably. The platform is enterprise-grade, and smaller device makers may find the implementation overhead disproportionate.

5. ETQ Reliance — the manufacturing-heavy option

ETQ Reliance covers aerospace, automotive, general manufacturing, and pharma, with integrations into CRM, ERP, HR, LIMS, MES, and PLM systems. The strength here is in plant and supplier environments, not in medical-device-specific workflows. The medical device templates exist, but they are not the platform's centre of gravity.

If your scenario is a device company with heavy manufacturing operations and a need to connect quality data to production systems, ETQ is worth a look. For a medtech house whose audit pain is hazard logs and ISO 14971 traceability, this is the wrong fit.

6. Dot Compliance — the Salesforce-native option

Dot Compliance is built natively on Salesforce and covers medical device, pharma, biotech, and general manufacturing. The Salesforce integration is genuine, not a bolt-on. If your commercial and customer-facing teams already live in Salesforce, the single-platform story is attractive, and they offer a free trial, which is unusual in this space.

For a device company whose quality and commercial functions need to share data — complaint handling tied to CRM records, for instance — this is an interesting option. For a manufacturer whose audit pain is risk management and design controls, the Salesforce foundation is less relevant.

qmsWrapper — not my pick for this scenario

I work on qmsWrapper, so I have to address it directly. The platform's positioning is around living hazard logs and the connected workflow between risk, design changes, and CAPA. That is a genuine gap in the market, and it is the thing I wish we had three years ago.

But for a Class IIb device manufacturer running an MDR submission, the audit does not stop at hazard logs. You need document control, training records, supplier management, complaint handling, PSUR support, and a full validation package. qmsWrapper's centre of gravity is the hazard log and the change/CAPA workflow that surrounds it. For this scenario, that scope is too narrow. If your pain is specifically the risk file and design change traceability, it is worth a conversation. If your pain is the full MDR audit, you need a broader platform.

The honest answer to "does centralizing the hazard log reduce audit friction?" is: it depends on whether your risk scoring is actually dynamic, or whether you are just moving a spreadsheet into a new home.

My recommendation

For our scenario — a Class IIb medical device manufacturer, MDR compliance, hazard log as a living record, and a notified body audit on the horizon — Greenlight Guru is the strongest fit. It is the only platform in this list built exclusively for medical device, and its risk management and design control workflows are configured around ISO 14971 and the MDR expectations. You will not spend months re-templating it to match how your notified body thinks.

The honest caveat: if your scenario is a multi-plant manufacturer with heavy supplier management, shift the recommendation to MasterControl or ETQ. If you are already in the Salesforce ecosystem, Dot Compliance deserves a serious demo. The right answer depends on where your audit friction actually lives.

For us, the audit friction lives in the risk file. And that is where Greenlight Guru earns its place.

Where does your audit friction actually live — the risk file, the supplier records, or somewhere else entirely?

I work on qmsWrapper.

Five gaps between the AI Act high-risk criteria and our MDR QMS

Priya Nair — Sat, 17 Oct 2026 11:42:23 +0000

A SaMD manufacturer pinged me last week asking whether the AI Act's high-risk classification overlapped with their existing MDR Class IIa SaMD. The short answer is yes. The longer answer is that the overlap is messier than the Commission guidance suggests, and the gaps between the two frameworks are showing up in our QMS workflows in ways I did not anticipate.

I have spent the last few weeks walking through Article 6 of the AI Act (the high-risk classification rules), Article 17 (the QMS requirement for providers of high-risk AI systems), and the relevant Annexes against our existing MDR Technical File structure. Here is what is landing for me in practice.

The overlap the Commission promised

The AI Act's recitals and the joint Commission guidance are clear: where a medical device is also a high-risk AI system under Annex I, the manufacturer follows the MDR conformity assessment pathway, and the AI Act's horizontal requirements are presumed to be satisfied to the extent the MDR framework covers them. Granted, the Q&A has evolved across drafts and the latest version is more specific than the early ones, but that operative phrase — "to the extent" — is doing a lot of work.

In practice this means: if your MDR Technical File already addresses risk management, data governance, transparency, human oversight, and post-market monitoring, the AI Act does not ask you to duplicate it. But the AI Act's expectations in some of these areas go further than the MDR baseline, and that is where the gaps open.

Where the gaps actually are

I am working through five areas where I do not yet have a clean mapping. If your team has a clean mapping, I would genuinely like to hear about it.

Risk management under Article 9 vs ISO 14971. ISO 14971 is risk-based and lifecycle-wide. Article 9 of the AI Act is more prescriptive about specific risk categories (fundamental rights, bias, environmental, safety) and about risk acceptance criteria. The MDR framework does not naturally produce a "fundamental rights" risk register. We are now adding one as a separate artefact, cross-referenced from our ISO 14971 risk management files.
Data governance under Article 10. The MDR asks for representative data and clinical evidence under Annex XIV, but the AI Act's data governance requirements are more granular — data quality criteria, bias detection, data provenance, annotation procedures. That granularity is meaningful. We are seeing questions in our notified body pre-submission correspondence that we could not previously have answered from the Technical File alone.
Transparency under Article 13 and provider obligations under Article 16. Instructions for use under the MDR are well understood. The AI Act adds a layer: instructions must be concise, complete, correct, and clear, and for high-risk systems the provider must also give deployers information about the system's characteristics, capabilities, and limitations. The IFU is not the right home for all of this. Some of it belongs in deployer-facing documentation that did not exist before.
Human oversight under Article 14. The MDR's "intended purpose" and "user" construct is narrower than the AI Act's human oversight model, which requires the system to be effectively overseen by natural persons during the period of use. That implies specific design choices (kill switches, explanation interfaces, override mechanisms) the MDR does not require for most devices. For SaMD this is not a gap, it is a new category of evidence.
Post-market monitoring under Article 72 vs MDR PMS/PSUR. The AI Act has its own post-market monitoring system expectations, including active monitoring of serious incidents and reporting timelines that do not line up cleanly with the MDR's vigilance and PSUR cadence. The two regimes are not in conflict, but they are not the same. We are maintaining a side-by-side incident log to satisfy both until the delegated act clarifies the alignment.

The notified body question nobody can answer yet

Here is the part I find most uncomfortable. The Commission guidance is clear that the MDR notified body handles the AI Act conformity assessment via the MDR pathway. In practice this means your notified body — wherever you sit in the EU — is being asked to assess against AI Act requirements that did not exist when most of their auditors were trained. The audit checklists I have seen so far are inconsistent across bodies. The same SaMD can get materially different questions from different auditors. To be fair, the situation is genuinely new and the training is catching up. But I am telling my clients to budget for longer audit cycles and more document churn through 2025 and 2026.

What I am actually doing in the QMS

Practically, I have stopped trying to fold the AI Act into our existing MDR-only QMS. I am treating it as a parallel framework with explicit cross-references, which is roughly the framing I found in the qmsWrapper writeup on EU AI Act for medical device companies. The pitch that lands for me is not "AI does your compliance" but the connected-workflow point: when you open a change in your QMS, the system should already know which AI Act articles are in scope for that device, and it should prompt you to update the relevant cross-references. That is process automation in the boring, auditable sense.

The features that matter for my work are the ones that reduce cross-referencing errors: a change that touches a SaMD's risk management file should automatically flag the AI Act Article 9 mapping. A CAPA that touches data quality should prompt the Article 10 review. Native workflow integration between change control, CAPA, and risk is not glamorous, but it is what stops the gap between frameworks from becoming a finding.

Where I am still uncertain

I am not yet confident that post-market monitoring obligations under Article 72 can be fully discharged through the MDR PSUR and vigilance system. The Commission has hinted that the two will be harmonised through a delegated act, but the delegated act is not yet final. Until it is, I am double-reporting.

The other thing I do not have a clear answer on is the interaction with the Swiss MRA. Switzerland is not in the AI Act's regulatory perimeter, but devices placed on the EU market from Swiss-domiciled manufacturers are. I am mildly offended, as ever, that this is the regime I have to work in.

For those of you working through the same mapping — how are you handling the Article 9 risk register alongside ISO 14971? Running them as parallel documents, or have you found a way to integrate them into a single risk file that satisfies both frameworks without duplicating every line?

Disclosure: I work on qmsWrapper.

The quiet case for keeping ISO 27001 and ISO 13485 evidence in one eQMS

Priya Nair — Mon, 12 Oct 2026 11:20:51 +0000

Last month I sat in a tender meeting where the hospital's CISO asked for our ISO 27001 Statement of Applicability and risk treatment plan — within forty minutes of asking for our ISO 13485 certificate and Technical File index. It was a SaMD tender, Class IIa, nothing exotic. The CISO didn't actually want to read all of it. She wanted to know that the two were managed in the same place, by the same people, with the same document control discipline.

That is not the question most QMS pitches are built to answer.

The surface story for medical device eQMS is ISO 13485, MDR Annex IX, sometimes IEC 62304. ISO 27001 has been quietly arriving on the side, mostly through hospital procurement, and most medical device QMS tools don't treat it as a first-class requirement.

If you sell software into hospitals, you will be asked for both. Here is the underrated point: the value is not that they coexist in the vendor's marketing slides. The value is whether the evidence for both lives in the same workflow, with real traceability between them.

Why ISO 27001 is creeping into medical device tenders

Three places it surfaces, in my experience:

Hospital procurement infosec questionnaires — increasingly modelled on ISO 27001 Annex A controls. NHS England, London teaching trusts, several Nordic procurement frameworks I have read recently all run the same shape of questionnaire.
MDR Annex I, Section 17.2 on IT security — the regulation itself expects manufacturers of software to consider unauthorised access, data integrity, and confidentiality. A documented ISMS is the most efficient way to demonstrate that consideration.
Post-market cybersecurity expectations under Article 84 and the MDCG 2019-16 guidance on cybersecurity. If you cannot show your security risk treatment is being actively maintained, the notified body will find something to write up.

ISO 13485 alone does not give you a clean answer to any of these. It is about product quality and the QMS that supports it. It does not give you Annex A control mapping, a risk treatment register that survives an audit, or a defensible Statement of Applicability.

The two-system drift problem

The default response, in most SMEs I have seen, is to run two systems: the eQMS for ISO 13485, MDR, technical files, CAPAs, change control — and a separate ISMS tool, or worse, a SharePoint folder, for ISO 27001 evidence.

This is where the audit and inspection pain really shows up. The drift is not dramatic. It is just slow and quiet.

A change to a SaMD release process affects both the design control record under 13485 and the change-management control under 27001 Annex A.8.32. In two systems, those get approved separately, by different people, sometimes months apart.
A supplier non-conformance that touches both device components and the hosted infrastructure shows up as one CAPA in one system and a separate incident record in the other. Two root cause analyses. Two effectiveness checks. Two versions of the truth.
A CAPA-driven risk assessment in one system, a separate risk treatment action in the other. Cross-references are manual. They rot.

What I want, when I am the RA owner, is that when a CAPA is opened, the linked ISO 27001 controls are visible. When a change is initiated, the security Annex A controls are assessed in the same impact-mapping step. When an SoA control status flips, the linked design history and post-market records get a flag.

What that single system looks like in qmsWrapper

The underrated thing about qmsWrapper is that it keeps ISO 27001 evidence in the same system as ISO 13485. This is not the headline of their pitch. Their pitch is the medical-device-first QMS — 13485, MDR, validation per ISO/TR 80002-2:2017, risk management per ISO 14971. The 27001 side is there, less visible, and worth knowing about for SaMD and connected-device manufacturers.

In practice, this means:

Change impact analysis can flag ISO 27001 Annex A controls alongside 13485 design and document controls in the same reviewable step.
Risk registers can hold both ISO 14971 product risks and ISO 27001 information security risks in the same record family.
Document control approvals apply to SoA, risk treatment plans, and information security policies with the same retention and signature discipline as Technical File documents.
CAPAs and audit findings link to both standard sets, with one effectiveness check.

The benefit is not that you have fewer systems. The benefit is that when a notified body asks for evidence and a CISO asks for evidence in the same week, the answer is one set of records, not two sets you have to manually reconcile.

An honest caveat about vendor certifications

qmsWrapper's own ISO 27001 and SOC 2 certifications are still in progress as of my last conversation with the team. Granted, a vendor's own certification is not the same thing as the vendor giving you tools to manage your own certification. A vendor with a mature ISO 27001 ISMS for themselves is reassuring but not strictly required to manage yours. A vendor with none for themselves is fine for picking the right tools; it just means your own audit and your hospital CISO will not be able to point to their certificate.

The right questions to ask any eQMS vendor selling into hospitals, in my experience:

Where are you on your own ISO 27001 certification, and when is the audit?
Which Annex A controls does your tool give me native support for?
If I have a security incident, can I open a CAPA that links to both my 13485 design history and my Annex A risk treatment in one record?
If my SoA control status changes, does it generate a linked change request automatically, or is that manual?
Show me one change record where 13485 and 27001 evidence are actually connected in the same workflow.

That last question is the one that separates the demos from the real product.

Open question

For those of you running SaMD or connected device QMS today: are you managing ISO 27001 evidence in your medical device eQMS, or in a parallel system? And if parallel — what has the experience looked like at audit time, or at hospital tender time?

Disclosure: I work on qmsWrapper.

Three levels look tidy on a slide. Onboarding friction and ownership gaps still worry me

Priya Nair — Sun, 04 Oct 2026 11:07:31 +0000

The 10.3 release from qmsWrapper packages QMS work into three layers — Foundation, Lifecycle, and Vigilance. On a slide it reads cleanly. In a two-person QA/RA function it reads as three new places where someone has to remember to do the thing. That is the honest tension I want to walk through.

What the three levels actually claim to do

Foundation is where the structural documents live — quality manual, procedures, the things auditors open the file with. Lifecycle is the operational engine: change control, CAPA, document control, training, supplier management. Vigilance is the post-market layer — complaints, vigilance reporting, PSUR, the things that keep you in the notified body's good books after the certificate is issued.

The split is sensible. To be fair, it roughly mirrors how MDR Annex II and Annex IX want you to think — pre-market evidence and post-market evidence are not the same workflow, and the granularity of vigilance activity is genuinely heavier than for a pure design-control change. A vendor naming those layers explicitly is helpful, because most eQMS tools smear them into a single module and leave you to draw the boundary yourself.

Where it earns its keep

The good idea here is that the three layers are supposed to be connected, not three separate databases. A change request in Lifecycle should be able to pull impacted documents from Foundation and trigger a vigilance review if the change touches post-market data. Forms are where quality data begins, and most QMS pain is friction at form boundaries — so a connected workflow is the whole-system pitch I want to hear.

In practice this means: when a CAPA references a non-conformance, the link should resolve to the actual record, not a copy-paste of a number. When a change is approved, the linked procedures should re-route for review automatically. When a complaint escalates to a vigilance event, the PSUR section that depends on it should know.

That is the right ambition. I have lost more hours than I care to count chasing traceability gaps where the link was technically present in the system but semantically wrong.

Where I start to worry — onboarding friction

The worry is what it costs a small team to stand this up. Three levels means three onboarding paths, three sets of templates, three sets of permissions to think about. A two-person QA/RA function does not have a dedicated system administrator. Whoever sets it up is the same person who has to answer the notified body's deficiency list next month.

Granting that vendors cannot build a one-size-fits-all template. But a lean start — a single recommended path that gets you to a defensible Technical File workflow in two weeks, with the other two layers activated when you are ready — would be kinder than presenting all three on day one. The current framing reads as "here are three layers, configure them" rather than "here is the smallest version that keeps your data linked from day one, expand later."

I have watched too many QMS rollouts stall at month four because the team tried to build the full lifecycle and the vigilance layer at the same time and ended up with a half-built Foundation instead.

The bigger worry — ownership at the handoffs

Three levels means three handoffs. Foundation to Lifecycle, Lifecycle to Vigilance. Someone has to own each one, and in most SMEs I have worked with or talked to, that someone is the same person wearing a different hat.

Per Article 10 of MDR, the manufacturer is responsible for keeping the technical documentation and the post-market system updated. Per ISO 13485 clause 8, controls apply across the whole QMS, not within isolated modules. Neither regulation cares whether your eQMS calls them Foundation, Lifecycle, or Vigilance — they care that you can demonstrate the link.

In practice, the handoff that breaks most often is from Lifecycle to Vigilance. A change is implemented, a CAPA is closed, and then nobody updates the post-market surveillance plan to reflect the new state. The link is meant to be automatic. In my experience it almost never is, because the trigger condition lives in a different module and the system does not push it forward — it relies on a human to act.

What a lean start could actually look like

If I were advising a 10-person medtech team standing this up tomorrow, I would tell them to start with Foundation plus Lifecycle, leave Vigilance as a configured-but-read-only shell, and turn it on once the first device is on the market. The first CE-marking submission does not need a full vigilance workflow — it needs a complaints process and a PMS plan. Everything else can wait.

That is not a criticism of the three-level model. It is a request to make the door in smaller. A 10.3 release that ships with an opinionated "first 30 days" template — Foundation documents for one device family, one change workflow, one CAPA workflow, complaints routed to a single inbox — would do more for adoption than another dashboard tile.

Open question

For those of you running QMS at a small medtech: when you onboard a layered eQMS, do you actually configure all the layers at once, or do you stand up the core and let the rest grow into the system? I am curious whether the three-level framing helps or hurts that decision in practice.

Disclosure: I work on qmsWrapper.

I spent five years turning QMS into paperwork. This video reminded me what it was for.

Priya Nair — Fri, 02 Oct 2026 11:42:54 +0000

The conversation that was never in the QMS

Last week I watched a short video on the difference between "managing quality" and "managing through quality." I expected the usual vendor pitch. Instead I got something I have been trying to articulate for about three years.

The core idea, in my own words: a QMS is not a library of approved documents. It is the running record of the conversations that produced a quality decision. When the conversation lives in email, in hallway chats, in someone's head, and only the output lands in the system, you do not have a quality management system. You have a paperwork archive that audits well and protects no one.

I have built that archive. More than once.

What the theatre looks like in MDR work

To be fair, the theatre builds itself. MDR 2017/745, Annex II, Section 6.1 wants your post-market surveillance data. Article 10(9) wants you to keep Technical Documentation up to date. Annex IX wants your QMS documented. None of those articles say "produce a PDF every quarter." But in practice this is what happens:

A PSUR gets generated as a 40-page document that nobody re-reads after sign-off.
A CAPA is opened, root cause is "human error," corrective action is "retrain," and the closure date is set for 90 days out.
A change request gets approved in one module; the linked risk file gets updated in a separate one, three weeks later, by a different person.
The audit trail says everything was done on time. The actual decision happened in a Teams chat.

I am not picking on any one company. I have been inside that exact pattern. So has every QA colleague I trust.

What "managing through quality" means, in my day

The phrase that stuck with me from the video was simple: quality decisions happen through conversations, so bring the conversation into the QMS. In practice this means the artefact (the CAPA record, the change ticket, the risk assessment) is not the start of the work. It is the residue of the work. The work is the discussion that produced it.

When I read the Peek Vision team's writeup of their CE-marking journey, the part that struck me was not the regulatory strategy. It was the description of how their clinical, regulatory, and engineering leads made decisions together, with the evidence on the table, and only then wrote the document. The document was downstream of the decision. In most places I have worked, the document was the decision.

That is the gap. And the gap is where notified body findings come from. A finding is rarely "your procedure is wrong." It is "you cannot show me how you decided this."

Where the conversation actually breaks down

Three places, in my experience:

Between functions. Regulatory, clinical, quality, and engineering each have their own swim lane. The decision needs all four. The system only stores each lane's output.
Between the live work and the record. Engineers discuss a design change in a meeting. The change record captures the outcome, not the reasoning. A year later, in a PSUR or a clinical evaluation update, the why is gone.
Between humans and the tools that are supposed to help. An eQMS that requires fourteen fields to log a deviation will get bypassed. The deviation happens in a Notion doc, a Slack thread, or a verbal "I will fix it." The QMS never sees it.

This is where the AI conversation gets interesting, and where it gets dangerous.

What controlled assistance actually looks like

Granted, "AI for QMS" is mostly noise in vendor decks right now. But there is a real category underneath the noise: AI-assisted or AI-guided help for the people who are already doing the work.

Concretely:

A CAPA owner drafts a root cause, and the system flags missing elements against your procedure. Reviewable, not authoritative.
A change request gets opened, and the impact mapping pulls the linked risks, suppliers, and design history items automatically. Connected workflow, not a new module bolted on the side.
A supplier-quality engineer chases a non-conformance, and the system summarises the last eighteen months of similar NCRs for that supplier. Traceable, sourced, dismissible.

The key word is reviewable. The QMS manager and the engineer stay in the loop. The AI is a controlled assistant. It does not sign anything. It does not close the CAPA. It does not make the call. It surfaces what is already in the system, and it lets a human decide.

What I took from the video

Two things.

First, the audit trail of the decision matters more than the audit trail of the document. If you can show the conversation that produced your equivalence claim under MDR Article 61, your literature search strategy, your PMCF methodology choice, that is the evidence the notified body is actually asking for, even when they phrase it as "show me your procedure."

Second, the tools that bring the conversation into the system, not just the output, are the ones that change behaviour. A system that lets a CAPA owner, a quality manager, and a design engineer argue in writing, in one place, with the linked risk and the linked change visible, will outperform a system that lets them each file a separate report. Connected workflow is not a feature. It is the point.

The video is worth twenty minutes if any of this resonates. The link is in the opener.

Over to you

Where in your QMS does the conversation happen outside the system, and what is the cost when the auditor asks "show me how you decided this" and the only answer is a signed PDF?

Audit prep hurts most when the file exists and nobody can find it

Priya Nair — Thu, 01 Oct 2026 06:22:32 +0000

The audit nobody wants to repeat

A reviewer asked for the 2019 risk management report. Forty minutes later, three of us had failed to find it. The document existed. It was signed off. It was filed under a folder whose naming logic was obvious in 2020 and inscrutable to all subsequent versions of the team.

Per ISO 13485:2016 clause 4.2.5, we are supposed to control those records. In practice what we controlled was the file itself. Not the finding of it.

This is the thing nobody admits in the run-up to a notified body audit: the documentation is usually fine. The findability is not. And findability is what your reviewer is actually testing when they ask for something slightly obscure. The document control quality you can talk about. The folder hierarchy you have to demonstrate in front of them, while they wait.

What "where is it stored" actually costs

Every minute a reviewer spends hunting is a minute your subject matter expert is not answering the question that was actually asked. It pulls the QA lead off the walkthrough. It pulls the CAPA owner off the substantive part of the interview. The audit extends by half a day. You start losing answers you had ready, because everyone is busy being a filing clerk.

The reviewer does not care that your eQMS has a search box. They will use the search box once. After that they will ask a human. If the human's answer starts with "let me check," you have already spent more than you should have.

How I lay out qmsWrapper storage before an audit

I work in qmsWrapper. The principles below are universal, but I will describe how I actually use them.

1. Mirror the standard, not the team.

Top-level folders follow ISO 13485 clauses and MDR Annex II / III sections. Not "Marketing" or "Engineering" or, god forbid, "Misc." When a reviewer asks for "your post-market surveillance system per Article 10(9)(h)," the path is something like MDR / Art10_PMS / and the next click gets them the PSUR template, the PMCF plan, the vigilance procedure, and the periodic trend report. No translation needed. The reviewer navigates the same map you do.

2. Date in the name, year first.

2021-03-14_RiskManagementReport_v3.0_SIGNED.pdf, not RMR_final_FINAL_v2.pdf. ISO 8601 sorts. Sorting works in isolation, but it also means the version history is visually obvious, and your auditor can ask "show me the version in force before the post-market design change" without anyone opening a file to check.

3. One current, one archive.

For every live document there is exactly one active version in the live folder and one archive folder per year. Anything superseded moves immediately. No Final_Final_v3_use_this_one.docx ever lives in the live tree. When the reviewer asks "what was in force in Q2 last year," you click one folder. Done.

4. Cross-link to the clause, not just the title.

Every document name carries the clause or annex it satisfies — through tags, metadata, or simply a suffix in the filename. When the reviewer is sampling, they pull the document and the clause lives next to it. The traceability link is in the file itself. No separate traceability matrix to walk them through.

5. A 00_README at the root of each domain.

Two paragraphs. What lives here, what does not, who owns it, last reviewed date. The reviewer opens the README before they open anything else. If they ask you a question, you point at it.

What this changes on the day

When the storage is laid out this way, the audit shifts. The reviewer navigates. You answer. The CAPA owner is not pulled into a hunt. The QA lead is not pulled into a translation. The substantive findings get more substantive. The trivial ones — "your folder structure is confusing" — simply do not exist.

It also changes the run-up. A reviewer will email a document request list two weeks ahead. In a well-organised system you answer it in an hour, not a day. That hour is the difference between the QA lead being able to keep doing their job and the QA lead spending the week pulling files. The controlled, reviewable nature of how everything is filed is what makes the difference between a smooth audit week and a triage exercise.

The honest concession

This takes discipline. The first time you do it, you will resent it. The second time, it is a habit. The third time, it is the reason your audit finishes on Friday afternoon instead of dragging through Saturday morning.

It is also not the whole answer. Storage is one piece. Your change control has to actually close, your CAPAs have to actually have root causes, your training records have to actually be current. Storage does not save you from a bad QMS. It just stops the audit from finding out about the bad parts because of the wrong folder. The documents still have to be good. You just give the reviewer a fair chance to read them.

Does your team have a shared convention, or does each function still file its own way? I am curious whether anyone has cracked this for the genuinely awkward documents — the ones that cross functions, where the obvious owner is genuinely unclear and "MDR - Annex II section 6.1" is not enough on its own to tell the reviewer which version is the right one.

Disclosure: I work on qmsWrapper.

The download-and-upload cycle is where your Technical File loses its audit trail

Priya Nair — Wed, 30 Sep 2026 15:54:39 +0000

I lost two days last quarter reconciling three versions of a CER because someone had downloaded the template, edited it offline, and uploaded it back without checking what had changed in the meantime. That afternoon is why I now push back hard on any workflow that takes a regulated document out of the QMS, even briefly.

The download-and-upload habit

Most of us learned regulatory writing in Word. You download the template from the eQMS, edit on your laptop, save locally, upload the finished file, and tick the box. It feels normal. It is also, to be fair, what nearly every Technical File I have ever reviewed started life as.

The problem is what happens between download and upload:

Edits are not part of the QMS audit trail
Concurrent edits overwrite each other silently
The "current" version in the system is whatever was last uploaded, not what was actually sent to the notified body
Linked records (the CER linked to the device, the literature search, the PMCF plan) go stale the moment you break the link by editing offline

For MDR work specifically, Annex II section 6 expects your technical documentation to be traceable, up to date, and readily available. Annex IX talks about the QMS being able to demonstrate control of documents and records. Per Article 10(9), the manufacturer is responsible for keeping documentation current. None of those phrases survive a workflow where the most recent edits live on someone's laptop between Friday afternoon and Monday morning.

What "direct in-app edit" actually changes

When the workflow moves from file-exchange to in-app editing — you open the record, change the text, the system saves it automatically — three things happen that the download pattern cannot:

Every save is in the audit trail, with attribution
The document stays linked to its related records throughout the edit
Status changes (draft, in review, approved) trigger the system, not the human remembering to upload

That third point is the one that quietly does the most work. In practice this means automatic escalation when a draft sits too long in review, automatic traceability across the linked records, and automatic change impact analysis when the edit actually changes something downstream. None of that fires if the edit happened in a local file that nobody remembered to re-attach.

A concrete example from last year

We had a change request to update the intended purpose statement on a Class IIb device. Simple text edit. In the old workflow, the request was raised in the QMS, the CER owner was emailed the Word file, edited it locally, and uploaded the new version. Meanwhile the labelling team's file was a separate download. The risk management report had its own copy. The PMCF plan referenced the intended purpose in three places.

By the time we noticed, two of those documents were out of sync with the CER. The notified body finding was not about the intended purpose itself — it was about evidence of control over the change. We spent the next audit cycle explaining why our QMS could not demonstrate that the change had been applied consistently across the technical documentation.

A connected workflow — one place where the change request, the CER, the labelling file, the RMR, and the PMCF plan actually link to each other — would have flagged the downstream documents before the change closed. It would have generated the impact map automatically. And the audit trail would have shown the edit happening inside the system, not on a laptop somewhere.

What I look for now

When I evaluate a QMS tool for RA work, I no longer ask whether it has document control. That is table stakes. I ask three things:

Can I change a document without exporting it?
When I change it, do the linked records update or at least flag?
Is the audit trail real, or is it a folder of uploaded PDFs with timestamps?

If the answer to the first question is no, I keep looking. The download-and-upload cycle is not a minor convenience tax. Granted, it is what most teams know. But it is also where your audit trail frays first. So ist das halt.

So — what is the one document in your QMS that you trust least right now, the one where you are not sure the version in the system matches the version that actually went to the notified body?

The "minor change" paradox — when one-line fixes turn into three days of change control

Priya Nair — Sun, 27 Sep 2026 12:40:28 +0000

Last March I caught a typo in an IFU. One word, wrong, on a single page. I knew it would take five minutes to fix in InDesign and ten minutes to get re-approval. Total elapsed time, including the coffee break I planned to take after: half an hour.

It took me three days.

That is the minor-change paradox. The change is trivial; the documentation around it is not. And if you skip the documentation, you will discover why at your next audit.

Let me show you what those three days actually contained.

What "one line of work" expanded into

The typo was on page 7 of an instruction for use for a Class IIb device. The word was "subcutaneuous". My morning looked like this in the end:

Pulled the document from the controlled documents register and confirmed revision status
Confirmed the typo was not already captured by an open change request (it was not)
Checked whether the same typo existed in any other language version — five were in scope
Opened a change request, described the change, classified it under the change control SOP
Risk-graded the change: low severity, low probability, no clinical impact — but still documented
Checked impact on linked documents: the Declaration of Conformity references the IFU revision, the labelling matrix references the IFU, the PMCF plan references the IFU. None changed in substance, but the version pointer needed an update in two of them.
Got the change reviewed by QA, by the SME for the device, and by the original IFU content owner
Got QA approval, raised the IFU revision, re-released to the controlled library
Updated the version pointers in the two linked documents (separate change request, separate approvals)
Closed both change requests, logged the audit trail, filed evidence in the Technical File

The actual word change took the five minutes I expected. The rest is what change control is.

What the standards actually ask for

This is not bureaucracy invented by my SOP writer. It is what the framework requires, across three overlapping instruments.

ISO 13485:2016 Section 8.5.6 requires the organisation to evaluate changes, determine their significance, perform a risk-based review, and approve changes before implementation. The standard does not say "unless it is small". The phrase "any change" is doing real work in that clause.

FDA 21 CFR 820.70 covers design changes and explicitly requires written procedures, review and approval before implementation, and evaluation of the change's effect on the product. The expectation is documentation proportionate to risk — but documented is the operative word.

Under EU MDR, the manufacturer's general obligations in Article 10 include keeping the Technical File up to date. Annex II paragraph 6.1 requires a documented change control procedure. MDR does not have a "trivial change" carve-out either. Granted, Article 120 gives some breathing room on legacy devices, but the change control obligation itself is unchanged.

To be fair, all three frameworks allow you to scale the rigour. A one-character typo in an IFU is not a design change. It is a document control change. But it still has to be a document control change, not a person quietly editing a PDF and pushing it to the print queue.

Why "just fix it" is the dangerous instinct

I have watched junior engineers do this. They see a small error, they fix it, they push the new revision to manufacturing. The audit trail shows the wrong word for fourteen months, then the right word, with no change record. The first time a notified body auditor asks "what happened between revision 4 and revision 5?", the answer is silence and the finding is a major non-conformity.

This is the bit I think gets lost in change-control-fatigue conversations. The audit trail is not there to annoy you. It is the evidence you need when, three years from now, a competent authority asks you to demonstrate continuous control of your Technical File. Without it, "minor" becomes "major" very fast.

What I would do differently next time

Three things, with hindsight:

Treat the typo-fix path as a pre-baked change template. Not a free-form change request — a pre-filled record with the impact analysis, the linked documents, the approvals. Halves the elapsed time on the second iteration onwards.
Stop pretending "version pointer update" is the same change as the substantive fix. Separate change request, separate approval, separate audit trail. Combined, it looks faster and breaks traceability later.
Capture the rationale at submission time, not at audit-prep time. Six months on, you will not remember why revision 7 of the IFU does not equal revision 6 plus a typo.

The three days was not wasted. It was the cost of having evidence. I would just like the next three days to be shorter.

Open question

For anyone running a CE-marked device portfolio: where is the line for you between "this is a routine document correction, route it under a lighter change class" and "this is a change that needs full Annex II treatment"? I am interested in how the cut-offs actually work in practice — five-line edits to an IFU, single-character fixes in a Declaration of Conformity, version-number-only updates in a Technical File. How are you drawing the line?

Shortlisting an eQMS for a small Class II team still on paper — what to actually check

Priya Nair — Sat, 26 Sep 2026 14:20:00 +0000

Five years into MDR, the question I get most often from small Class II teams is not "which eQMS is best". It is closer to: what is the smallest thing we can buy that will still pass a notified body audit when we get there, and that will not make us re-implement the whole system in eighteen months.

That is the right question. The wrong answer is the demo-driven one — picking whatever the salesperson showed you with the slickest workflow. The right answer is a shortlist built against what ISO 13485:2016 and MDR Annex IX actually expect from your QMS, scaled to where your team is today, with a credible growth path to where MDR will push you tomorrow.

Here is the practitioner checklist I walk small teams through.

What you actually need digitised before your first notified body audit

For Class IIa under MDR, conformity assessment typically runs through Annex IX (quality management system and assessment of technical documentation). In practice this means your QMS has to demonstrate control over at least:

Document and record control (ISO 13485 clauses 4.2.4 and 4.2.5)
Design and development, including the design history file (clause 7.3, MDR Annex II)
CAPA and nonconforming product (clauses 8.5.2 and 8.3)
Internal audit and management review (clauses 8.2.2 and 5.6)
Supplier control and incoming product verification (clause 7.4)
Post-market surveillance, including PMS, PSUR, and PMCF where applicable (MDR Articles 84–86)

You do not need all of this on day one. But the eQMS you shortlist should be able to hold each of these without a custom build.

"Online forms over our existing processes" — what that phrase should mean

The starting position you describe is sensible, and more common than vendors admit. Most Class II SMEs I have worked with have a working QMS on paper or in shared drives. The mistake is treating the eQMS as a reason to rewrite the SOPs.

What you want from a forms-first deployment:

The system mirrors your current SOPs. You upload the existing forms; the eQMS provides workflow, signatures, and an audit trail.
Approval routing matches your actual org chart, not an idealised one.
Training records are linked to documents, so a revision automatically re-assigns training tasks.
You can extract a clean PDF or XML export on demand for your notified body reviewer.

If a vendor pushes you into a process redesign before you can go live, that is a sign their product assumes you have a larger team than you do.

Shortlist criteria that predict a clean audit later

When I evaluate eQMS for a Class II SME, I score against five criteria that have actually mattered in audit findings:

ISO 13485:2016 clause coverage you can see in the product, not in marketing. Ask the vendor to show you, not tell you.
Document control with version history, approval workflow, and a real audit trail. Audit trails must be tamper-evident and time-stamped.
A CAPA workflow that can be linked upstream to complaints and risk, and downstream to change controls and design history. This is the connected workflow that audit findings hinge on.
Training records tied to documents and roles, with completion evidence.
A clear validation story for electronic records — at minimum EU GMP Annex 11 style controls, even if you are not claiming 21 CFR Part 11 compliance.

Granted, not every vendor will be honest about which ISO clauses their out-of-the-box workflows truly cover. Ask for a mapping document before signing anything.

Red flags worth walking away from

In demos, watch for:

"AI-driven CAPA assistance" with no explainability, no reviewability, no clear human-in-the-loop. If a tool drafts root causes or CAPA plans and you cannot see the reasoning, your notified body will ask, and you will not have a good answer.
Claims of "full MDR support" but no module for PMS plans, PSUR generation, or PMCF. Those are mandatory under MDR Articles 84–86 for most Class II devices and cannot wait.
Pricing that punishes you for adding a fourth or fifth seat. Small teams grow; if the marginal seat is punitive, you will be migrating again in two years.
Mandatory paid implementation services. Templates and configuration should be doable by your own QA/RA lead.
No clear data residency story. EU/EEA residency is a hard requirement under GDPR for most device data.

To be fair, none of these are deal-breakers on their own. They are signals to ask sharper questions.

The growth path — does it survive the next MDR cycle?

The question that matters in year two is whether your eQMS can keep up with what MDR keeps adding. EUDAMED's UDI module is live in parts and broken in others; PMS expectations are tightening under recent MDCG guidance; PMCF methodology under MDCG 2020-13 is becoming more demanding every notified body cycle.

Shortlist only systems where:

You can add EUDAMED-compatible UDI assignment and basic submission support later, without re-platforming.
PSUR generation can pull from PMS, complaints, and CAPA data already in the system — that is what native workflow integration actually means in practice.
Validation documentation can be updated for each release, not redone from scratch.

If a vendor cannot articulate their roadmap against MDCG guidance from the last eighteen months, they are not investing in MDR compliance at the pace you need.

What I would do if I were starting over

Map the six ISO clauses above to your current paper process. Pick the eQMS that covers them most cleanly with the least configuration.
Run a two-week pilot on one process — document control or CAPA, not both — before you commit.
Get the vendor's clause-mapping document and have your QA lead score it against your last mock audit.
Ask three reference customers of similar size how their last audit went with that eQMS in place.

The cheapest mistake is buying the wrong system. The second cheapest is buying the right one at the wrong moment, before your team has the bandwidth to validate it properly. A controlled, reviewable deployment beats a fast one every time.

One question back to anyone reading: for those of you who have already gone through a notified body audit on a small eQMS deployment, what was the single ISO 13485 clause that turned out to matter most in the findings, and did your eQMS handle it out of the box or did you bolt something on?

ISO 13485 does most of the work. The 2026 ISO 9001 revision shifts where the rest lives

Priya Nair — Fri, 25 Sep 2026 10:21:13 +0000

The audit prep spreadsheet for our dual-cert surveillance has six rows for ISO 13485 and two for ISO 9001. That ratio has been roughly stable for the four years I have been at my current role, and it reflects a reality most medical device QMS people know: 13485 carries the load, 9001 is the standard we run alongside it for other reasons.

Which is why the upcoming revision of ISO 9001 deserves a careful look rather than a shrug. The easy answer is "13485 already covers everything that matters, so who cares." The honest answer is more interesting.

Why medical device companies hold ISO 9001 at all

Article 10(9) of the EU MDR requires a QMS. ISO 13485:2016 is the harmonised standard under MDR, so for CE marking that is — operationally — the standard you have to satisfy. ISO 9001 is held for other reasons: a parent company requirement, a non-medical customer asking for "ISO certified" on a tender, some third-country registrations, or occasionally a board that wants the badge.

For a pure EU meddev SME selling only CE-marked product, ISO 9001 is sometimes optional. In practice it stays on the certificate because pulling it triggers internal conversations nobody wants to have.

What the two standards actually disagree on

The widely held belief is that ISO 13485 is "ISO 9001 with extra medical device stuff." That is not quite right.

ISO 13485 is more prescriptive on the things medical device regulators care about: document control (4.2.4), records control (4.2.5), design and development (7.3), purchasing and supplier control (7.4), production and service provision (7.5), CAPA (8.5.2 and 8.5.3), and complaint handling. ISO 9001 covers some of the same ground but at a higher level, and pulls in different themes: context of the organisation, leadership, customer satisfaction, and a broader definition of "interested parties."

13485 also has a few explicit exclusions and modifications relative to 9001 — post-delivery activities in 7.5.5, for instance, are narrower. So the two standards do not align clause for clause, even though Annex SL keeps the structure compatible.

The practical upshot: when we map our QMS to both, the 13485 clauses generate real procedure work. The 9001 clauses mostly need a sentence in the manual and a paragraph in a management review.

What the 2026 revision actually changes

Without going clause-by-clause into FDIS territory, the themes that show up across the draft material are:

Climate change and sustainability considerations inside "context of the organisation"
Risk-based thinking made more explicit at strategic and operational levels
Broader stakeholder and interested-party framing beyond customers
Digital transformation as something the QMS is expected to address
A continued relaxation of prescriptive documentation requirements — less "you shall maintain documented information for X"

For a 13485 shop, the risk-based thinking theme is old news — 13485 has been risk-obsessed since long before MDR made it fashionable. The digital transformation theme is mostly already covered by your design controls and your change control. The documentation relaxation mostly aligns 9001 with how most of us were running it anyway.

The genuinely new content is climate and sustainability in the context-of-the-organisation analysis.

Where it actually bites for a meddev QMS

Here is the honest list:

Context of the organisation: you will need to address climate change as an external issue. Not as a product requirement — your 13485 risk file is not suddenly expected to manage emissions — but as a strategic QMS consideration. To be fair, this is one paragraph in a context document. It is still work.
Interested parties: the broadening of who counts as a "stakeholder" beyond customers and regulators might surface people you have not formally documented. Usually a tweak.
Leadership and commitment: usually already addressed; unlikely to require new procedure.
Documentation requirements: the relaxation is real and welcome, but be careful not to throw out records your 13485 system or your notified body still expects.

The 2026 revision does not require a 13485 rebuild. It requires a 9001 refresh with one new strategic content area and a general tightening of the context and stakeholder sections.

What I would do differently this time

Granted, my first reaction to the FDIS was to file it under "noted." A more useful reaction would have been:

Pull the current 9001 quality manual and do a clause-by-clause gap against the new revision before anyone else on the team touches it. The context and stakeholder sections are where your bespoke text lives; that is where the new content lands.
Decide how you are going to address climate in your QMS — paragraph in the context document, reference to your ESG reporting, or a real operational control? The standard gives latitude. Auditors will not.
Do not assume 13485 automatically satisfies the new 9001 expectations. The overlap is large but not complete, and the new themes sit mostly outside 13485's scope.
Watch your transition timeline. Most notified bodies will want your 9001 transition plan bundled into your next 13485 surveillance.

The honest answer

For a medical device company running ISO 13485 well, the 2026 ISO 9001 revision is mostly paperwork. It is paperwork with one genuinely new content area (climate and sustainability), a tightening of the context analysis, and a more flexible stance on documentation that most of us were already taking.

It is not the upheaval some of the FDIS commentary suggested. But it is not a no-op either, and the audit prep spreadsheet will probably grow from two rows for ISO 9001 to three.

For those of you holding both — how are you treating the climate and sustainability content? Reference to existing ESG reporting, or genuinely new content inside the QMS itself?

The internal audit that finds nothing is the one that ticks 'procedure exists' and moves on

Priya Nair — Tue, 22 Sep 2026 11:22:41 +0000

I sat through an internal audit last quarter where the auditor opened the complaints SOP, confirmed it had a revision number, ticked the box, and moved on. The procedure existed. The audit was technically complete. Nothing useful came out of it.

The audits that find something are the ones that pick one real record and follow it from end to end. Complaint goes in. CAPA comes out. Change gets raised. Training gets delivered. Does the loop close? That is the actual question. ISO 13485:2016 clause 8.2.4 wants internal audits at planned intervals, and ISO 19011:2018 nudges you toward the process approach — inputs, outputs, interfaces, effectiveness. None of that is satisfied by "the SOP exists."

What the tick-box audit looks like

You have probably seen it. The auditor:

Opens the relevant procedure (complaint handling, CAPA, change control)
Confirms revision number, approval date, and sign-offs are present
Confirms a template exists for the CAPA form
Ticks "complaint handling: compliant"
Moves to the next clause

The procedure exists. The form exists. The process might be a shambles. Nobody is looking.

What a record-tracing audit looks like

Pick a real complaint. Say, a complaint received eight months ago about a delivery issue with a Class IIa sterile barrier component. Now ask the following, in order:

Where is the complaint record — in the eQMS, a spreadsheet your QA lead maintains, or somewhere worse
Was it acknowledged within the timeline your SOP promises
Did it become a CAPA? If not, why not — and is the reasoning documented
If yes, what was the root cause methodology (5-why, fishbone, fault tree)
Did the CAPA raise a change, and what was the change impact mapping
Was the change implemented, and who signed it off
Was training triggered, who was in the audience, and did they actually complete it
Was effectiveness verified after a defined period

This is one record. It will take you an hour or two to walk through properly. It will surface three or four findings a procedure-existence audit would never see. Granted, an existence check is not nothing — it confirms the documented intent exists. The problem is what it does not confirm.

Where the loop usually breaks

After running this exercise with several meddev SMEs — and quietly inside my own Technical File reviews — the breakages tend to cluster in the same five places:

CAPA raised, change raised, change implemented, training never triggered
Training triggered, completion tracked, but no competency check (the training is treated as the assessment)
Change raised, but the change impact mapping did not update the risk management file per ISO 14971
Effectiveness check written into the CAPA closure, but never actually performed
Complaint logged in a spreadsheet, the CAPA logged in the eQMS — two systems that do not talk to each other

That last point is the one I want to dwell on. The complaint does not appear in the CAPA. The CAPA does not appear in the change. The change does not trigger training. Your traceability chain has gaps, and your next notified body audit (TÜV, BSI, DEKRA — pick your favourite) will absolutely find them under MDR Annex II section 6.1 or ISO 13485 clause 8.2.3.

How to keep the programme honest

A few things that have worked in practice, in order of how easy they are to implement:

Define your audit programme around processes, not clauses. "Audit the complaint-to-retraining process" beats "audit clause 8.2.1 today."
Require every internal audit to include at least one record-tracing exercise. Make it non-negotiable in the audit plan.
Pre-select the record before the audit. The auditor should not get to choose a friendly example.
Train internal auditors in the process approach per ISO 19011:2018 clause 6. Reading the SOP is not an audit skill.
Feed the findings into management review with the full chain visible — complaint, CAPA, change, training, effectiveness check.

If your QMS supports process automation, the easier this gets. AI-driven CAPA assistance can flag a CAPA that closed without an effectiveness check, or a change that implemented without a training record. The technology is the easy part. The harder part is a culture where an auditor feels allowed to say "this record is broken" and a process owner who treats that as a gift.

A tick-box audit is comfortable. Nobody has to make a judgement call. Nobody has to write a finding that will land in front of a notified body at the next surveillance audit. The procedure exists. The audit passes. Everyone moves on.

Until the next complaint comes in, and the same thing happens again, and the notified body audit lands and the finding is not "your SOP is missing" but "your process does not work" — which is a much harder thing to remediate.

Over to you

For those of you running internal audit programmes in medtech: how do you pick the records you trace? Do you sample randomly, or do you bias toward recent complaints, older open CAPAs, or supplier-heavy changes? I am particularly interested in whether anyone has had pushback from process owners on record-tracing audits, and how you handled it.