Common Notified Body Findings in Technical File Reviews

Why findings cluster the way they do

Most Notified Body findings in technical file reviews are not about obscure requirements that teams missed. They are about the same handful of issues that come up across manufacturers, device types, and submission cycles. Some are about missing documents; most are about documents that exist but do not say what they need to say, or do not connect to other documents they should.

Understanding where findings cluster is useful whether you are preparing for a first submission, doing a pre-audit readiness review, or trying to understand what came back from a previous assessment. The issues below are the ones that come up most often — not as a comprehensive checklist, but as the places worth looking first.

Thin or generic clinical evidence

This is the most frequent finding category in EU MDR technical file reviews, and the one that has the most downstream impact. The clinical evaluation is not accepted as device-specific when it consists primarily of general literature that describes the technology or procedure rather than the actual device being evaluated.

What auditors look for: equivalence claims that are made but not properly substantiated; literature searches that have no documented methodology (no search strings, no database selection rationale, no inclusion/exclusion criteria); CERs that use the same structure and much of the same text across multiple device variants without differentiating performance characteristics. The finding is usually: clinical evidence insufficient to support the intended purpose and claimed indications, or equivalence claim not adequately substantiated under MEDDEV 2.7/1 rev 4.

The consequence: a major finding here typically blocks progression until the CER is substantially revised. This is not a paperwork fix — it requires real clinical data or a defensible equivalence pathway.

GSPR matrix entries with no supporting evidence

A matrix that maps requirements to standards but does not show the actual evidence documents is incomplete. The most common pattern: GSPR requirements marked as "met" with a standard listed, but no test report referenced; or test reports referenced by title only, with no document number, version, or date.

A secondary pattern is listing standards as applicable without documenting the applicable edition. If the current harmonised standard has been revised since the device was certified, and the matrix still shows the old edition with no rationale, that is a finding. If you are relying on a harmonised standard for presumption of conformity, you need the edition that was current and listed when the standard was applied — a withdrawn edition does not carry that presumption, and if an auditor finds you used the old version, the finding writes itself.

Risk management file not connected to the technical file

The risk management file exists and is comprehensive, but it reads as a standalone QMS document rather than a technical file component. The finding: no explicit benefit-risk analysis in the technical file that draws on the residual risk data; or residual risks listed in the risk management summary that are not addressed in the GSPR matrix or the clinical evaluation.

A related finding: the risk management file was last updated before the most recent design change or post-market data collection, and the technical file sections that depend on it (GSPR matrix, benefit-risk analysis, clinical evaluation summary) were not updated in step.

Software documentation gaps

Under MDR, software is covered by GSPR 17 and GSPR 23, and the requirements are substantive. The most common findings:

• No IEC 62304 software development lifecycle documentation, or IEC 62304 referenced but no software classification (Class A, B, or C) documented with rationale
• No SOUP (software of unknown provenance) list, or SOUP list exists but no assessment of the risks introduced by each SOUP item
• Cybersecurity not addressed — no threat model, no vulnerability assessment, no reference to applicable guidance (MDCG 2019-16 or successor)
• For AI/ML-enabled devices: no documented approach to managing algorithm changes post-certification

Software documentation gaps are especially common in hardware devices that incorporate firmware or embedded software where the team views the software as ancillary to the physical device.

Device description incomplete or inconsistent

The device description in Section 1 of Annex II is supposed to establish a clear, stable description of the device that the rest of the technical file references. Common findings: the intended purpose statement in the device description does not match the intended purpose in the labelling or in the clinical evaluation. Accessories and variants are listed differently in different sections. Previous generations of the device and comparable devices on the market are not addressed (this is explicitly required and is often overlooked).

An inconsistency in the device description ripples through the whole file. If the clinical evaluation was written for a slightly different intended purpose than the one in the device description, the mismatch will be flagged.

Labelling not verified against Annex I requirements

The labelling requirements in Annex I, Section 23 are detailed and specific. MDR introduced new requirements — including UDI carrier requirements, QR code references to the Summary of Safety and Clinical Performance for certain device classes, and specific symbol requirements. Findings here usually involve: missing mandatory information (website, unique device identifier, warnings for specific device types); symbols used without reference to the standard that defines them; or instructions for use provided in electronic form where the regulation requires paper.

Post-market documents not current

At surveillance audits, auditors check whether the post-market system is producing outputs and whether those outputs are flowing back into the technical file. Common findings: PSUR not prepared or significantly overdue; PMCF plan exists but no PMCF evaluation report because data collection has not started; serious incidents reported to the competent authority but no documented assessment of whether the incidents affected the risk management file or benefit-risk balance.

The MDR is explicit that the PSUR for Class IIb and Class III devices must be updated at least annually and submitted to the Notified Body. For Class IIa devices, the update must be available on request. A PSUR that was prepared once and not updated is a finding at surveillance.

What to do with this list

Use it as a pre-audit check, not a compliance guarantee. If you can work through each of these areas and find documented, current evidence for each one, your technical file is in a substantially better position. If any of these areas is thin or unclear, that is where to focus effort before an audit — because it is also where an auditor will focus.