Compliance self-scan: 20 notified-body questions

This checklist collects the questions a notified-body auditor asks first when assessing medical device software for the first time. It is designed for a self-assessment in about fifteen minutes.

The scoring principle is simple. For each question, answer honestly:

Yes (1 point): the element exists, is documented, and you can show it in under five minutes.
Partial (0.5 point): the element exists in people’s heads or in an outdated document, but would not survive an audit.
No (0 points): the element does not exist.

The “showable in five minutes” criterion is not a detail: in a real audit, evidence that cannot be found is evidence that does not exist.

0/20points checked

01Strategy and classification0/4

Have you formalised the intended use of your software in writing?01The auditor looks for a single, dated, approved document describing the medical purpose, the patient population, the intended users and the context of use. The classic trap: an intended use that exists in several contradictory versions across the website, the sales pitch and the technical file — the auditor will compare them.
Have you documented the qualification of your software as a medical device (or not)?02This is a reasoned analysis, grounded in MDCG 2019-11, concluding that the software is or is not a medical device. The trap: companies that “decide” their product is not a device without a written analysis, while their marketing claims (diagnostic support, clinical alerts) say the opposite.
Have you determined and justified the risk class under MDR Rule 11?03The auditor expects an explicit classification rationale: which rule applies, why, and which class results. The trap: aiming for Class I out of optimism when Rule 11 places any software whose output feeds diagnostic or therapeutic decisions in Class IIa at minimum.
Do you have a written regulatory strategy covering your target markets?04A document listing the intended markets (EU, US, others), the corresponding access routes (CE marking, 510(k)) and their sequencing. The trap: discovering after the funding round that notified-body lead times run in months and were never built into the product roadmap.

02Quality system0/4

Do you have a documented, genuinely applied QMS aligned with ISO 13485?05The auditor is not looking for a binder of off-the-shelf procedures but for processes the teams actually use: they will cross-check procedures against real records. The trap: the “façade” QMS written in the weeks before the audit, betrayed by records that do not exist or are all dated the same month.
Is regulatory responsibility clearly assigned in the organisation?06The MDR requires a person responsible for regulatory compliance (PRRC), and the auditor will check that this person has real qualification and authority. The trap: naming a PRRC on paper without giving them either time or the power to block a release.
Do you control your documents and records (versions, approvals, archiving)?07Every procedure and record needs a version, an author, an approver and a date, with a change history. The trap: working documents on a shared drive, editable by everyone, with no identifiable approved state — the auditor will read it as a global loss of documentation control.
Are your critical suppliers and subcontractors evaluated and monitored?08Cloud host, development contractors, component suppliers: the auditor expects selection criteria, quality agreements and periodic monitoring. The trap: outsourced development with no quality agreement, which leaves the manufacturer responsible for a life cycle it does not control.

03Software life cycle — IEC 623040/7

Have you assigned and justified a software safety class (A, B or C)?09The class must follow from the risk analysis: what harm can a software failure cause? The trap: choosing Class A by default to lighten the documentation, with no written justification — one of the first points an auditor attacks.
Is your software development plan documented and followed?10IEC 62304 requires a plan covering the activities, deliverables, tools and responsibilities of the life cycle. The trap: a generic plan never updated, contradicted by the team’s actual practice (different tools, skipped steps).
Are your software requirements documented and traced through to tests?11Each requirement must be identifiable, verifiable and covered by at least one test, with a traceability matrix navigable in both directions. The trap: user stories closed in the ticketing tool standing in for requirements, with no usable link to verification results.
Is your software architecture documented, with segregation of critical items?12The auditor wants to understand the decomposition into software items, the interfaces, and how higher-class items are segregated from the rest. The trap: a marketing architecture diagram that matches neither the real code nor the assigned safety classes.
Are your SOUP (third-party components) inventoried and evaluated?13Every embedded library, framework or OS must be listed with its version, its requirements and an evaluation of its known anomalies. The trap: the manual inventory that is stale by the next sprint — without automated generation from the dependency manager, the list is wrong on audit day.
Is your anomaly and change management process formalised?14Every anomaly must be recorded and assessed for safety impact, and every change must go through an impact analysis before implementation. The trap: hotfixes pushed to production with no impact analysis and no update of the risk documentation.
Are your verification activities documented, with acceptance criteria defined in advance?15The auditor expects test plans, success criteria set before execution, and result reports archived per version. The trap: a green CI presented as the only evidence — without a link between the tests run, the requirements covered and a review of the results, verification is not demonstrated.

04Risk management — ISO 149710/3

Do you have a living risk management file, compliant with ISO 14971?16Risk management plan, analysis, evaluation, control and overall residual risk evaluation must exist and be kept current with every product change. The trap: the risk file written once before certification and never reopened, while the software has shipped twenty releases since.
Are your risk control measures implemented and verified?17Every measure decided in the risk analysis must be traced to its implementation in the code and to the test that proves its effectiveness. The trap: measures “declared” in the risk file that appear nowhere in the software requirements and were therefore never verified.
Does your risk analysis cover use errors?18The auditor checks that the analysis is not limited to technical failures: misreading a result, wrong input, bypassing an alert belong to usability engineering (IEC 62366-1). The trap: treating UX as a product topic rather than a safety topic, with no usability evaluation data at all.

05Cybersecurity0/2

Do you have a threat model and a cybersecurity risk analysis articulated with ISO 14971?19The auditor expects a structured identification of attack surfaces and threat scenarios, whose clinical consequences are assessed in the risk management process. The trap: an annual pentest presented as the whole security effort — a point-in-time test replaces neither the threat model nor the secure development process IEC 81001-5-1 requires.
Can you produce an up-to-date SBOM, and do you manage vulnerabilities continuously?20An SBOM generated automatically on every build, monitoring of CVEs affecting your components, and a qualification-and-fix process with defined deadlines. The trap: the SBOM generated once for a submission then forgotten, when the FDA (§524B) and notified bodies alike expect a continuous, demonstrable vulnerability management process.

Reading your score

0 to 10 points — Foundations to build. Your product is exposed: as things stand, an audit would end in major non-conformities, and compliant market access is not reachable without structural work. The good news: starting early from a nearly blank page lets you build a proportionate system, with no documentation debt to pay down. Prioritise qualification, classification and the QMS foundation.

11 to 16 points — Structuring in progress. The foundation exists, but the remaining gaps are exactly the ones an auditor flags: incomplete traceability, a risk file not kept current, cybersecurity handled at the edges. A mock audit focused on your “partial” answers is the best investment at this stage: it turns a list of hunches into a prioritised action plan.

17 to 20 points — Audit-ready maturity. Your system is close to what a notified body expects. The remaining work is about the robustness of the evidence: consistency across documents, freshness of records, the teams’ ability to answer in interviews. At this level, preparation means rehearsing the audit, not producing new documents.

References & standards cited

[01] Regulation (EU) 2017/745 on medical devices (MDR)
[02] MDCG guidance documents — European Commission
[03] FDA — Cybersecurity in Medical Devices
[04] IEC 62304:2006+A1:2015 — Medical device software — Software life cycle processes
[05] ISO 14971:2019 — Application of risk management to medical devices
[06] ISO 13485:2016 — Medical devices — Quality management systems

Compliance self-scan: the 20 questions a notified body will ask first

01Strategy and classification0/4

02Quality system0/4

03Software life cycle — IEC 623040/7

04Risk management — ISO 149710/3

05Cybersecurity0/2

Reading your score

References & standards cited

Medical software that has to hold up in production?

01Strategy and classification0/4

02Quality system0/4

03Software life cycle — IEC 623040/7

04Risk management — ISO 149710/3

05Cybersecurity0/2

Reading your score

References & standards cited

Medical software that has to hold up in production?

Read next