A technical documentation gap analysis is an independent review of your technical file against EU MDR Annexes II and III, the applicable general safety and performance requirements (GSPRs) in Annex I, and the standards and guidance you rely on. The output is a list of findings, each with a severity and a recommended action, ordered so your team fixes the most important problems first. This guide explains the method and shows an illustrative excerpt for a fictional Class IIa app. It also covers what to send and what to do with the results.
What a gap analysis is not. It is not a certification, a pre-certification or a Notified Body assessment. Only a Notified Body assesses conformity and issues certificates for Class IIa, IIb and III devices. As the manufacturer, you remain responsible for the device. A gap analysis predicts where a Notified Body is likely to object, so you can fix those points before submission.
How the review works
- Baseline. We start by confirming the intended purpose, the classification and the rule applied (Annex II 1.1(f)), and the conformity assessment route. We also confirm the list of standards and guidance you apply. A finding here changes everything downstream, so it comes first.
- Structure against Annexes II and III. We check that every required section exists and is easy to find. Annex II requires the documentation to be "clear, organised, readily searchable and unambiguous". The sections cover:
- device description and specification (1)
- information supplied by the manufacturer (2)
- design and manufacturing information (3)
- GSPRs (4)
- benefit-risk analysis and risk management (5)
- product verification and validation (6)
- post-market surveillance documentation (Annex III)
- GSPR traceability. Annex II Section 4 asks four things: which GSPRs apply and why the others do not (4(a)), the method used to show conformity (4(b)), the harmonised standards, common specifications or other solutions applied (4(c)), and the precise identity of the controlled documents that hold the evidence (4(d)). We follow each applicable GSPR to the evidence it points to.
- Depth of evidence. A heading with a paragraph under it is not evidence. We check the substance in five areas:
- software verification and validation (Annex II 6.1(b), IEC 62304)
- risk management (Annex I Section 3, ISO 14971)
- clinical evaluation (Annex II 6.1(c), MDCG 2020-1)
- usability (Annex I Section 5, IEC 62366-1)
- cybersecurity (Annex I 17.2 and 17.4, MDCG 2019-16 Rev.1)
- Consistency. The intended purpose, users, patient population and claims should read the same way in the IFU, the clinical evaluation, the risk file, the labelling and the classification rationale. In our experience, mismatches between these documents are among the most common causes of Notified Body questions.
- Rating and action plan. Each finding gets a severity and a concrete action. We then group the actions into a prioritised plan.
Severity scale
| Severity | Meaning | Typical response |
|---|---|---|
| Critical | Likely to lead to a major non-conformity from the Notified Body | Fix before submission. May change the plan or the route |
| Major | Likely to lead to a Notified Body question or request for information | Fix before submission where possible, otherwise prepare the answer |
| Minor | Improvement recommended. Unlikely to block assessment on its own | Schedule into normal document maintenance |
Separately from severity, each requirement is rated Compliant, Partially compliant or Non-compliant. The severity is our prediction of a Notified Body's reaction, not its decision. Notified Bodies grade their own findings, and their judgements differ.
Example excerpt
Illustrative example
Illustrative example — fictional product, written for this guide. Not a client document and not a sample of a delivered report.
Example: a fictional AI triage app. A web and mobile application for emergency department triage nurses. It uses a machine-learning model to suggest an urgency category for adult patients from vital signs and structured symptoms. The manufacturer has classified it as Class IIa under Rule 11 and plans an Annex IX conformity assessment.
| Section | Requirement reference | Observation | Severity | Recommended action |
|---|---|---|---|---|
| Classification | Annex II 1.1(f); Annex VIII Rule 11; MDCG 2019-11 Rev.1 | The rationale concludes Class IIa because the app "provides information used for decisions". It does not consider whether decisions taken on a wrong, too-low urgency suggestion could cause a serious deterioration of a person's state of health. Under Rule 11, that is the Class IIb criterion. | Critical | Rewrite the rationale using the worst-case impact of decisions informed by the output, including the clinical context of use. If the result is IIb, update the route, the plan and the clinical evidence strategy before doing anything else. |
| Device description | Annex II 1.1(a), 1.1(c) | The IFU says the app "supports triage decisions", while the technical file says it "prioritises patients". The patient population (adults only?) and contraindications are not stated. | Major | Agree one intended purpose statement covering users, population, indications, contraindications and warnings. Use it everywhere. |
| Device description | Annex II 1.1(g), 1.1(j) | The machine-learning model is not explained as a novel feature. The overview of key components leaves out the third-party inference library and the cloud hosting service. | Major | Describe the model, its inputs and outputs and its locked or adaptive status. Add a component overview that includes SOUP and cloud services. |
| Information supplied | Annex II 2; Annex I 23.4(ab), 17.4 | The IFU does not state minimum requirements for hardware, IT network characteristics or IT security measures. | Major | Add the minimum platform, browser, network and security requirements, consistent with the security risk assessment. |
| Information supplied | Annex II 2; Art. 10(11) | The labels and IFU exist only in English. There is no plan for the languages required in the target Member States. | Minor | List the target Member States and their language requirements, and plan the translations before placing on the market. |
| Design information | Annex II 3(a) | The design stages are described only as "two-week sprints". The section does not refer to the software development plan or to the records of reviews and releases. | Major | Describe the design stages and point to the controlled plan and the release records. See our Jira/GitHub design controls guide. |
| GSPR checklist | Annex II 4(a), 4(d); Annex I 17.3 | GSPR 17.3 (mobile computing platforms) is marked "not applicable", although the app runs on smartphones. Several evidence entries say "see risk file" without document IDs. | Major | Reassess applicability with a justification. Cite controlled document IDs and versions for every applicable GSPR. |
| Software V&V | Annex I 17.2; Annex II 6.1(b); IEC 62304 | There is no justification of the software safety class. System tests are not traceable to software requirements. The system test report was run on a build that differs from the release candidate. | Critical | Document the safety classification. Build traceability from requirements to tests to results. Repeat or bridge the system tests on the release candidate, with build identifiers. |
| Risk management | Annex I §3; Annex II 5(b); ISO 14971 | The hazard "urgency under-estimated" is identified. The risk control for model performance drift in the field is not linked to any post-market indicator. | Major | Define performance indicators and thresholds in the PMS plan, and link them to the risk control and the review frequency. |
| Usability | Annex I §5; IEC 62366-1 | The formative evaluations are documented. There is no summative evaluation with representative triage nurses in a simulated use environment. | Critical | Plan and run a summative evaluation on the final user interface. Link critical tasks to use-related risks. |
| Cybersecurity | Annex I 17.2, 17.4; MDCG 2019-16 Rev.1 | A security risk assessment exists. There is no evidence of security testing (for example vulnerability scanning or penetration testing) on the release candidate. | Major | Run and document security testing that matches the identified threats. Record how findings were resolved or accepted. |
| Clinical evaluation | Annex II 6.1(c); MDCG 2020-1 | Valid clinical association is supported by literature and technical performance by an internal test set. Clinical performance relies on retrospective data from one site, with no analysis of how representative that site is of the intended population. | Critical | Justify representativeness or generate more clinical performance data. Update the clinical evaluation plan and report. |
| PMCF | Annex II 6.1(d); Annex III 1.1(b); Annex XIV Part B | There is no PMCF plan and no justification for why PMCF is not applicable. | Critical | Write a PMCF plan that addresses the residual uncertainties from the clinical evaluation. MDCG 2020-7 provides a template. |
| PMS plan | Annex III 1.1(b); Art. 88 | The PMS plan lists data sources but no indicators, threshold values or trend-reporting method. | Major | Add indicators, thresholds, the trend-reporting method and the communication routes required by Annex III 1.1(b). |
| PSUR | Annex III 1.2; Art. 86 | The PSUR procedure does not state an update frequency. | Minor | For Class IIa, state "when necessary and at least every two years". Revisit if the class changes. |
| Format | Annex II (introductory text) | There is no document index, and files are named only by internal IDs. | Minor | Add an index that maps Annex II and III sections to documents and versions. |
In this fictional excerpt, the classification finding would be dealt with first. A move to Class IIb would change what "enough" clinical evidence means, and it could change other findings.
What to send for an audit
Send what you have, in whatever form it exists. Missing documents become findings too. A typical package contains:
- the intended purpose statement, classification rationale and regulatory strategy (if one exists)
- the device description, architecture overview, and list of SOUP and third-party services
- labels, the IFU (all existing language versions) and screenshots of the user interface
- the GSPR checklist and the list of applied standards with their versions
- software lifecycle documentation: development plan, requirements, architecture, safety classification, verification plans and reports, traceability, release notes and known anomalies
- the risk management file
- the usability engineering file
- cybersecurity documentation: security risk assessment, test reports, vulnerability handling process
- the clinical evaluation plan and report, the literature search protocol and any performance study reports
- the PMS plan, PMCF plan or justification, and the PSUR procedure or template
- relevant QMS procedures (design control, change control, document control), if you want them included
- a draft EU declaration of conformity and any earlier Notified Body correspondence
Read-only access to your document system or wiki is fine instead of exports, as long as the versions are identifiable.
What you get
Our technical documentation audit includes:
- a section-by-section report, with each requirement rated Compliant, Partially compliant or Non-compliant
- a severity for each finding (Critical, Major, Minor)
- specific remediation guidance, not just "missing"
- a prioritised action plan with effort estimates
- a one-hour debrief call
An optional re-audit after remediation is available. The gap analysis takes 1–4 weeks, depending on scope, and costs about €3,000.
How to act on the findings
- Deal with Critical findings first, starting with anything that affects classification, intended purpose or the clinical evidence strategy, because they change other work.
- Give each finding an owner and a date. Track them in your normal tooling, not in a separate spreadsheet that nobody updates.
- Fix the source documents, not just the summary. If the GSPR checklist cites a test report, the test report has to exist and be controlled.
- Re-check consistency after each fix. A changed intended purpose has to flow into the IFU, the risk file, the clinical evaluation and the labelling.
- Update the plan and the budget. Findings often add work such as a summative evaluation, more clinical data or security testing. See EU MDR timeline for software and EU MDR budget components.
- Re-audit selectively before submission if Critical findings needed substantial rework.
For the full requirements behind each section, see EU MDR technical documentation for SaMD.
Sources
- Regulation (EU) 2017/745, Annex II – Technical documentation (as adopted; legislation.gov.uk reproduction of the Official Journal text)
- Regulation (EU) 2017/745, Annex III – Technical documentation on post-market surveillance (as adopted)
- Regulation (EU) 2017/745, Annex I – General safety and performance requirements (as adopted)
- Regulation (EU) 2017/745, Annex VIII – Classification rules, Rule 11 (as adopted)
- Regulation (EU) 2017/745, Article 10 (as adopted)
- Regulation (EU) 2017/745, Article 86 (as adopted)
- European Commission – MDCG endorsed guidance documents (MDCG 2019-11 Rev.1, MDCG 2020-7)
- MDCG 2020-1 – Clinical evaluation of medical device software
- MDCG 2019-16 Rev.1 – Guidance on cybersecurity for medical devices
- IEC 62304:2006+AMD1:2015 CSV – IEC Webstore
- IEC 62366-1:2015+AMD1:2020 CSV – IEC Webstore
