Under Regulation (EU) 2017/745, the technical documentation is the evidence package that demonstrates a device complies with the regulation. Annex II covers the device itself. Annex III covers post-market surveillance. Together they cover the device’s full lifecycle, and they are what a Notified Body reviews to decide whether you get or keep your CE certificate.

What most checklists do not tell you is that the structure of Annex II is also the structure of the review. Reviewers open the file and look for sections in roughly the same order Annex II lists them. If your file is organised differently, you can still pass, but the deficiency letter usually starts with structure before it touches content. So before going into what each section contains, I would suggest matching your file’s top-level structure to Annex II’s headings. It costs you nothing, and it changes the tone of the first review meeting.

The rest of this article walks through each Annex II section and the matching Annex III obligations, with the deficiency patterns I see most often and the questions a reviewer typically asks during the assessment.

1. Device description and specification

This section is supposed to establish what the device is, what it is for, and what falls inside the scope of the technical file. It should include the trade name, model and configuration numbers, the intended purpose written in regulatory language and not marketing copy, the indications and contraindications, the patient and user population, the classification with the specific Annex VIII rule cited and the rationale for that rule, the Basic UDI-DI, the UDI-DI for each variant, and the principles of operation.

It should also list every variant, accessory, and configuration covered by the file, and it should list previous generations of the same device and similar devices already on the market. Manufacturers underestimate how much weight Annex II Section 1.1(h) puts on that last point. The reviewer uses it to anchor the clinical evaluation and to check that what is being called the previous generation actually had the same intended purpose.

What I see go wrong here is the intended purpose itself. Marketing teams write it for the website, regulatory teams paste it into the technical file, and by the time it reaches the clinical evaluation the wording has drifted. Reviewers compare the intended purpose across the IFU, the GSPR checklist, the risk file, and the CER. If those four documents do not say the same thing, that becomes a deficiency before any technical content is even reviewed.

What the reviewer asks: which Annex VIII rule, why this rule, where are the variants listed, and does the intended purpose match word for word across the IFU, the GSPR checklist, the risk file, and the CER.

2. Information to be supplied with the device

This is your labelling, instructions for use, packaging artwork, symbols legend, and where applicable the implant card and patient information leaflet. Annex I Chapter III, mostly GSPR 23, tells you what the content has to be. The trap is that compliance is jurisdiction-dependent. Language requirements for the IFU vary by Member State. The eIFU option is only available for the device categories defined in Commission Regulation (EU) 2021/2226, which replaced 207/2012. The symbols you use need to match ISO 15223-1:2021 with the correct edition referenced.

Implant cards under Article 18 are a frequent gap for implantable devices, because the regulation requires both the card and the patient information to be in the language or languages of the Member States where the device is sold. Manufacturers often have the English template ready and the local-language versions still pending at the point of submission. Reviewers see this and write it up.

What the reviewer asks: are the language versions complete for the declared markets, is the symbols legend current, is the eIFU justification in line with 2021/2226, and does the implant card content meet Article 18.

3. Design and manufacturing information

This section should give the reviewer a clear view of how the device is designed and how it is produced. Design history, design inputs and outputs, design verification, design transfer, and a manufacturing process flow with critical control points marked. The site addresses of all manufacturing locations need to be there, with the activity performed at each site identified, because the Notified Body audit scope is built directly from this list.

Suppliers and subcontractors are the part that catches manufacturers out. The list needs to identify critical suppliers, meaning the ones whose output affects safety, performance, or regulatory compliance, the activity each supplier performs, and the controls applied to that supplier. If the QMS has a supplier evaluation procedure but the technical file does not show how that procedure was applied to the specific suppliers listed, the reviewer will ask for the evidence.

What the reviewer asks: which suppliers are critical and why, where is the control evidence for each critical supplier, are all manufacturing sites included in the certificate scope, and where does the design transfer documentation sit.

4. General safety and performance requirements

The GSPR checklist, which maps to Annex I, is the spine of the technical file. The expectation is that for every applicable GSPR, the checklist points to the specific evidence (document title, document number, section, and page or table number) that demonstrates compliance, and that the cited evidence actually demonstrates compliance when the reviewer opens it.

The two patterns that trigger deficiencies are non-applicability claims that are not justified, and references that are too generic. Marking GSPR 10.4 as not applicable when the device contains any substance that could fall under CMR or endocrine-disruptor scope requires a written rationale, not just a checkbox. Pointing to “see risk management file” without naming the specific risk control and its verification report wastes the reviewer’s time and produces a deficiency.

GSPR 14 for devices incorporating materials of biological origin, and GSPR 22 for devices with a measuring function, are two areas where I see manufacturers underestimate scope. Both pull in adjacent regulations and harmonised standards that need to be cited specifically, not bundled into a generic reference.

What the reviewer asks: are non-applicability claims justified in writing, does each cited document actually support the claim, are the harmonised standards listed with edition numbers, and does the checklist match the device’s current configuration.

5. Benefit-risk analysis and risk management

Risk management is governed by ISO 14971:2019, and for the European context EN ISO 14971:2019/A11:2021, which adds the Annex Z mapping to MDR requirements. The technical file should contain the risk management plan, the hazard analysis, the risk estimation and evaluation, the risk control measures with verification of effectiveness, the residual risk evaluation, the overall benefit-risk analysis, and the production and post-production information loop.

The gaps I see most often sit in three areas. First, verification of risk control effectiveness: the file lists controls but does not show how each one was verified, especially for procedural controls such as information for safety. Second, communication of residual risk: ISO 14971 and ISO/TR 24971 require residual risks to be communicated in the IFU, and reviewers check this by mapping risk file warnings to IFU warnings. Third, the overall benefit-risk argument: this is often a single paragraph at the end of the risk management report, when it should be a structured argument tied to the clinical evidence.

What the reviewer asks: how was each risk control verified, where is each residual risk communicated to the user, where is the structured benefit-risk argument, and how is the production and post-production information loop closed.

6. Product verification and validation

This is usually the largest section by volume, and the one with the most heterogeneous content. Depending on the device, it can include biocompatibility per the ISO 10993 series with the specific parts that apply justified through a biological evaluation plan, electrical safety per IEC 60601-1 with the relevant collateral and particular standards, software lifecycle per IEC 62304 with the safety classification (A, B, or C) justified, usability per IEC 62366-1, sterilization validation per ISO 11135 for ethylene oxide or ISO 11137 for radiation or ISO 17665 for moist heat, packaging and shelf-life with accelerated aging studies per ASTM F1980 supported by real-time data, and clinical performance bench testing.

The pattern that recurs here is worst-case selection. Whether for sterilization, packaging, biocompatibility, or performance testing, the reviewer expects a documented rationale for which variant or configuration represents the worst case for each test, and the rationale should be specific enough that a different reviewer would reach the same conclusion. When the rationale is “size XL was selected because it is the largest”, the reviewer will ask about chemistry differences across the range, about geometry effects on sterilant penetration, about ageing assumptions, depending on the test.

What the reviewer asks: where is the worst-case justification for each test, are the harmonised standards applied at the correct edition, where is the verification protocol that links to the verification report, and where is the test article description that confirms the test article matches the device on the market.

7. Clinical evaluation

Clinical evaluation is governed by Article 61 and Annex XIV Part A, with MDCG 2020-13 providing the assessment template that Notified Bodies use to document their review. The CER itself should reflect the structure of MEDDEV 2.7/1 Rev. 4 updated for MDR, or the MDCG 2020-13 template, but the more important point is that the CER should match the device, the intended purpose, and the indications stated in Section 1 of the technical file.

The recurring deficiency is the equivalence claim. Article 61(4) requires equivalence to be demonstrated against technical, biological, and clinical criteria, and Notified Bodies are required to scrutinise this for implantable and Class III devices in particular. MDCG 2020-5 explains what equivalence means in practice. The mistake manufacturers make is treating equivalence as a checkbox exercise rather than a side-by-side argument supported by evidence the manufacturer actually has access to, including, where required, a contract with the manufacturer of the equivalent device for ongoing access to its technical documentation.

PMCF is the other recurring deficiency. If the CER concludes that PMCF is needed, which is the default for Class IIa and above, the PMCF plan needs to be in the file, it needs to address the specific gaps identified in the CER, and it needs realistic timelines. PMCF described as “we will collect data through our complaints process” is not a plan. MDCG 2020-7 (PMCF plan template) and MDCG 2020-8 (PMCF evaluation report template) define what the structure should look like.

What the reviewer asks: where is the equivalence justification with side-by-side data, what is the rationale for the literature search methodology, where is the data analysis with statistical considerations, and how does the PMCF plan address the specific gaps identified in the CER.

8. Post-market surveillance (Annex III)

Annex III covers the PMS documentation, which is part of the technical file even though manufacturers sometimes treat it as a separate package. The PMS plan must comply with Article 84 and cover proactive and reactive data sources, methods of analysis, indicators and thresholds, the link to risk management and clinical evaluation, and how outputs feed CAPA. The PSUR under Article 86 applies to Class IIa, IIb, and III devices. The PMS report under Article 85 applies to Class I. PMCF plans and reports under Annex XIV Part B sit alongside.

Vigilance procedures under Articles 87 to 92 should be referenced in the PMS plan, and the underlying procedures should be available for review. The 2-day, 10-day, and 15-day reporting timelines are a frequent area of audit findings, not because the procedure is missing, but because the procedure does not match what the QMS records show actually happens in practice.

What the reviewer asks: where are the proactive data sources defined, what are the trigger thresholds for serious incident escalation, how does PMS output feed back into the risk file and the CER, and how is the manufacturer monitoring the post-market signal across all variants in the Basic UDI-DI group.

Common Notified Body findings, in plain terms

The deficiencies that show up most often are not exotic. The intended purpose drifts between documents. The GSPR checklist points to evidence that does not actually demonstrate compliance. Risk controls are listed without verification. The equivalence argument in the CER does not survive Article 61(4) scrutiny. The PMCF plan is generic. Sterilization or shelf-life uses an accelerated model without real-time data to back it up. The supplier list does not match the QMS supplier evaluation.

None of these are technical surprises. They are traceability problems. The technical file does well when each claim has one specific evidence reference, and that reference, when opened, supports the claim without further argument.

Conclusion

A complete MDR technical documentation file is the device’s regulatory identity card. It defines what the device is, how it was designed, how it is built, how its safety and performance were demonstrated, and how the manufacturer keeps watching it after it reaches the market. The Notified Body review is not about catching the manufacturer out. It is about being able to follow the evidence from the intended purpose through the risk file, through the verification testing, through the clinical evaluation, into the post-market plan. When that thread is visible, the review goes faster and the certificate comes through with fewer rounds. When it is not, every section becomes a deficiency.