How to Structure Your Annex II Technical File

What Annex II actually asks for

Annex II of EU MDR 2017/745 sets out what a technical file must contain. But reading the annex can leave you with a list of headings and no real sense of what "complete" looks like in practice. The structure is not complicated — but filling it with documents that actually demonstrate conformity, rather than just occupying the right folder, is where the real work is.

Annex II divides the technical file into two parts. Part A covers everything up to and including the clinical evaluation. Part B covers post-market surveillance documentation. Most of the attention in a Notified Body review falls on Part A — particularly the GSPR demonstration and the clinical evaluation — but Part B has teeth too, especially at surveillance audits.

The sections you need to know

Device description and specification (Section 1) This is your baseline. Device name, model numbers, intended purpose, indications for use, target patient population, contraindications, variants and accessories, and a description of how the device works. The part that catches teams off guard is the requirement to include previous generations of the device and comparable devices on the market. Notified Bodies use this to frame the state of the art assessment. If you leave it blank or thin, you create a gap that feeds problems downstream in the clinical evaluation.

Design and manufacturing information (Section 2) Drawings, component specifications, material formulations, manufacturing processes, and sterilisation information where relevant. The requirement is not just to list these — it is to show that the manufacturing process will consistently produce a device that meets its specifications. If you have multiple manufacturing sites, each needs to be covered. A common shortfall here is relying on supplier documentation without tracing it back to how it controls the specific device being manufactured.

General safety and performance requirements (Section 3) This is the GSPR traceability matrix — the document that maps each of the 23 requirements in Annex I to the evidence that demonstrates compliance. Standards, test reports, design specifications, or documented rationale for non-applicability. The matrix itself is a navigation tool; what it points to is what matters. Notified Bodies will pull documents at random to verify that the links are real. If a standard is listed as applicable but no test report exists, that is a finding.

Benefit-risk analysis and risk management (Section 4) Your ISO 14971 risk management file needs to do two things here: document the risk management process and feed into the benefit-risk assessment that Annex I Section 1 requires. Residual risks need to be acceptable in the context of the intended benefit. The common mistake is treating risk management as a separate QMS activity that happens to be referenced in the technical file — the MDR requires it to be integrated, not just adjacent.

Product verification and validation (Section 5) Test reports, software validation records, usability engineering files, biocompatibility assessments, sterility validation. The test reports need to match the device as it is actually manufactured and sold — not a prototype, not a slightly different configuration. If there were design iterations, the documentation trail needs to show which tests apply to the final version and why earlier tests are still valid or why they were superseded.

Clinical evaluation and post-market performance follow-up (Section 6) The Clinical Evaluation Report, the PMCF plan, and if available the PMCF evaluation report. This section links directly back to the benefit-risk assessment in Section 4. The clinical evaluation needs to be device-specific — generic literature reviews that do not connect to the actual device performance data are a consistent Notified Body finding. Post-market data that has been collected also belongs here, feeding back into the ongoing benefit-risk picture.

The most common structural problem

Most technical file failures are not about missing sections. They are about documents that exist but do not connect to each other. A risk management file that does not reference the GSPR matrix. A clinical evaluation that uses a different product name than the device description. Test reports that reference a design revision that is not documented in the design history.

Notified Bodies are looking for a coherent story: this is what the device does, this is how it performs, this is how risks have been identified and managed, and this is why the benefits outweigh the risks. If the documents in the technical file tell different versions of that story, or if the auditor has to guess at the connections, you are going to get findings.

A practical approach to building or reviewing a file

If you are building from scratch: start with the device description and GSPR matrix and treat them as the backbone. Every other document in the file should trace back to one or both of these. If you are reviewing an existing file: check whether the version numbers are consistent across documents, whether the risk management file references the current GSPR matrix, and whether the clinical evaluation summary was updated after any design change or post-market data collection. These are the spots where files quietly drift out of alignment.