The first decision is not how to rewrite the technical file. It is whether the problem sits in the explanation, the documentation or the underlying work. Getting that distinction wrong can send your team into weeks of unnecessary editing, or leave a real evidence gap hidden behind better prose.
This guide focuses on EU MDR findings. The response-management approach can also help with IVDR work, but the applicable requirements and evidence must come from your device's own regulatory framework. It is a practical planning tool, not a substitute for device-specific regulatory judgment or your Notified Body's response instructions.
What should you do when the findings arrive?
Preserve the original findings and build a single response register before splitting work across your team. Record each finding's identifier, the cited requirement, the affected device or process, its classification, the requested response and the deadline. Check immediately whether any finding raises a product-safety or ongoing compliance concern requiring action outside the response package.
Keep the exact wording alongside your interpretation. A short internal summary is useful, but it must not quietly narrow a finding that covers several products, records or processes.
Then establish the assessment context. A question during an initial technical-documentation assessment is not automatically the same as a QMS audit nonconformity. A finding against an existing certificate has different consequences from a question that prevents initial certification. Follow the classification and response process your Notified Body actually uses rather than applying one generic CAPA template to everything.
Assign one person to own the complete response package. Individual specialists can own clinical, engineering, risk or quality actions, but someone needs to reconcile their answers before submission. Otherwise, your clinical response can describe a device version that no longer matches the test report attached by engineering.
Your first planning discussion should resolve three questions. What needs immediate attention? What is unclear enough to ask the reviewer about? What work cannot finish without a laboratory, supplier, clinician or another external dependency?
Those answers matter more than the number of documents you can edit this week.
What does a major or minor finding mean?
Use the category and definition in your Notified Body's report and applicable process. A major or minor label communicates the assessor's classification of a nonconformity, but it does not replace the evidence about its extent, product impact or required response. Do not translate a QMS audit label into a technical-review category, or import numerical grades from another scheme.
In schemes that use this distinction, major commonly signals a more substantial failure to meet requirements, while minor commonly describes a more limited failure. Those descriptions are orientation, not grading criteria. The actual definitions may consider the ability of a process to achieve its intended results, systemic failure or other scheme-specific factors. Ask your Notified Body for the applicable definition before relying on the label to plan your response.
A single observation can reveal a wider process failure. Conversely, several references in a technical-review letter may concern one underlying evidence question. Counting observations will not establish severity, and calling something a typo will not establish that its impact is limited.
Read the category alongside the evidence
The following comparison card is illustrative. Both situations and identifiers are invented, and neither assigns or predicts an assessor's classification.
| Decision field | An isolated reference discrepancy | Repeated absence of required release evidence |
|---|---|---|
| Assessment context | Technical-documentation review | QMS audit |
| Recorded category | Preserve the category in the review letter, including no category if none is stated | Preserve the audit report's assigned category and its definition |
| Observed issue | A traceability row points to the wrong report revision | Several sampled release records lack a required review record |
| Extent to establish | Whether the correct report covers the submitted version and whether other references have the same problem | Which devices, release periods and process users could be affected |
| Product or process impact | Whether the missing reference hides an actual verification gap | Whether release decisions had adequate supporting evidence and whether affected product needs action |
| Next deliverable | Evidence reference and scope assessment, plus any necessary correction | Investigation, assessment of affected outputs and the actions and evidence the report requires |
| Timing source | The review letter and applicable assessment instructions | The audit report, agreement and applicable response instructions |
The first situation can look administrative until you discover that the report concerns a different software version. The second needs an extent investigation even if you can quickly complete one missing review. In both cases, evidence determines the work. The label alone does not.
If you disagree with the classification, preserve the original finding and present the specific facts that support your position. Ask for clarification through the agreed channel. Do not downgrade it in your internal register, pause necessary risk controls or treat a challenge as an extension of the response date.
Is this a documentation gap or missing evidence?
A documentation gap means the required work or supporting evidence exists but the submitted record does not explain, locate or connect it adequately. An evidence gap means you cannot yet support the relevant claim. A process gap means the way you work needs correction. A single finding can contain all three.
Use this triage table before agreeing a remediation scope.
| What you find | What to check | Sensible next action | What would not resolve it |
|---|---|---|---|
| The evidence exists, but the reviewer cannot locate it | Does it address the exact requirement, device version and intended use? | Provide the controlled reference and explain the connection; improve the index or cross-reference where needed | Sending the same folder again without explaining where the answer sits |
| The evidence exists, but documents contradict each other | Which statement is correct, and what supports that conclusion? | Resolve the inconsistency through document control and assess connected documents | Choosing whichever wording sounds easier to defend |
| The work happened, but its record is incomplete | Can you reconstruct an accurate, attributable record from contemporaneous evidence? | Assess the record gap and determine whether additional work is necessary | Backdating a report or presenting a reconstruction as an original record |
| The required work has not happened or does not cover the claim | What evidence would support the actual device and claim? | Define the work, acceptance criteria, owner and dependencies | Writing a more confident conclusion without generating evidence |
| A process allowed the problem to recur | What failed in the process and where else could it have failed? | Investigate the cause, correct affected outputs and verify the corrective action | Updating a procedure without showing implementation |
| The finding's scope is unclear | Which requirement, sub-requirement or evidence limitation remains unresolved? | Ask a focused clarification question with the relevant evidence attached | Assuming ambiguity means the finding can be ignored |
The adopted text of MDR Annex II requires clear, organised, readily searchable and unambiguous technical documentation. Section 4 also calls for the precise identity and location of controlled evidence supporting conformity with the general safety and performance requirements.
But a well-organised file is not the same as adequate evidence. Annex II also calls for verification and validation results and their critical analysis. An index can help the reviewer find a test report. It cannot make an irrelevant test report answer the question.
When should you ask the Notified Body for clarification?
Ask when you cannot identify the precise requirement, understand the affected scope or determine what the reviewer considers unsupported. Explain your current interpretation and point to the relevant evidence. Seek clarification of the assessment, not consultancy on how to design your device or run your quality system.
The following clarification question is illustrative, with invented identifiers.
We understand finding F-04 to concern the traceability between the stated requirement and the verification evidence. The submitted file references report VR-018, revision 2, section 5. Please confirm whether the outstanding concern is the location of that evidence or its coverage of the current device configuration.
That question gives the reviewer something concrete to answer. “What do you want us to change?” does not.
Previous acceptance of a document can help establish history, but it does not prove that the current document, device or evidence meets every applicable requirement. Avoid using “you accepted this before” as the whole response. Check what changed and whether the earlier assessment addressed the same point.
Log the question, the answer and the resulting scope decision. If you discuss the issue on a call, confirm the material understanding through the agreed written channel. Keep other remediation work moving while you wait, and do not assume a clarification request extends your deadline.
How do you turn findings into an evidence plan?
Build one row per finding, then connect related rows to shared work. Each row should show the requirement, your diagnosis, the proposed response, the evidence and the internal acceptance check. This makes missing work visible before the response letter makes it look finished.
You can copy the following structure into your existing tracker. It is a planning aid, not a mandatory Notified Body form.
| Field | What to enter |
|---|---|
| Finding | Original identifier and exact wording |
| Requirement and scope | Cited provision, affected device version, records, sites or process |
| Current evidence | Document ID, revision and exact section, including any limitation |
| Gap diagnosis | Clarification, documentation, evidence, process, or a combination |
| Correction | What resolves the identified problem in the affected output |
| Cause and corrective action | What caused the problem and what prevents recurrence, where applicable |
| Connected records | Other findings and documents that the change may affect |
| Deliverable and owner | A concrete output and the person accountable for it |
| Internal acceptance check | What another competent reviewer must be able to verify |
| Timing and dependency | Due date, external dependency and escalation trigger |
| Status | Planned, implemented, internally verified, submitted, or accepted by the Notified Body |
Keep those status labels separate. “Submitted” is not “accepted”. “Procedure approved” does not necessarily mean the procedure has been used. “Test planned” does not mean the result supports your claim.
If several findings share one cause, use a common corrective-action record and map it back to every affected finding. Do not merge the findings so aggressively that a reviewer has to work out which part of your answer addresses which observation.
This also gives a founder a more useful view of the project. Instead of asking how many documents are complete, you can ask which findings still depend on new evidence, which need a decision and which are ready for internal review.
What is the difference between correction and corrective action?
A correction addresses the identified problem. A corrective action addresses its cause so it does not recur. Replacing a wrong reference in a checklist may correct that record. Changing the review process that allowed wrong references through, then checking whether the change works, may be the corrective action.
The distinction matters because a response can resolve the visible error while leaving the process unchanged. Equally, a broad process-improvement plan does not remove the need to correct the affected record or evaluate the affected product.
For a QMS nonconformity, test the proposed cause against records rather than starting with “retrain the team”. Then connect the supported cause to an action and a defensible effectiveness check. The adopted text of MDR Article 10(9) includes management of corrective and preventive actions and verification of their effectiveness within the manufacturer's QMS.
A revised procedure shows a documented change. Records of its use show implementation. Evidence that it addresses the cause supports effectiveness. Keep these stages separate, especially when the response date arrives before you can complete the effectiveness evaluation.
What does a useful response look like?
A useful response explains the gap, describes completed action and sends the reviewer directly to the evidence. Where work remains open, it says so. It does not describe an approved plan as an implemented solution or ask the reviewer to infer the result from a collection of attachments.
The following example is illustrative. The finding, document identifiers and actions are invented to demonstrate the structure, not drawn from a customer case or an accepted Notified Body response.
Illustrative finding
The technical documentation does not demonstrate how the specified alarm requirement has been verified for the submitted software version.
Before writing the answer, the manufacturer checks the requirement, released software configuration and original verification records. Two different routes are possible.
Route A when relevant evidence already exists
The check establishes that an approved test report covers the submitted software version and the alarm requirement. The traceability table omitted the link.
A response could explain the correction as follows.
We reviewed requirement AL-07 against the submitted software configuration. Verification report VR-018, revision 2, section 5.3 identifies that configuration, records the acceptance criterion and reports the result. The submitted traceability table omitted this reference. We corrected the link in TM-004, revision 3, row AL-07, and attached the approved revision with the change identified.
Our impact review covers the remaining alarm requirements and their evidence references. The results and any additional actions appear in review record RR-012. The response register identifies the associated document-control investigation and its current status.
This is only a sound answer if those records actually establish what the response says. Before submission, the internal reviewer must check the configuration, criterion, result and impact review, not just confirm the files exist.
Route B when the evidence does not cover the version
Now suppose the report covers an earlier configuration and the team cannot justify its applicability to the submitted version. Adding the reference would make the file look complete without resolving the finding.
The response plan needs different work.
The existing report does not establish verification of AL-07 for the submitted configuration. We have defined the additional verification work in protocol VP-021 and recorded the configuration and acceptance criteria. The response plan identifies the test owner, required resources and proposed completion date. We will provide the approved results and updated traceability after execution and review.
This describes a plan, not a closed finding. Whether the Notified Body can accept a plan at that stage depends on the assessment and its requirements. Agree the submission expectations and timing rather than presenting future work as completed evidence.
In either route, assess whether the finding has implications beyond the file, including the device's risk controls and any affected released product. Record the evidence decision, owner and next deliverable in the response register. Do not let a documentation-focused answer narrow the safety assessment.
How do you check the response before submitting it?
Ask a competent reviewer who did not draft the answer to reconstruct it from the package alone. They should be able to identify the requirement, understand the action and verify the supporting evidence without asking the author where to look. Treat that as an internal submission gate, not a promise of Notified Body acceptance.
| Internal check | Ready for submission when | Return it to the author when |
|---|---|---|
| Coverage | Every part of the finding has an answer or an explicit open item | One paragraph answers only the easiest part |
| Applicability | The evidence covers the relevant device, version, use and scope | The report concerns a different configuration without a justified link |
| Traceability | References identify the controlled document, revision and section | The response says only “see technical file” |
| Completion | The text distinguishes completed work from plans | Future activity is written as an established result |
| Consistency | Connected documents tell the same supported story | Risk, clinical, labelling and verification records contradict each other |
| Corrective action | The cause and action connect, with an appropriate effectiveness check | Training or a procedure revision stands in for an investigation |
| Package control | The attachment list matches the files and revisions supplied | The response points to an obsolete or missing attachment |
Use the Notified Body's required format and submission channel. Retain a controlled copy of exactly what you submitted, including the response letter, attachments and any change summary. If the reviewer later asks about an earlier version, you need to know what they had, not what your working folder contains today.
Avoid making unrelated improvements during final packaging. A worthwhile change can still affect another claim, report or finding. Put it through the same impact assessment rather than slipping it into the submission as housekeeping.
How long do you have to respond?
Start with the written findings, your assessment agreement and the Notified Body's applicable instructions. Confirm what is due, when, and whether the requested deliverable is a plan, completed evidence or both. Do not assume a deadline quoted for another manufacturer, certification scheme or assessment stage applies to your case.
If a dependency threatens the date, raise it early with a specific explanation and proposed plan. Record any agreed change in writing. Silence is not an extension, and sending an incomplete package does not establish that the Notified Body has accepted your revised schedule.
Assessment time limits, manufacturer response dates and the time needed to demonstrate effectiveness are different clocks. A rule about the Notified Body's assessment process does not, by itself, tell you when your response is due. Verify the applicable legal version, assessment agreement and any transitional provisions before using a new timing rule in your schedule.
What happens if findings remain unresolved?
Start by identifying the status at stake. During an initial assessment, unresolved findings can prevent you from reaching a positive certification decision. For an existing certificate, the question is whether requirements remain met and what action the Notified Body takes. These are different situations, not successive steps on one automatic escalation ladder.
The adopted text of MDR Article 56(4) provides for proportionate restriction, suspension or withdrawal where requirements are no longer met, unless appropriate corrective action ensures compliance within an appropriate deadline set by the Notified Body. It also requires the Notified Body to give reasons for its decision. It does not supply a universal number of days or say that every open major finding automatically triggers suspension.
The legal links in this guide identify the adopted text. For a live certificate or supply decision, confirm the current EU provisions and your certificate-specific terms with a qualified regulatory adviser. Do not infer permission to continue supplying devices, an automatic recall or a route to reinstatement from a general certificate provision alone.
Match your next action to the actual certificate position
| Your position | What is at stake | Written information to establish | Who should own the next action |
|---|---|---|---|
| Initial assessment with unresolved technical questions or audit findings | Progress towards a certification decision, rather than suspension of a certificate not yet issued | Outstanding evidence, the next deliverable and remaining assessment and decision steps | Response lead with the relevant technical or QMS owner |
| Existing certificate with open findings and no stated status change | Continued conformity and the potential for certificate action | Required corrective action, deadline, scope and any conditions or restrictions already communicated | RA/QA lead with management support and the certificate holder's responsible functions |
| Formal restriction notice | The precise certificate scope or conditions affected | Effective date, affected devices or activities, reasons and conditions for reconsideration | Regulatory lead coordinating affected operations and commercial commitments |
| Formal suspension notice | The certificate's suspended status and its consequences for affected activities | Scope, effective date, reasons, required evidence and the process for any reinstatement | Management and regulatory lead, with qualified advice on product and supply implications |
| Formal withdrawal notice | Loss of the certificate concerned | The decision's scope, reasons, effective date and any applicable challenge or subsequent assessment process | Management and regulatory lead coordinating the necessary operational response |
Restriction, suspension and withdrawal are not a mandatory sequence. Read the actual decision rather than assuming you will receive one more warning or another review round. If a letter is ambiguous about whether it reports unresolved findings or changes certificate status, resolve that ambiguity promptly in writing.
Your action plan should separate the work needed to address the finding from decisions about affected product, supply and communications. A supplier test may sit with engineering, while a certificate-scope question sits with regulatory and a commercial commitment needs management attention. Record those dependencies together so the response owner can see when a technical delay creates a wider decision.
Submitting a plan does not establish compliance, and sending evidence does not establish that the Notified Body has accepted it. Likewise, a positive technical review does not necessarily finish the final review, certification decision or issuance process. Obtain the relevant written outcome before changing the status in your register.
What if you need outside help?
Ask a prospective support team to explain how it will diagnose the findings before it promises a rewrite. You need to know which work it owns, which evidence your team must provide, what depends on third parties and what will be ready at each milestone.
A useful scope names deliverables. Those might include a finding-by-finding assessment, clarification questions, a controlled evidence map, defined technical work, corrective-action support and an internally reviewed submission package. “We will handle compliance” is not a scope you can manage.
Also ask who will review the work and who will communicate with the Notified Body. An adviser can support your response, but the manufacturer's responsibilities do not disappear when a consultant takes the call.
Questions that come up during findings response
These are the questions worth settling before the response package leaves your team.
Does every finding need a new CAPA?
Do not assume that every technical-review question requires a separate CAPA. Establish the assessment context and follow your QMS procedure and the Notified Body's instructions. Where several nonconformities share a cause, a common corrective action may support them, provided each finding has a clear response and evidence trail.
Can we disagree with a finding?
You can ask for clarification or explain why relevant evidence addresses the cited requirement. Keep the response factual and specific. A disagreement does not close the finding, remove a safety concern or suspend the deadline. Use the Notified Body's applicable escalation or appeal process where necessary.
Can a revised procedure prove that the problem is fixed?
It can show that you changed the documented process. It does not, by itself, show implementation or effectiveness. Identify the records that demonstrate the new process has been used and the check that will establish whether it addresses the cause.
Can we close everything in one round?
A complete, coherent package can reduce avoidable questions, but you cannot guarantee one-round closure. The outcome depends on the findings, evidence, assessment and reviewer. Plan for clarification without treating further questions as proof that all the work must start again.
Does technical-review closure mean we have a certificate?
Do not treat those as interchangeable milestones. Ask your Notified Body which final review, decision and certificate-issuance steps remain. Track them separately from your response work so a completed document package does not become an unsupported market-access promise.
Make the next action specific
Your response should leave no ambiguity about what you know, what you changed and what still needs work. That clarity starts before the first rewrite, with a decision about whether the answer already exists or you need to generate it.
At Dovetail, the useful starting point is the findings themselves, the assessment stage and the evidence available. From there, the conversation can focus on the work you need and who will own it.
