CE Marking for Medical Device Software: The Full Route

If you are building software that treats, diagnoses, monitors, or otherwise makes clinical decisions easier for a patient or clinician in the EU, CE marking is very likely somewhere on your roadmap, whether or not your team has said that sentence out loud yet. This guide is the long version: every stage from confirming your classification to standing in front of a Notified Body auditor, written for a founder who wants the whole path laid out once, in order, with the honest cost and timeline attached to each stage instead of a single headline number.

This guide will not promise you a specific outcome or a specific date for your product. It gives you a complete, accurately sequenced map of the process, so that when you talk to a Notified Body, a QMS consultant, or your own board, you are working from the same structure the people who review these files actually use.

In short: CE marking medical software means: confirm classification, build an ISO 13485 QMS, assemble the Annex II/III technical file with its clinical evaluation report, appoint your PRRC, then pass Notified Body assessment. Commonly cited at 12–18 months and EUR 120,000–300,000 for Class IIa–III (industry figures). This guide walks every stage.

On this page: The route map and the honest budget · Classification recap · The QMS build: lean ISO 13485 · The technical file, section by section · The CER: evidence routes · Software-specific evidence · PRRC, Authorised Rep, EUDAMED · Choosing and surviving the Notified Body · Post-market obligations · The 10 most common first-pass failures · FAQ

Not sure where to start? Still unsure of your class → Chapter 2. Need the budget conversation first → Chapter 1. Choosing a Notified Body → Chapter 8. Recovering from a first-pass failure → Chapter 10.

The route map and the honest budget

Founders researching CE marking almost always ask the same two questions first: how long, and how much. Both have honest answers, but only if you accept that the answer is a range tied to a specific starting point rather than a fixed number. The table below is the route map for the entire process: every stage this guide covers, in the order teams actually work through them, with what typically drives the time and cost at each one. Read it once here, then use the chapters below as the detail behind each row.

Stages 1 through 6 typically run partly in parallel rather than in a strict waterfall — a disciplined team starts risk management and technical documentation before the QMS is fully mature, and starts CER groundwork before every verification test is complete. The route map above shows the logical order of dependency, not a claim that each stage waits for the previous one to finish completely.

For Class IIa–III software, this whole path (internal preparation through Notified Body certification) is commonly cited at roughly 12 to 18 months, with an initial investment in the EUR 120,000–300,000 range (industry figures, cited consistently by regulatory consultancies and market analysts such as posos.co, not a Venitara quote or outcome guarantee). CE Marking Cost and Timeline for Medical Software breaks that range down by artefact and by phase in full detail. The summary worth internalising here: the range is wide because two variables drive most of the swing. How mature your documentation is when you start, and which Notified Body you engage and their current capacity. The first is mostly inside your control; the second isn't.

A rough phase split, also industry-cited rather than a Venitara benchmark, looks like this. Internal preparation (stages 1–7 above) takes the largest share of both time and cost, and it's the phase most within your control. Notified Body review (stage 8) is typically the single largest source of schedule variance between an optimistic plan and actual experience, because queue position and review depth are the Notified Body's to set, not yours. Post-certification setup (stage 9) is typically the shortest phase of the nine. Budgeting schedule margin specifically around the phase you don't control, Notified Body review, is a more realistic planning posture than assuming your own preparation timeline is the only variable that matters.

One number worth separating out early, because founders consistently under-budget it: post-market obligations (stage 10) are not part of the 12–18 month, EUR 120,000–300,000 range at all. They begin once you are certified and continue for the life of the product on the market. Chapter 9 covers what that ongoing obligation actually looks like.

Get an expert read on where your specific product sits on this route map before you commit a budget to it. Book an expert conversation →

What class is my software? A classification recap

Everything else in this guide is downstream of one determination: your MDR class. This chapter is a summary, not the full treatment — for the complete Annex VIII walkthrough, worked examples, and the common misclassification traps, the pillar on medical device classification and its underlying spoke, MDR Annex VIII: How Device Classes Are Set, cover the topic in full depth. What follows here is the version you need to read the rest of this pillar correctly.

MDR sorts devices into four classes, I, IIa, IIb, and III, using 22 rules in Annex VIII organised into four groups: non-invasive devices (Rules 1–4), invasive devices (Rules 5–8), active devices (Rules 9–13), and special rules (Rules 14–22). You classify by working through the applicable rules and applying the highest classification any of them assigns. Class I can be self-certified, with no Notified Body involvement for most standard cases; Class IIa and above require third-party conformity assessment.

For software specifically, Rule 11 is the rule that matters most. It classifies software providing information used to take decisions with diagnostic or therapeutic purposes by the significance of that information and the state of the patient: Class III where a wrong decision could cause death or irreversible deterioration, Class IIb where it could cause serious deterioration or require surgical intervention, and Class IIa for essentially everything else that provides diagnostic or therapeutic decision-support information. Rule 11 has two further outcomes worth knowing: software intended to monitor physiological processes is Class IIa (Class IIb where it monitors vital physiological parameters whose variation could result in immediate danger to the patient), and all other software falls to Class I — so genuinely Class I software still exists; it is simply no longer the default for anything with a decision-support function. Before MDR, a large share of clinical software defaulted to Class I self-certification under the previous directive's more permissive treatment. Rule 11 closed that gap deliberately, and the practical consequence is that most software with a genuine clinical decision-support function is now Class IIa at minimum. For this category, self-certification is the exception now, not the default.

Worth watching, not yet in force: on 16 December 2025, the European Commission published a proposal (COD 2025/0404) to simplify MDR and IVDR, which includes revising Rule 11 so that software would start at Class I and be up-classified based on intended use — the reverse of today's rule. This is early-stage: it still needs European Parliament and Council agreement, and most trackers put 2027 as the earliest realistic date for any amended Rule 11 to take effect. It does not change today's binding rule, and everything above remains an accurate description of how Rule 11 currently classifies software — but it's worth keeping an eye on if you're setting a classification strategy with a multi-year horizon.

This pillar addresses classification only briefly, rather than re-running the full Annex VIII logic, because getting your class right is a precondition for everything that follows here, not a parallel workstream. If you have not yet confirmed your class with confidence, that is the highest-leverage thing to resolve before investing further in the QMS or technical file chapters below. Your class determines the depth of clinical evidence required, which quality management system elements actually get audited, and the shape of your budget, all before you have written a line of technical documentation.

Not sure which class you're in yet? the free MedTech Compass can give you an AI-generated first read against Annex VIII in minutes — treat it as a starting point, not a determination, and bring the result to an expert conversation before committing your roadmap to it. Start the MedTech Compass →

How do I build a lean ISO 13485 QMS for CE marking?

Building or upgrading an ISO 13485-aligned quality management system is usually the single largest line item for a team starting with no formal process discipline, and it is also the artefact a Notified Body will audit most directly as an organisation, distinct from auditing your specific product's technical file. This chapter covers the CE-marking-specific slice of that build: what a QMS needs to contain to support Class IIa–III certification, and what a lean, startup-appropriate version looks like in practice. For the fully worked version — the complete build sequence, document set, and internal audit cadence — the pillar on ISO 13485 for medical software startups is the deeper resource; this chapter gives you enough to understand how the QMS interacts with everything else in this guide.

A quality management system, for the purposes of CE marking, isn't a binder of policies written once and filed away. It's the operational infrastructure that produces, controls, and maintains every other artefact this guide covers: your technical file, your risk management file, your verification and validation evidence, and your post-market surveillance records all live inside processes the QMS defines. When a Notified Body audits your QMS, it's checking whether the organisation that produced your technical file is structurally capable of producing it correctly and consistently. Whether this one file happens to be complete is a separate question.

At minimum, a CE-marking-ready QMS needs to cover: document control (how documents are created, reviewed, approved, versioned, and retired); design and development control (how requirements flow into design, and design into verification and validation, with traceability maintained throughout); risk management process (the procedural backbone that ISO 14971 execution sits inside, distinct from the risk management file itself, which is a technical file artefact); supplier and purchasing controls (relevant even for software-only teams, since cloud infrastructure, third-party libraries, and contracted development work all fall under this); internal audit process (a genuine, scheduled internal audit cadence, not a one-time exercise before submission); corrective and preventive action (CAPA) process; management review; and post-market surveillance process, which extends beyond certification into the ongoing obligations Chapter 9 covers.

What "lean" means in practice for a small team. Early-stage founders often swing to one of two extremes: over-building a QMS modelled on a large medical device manufacturer's system, which is expensive and slow to stand up, or under-building one that looks complete on paper but has no genuine operational teeth, a pattern Notified Body auditors recognise quickly. A lean QMS, appropriately scaled to a small team, keeps the same required elements but scopes the process documentation to match actual team size and product complexity: a five-person software team doesn't need a 40-page supplier qualification procedure if it has two suppliers, but it does need a real one that is actually followed. Document volume isn't the discipline that matters. What matters is that whatever the QMS says happens actually happens, consistently, and is evidenced.

Build it early, not as a pre-submission scramble. Teams that stand up their QMS early and keep it live through development, generating real records as they go, consistently spend less on the QMS line item than teams that retrofit a QMS shortly before submission. That's because a retrofitted QMS has to reconstruct evidence after the fact (design reviews that should have been documented as they happened, risk assessments that should have been contemporaneous), and reconstructed evidence is both more expensive to produce and less credible to a reviewer than evidence generated as development happened. CE Marking Cost and Timeline for Medical Software puts a number on this: the QMS build is commonly the largest single cost line item for a team starting from nothing, in the range of EUR 40,000–70,000 for a five-person team with no prior QMS. Unlike the headline EUR 120,000–300,000 figure above, this narrower figure isn't independently sourced to a named third party. It's Venitara's own sub-allocation estimate, derived by apportioning a share of that headline range to the QMS line item specifically, not a distinct industry-cited statistic. Treat it as illustrative rather than a quote, and expect it to vary with your specific starting point.

Certification versus conformity. A point worth being precise about: your QMS doesn't need a standalone ISO 13485 certificate from an accredited certification body to support CE marking, though many teams pursue one anyway, often for commercial or investor-facing reasons, or because it streamlines FDA QMSR alignment if a US launch is also planned (FDA's Quality Management System Regulation, effective 2 February 2026, incorporates ISO 13485 by reference, so EU-first teams building a genuinely ISO 13485-conformant QMS gain real leverage toward US QMSR alignment without duplicating the work). What CE marking actually requires is that your Notified Body's audit of your QMS, conducted as part of their conformity assessment, confirms it meets the relevant requirements. A separate, standalone certificate isn't a legal precondition for that audit, though in practice most manufacturers pursuing Notified Body conformity assessment do build toward, and often hold, ISO 13485 certification as the clearest way to demonstrate this.

What actually goes in the technical file? An Annex II walkthrough

This is the longest chapter in this guide, deliberately. The technical file is what a Notified Body reviewer actually reads to decide whether your device may carry the CE mark. For Class IIa and above, the reviewer largely reads this file and nothing else. Getting its structure right, and understanding what genuinely belongs in each section rather than treating the whole thing as one undifferentiated pile of documentation, is the single highest-leverage piece of process knowledge in the entire CE marking path. This chapter summarizes and extends Building an MDR Technical File and CER, which covers the build sequence in full. Here, the emphasis is on the Annex II structure itself, section by section, exhaustively.

MDR Annex II sets out the technical documentation structure directly; Annex III adds the post-market surveillance documentation that sits alongside it. The table below is the full section map — treat it as the actual checklist, not a paraphrase of one.

Section-by-section, in the order teams should actually build them, not the order Annex II lists them:

Device description and intended purpose comes first, before any other section is drafted, because everything downstream references it. This section states the medical indication, the patient population, the part of the body or type of tissue involved, and the intended user, precisely enough that classification, risk management, and clinical evaluation can all be built against a stable target. A vaguely or inconsistently worded intended purpose statement, discovered only once the rest of the file is already drafted around it, is genuinely expensive to unwind. Sections written against an earlier, looser version of the intended purpose have to be revisited, sometimes substantially.

The GSPR checklist comes early, not late, and functions as a build checklist for the rest of the file rather than a document completed at the end. The General Safety and Performance Requirements, set out in Annex I, are the substantive safety and performance standards every device must meet. The checklist maps each applicable requirement to the specific evidence in your file (standard referenced, test report, risk analysis section) that demonstrates compliance. A Notified Body reviewer commonly works through this checklist directly during review, checking that each cited piece of evidence genuinely supports the claim made against it. Gaps or weak cross-references here are among the most visible, and most common, sources of review findings, because the checklist is precisely the tool a reviewer uses to navigate the rest of your file. An entry that points to evidence that doesn't exist, or doesn't actually support the specific claim, gets found quickly.

Design and manufacturing information documents how the device is designed and produced. For software-only devices, this section carries substantially different weight than it does for hardware: physical manufacturing detail is typically minimal, replaced by software architecture documentation, version control evidence, and, critically, the software development lifecycle evidence expected under IEC 62304, covered in full in Chapter 6. Founders coming from a hardware-adjacent regulatory background sometimes expect this section to be lighter than it actually needs to be for software. Think of it as a shift in emphasis, not a reduction in rigor.

Risk management under ISO 14971 is not a document produced once and archived; it is meant to be a living record, updated continuously as new risks are identified through verification, validation, or post-market experience. The file systematically identifies hazards, estimates and evaluates the associated risks, implements risk control measures, and verifies their effectiveness, across the device's entire lifecycle. A risk management file that reads as though it was written in a single sitting at the end of development is a pattern reviewers recognise quickly and a common, avoidable source of findings. If your device includes an AI or machine learning component, this file extends to cover AI-specific risks — dataset shift, automation bias, performance degradation — as an addition to, not a replacement of, the conventional hazard analysis; One Notified Body for MDR and the AI Act covers how that extension works in practice if your device also carries AI Act obligations.

Verification and validation evidence is usually the most labour-intensive section to produce well, and the one that benefits most from contemporaneous documentation. Verification confirms the device meets its specified requirements; validation confirms it meets the user's actual needs in the intended use environment. For software, this typically includes unit and integration testing, system-level verification against requirements, and usability engineering evidence. Evidence generated and recorded as development happens is both cheaper to produce and more credible to a reviewer than evidence reconstructed retrospectively from code history and developer memory months later. This single point of discipline is one of the most reliable predictors of whether a team lands toward the lower or higher end of the cost and timeline ranges discussed in Chapter 1.

The clinical evaluation report sits within Section 6a, but because of its size and importance it gets its own full chapter below (Chapter 5). What matters here is sequencing: the CER should be built last among the major technical file sections, because it needs to reference a substantially complete risk management file and verification and validation evidence to make its safety and performance argument credibly. Treating the CER as a standalone literature-review exercise, outsourced and produced independently of the rest of the file late in the process, is the single most common sequencing mistake teams make. A CER that isn't tightly integrated with the specific risks and evidence documented elsewhere in the same file reads as disconnected to a reviewer.

Annex III's PMS documentation — the post-market surveillance plan and, for higher classes, periodic safety update report structure — is the section most likely to be under-resourced by teams focused entirely on reaching first certification, because it describes obligations that begin after certification rather than evidence needed to get there. Chapter 9 covers what this actually involves once you are on the market.

Companion asset: the technical file structure checklist. This guide walks the Annex II structure in prose; the companion checklist turns it into a working document, with every section above broken into its constituent evidence items, in build order, so a team starting from a blank page has an actual artefact to work against rather than a mental model reconstructed from an article. One example of what a single line in it actually looks like: "☐ GSPR Annex I clause mapped to a specific verification test report, not just a design document reference." It is available through the free MedTech Compass and contact flow (gated: it collects your email so we can follow up with a working session). Any AI-assisted output within it is flagged clearly as an AI-generated starting point, not validated, reviewed structure — a first draft of your own checklist, not a substitute for expert review of your actual file before submission.

A recurring pattern worth designing against from the outset, because it accounts for a disproportionate share of Notified Body findings across the technical file as a whole: GSPR checklist entries that cite evidence either missing from the referenced section or not actually supporting the specific claim made; risk management entries that identify a hazard and a control measure without clear evidence the control measure was actually verified as effective; and verification and validation evidence that demonstrates a feature works without tracing clearly back to the specific requirement or risk control measure it was meant to verify. All three break the traceability chain reviewers specifically check for, section by section, throughout the file.

How do I build the clinical evaluation report?

The clinical evaluation report is the technical file's evidentiary core: a documented, systematic appraisal of the clinical evidence relating to your device, assessing whether it demonstrates sufficient clinical safety and performance for its intended purpose. Its binding legal basis is MDR Article 61 together with Annex XIV Part A (clinical evaluation and equivalence), with post-market clinical follow-up governed by Annex XIV Part B. Methodologically, it generally follows the analytical logic set out in the MEDDEV 2.7/1 rev 4 guidance document, which — despite predating MDR itself — remains the reference methodology most Notified Bodies expect a CER to follow. Building an MDR Technical File and CER covers the CER build in the context of the whole file; this chapter goes deeper on the evidence-route decision specifically, since it is the single choice with the largest downstream effect on cost, timeline, and defensibility.

Two broad routes exist for building the clinical evidence base a CER analyses, and choosing between them is a strategic decision, not a formality.

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. This route is materially cheaper and faster when it is genuinely available, because it substitutes literature review and comparative analysis for original data generation. MDR set a substantially stricter bar for equivalence arguments than the previous Medical Devices Directive did, requiring closer, better-documented equivalence across all three dimensions (clinical, technical, biological) and, in most cases, direct access to the equivalent device's own technical documentation. That access isn't always available from a competitor manufacturer who has no obligation to share it. This access problem is the most common reason an equivalence argument that looks viable on paper turns out not to be sustainable in practice: without the comparator's underlying technical documentation, you cannot demonstrate technical equivalence to the standard MDR now expects, only broad similarity, and that's not the same thing.

The own-clinical-data route generates clinical evidence directly, either through a dedicated clinical investigation or through structured collection and analysis of real-world performance data. It is more resource-intensive to execute, both in cost and time, but it is increasingly the more defensible route as MDR's equivalence bar has tightened, and it avoids the access-to-comparator-documentation problem entirely, since the evidence is your own. For genuinely novel software (a decision-support algorithm without a clear, well-documented predecessor already on the market), this route is often not really optional. There may simply be no adequately equivalent device to argue against.

How to decide between them. The decision hinges on three questions, worked through in roughly this order. First, does a genuinely comparable device exist on the market? Not just a device that performs a similar function, but one close enough in clinical, technical, and biological characteristics that the comparison would survive scrutiny. Second, can you actually obtain the level of access to that comparator's technical documentation MDR's stricter standard now requires? This is worth answering early, since discovering the access problem after building an equivalence argument around a specific comparator is a costly redirection. Third, even where equivalence is technically available, does the strength of an own-data argument matter enough to your broader evidence and competitive positioning, for instance because you plan to make a stronger clinical claim than the comparator supports, that it's worth the extra investment regardless?

Whichever route you take, the CER has two further jobs beyond establishing the evidence base itself. It must explicitly address the residual risks identified in your risk management file, confirming that the clinical evidence supports an acceptable benefit-risk conclusion for each one individually, not just in aggregate. And it must define your post-market clinical follow-up (PMCF) plan: how you will continue generating clinical evidence about the device once it is on the market. MDR treats clinical evaluation as a continuing obligation, not a one-time submission exercise, and a CER that reads as though clinical evidence-gathering ends at certification is treated as incomplete on its own terms, independent of how strong the pre-market evidence is. Chapter 9 covers what PMCF actually involves in practice.

A CER built on an equivalence argument without the depth of comparative data MDR's stricter standard now expects — particularly one missing direct technical access to the comparator device's documentation — is one of the most common sources of significant Notified Body findings, and it is worth naming as its own item in the failure gallery in Chapter 10, because it recurs often enough to deserve specific attention rather than folding into general "incomplete evidence" findings.

What software-specific evidence do I need? IEC 62304, IEC 62366, cybersecurity

Three evidence streams deserve deliberate, early attention for software-only devices, rather than being folded loosely into general verification and validation work. Each has its own standard, its own document set, and, crucially, its own point in the development lifecycle where it needs to start, which for all three is considerably earlier than most teams coming from a non-regulatory software background expect.

IEC 62304 — software development lifecycle. IEC 62304 is the internationally recognised standard for medical device software lifecycle processes, and compliance evidence documents that your development process itself, not just the resulting software, meets a defined standard of rigor. The standard assigns a software safety classification — Class A, B, or C — based on the severity of harm the software could contribute to if it failed, with correspondingly more rigorous process documentation required at higher classes. Class A software (no injury or damage to health possible) carries the lightest process burden; Class C software (death or serious injury possible) carries the heaviest, including detailed unit-level verification and more extensive architecture documentation. Getting your IEC 62304 classification right early matters because it sets the process rigor your team needs to run from that point forward — a team that discovers mid-development that its software safety classification is higher than assumed faces a retrospective documentation gap similar to any other late-discovered evidence problem in this guide.

The practical evidence set includes a software development plan, requirements documentation with traceability to design and test evidence, architecture and detailed design documentation scaled to safety class, unit and integration verification records, and a defined problem resolution process for defects discovered during development and after release. Teams building software with any continuous delivery or frequent-release model should design their release process to generate this evidence as a natural output of shipping, not as a separate compliance exercise bolted onto each release. This is one of the more common places where a genuinely agile engineering culture and MDR documentation expectations can either reinforce each other or work against each other, depending entirely on how deliberately the process is designed.

IEC 62366-1 — usability engineering. This standard sets out a structured process for identifying use scenarios, use errors, and hazards related to usability, and validating that your final design mitigates them adequately for real, representative users in realistic conditions — not just for your own development and clinical team in a controlled internal setting. The usability engineering file documents this process end to end: the use specification (who uses the device, in what environment, for what task), a use-related risk analysis, formative evaluation activity conducted iteratively during design (informal testing that shapes the design as it develops), and summative evaluation — the formal, documented validation activity, typically conducted with representative users performing critical tasks under conditions resembling actual use, that demonstrates the final design is safe to use as intended.

The most common gap in this evidence stream is treating usability testing as something done once, informally, late in development, by whoever happens to be available internally, rather than as a structured process run against defined critical tasks with genuinely representative users. A Notified Body reviewing this file checks specifically for evidence that use errors were identified systematically, not just that the software "seemed usable" to the people who built it. That distinction matters more than it might initially seem, since the people who built a piece of software are, almost by definition, its least representative users.

Cybersecurity. Cybersecurity evidence sits partly inside the GSPR checklist (several Annex I requirements address IT security directly), partly inside risk management (cybersecurity risks are a category of hazard your ISO 14971 file needs to address explicitly), and partly as its own documentation stream covering secure design principles, vulnerability and patch management processes, and a software bill of materials identifying third-party and open-source components and their known vulnerability status, increasingly expected by Notified Bodies even where not always explicitly named in older guidance. For connected or cloud-dependent software specifically, this evidence stream also needs to address data transmission security, authentication and access control design, and a plan for how security updates are delivered and validated post-market without triggering an unintended change to the certified device's function each time a patch ships.

A practical note on sequencing all three of these evidence streams together: they are not independent workstreams that happen to share a technical file. IEC 62304's architecture documentation, IEC 62366's use-related risk analysis, and your cybersecurity risk assessment all feed into, and are cross-referenced by, the same ISO 14971 risk management file discussed in Chapter 4. Building them as genuinely integrated inputs to one risk file, rather than three parallel documents assembled independently and stitched together before submission, is both less work overall and produces a more coherent file for a reviewer to assess.

Who do I need? PRRC, Authorised Representative, and EUDAMED registration

Three roles and registrations sit alongside the technical file itself, and small teams routinely underestimate all three, usually because none of them block early development work directly. That makes it easy to treat them as late-stage administrative items rather than structural requirements that need real lead time.

The PRRC (Person Responsible for Regulatory Compliance), MDR Article 15. PRRC Under MDR Article 15: What to Know covers this role in full; the summary that matters for this pillar is that it isn't a nominal title. Article 15 requires every manufacturer to have at least one person, employed or contracted, with defined qualifications and named, personal accountability for four things: conformity checking before device release, keeping technical documentation and the declaration of conformity up to date, post-market surveillance compliance, and vigilance reporting obligations under Articles 87–91. Qualification runs through one of two routes: a relevant formal qualification (diploma or equivalent in law, medicine, pharmacy, engineering, or another relevant scientific discipline) plus one year of relevant professional experience, or four years of relevant professional experience without the formal qualification requirement. Manufacturers that qualify as micro or small enterprises under Recommendation 2003/361/EC (broadly, fewer than 50 employees and either annual turnover or balance sheet total under EUR 10 million) don't need to employ a PRRC in-house, but must have one "permanently and continuously at their disposal": a genuine, substantively engaged arrangement rather than a nominal consulting relationship invoked only when convenient.

For a small team, the practical decision is choosing among three models: hiring a qualified PRRC directly (the most robust option where headcount and budget allow), contracting an external PRRC under the small-enterprise flexibility (the more common early-stage route), or a fractional arrangement shared across several non-competing small manufacturers, provided their capacity genuinely supports the "permanently and continuously at disposal" standard for each client. Whichever model you choose, get it in place with real lead time before Notified Body engagement — retrofitting a genuinely functional PRRC relationship under audit pressure, after an auditor has already asked to speak with the PRRC directly about a specific gap, is a materially worse position than establishing the role deliberately during technical file build.

The Authorised Representative. For manufacturers established outside the EU, MDR requires appointment of an EU-based Authorised Representative — a separate role from the PRRC, though the two are sometimes confused — acting on the manufacturer's behalf for regulatory communication and market access purposes within the EU. The Authorised Representative is named on your technical documentation and is a legally designated point of contact for your Notified Body and EU competent authorities; selecting one with genuine experience in your device type, and confirming their actual capacity to engage substantively rather than merely lending their name to a mandate, matters for the same reasons PRRC engagement quality matters. Teams headquartered outside the EU should treat Authorised Representative selection as a decision with real lead time attached, not a late-stage administrative booking — this is a recurring bottleneck other Venitara guidance on multi-market sequencing flags specifically.

EUDAMED registration. EUDAMED, the European database on medical devices, is where manufacturers, Authorised Representatives, and devices themselves get registered, and where certificates and market surveillance information are recorded. This is no longer a forthcoming obligation: the first four modules — Actor registration, UDI/Device registration, Notified Bodies & Certificates, and Market Surveillance — have been mandatory since 28 May 2026 under Regulation (EU) 2024/1860, so actor and device registration is now a live legal requirement, with the vigilance and clinical-investigation modules following (expected around 2027). Registration itself is an administrative process, but it depends on having your organisational structure — your manufacturer identity, your Authorised Representative if applicable, your PRRC — already settled, which is why it sits logically after those roles are confirmed rather than before. Building registration into your project plan as a defined step with its own lead time, rather than assuming it happens automatically alongside certification, avoids a late-stage scramble that has nothing to do with your technical file's actual quality but can still delay market access if left until the last moment.

How do I choose and survive a Notified Body?

Notified Body selection and review is the phase of this entire process least within your control, and for that reason it deserves more deliberate attention than founders typically give it. Founders often treat the choice as an administrative step, whichever body has an available slot, when it's actually one of the more consequential decisions in the process. The review itself is often imagined as a black box that either passes or fails, rather than a process with a knowable structure.

Selection criteria, and why they matter to your timeline. Notified Bodies vary meaningfully in four dimensions worth checking before committing to an engagement:

Notified Body capacity has been a persistent, structural bottleneck since MDR's introduction, because the number of designated bodies didn't scale with demand at the pace the regulation's stricter requirements increased the volume and depth of review needed per submission. This is the single most important fact to internalise about the backlog reality: it isn't primarily about how good your file is. It's about how many files a given body's staff can review in a given period, and that constraint sits upstream of your control entirely. What you can influence is how efficiently your own review proceeds once it starts (a complete, well-organised file generates fewer clarification rounds), but you cannot compress a Notified Body's own queue.

What an audit actually checks, walked through in the order it typically happens. A Notified Body's conformity assessment for Class IIa and above combines a QMS audit (an organisational assessment, often including an on-site or remote facility audit) with technical documentation review (a file-by-file assessment of your specific device's evidence). The QMS audit checks whether your organisation's actual practice matches its documented processes. Auditors will ask to see records, not just procedures, and will probe for evidence that your QMS is genuinely operational rather than a document set produced for the audit itself. The technical documentation review works through your file broadly in the order this guide has presented it: intended purpose and device description for internal consistency, the GSPR checklist as the navigational spine (checking that cited evidence actually exists and actually supports the claim made against it), the risk management file for genuine iterative maintenance rather than single-sitting authorship, verification and validation evidence for clear traceability back to specific requirements and risk controls, and the clinical evaluation report for both route validity (is an equivalence argument genuinely sustainable, or does it lack the comparator access MDR now requires) and integration with the rest of the file's identified risks.

Reviewers also check two things that sit outside the formal document structure but matter in practice: internal consistency between your technical file's stated intended purpose and your externally facing marketing materials or website (MDR's intended-use test looks at the totality of what a manufacturer communicates, not only the formal labelling), and whether your named roles, PRRC in particular, are demonstrably substantive rather than nominal.

Surviving the process, practically. Queue position and review depth aren't levers you control directly. The most consequential thing a team can do to influence Notified Body review time is submit a complete, internally consistent file the first time. A first-pass rejection or a submission returned with significant findings doesn't just cost the time to address those findings; it costs a second full review cycle, which in a capacity-constrained system can mean a materially longer total timeline than if the submission had been complete from the start. This is the strongest practical argument for treating pre-submission internal review as genuine quality assurance rather than a formality, and it's the reason Chapter 10 of this guide exists as a dedicated failure gallery: knowing the patterns that generate findings before you submit is cheaper, by a wide margin, than discovering them during review.

Get help selecting and preparing for a Notified Body before you commit to an engagement. Book an expert conversation →

What happens after certification? PMS, PMCF, and vigilance obligations

Certification isn't the finish line. It's the point at which a different, ongoing set of obligations begins, and it's one of the most consistently under-budgeted parts of the entire CE marking path, because founders focused on reaching first certification naturally orient their planning around that milestone rather than what follows it.

Post-market surveillance (PMS). MDR Article 83 requires manufacturers to proactively and systematically collect and review experience from devices already on the market, feeding it back into risk management, technical documentation, and clinical evaluation as a continuous loop rather than a one-time submission exercise. The PMS plan, drafted before certification as part of Annex III documentation, defines how this collection happens: sources of data (customer feedback, complaint records, service and maintenance data, literature and registry data where relevant, and increasingly real-world usage data for software specifically), the process for analysing it, and how findings feed back into the technical file. For higher classes, this extends into periodic safety update reports (PSURs), a structured, scheduled analysis submitted at defined intervals rather than produced only reactively.

Post-market clinical follow-up (PMCF). PMCF is the clinical-evidence-specific component of post-market surveillance, and it connects directly back to the CER discussed in Chapter 5: MDR treats clinical evaluation as continuing after certification, not concluding at it, and the CER itself is required to define a PMCF plan describing how you will continue generating clinical evidence about the device once it is on the market. For software specifically, PMCF activity can include structured collection and analysis of real-world performance data, ongoing literature monitoring relevant to your device's clinical claims, and, where the equivalence route was used for initial certification, PMCF activity that strengthens the evidence base over time rather than resting indefinitely on the original comparator argument.

Vigilance. Vigilance obligations under Articles 87–91 require reporting serious incidents and field safety corrective actions to the relevant competent authorities within defined timeframes, and this is one of the four core areas the PRRC is personally accountable for under Article 15. A functioning vigilance process needs to be genuinely operational before you need it, not designed reactively at the moment of a first serious incident. This is one of the clearest examples in the entire CE marking path of a process that looks sufficient on paper long before it is tested, where the gap between documented process and actual operational readiness is most likely to surface at the worst possible moment.

Why this matters for your budget, not just your compliance posture. These obligations are ongoing costs that persist for the life of the product on the market, not one-time submission costs, and they are separate from the EUR 120,000–300,000 certification-path figure discussed in Chapter 1 (industry figures, attributed as elsewhere in this guide). Teams that model their CE marking budget as ending at certification consistently under-budget for the real, continuing cost of PMS infrastructure, PMCF activity, and vigilance system maintenance — a pattern worth correcting at the initial budgeting stage discussed in Chapter 1, not discovering a year after launch.

What are the most common first-pass failures?

The patterns below recur often enough, across the technical file, the CER, the QMS, and the roles discussed throughout this guide, to be worth gathering in one place rather than leaving scattered across individual chapters. Each entry below names what the failure actually looks like in a real file, and what avoiding it looks like in practice.

1. GSPR checklist entries that cite evidence that doesn't actually support the claim. What it looks like: a checklist entry references a test report or risk analysis section, but on inspection, the referenced evidence addresses a related but distinct point, not the specific requirement the entry claims to satisfy. How to avoid it: build the GSPR checklist early, as a live build tool, and have someone who did not author the underlying evidence verify each cross-reference actually supports the specific claim made, not just that a plausible-looking document exists nearby.

2. A risk management file that reads as though it was written in one sitting. What it looks like: uniform documentation style and dates across the entire file, hazards identified without visible iteration, and risk control measures asserted without evidence they were verified as effective after implementation. How to avoid it: treat the risk file as a living document from day one of design and development, with dated, incremental entries as risks are actually identified and controlled, not a single retrospective authoring pass before submission.

3. A clinical evaluation report built on an equivalence argument without genuine comparator access. What it looks like: a CER argues equivalence to a marketed device based on published literature and public marketing claims, but without the comparator's own technical documentation, which MDR's stricter post-2021 standard generally requires for a defensible equivalence claim. How to avoid it: confirm you can actually obtain the level of technical access equivalence requires before committing to that route, and default to the own-clinical-data route where access is uncertain rather than discovering the gap during Notified Body review.

4. Verification and validation evidence that doesn't trace back to a specific requirement or risk control. What it looks like: a test report demonstrates a feature works, but the file doesn't clearly show which requirement or which specific risk control measure the test was designed to verify, breaking the traceability chain a reviewer follows through the file. How to avoid it: design your requirements-to-test traceability structure before writing test protocols, not after, so every piece of V&V evidence is generated already linked to what it's meant to prove.

5. A nominal PRRC with no genuine engagement. What it looks like: a named PRRC on the org chart or contract who has minimal substantive contact with the actual technical documentation, and who a Notified Body auditor discovers, on direct questioning, cannot speak to specific content in the file. How to avoid it: whether in-house, contracted, or fractional, confirm the PRRC arrangement involves genuine, ongoing engagement with your specific device and documentation, not an annual check-in dressed up as continuous availability.

6. Intended purpose drift between the technical file and public-facing materials. What it looks like: the technical file describes a conservative, well-scoped intended purpose, but the marketing website, app store listing, or sales deck describe a broader or higher-risk use than the file supports. How to avoid it: audit your own public-facing claims against your technical file's intended purpose statement before submission, and treat any drift as a finding to fix internally before a reviewer finds it externally — MDR's intended-use test looks at the totality of what you communicate, not just the formal documentation.

7. Software safety classification (IEC 62304) applied too late. What it looks like: a team discovers mid-development, or worse, at technical file assembly, that their software safety classification under IEC 62304 is higher than assumed, requiring process rigor that wasn't applied from the relevant point in development, creating a retrospective documentation gap. How to avoid it: determine your IEC 62304 software safety classification (A, B, or C) early, ideally before significant development work begins, and design your development process to generate the required evidence at the correct rigor level from the start.

8. Usability evidence that reflects internal testing, not representative users. What it looks like: the usability engineering file's summative evaluation was conducted informally by the development team or internal staff rather than genuinely representative users performing defined critical tasks under realistic conditions. How to avoid it: plan and budget for structured usability testing with representative external users as a defined, scheduled activity, not an informal internal exercise retrofitted into the file.

9. A QMS that exists on paper but isn't operationally real. What it looks like: documented procedures that, on audit, don't match what the organisation actually does — an internal audit schedule that exists as a document but was never actually run, or a CAPA process with no real corrective actions ever logged. How to avoid it: build a lean but genuinely operational QMS from early in development, and run real internal audits against it before a Notified Body does, so gaps surface internally first.

10. Treating the whole file as complete when post-market documentation is missing. What it looks like: a technical file with a strong Annex II core but a thin or missing Annex III post-market surveillance plan and PMCF plan, treated as a lower priority because those obligations begin after certification rather than before it. How to avoid it: build your PMS and PMCF plans as first-class technical file deliverables from the start, not an afterthought completed hastily once the rest of the file looks finished — a Notified Body reviews these as required documentation, not optional extras.

These ten patterns aren't exhaustive, but they account for a disproportionate share of the findings that turn a first submission into a second review cycle, which, given the capacity constraints discussed in Chapter 8, is the single most expensive mistake available in this entire process. Designing your build process against these patterns from the start, 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.

Frequently Asked Questions

Do I need to finish my QMS before I can start the technical file? No, and waiting to do so is one of the more common early planning mistakes. The QMS provides the process infrastructure — document control, design control, risk management process — that the technical file's evidence gets produced inside, so the two build in parallel in practice, with the QMS maturing alongside the technical file rather than fully preceding it. What matters is that both are live and operating by the time you approach Notified Body submission, not that one is finished before the other starts.

Can we use the same technical file for multiple Notified Bodies if we switch? The underlying evidence — your risk management file, verification and validation records, clinical evaluation — transfers in substance, since it describes your device rather than a specific Notified Body's requirements. However, switching bodies mid-review generally means restarting the formal review process with the new body, since conformity assessment is a relationship with a specific designated body, not a portable credential. Switching should be a considered decision, not a response to short-term frustration with review pace, given the restart cost involved.

How much of this can we realistically do without external help? It depends heavily on whether your team already includes people with direct MDR technical documentation or Notified Body review experience. Teams with that experience in-house can do meaningfully more independently; teams without it, which describes most first-time medical software founders, typically find that early expert input on classification, evidence strategy, and file structure prevents costly rework later, even where most of the documentation drafting itself is done internally.

What's the single biggest lever we have to shorten the total timeline? Submission completeness, consistently, across every stage of this guide. Notified Body review is the phase least within your control and the largest source of schedule variance, but the way you influence it is entirely indirect: a complete, well-organised, internally consistent file generates fewer clarification rounds. Everything else in this guide, contemporaneous documentation, early GSPR checklist discipline, genuine risk file maintenance, is in service of that single lever.

Does our device need a clinical investigation, or can we always use existing literature? It depends on whether a genuinely equivalent, already-marketed device exists with technical documentation you can actually access, and on how tightly your intended claims match what an equivalence argument can support. Many software devices, particularly genuinely novel ones without a clear predecessor, cannot sustain a defensible equivalence argument under MDR's current standard and need to build at least some original clinical evidence. This decision should be made deliberately and early, per Chapter 5, not defaulted into by assuming literature review is always the cheaper option.

How do AI Act obligations interact with this whole process if our software includes an AI component? If your device requires Notified Body conformity assessment under MDR — broadly Class IIa and above — and includes an AI system as defined in the EU AI Act, it is automatically classified as high-risk under Article 6(1) of the Act, with obligations designed to integrate into the same conformity assessment process rather than create a separate one. In practice this mostly extends work you're already doing under this guide (risk management, technical documentation, post-market surveillance) with additional data governance evidence. One timing note (updated 25 July 2026): the Digital Omnibus package that postpones the AI Act's high-risk deadlines was published in the Official Journal on 24 July 2026 as Regulation (EU) 2026/1744 and enters into force on 27 July 2026. From entry into force, the deferred dates are the legally binding ones — 2 December 2027 for Annex III stand-alone high-risk systems, and 2 August 2028 for high-risk AI in regulated products, including medical devices under Article 6(1) — and the original 2 August 2026 and 2 August 2027 dates are superseded. Plan against the deferred dates, and keep AI Act evidence-generation moving inside your MDR work regardless. Note also that the same 16 December 2025 MDR/IVDR simplification proposal flagged in Chapter 2 would change how the AI Act integrates with device conformity assessment (moving AI devices from Annex I Section A to Section B). Our pillar on the EU AI Act for medical devices covers this overlap in full.

Is it possible to get CE marked faster by paying a Notified Body more? No. Notified Body queue position and review depth are set by the body's own capacity and process, not by fees paid, and no party can reliably purchase faster review. What genuinely shortens timeline is submission completeness and, where you have a choice, selecting a body whose current capacity and sector experience are well matched to your device from the outset.

What happens if we fail our first Notified Body review? "Fail" is rarely a single binary outcome; more commonly a review returns significant findings that need to be addressed before certification proceeds, which functions as a second review cycle rather than an outright rejection. This is genuinely costly in a capacity-constrained system, since it can mean a materially longer total timeline than if the submission had been complete initially — which is the core argument, throughout this guide, for investing in pre-submission quality assurance rather than treating Notified Body review as a first draft of your own file checking.

Once certified, how often do we need to update the technical file? The technical file is a living document for the life of the product, not a one-time deliverable. Every material change — a new feature, an updated algorithm, a change to intended purpose or claims — needs to be assessed against your existing certificate and documented accordingly, and post-market surveillance findings feed back into risk management and clinical evaluation continuously. Some changes are minor enough to document within your existing QMS change-control process; others are substantial enough to require Notified Body notification or a fuller reassessment, depending on whether they affect classification or intended purpose.

---

CE marking a genuinely novel piece of clinical software, from a standing start, touches nearly every function in an early-stage company: product, engineering, clinical, and whoever is accountable for the regulatory strategy itself. Nothing in this guide substitutes for a working session with someone who has taken products through Notified Body review, not just read the regulation. The value of expert input concentrates most heavily at exactly the decision points this guide has flagged throughout: classification, evidence-route choice for your CER, Notified Body selection, and pre-submission file review.

Get an expert read on where your product sits, and what the fastest honest path to submission-ready looks like for your specific situation. Book an expert conversation → And if you haven't already, the technical file structure checklist described in Chapter 4 is available through that same conversation — a working starting point for the file itself, not just the strategy behind it.

---

Where next: MDR Annex VIII: How Device Classes Are Set · CE Marking Cost and Timeline for Medical Software · Building an MDR Technical File and CER · PRRC Under MDR Article 15: What to Know

Related complete guides: Is It a Medical Device? MDR Rule 11 and FDA Rules · ISO 13485 QMS for Medical Software Startups

Last reviewed 2 July 2026. This guide references cost, timeline, and process figures that are industry-cited context, attributed at each occurrence, not Venitara pricing or outcome guarantees, and it references adjacent EU AI Act and multi-market content that changes on its own schedule — see the linked spokes and sibling pillars above for the current status of any date-sensitive item.