Articles · Guide
Last reviewed 21 July 2026
Building an MDR Technical File and CER from Scratch
Most teams facing a blank technical file underestimate how structured the task actually is. MDR tells you almost exactly what belongs in the file and in what order. The hard part isn't figuring out the structure, it's generating the evidence each section demands. This guide walks through both, and reformats the build as a sequence you can actually follow rather than a wall of requirements to somehow absorb at once.
In short: An MDR technical file is the structured evidence set defined in Annexes II and III: device description, design and manufacturing information, GSPR mapping, risk management, verification and validation, and the clinical evaluation report. The CER is its core: a documented appraisal of clinical evidence demonstrating safety and performance for the intended purpose.
A scope note before anything else: this guide covers devices under the MDR. Software or devices with an in vitro diagnostic purpose — analysing specimens such as blood, saliva, or genomic data — fall under the IVDR (Regulation (EU) 2017/746) instead: they classify under IVDR Annex VIII (Rules 1–7, Classes A–D) and require a performance evaluation (IVDR Article 56 and Annex XIII), not an MDR clinical evaluation report. If your product is a diagnostic, this article's CER framework is the wrong dossier to build.
What the file is for
A Notified Body reviewer, for Class IIa and above, will read your technical file and largely nothing else to decide whether your device may carry the CE mark, which is where the file sits inside the full CE marking route for software. (Class I devices — non-sterile, non-measuring, non-reusable-surgical — are self-declared: you build and hold the same file, but no Notified Body reviews it for initial certification.) That single fact should shape how you think about every section. The file isn't a record of what you did. It's the argument, addressed to a specific, technically literate but externally positioned reader, that your device is safe, performs as intended, and that you have the evidence to prove both.
A file that is technically complete but poorly organized forces a reviewer to hunt for how pieces connect. That generates more questions and more review cycles than a file of equivalent content that is clearly structured around the argument it needs to make. The seven steps below are the build sequence we'd recommend to a team starting genuinely from zero, each with what it covers, why it matters, and the specific pitfall we see most often at that stage.
One horizon note for software teams, clearly hedged: in December 2025 the European Commission published a proposal to simplify the MDR and IVDR (COM(2025) 1023) which would, among other things, move much stand-alone software toward Class I self-declaration — potentially changing whether some software needs full Notified Body file review at all. It is a proposal, not law, and adoption is realistically ~2027 at the earliest, so build against the current rules.
Step 1: Device description and intended purpose
What this step covers: Annex II opens with device description and specification, including variants and accessories, plus a precise statement of intended purpose: the medical indication, patient population, part of the body or type of tissue involved, and the intended user. Plan the closely related Annex II §2 material — the information supplied by the manufacturer, meaning labelling and instructions for use, which for software includes in-app disclosures and e-labelling — as its own build item alongside this step; it is a common source of Notified Body findings when left as an afterthought.
Why it matters: Your intended purpose statement is the reference point against which classification, risk management, and clinical evaluation are all subsequently built. Everything downstream cites back to this section, directly or implicitly.
Common pitfall: Drafting a vague or inconsistent intended purpose and only discovering the problem once the rest of the file has been built around it. Unwinding that late is expensive, because classification decisions, risk analyses, and clinical claims may all need revisiting.
Step 2: The GSPR checklist as the file's spine
What this step covers: The General Safety and Performance Requirements, set out in MDR Annex I, are the substantive safety and performance standards every device must meet. The GSPR checklist is a structured table mapping each applicable requirement to the specific evidence in your file that demonstrates compliance: standard referenced, test report, risk analysis section, and so on.
Why it matters: This checklist connects every other part of the file. A Notified Body reviewer commonly works through it directly, checking that each cited piece of evidence genuinely supports the claim made against it. Gaps or weak cross-references here are among the most common sources of review findings. Building the checklist early, even before all underlying evidence exists, turns it into a build checklist for the rest of the file rather than a wrap-up document assembled at the end.
Common pitfall: Treating the GSPR checklist as a final compliance summary written after everything else is done, rather than the organizing document that should have shaped what you built and in what order.
Step 3: Design and manufacturing information
What this step covers: This section documents how the device is designed and produced: design specifications, manufacturing processes, and, for software specifically, the software development lifecycle evidence expected under IEC 62304, the internationally recognized standard for medical device software lifecycle processes.
Why it matters: Reviewers use this section to understand how the device physically or functionally comes into being, which underpins their assessment of whether your verification and validation evidence actually matches what gets manufactured or deployed.
Common pitfall: Software-only teams often assume this section needs heavy physical-manufacturing detail modeled on hardware conventions. In practice it's usually lighter on manufacturing and heavier on software architecture, version control, and development process documentation than founders coming from a hardware-adjacent regulatory background expect.
Step 4: Risk management under ISO 14971
What this step covers: The risk management file, built to ISO 14971, systematically identifies hazards, estimates and evaluates the associated risks, implements risk control measures, and verifies their effectiveness across the device's entire lifecycle.
Why it matters: This isn't a document produced once and filed away. It's meant to be a living record, updated as new risks are identified through verification, validation, or post-market experience. Reviewers can generally tell the difference between a file maintained iteratively and one written retrospectively.
Common pitfall: A risk management file that reads as though it was written in a single sitting at the end of development is a common and avoidable red flag. One Notified Body for MDR and the AI Act covers how AI-specific risks extend this same document if your device includes an AI component.
Step 5: Verification and validation evidence
What this step covers: Verification confirms the device meets its specified requirements. Validation confirms it meets the user's needs and intended use in the intended use environment. For software, this typically includes unit and integration testing, system-level verification against requirements, and usability engineering evidence demonstrating the device can be used safely and effectively by its intended users.
Why it matters: This section is usually the most labor-intensive to produce well, and the one that benefits most from contemporaneous documentation. Evidence generated and recorded as development happens is both cheaper and more credible to a reviewer than evidence reconstructed retrospectively from code history and developer memory.
Common pitfall: Waiting until close to submission to reconstruct verification records from scratch, which is slower than it looks and often surfaces gaps that should have been caught during development.
Step 6: The clinical evaluation report
What this step covers: The CER is the technical file's evidentiary core: a documented, systematic appraisal of the clinical evidence relating to a device, assessing whether it demonstrates sufficient clinical safety and performance for its intended purpose. Its legal basis is MDR Article 61 together with Annex XIV Part A (clinical evaluation and equivalence) — the clauses to look up when you want the binding requirements rather than a summary. Methodologically, it generally follows the analytical logic set out in the MEDDEV 2.7/1 rev 4 guidance document, which remains the reference methodology most Notified Bodies expect even though it predates MDR itself; current MDCG guidance (e.g., MDCG 2020-5 on equivalence and the MDCG 2020-13 clinical evaluation assessment report template) is worth reading alongside it.
Why it matters: Two broad routes exist for building the clinical evidence base a CER analyses, and choosing between them shapes most of what follows. The equivalence route argues that your device is clinically, technically, and biologically equivalent to an already-marketed device with established clinical evidence, and relies on that existing literature and data rather than generating new clinical data of your own. MDR set a materially stricter bar for equivalence arguments than the previous directive, requiring closer, better-documented equivalence (Annex XIV Part A) and, in most cases, direct access to the equivalent device's technical documentation (Article 61(5)), which isn't always available from a competitor. One class caveat before treating equivalence as an open default: for implantable and Class III devices, Article 61(4) generally requires a clinical investigation, with only limited exceptions (such as modifications to the manufacturer's own already-marketed device, or the legacy-device provisions of Article 61(6)) — so for the highest-risk classes, equivalence is not freely available. The own-data route generates clinical evidence directly, through a clinical investigation or through structured collection and analysis of real-world performance data. It's increasingly the more defensible route as MDR's equivalence bar has tightened, though it's also more resource-intensive to execute.
Whichever route you take, the CER needs to explicitly address residual risks identified in your risk management file, confirming the clinical evidence supports an acceptable benefit-risk conclusion for each. It also needs to define your post-market clinical follow-up (PMCF) plan — governed by Annex XIV Part B — describing how you will continue generating clinical evidence about the device once it's on the market. MDR treats clinical evaluation as an ongoing obligation (Article 61(11)), not a one-time submission exercise, so the PMCF plan should specify what data you'll collect, how often, and what would trigger an update to the CER itself.
Common pitfall: Choosing the equivalence route by default because it looks faster, without first checking whether you can actually obtain the comparator device's technical documentation. Discovering that access gap mid-review, rather than before committing to the route, is one of the more expensive mistakes teams make at this step.
Step 7: Software-specific evidence
What this step covers: For software-only devices, two additional evidence streams deserve deliberate, early attention rather than being folded loosely into general verification and validation. IEC 62304 compliance evidence documents your software development lifecycle process, itself risk-classified (Class A, B, or C by the software's potential to contribute to a hazardous situation), with correspondingly more rigorous process documentation required at higher classes. Usability engineering evidence, following IEC 62366-1's structured process, documents that you identified use scenarios, use errors, and hazards related to usability, and validated that your final design mitigates them adequately for real users in realistic conditions.
Why it matters: These two evidence streams are frequently under-scoped by teams that treat them as an extension of general software QA rather than as distinct regulatory deliverables with their own documentation expectations.
Common pitfall: Validating usability only with your own development team in a controlled setting, rather than with representative users in conditions that resemble real-world use. Reviewers specifically look for evidence that use errors were tested with the intended user population, not an internal proxy for it.
Sequencing the build
Teams starting from a genuinely blank page consistently do better working in a specific order rather than attempting all sections in parallel. Intended purpose and device description come first, since everything else references them. The GSPR checklist starts early, as a build checklist rather than a final document. Risk management begins immediately after and gets maintained continuously, not drafted once late. Verification and validation evidence gets generated contemporaneously with development, section by section, as features are built and tested, rather than reconstructed afterward. The clinical evaluation report comes last, since it needs to reference a substantially complete risk management file and verification and validation evidence to make its safety and performance argument credibly.
The single most common sequencing mistake is treating the CER as a standalone literature-review exercise that can be outsourced and produced independently of the rest of the file, late in the process. A CER that isn't tightly integrated with the specific risks and evidence documented elsewhere in the same technical file reads as disconnected to a reviewer, and is one of the more common sources of significant findings during Notified Body review. CE Marking Cost and Timeline for Medical Software breaks down how much of typical project cost and delay traces back to exactly this kind of late-stage, poorly integrated evidence generation.
Common Notified Body findings to design against
A recurring pattern worth designing against from the start: GSPR checklist entries that cite evidence not actually present, or not actually supporting the specific claim made, in the referenced section. Risk management files that identify hazards but document risk control measures without clear evidence those measures were verified as effective. CERs built on an equivalence argument without the depth of comparative data MDR's stricter standard now expects, particularly missing direct technical access to the comparator device's documentation. Verification and validation evidence that demonstrates a feature works without clearly tracing back to the specific requirement or risk control measure it was meant to verify, breaking the traceability chain reviewers specifically check for.
Building your file with these patterns in mind from the outset, rather than discovering them as review findings, is the practical difference between a file that reaches submission-ready status efficiently and one that requires substantial rework after a first review cycle.
Keeping the file alive after submission
A technical file doesn't stop being a live document once it's submitted, and treating it as finished at that point creates problems down the line. Notified Bodies expect periodic safety update reports (PSURs, MDR Article 86, within the post-market surveillance system of Articles 83–86 and Annex III) and PMCF activity (Annex XIV Part B) that feed back into the CER and risk management file on an ongoing basis, not just at the point of initial certification or renewal. Design changes, new post-market data, and even changes in the state of the art for equivalent devices can all trigger an obligation to revisit sections you might otherwise consider closed.
Practically, this means assigning clear internal ownership for keeping the GSPR checklist, risk management file, and CER synchronized as the product evolves, rather than letting them drift apart between now and your next renewal cycle. Teams that build this maintenance rhythm in from the start, treating updates as routine rather than as a scramble before the next audit, tend to find recertification meaningfully less disruptive than teams that let the file go stale between formal review points.
This guide sets out the structure. Building the evidence itself, particularly the clinical evaluation report and the risk management file, benefits from expert review before submission, given how much of Notified Body scrutiny concentrates on exactly these two documents.
Who should own each section
Technical files are frequently built by a mix of internal staff and external consultants, and getting the ownership split wrong is a quieter but still common source of delay. Device description and design documentation usually sit best with whoever actually built the product, engineering or product leadership, since they hold the detail a consultant would otherwise need to extract secondhand. The GSPR checklist works best owned by whoever is coordinating the whole file, often a regulatory lead or an external consultant retained specifically for this purpose, because it requires visibility across every other section rather than deep expertise in any single one.
Risk management is worth keeping close to engineering as well, since risk controls are design decisions and the people making those decisions are best placed to document why they were made and how they were verified. The CER is the one section most teams are right to bring in outside expertise for, not because internal teams can't write a competent clinical evaluation, but because the literature search methodology, the equivalence argument (if you're using one), and the specific expectations Notified Bodies bring to CER review are a narrower specialism than most in-house teams maintain day to day.
None of this is a hard rule. Small teams often can't afford the split described above and end up with one or two people, sometimes with outside support, touching most sections. The point isn't the org chart, it's recognizing that the GSPR checklist and CER in particular reward a level of coordination and specialist judgment that's easy to underinvest in when a small team is stretched across every section at once.
Tooling and version control
However you divide the work, a technical file with unclear version control is a liability independent of the quality of its content. Notified Body reviewers expect to see a coherent document history, not a folder of similarly named files with no clear indication of which version was current at which point in development. This matters doubly for the risk management file and the CER, both of which are meant to evolve over the device's lifecycle rather than being frozen at submission.
A simple, consistently applied convention, dated versions, a clear change log, explicit links between a risk control measure and the verification evidence confirming it works, saves meaningfully more review time than any amount of polish applied to individual sections in isolation. Reviewers who can trace a claim to its evidence in one or two clicks form a different impression of the file's overall rigor than reviewers who have to hunt across loosely connected documents to confirm the same claim.
Where next: MDR Annex VIII: How Device Classes Are Set · CE Marking Cost and Timeline for Medical Software · What a CE File Transfers to SFDA and the GCC · One Notified Body for MDR and the AI Act
Get expert review on your technical file before you submit. Book an expert conversation →