If your first answer is “human error” or “training needed”, treat it as a hypothesis. You still need to establish what the person understood, what the process required and which controls should have prevented or detected the failure.
This guide focuses on investigating quality management system findings under an EU MDR assessment. The worked example is illustrative throughout. It is not a customer case, an approved response or evidence of a Notified Body decision.
Start with the failure you can demonstrate
Before asking why something happened, write down what should have happened and what the evidence shows actually happened. A vague problem statement produces a vague investigation.
Keep three things together in your investigation record. Record the requirement cited in the finding, the auditor's observed evidence and the precise gap between them. Preserve the original finding and source records, including their dates and revisions. Your working description can make the problem easier to investigate, but it should not quietly change its scope.
Suppose an auditor identifies two overdue supplier re-evaluations. “Supplier management is ineffective” is too broad to guide the first evidence search. “Two suppliers remained approved after their scheduled re-evaluation dates, without a completed review or a documented decision under the applicable procedure” gives you a testable starting point.
Clarify any ambiguity with the Notified Body through its response process. A request to locate an existing report may need a technical clarification. Evidence that a required review repeatedly fails may need a QMS investigation. Do not force every technical question into the same causal worksheet, or dismiss a process failure as a missing attachment.
Assess immediate product and patient implications alongside the investigation. If an overdue supplier review could conceal a material, manufacturing or service problem, evaluate the relevant evidence and escalation needs now. Completing root cause analysis is not a reason to delay necessary protective action.
Separate the evidence from your explanation
Root cause analysis becomes more useful when you distinguish observations, hypotheses and conclusions in the record. Observations describe what you found. Hypotheses explain how it might have happened. Conclusions state what the available tests support, including any limits.
The adopted MDR text, Article 10(9)(l), includes management of corrective and preventive actions and verification of their effectiveness within the QMS. That provision does not prescribe the worksheet below or make a particular investigation tool a condition of acceptance. Use your applicable QMS procedures and the Notified Body's actual response requirements to determine the record you need.
Five Whys can help you develop questions. A fishbone diagram can help you consider people, methods, systems, materials and working conditions. Neither diagram establishes a cause simply because you completed it. Every causal link still needs evidence.
For example, “the owner forgot because they were busy” combines an observation you may not have established with an explanation you have not tested. Check assignment records, workload, notifications and the actual review process before deciding whether capacity, ownership or something else explains the failure.
An illustrative investigation into overdue supplier reviews
In this illustrative example, the QMS requires periodic supplier re-evaluation at intervals recorded in the supplier register. An audit sample finds two suppliers past their recorded due dates. Both still appear as approved, and neither has a completed re-evaluation or documented decision addressing the delay.
The initial response proposes retraining the purchasing lead. The investigator instead preserves the register history, task records, procedure revisions and relevant supplier files before testing competing explanations.
The example uses invented record identifiers so you can see how the reasoning connects. E1 is the supplier register export. E2 is the procedure and revision history. E3 is the task configuration and event history. E4 is the training and competence record. E5 is a controlled demonstration of the scheduling workflow. E6 is the extended file review.
| Possible explanation | Evidence test | Illustrative result | What the result supports |
|---|---|---|---|
| The assigned reviewer did not understand the requirement | Compare E2 and E4, then ask the reviewer to explain the task using an unaffected record | The reviewer describes the required review and has completed comparable reviews correctly | Lack of understanding is not supported as the main explanation. Attendance alone would not establish this |
| Due dates were wrong after a data import | Recalculate the two dates using the underlying records and compare them with E1 | Both dates match the intervals assigned in the source records | The missed reviews cannot be explained by those dates being incorrect |
| Tasks did not reach an active reviewer after an ownership change | Compare E3 with ownership-change dates and reproduce the workflow in E5 | Tasks remain assigned to the previous, inactive account when the register owner changes | The reassignment mechanism can reproduce the observed failure |
| A second control should have detected the overdue reviews | Compare E2 with actual dashboard use and E6 | The procedure describes individual reminders but assigns no overdue-register reconciliation | The process lacks an assigned check that would detect this failure independently of the reminders |
Interviews help explain how work happens, but corroborate them where records or demonstrations are available. A reviewer remembering that no reminder arrived is weaker evidence than an event history showing its destination.
Also test explanations that could change the action. If the tasks reached an active reviewer and the reviewer deferred them, fixing reassignment would not address the actual failure. If the demonstration contradicts your preferred explanation, record the contradiction and revise the hypothesis rather than selecting only the records that fit.
Extend the investigation along the suspected failure path
The auditor's sample identifies a problem, not necessarily its full extent. Your extent review should follow the mechanism you are investigating and explain both what you included and why you stopped.
In the illustrative case, the investigator starts with all active suppliers because the same register and task mechanism govern their reviews. They examine the period since the current task workflow went live, then compare earlier records to test whether the failure predates that change.
| Scope decision | Illustrative review | Interpretation |
|---|---|---|
| Active supplier population | Review all 24 active suppliers in E1 | Five have overdue reviews, including the two sampled by the auditor |
| Ownership changes | Identify seven suppliers whose assigned reviewer changed during the period | All five overdue reviews sit within this group. Two others were completed through manual follow-up |
| Suppliers without an ownership change | Check the remaining 17 suppliers | No overdue reviews appear in this group during the period examined |
| Historical boundary | Examine the previous scheduling method and relevant completed records | The task-reassignment failure relates to the current workflow. Earlier records need a separate assessment if they show unexplained gaps |
| Other processes | Check which other recurring tasks use the same ownership mechanism | The training workflow uses a separate assignment mechanism. The calibration workflow shares the affected mechanism and needs an extent review of its own |
The two manually completed reviews matter. They explain why an ownership change did not always produce an overdue review, rather than disproving the mechanism. Record the manual intervention as a compensating action that happened in those instances, not as evidence that the normal control worked.
These counts describe only the invented example. They are not a recommended sample size. In your investigation, justify a full-population review or a sample using the population, risk, process variation and availability of records. A small convenient sample cannot support a claim that no other records are affected.
Keep product impact separate from administrative extent. Finding five overdue supplier reviews does not establish that five suppliers delivered unacceptable output. Nor does a clean complaint search establish that delayed supplier oversight had no effect. Examine the relevant supplied products or services, acceptance results, changes, deviations and other risk information before reaching that conclusion.
Write a causal conclusion someone else can challenge
A useful conclusion identifies the failure mechanism, explains the evidence that supports it and states what remains unresolved. Avoid a broad label such as “inadequate procedure” when you can describe the actual missing control.
For the illustrative investigation, a supported conclusion could read as follows.
Changing a supplier's owner in the register did not reassign existing review tasks. Event history E3 and controlled demonstration E5 show that the tasks remained with the inactive account. The procedure in E2 relied on individual reminders and assigned no reconciliation of overdue reviews, so the missed tasks had no defined independent detection step. The extent review in E6 found five overdue reviews among seven suppliers with ownership changes. Manual follow-up explains the two completed reviews in that group. The related calibration-task review remains open.
This conclusion separates the mechanism that allowed work to be missed from the missing control that allowed the failure to persist. It does not claim that one person caused every problem, or that the entire QMS failed.
There may be more than one cause. Do not force several independent failure paths into a single sentence just because a response form has one root-cause field. Use a short summary with a reference to the controlled investigation record.
Connect each cause to a change you can test
Correcting the overdue reviews addresses the detected problem. Corrective action addresses the supported causes. Keep that distinction visible without letting the action plan replace the investigation.
For this example, completing the five reviews would not prove that future ownership changes route tasks correctly. Training everyone again would not, by itself, change the task assignment mechanism.
| Supported cause | Cause-directed change to consider | Evidence needed to test the change |
|---|---|---|
| Ownership changes leave existing tasks with an inactive reviewer | Change the assignment workflow so an ownership change triggers reassignment and an accountable confirmation | Test existing and future tasks across relevant ownership-change scenarios, including inactive accounts and reassignment failures |
| No assigned control identifies overdue reviews independently of reminders | Assign an overdue-register reconciliation, escalation route and backup responsibility | Examine actual reconciliation records and verify that an overdue or unassigned review triggers the intended follow-up |
These are proposed changes in an illustrative case, not implemented results. Assess changes through your own change-control process, including any applicable verification or validation needs and unintended effects.
Define effectiveness criteria before interpreting the results. You might require eligible tasks to route to an active accountable reviewer and require the independent check to identify and escalate missed assignments. Specify which scenarios, records and operating period will provide meaningful evidence, with a rationale tied to the process and its risks.
“No recurrence” is weak evidence if no ownership changes occurred during the observation period. A controlled test can challenge the mechanism, while operational records show how the process performs in use. Decide what combination gives you sufficient evidence rather than selecting an arbitrary number of quiet weeks.
Be explicit when the cause remains uncertain
An honest unresolved investigation is more useful than a polished unsupported conclusion. If logs are missing or different explanations still fit, state what you know, what you cannot distinguish and which evidence would resolve the question.
For example, you may know that reviews became overdue after an ownership change but lack task history showing where reminders went. Record reassignment failure as a working hypothesis, retain alternative explanations and test the workflow where possible. A demonstration of the current configuration may support a mechanism without proving that the historical configuration behaved identically.
Keep immediate controls proportionate to the risk while you investigate. Record responsibility for obtaining the missing evidence and the decision point for reassessing your conclusion. If the response due date arrives first, use the Notified Body's process to establish what is due and how an incomplete investigation should be presented. Do not describe planned tests as completed, or assume that an extension is available.
Make the record readable without removing the reasoning
Your response should let a reviewer move from the finding to the evidence and then to the conclusion without reconstructing the investigation from attachments. Lead with the supported causal statement, followed by the extent, important exclusions and unresolved questions. Reference the underlying record for the detailed tests.
Keep the evidence trail specific. “See supplier records” is less useful than a controlled export reference, review date, defined population and identified exceptions. Preserve historical records and show later corrections transparently. Never recreate an approval as though it existed before the audit.
Before submitting, ask someone who did not lead the investigation to challenge the causal chain. Can they find the evidence for each link? Does the explanation account for both failed and successful records? Would the proposed action prevent or detect the same mechanism if a different person performed the work?
Questions that come up during an investigation
Is human error ever a valid cause?
An individual action can contribute to a failure. Describe the action precisely and investigate the conditions and controls around it. If the evidence shows a competence gap, training may belong in the response. If the system routed work to an inactive account, training the current reviewer does not repair that mechanism.
Do you have to use Five Whys?
Choose a method that helps you test the failure and document your reasoning, subject to applicable requirements and your procedures. Five Whys is useful for developing a causal chain, but five unsupported answers do not become evidence. Stop or branch when the facts require it, not when a diagram looks complete.
Can a convincing root cause guarantee closure?
No. The Notified Body evaluates the response within its applicable assessment process. A supported investigation helps explain your actions, but it does not replace evidence of correction, implementation or effectiveness where those are required, and it cannot guarantee acceptance or a particular number of review rounds.
The strongest investigation gives you a cause you can defend and an action you can meaningfully test. If you cannot connect those two yet, that is the next piece of work.
