ISO 42001 for Medical Devices: What It Adds to ISO 13485
If you make medical devices with AI in them, you already operate two management systems that overlap heavily with a third you are now being asked about.
You have ISO 13485 for quality. You have IEC 62304 for the software life cycle, ISO 14971 for risk, and IEC 62366 for usability. You have a technical file, post-market surveillance, and a notified body that reads all of it.
Then a customer asks whether you are certified to ISO/IEC 42001, and the honest first reaction is that you already do most of this.
You partly do. The question worth answering is which part, and what the remainder actually costs — because the answer is smaller than the AI governance vendors suggest and larger than a device manufacturer’s first instinct.
Already running ISO 13485 and wondering what the gap actually is? The ISO 42001 Compliance Suite is built to slot into an existing QMS: procedures that reference rather than duplicate your document control, internal audit and CAPA, plus the four processes that genuinely do not exist yet. €590 excl. VAT.
The standard knows you exist
ISO/IEC 42001 is unusual in naming its neighbours. Annex D of the standard explicitly refers to ISO 13485 and IEC 62304 among the sector standards an AI management system may need to integrate with.
That is not a courtesy. It signals that the drafters expected AI management systems to sit inside existing regulated quality systems rather than beside them, and it gives you a defensible basis for saying that a single integrated system satisfies both — provided you can show which requirement is met where.
What you already have
Take the ISO 42001 clauses in order and most of the management system layer is already running in your QMS.
| ISO 42001 requirement | What covers it today |
|---|---|
| Context, interested parties, scope | Your QMS scope and regulatory analysis |
| Leadership, policy, roles | Management responsibility under ISO 13485 clause 5 |
| Objectives and planning of changes | Quality objectives and change control |
| Competence and awareness | Training records, already audited |
| Documented information | Document and record control — the most mature process you have |
| Operational planning and control | Process controls under ISO 13485 clause 7 |
| Life cycle of the AI system | IEC 62304 for the software part |
| Data management | Partly, through design inputs and validation data |
| Monitoring in operation | Post-market surveillance |
| Incident handling | Complaint handling and vigilance |
| Internal audit, management review | Already running, already sampled by your notified body |
| Nonconformity and corrective action | CAPA — the process a device manufacturer runs best |
That is most of clauses 4 to 10 and a good part of Annex A. If you already hold ISO 13485, the management system half of ISO 42001 is a mapping exercise, not a build.
What is genuinely new
Four things, and they are the ones that decide whether the project is a fortnight or a quarter.
1. The impact assessment, and who it is for
You perform risk management under ISO 14971. It asks about harm to the patient, the user and the environment.
The AI system impact assessment asks a different question: what are the consequences for individuals and for groups of individuals, and for societies, of the system working as designed. Not of it failing — of it functioning exactly as intended.
For a device manufacturer this is the least familiar idea in the standard, and the most useful one. A triage algorithm that performs to specification across the population and worse for one subgroup has not failed in the ISO 14971 sense. It has produced a differential outcome that the risk file, as written, does not capture.
This is a separate assessment with its own record. It feeds the risk process rather than replacing it.
2. Data, beyond validation
Your design controls cover whether the training and validation data was adequate for the intended purpose. ISO 42001 adds questions your technical file probably does not answer in writing:
- Provenance. Where did the data come from, and do you have the right to use it for this purpose? Consent for treatment is not consent for model training.
- Quality for the purpose, assessed against the population the device will be used on rather than the one it was trained on.
- Bias, examined as a property of the data and the design rather than only as a performance metric.
The awkward version of this question is the retrospective one: a model trained three years ago on a dataset assembled for something else. It is far cheaper to answer before training than after.
3. Human oversight as an operating condition
Your usability engineering file covers whether the user can operate the device safely. ISO 42001 asks something narrower and harder: can the human reviewer, in practice, contradict the system?
A clinician reviewing two hundred outputs an hour is not exercising oversight in any meaningful sense. The question an auditor asks is how many were overridden, and what happened when one was. If the answer is none, the oversight is nominal, and nominal oversight is worse than none because it is relied upon.
4. Information for the affected person
Your IFU tells the user how to use the device. ISO 42001 asks what the person affected by the output is told, and who answers when they ask why a decision was made about them.
In a device context that person is usually the patient, and they are usually not your customer. Nobody has written down who answers that question — and it arrives eventually, usually through the clinician.
The scope trap, and it is specific to you
Device manufacturers get one scope decision wrong more often than any other, and it is worth naming.
Your QMS scope is defined by your devices. Your AI management system scope is defined by your AI systems — and those two sets overlap without coinciding.
The AI in your devices is in both. But an AI management system scope drawn only around the devices leaves out the models you use to run the business: complaint triage, literature screening for post-market surveillance, regulatory writing assistance, code generation in the development environment. Those are AI systems the organisation uses, and if the scope statement says “AI within our medical devices” then a certificate issued against it says nothing about them.
That is a defensible narrow scope, provided it is deliberate. It becomes a problem in two situations. When a customer’s procurement questionnaire asks whether you have AI governance and the honest answer is “for part of the business”. And when a model used in complaint triage misclassifies a complaint that should have been a vigilance report — because that one sits inside your MDR obligations regardless of what your AI scope says.
Decide it explicitly and write both boundaries down. The certificate will name one of them.
What an auditor will ask you specifically
A certification auditor who knows the device sector will not test whether you have a QMS. They will assume it, then look for the seams between the two systems.
“Show me the impact assessment for this device, and the risk file.” They are checking whether the two are cross-referenced or whether the impact assessment was written as a standalone document that nobody feeds. The AI-derived risks should appear in the risk file with the same treatment discipline as any other.
“Which came first, the impact assessment or the deployment?” They will compare the date on the record against the go-live date. An impact assessment dated after release is the most common single finding in this area, and it is unarguable.
“Who reviewed the last twenty outputs, and how many did they override?” The oversight question, asked in a way that a policy statement cannot answer. If the override count is zero across a meaningful sample, the follow-up is whether the reviewer could have overridden it.
“Where did the training data come from, and what says you can use it for this?” Not whether the data was adequate — your design controls answer that — but whether the right to use it for this purpose was established and recorded.
“What happens when a patient asks why the system said what it said?” The information-to-affected-persons question. In most organisations nobody owns it, and the honest answer is that the clinician absorbs it.
None of these are hard if the system genuinely runs. All of them are hard to answer retrospectively.
Where the EU AI Act comes in, and the date that just changed
Most AI in medical devices is high-risk under the AI Act as a safety component of a product regulated under Annex I legislation — which for you is the MDR or the IVDR.
That classification carries a deadline, and it moved this summer. Regulation (EU) 2026/1744, the Digital Omnibus on AI, deferred the Annex I high-risk obligations to 2 August 2028. The Annex III deadline moved separately to 2 December 2027; yours is the later one. What moved and what did not sets out the full picture, and the short version is that the transparency obligations under Article 50 were not deferred at all.
Two years is a comfortable-looking runway that is not as comfortable as it looks, because your conformity route runs through a notified body whose capacity for AI-related assessment is not yet built out, and because the AI Act sits on top of the MDR rather than replacing any part of it.
ISO 42001 certification does not discharge either. What it does is produce, as a by-product of running the system, most of the evidence both regimes ask for.
The integration decision
The general version of this question — what transfers between any two management systems and what does not — is worked through in ISO 42001 vs ISO 27001.
The same integration question arises with ISO 27001 if you hold it: what transfers between the two management systems covers which processes can be operated once and which cannot.
Two ways to do this, and the choice is structural.
Integrate into the existing QMS. One document control system, one internal audit programme, one management review with an extended agenda, one CAPA process. The AI-specific processes — impact assessment, data management, AI life cycle, information to affected persons — become additional procedures inside the QMS rather than a parallel set.
Run a separate AI management system. Cleaner certification boundary, and defensible if AI is a small part of a large portfolio. But it means two audit programmes, two review cycles, and two places where a nonconformity can be recorded.
For most device manufacturers the first is right, for the same reason the standard names ISO 13485 in its annex: your QMS is the most audited process you own, and the marginal cost of extending it is far below the cost of maintaining a second system.
The scope statement is where this becomes concrete. The AI management system scope and the QMS scope are rarely the same boundary — you may have AI in one product line and not others, or AI tools used internally that are nowhere near a device. Say so explicitly rather than letting one scope imply the other.
A realistic sequence
For a manufacturer with an operating ISO 13485 QMS and a handful of AI-enabled products:
- Inventory the AI systems, including the ones that are not devices — the models used in production, in complaint triage, in regulatory writing. The scope depends on it and the count is usually higher than expected.
- Record the role you hold for each: provider, deployer, or both. Under the MDR you are the manufacturer; under the AI Act you may be the provider of one system and the deployer of another.
- Map ISO 42001 against your existing QMS clause by clause. The output is a list of genuine gaps, which is shorter than a gap analysis run from scratch.
- Build the impact assessment process, and run it on the highest-risk product first. This is the largest single piece of new work.
- Extend data management to provenance, rights and bias, and answer the retrospective question on models already deployed.
- Define oversight in operational terms for each system, with a measure that would reveal it if the oversight were nominal.
- Add the AI agenda items to the existing management review rather than scheduling a second one.
Frequently asked questions
Do we need ISO 42001 if we already have ISO 13485? Not as a matter of law. It is voluntary, and neither the MDR nor the AI Act requires it. It is increasingly asked for in procurement, and it produces evidence both regimes want. The management system half of it you largely have already.
Does ISO 42001 replace ISO 14971 for AI risk? No. They ask different questions. ISO 14971 covers harm arising from the device; the AI impact assessment covers consequences for individuals and societies of the system working as designed. Both are needed and they cross-reference.
Can one management system cover ISO 13485 and ISO 42001? Yes, and Annex D of ISO 42001 anticipates it. What matters is that you can show which requirement is satisfied where, and that the two scopes are stated separately even when the system is one.
When do the AI Act obligations apply to our devices? For AI that is a safety component of a product regulated under Annex I legislation, 2 August 2028 following the Digital Omnibus. The Article 50 transparency duties applied from 2 August 2026 and were not deferred.
Will our notified body assess the AI management system? Not as part of MDR conformity assessment. ISO 42001 certification is issued by a certification body accredited for it, which may or may not be the same organisation. Check that ISO 42001 is within their accreditation scope, not just that they are accredited.
What is the largest piece of new work? The impact assessment: the process, the criteria and a record per system. Everything else either exists in the QMS or is an extension of something that does.
Where to go from here
The instinct that you already do most of this is correct, and it is worth acting on rather than arguing with. The management system layer transfers. What does not transfer is the part of ISO 42001 that looks outward — at the person affected by the output rather than at the patient in front of the device — and that is the part worth building carefully, because it is also the part the AI Act will ask you about.
If you are working out where you stand, the ISO 42001 readiness checklist is organised by what produces evidence rather than by clause number, and what certification involves covers the audit and the accreditation check that most buyers skip.
The ISO 42001 Compliance Suite contains the documents an AI management system needs, including the impact assessment process and record, the data provenance and quality register, and a Statement of Applicability pre-populated with all 38 Annex A controls. Written to integrate with an existing quality system rather than to sit beside one. €590 excl. VAT.
If the AI Act timeline is what brought you here, what the Digital Omnibus actually changed sets out the dates that apply to Annex I products.