--- title: Root Cause Analysis Techniques for MedTech Startups description: Root cause analysis is the heart of CAPA under EN ISO 13485. Here are the techniques that work in small MedTech teams without bureaucratic overhead. authors: Tibor Zechmeister, Felix Lenhard category: Quality Management Under MDR primary_keyword: root cause analysis MedTech startups canonical_url: https://zechmeister-solutions.com/en/blog/root-cause-analysis-medtech-startups source: zechmeister-solutions.com license: All rights reserved. Content may be cited with attribution and a link to the canonical URL. --- # Root Cause Analysis Techniques for MedTech Startups *By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.* > **Root cause analysis for MedTech startups is the disciplined process of working back from an observed nonconformity to the underlying cause that, if removed, would prevent the problem from recurring. The legal anchor is MDR Article 10, which requires a proportionate quality management system and corrective action when devices may not be in conformity. The standard that describes the mechanics is EN ISO 13485:2016+A11:2021 clause 8.5.2, which requires the cause of nonconformities to be determined as part of corrective action, and clause 8.3, which governs the control of nonconforming product that often triggers the analysis. At startup scale, three techniques cover almost every situation: 5 Whys for linear causes, fishbone (Ishikawa) analysis for multi-factor causes, and fault tree analysis for safety-critical or complex technical failures. The method matters less than the discipline of not stopping at the first plausible answer.** **By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.** --- ## TL;DR - Root cause analysis (RCA) is the investigation step inside CAPA required by EN ISO 13485:2016+A11:2021 clause 8.5.2. Without a real RCA, the corrective action fixes the symptom and the problem recurs. - MDR Article 10 requires a proportionate quality management system and obligates manufacturers to take corrective action when a device may not be in conformity. RCA is how the word "cause" in clause 8.5.2 gets honoured in practice. - Three techniques cover most startup situations: 5 Whys, fishbone (Ishikawa) analysis, and fault tree analysis. Each fits a different type of problem, and picking the right one saves time. - The test of a root cause is not how deep you dug but whether removing the identified cause would actually prevent the observed problem. If the answer is no, the analysis is not finished. - Documentation of RCA inside a CAPA record does not need to be elaborate. It needs to be legible, dated, honest, and attached to the observation and the action. --- ## What RCA is and is not Root cause analysis is the step in a CAPA where the team moves from "this went wrong" to "this is what allowed it to go wrong." It sits between the observation and the corrective action, and the quality of everything downstream depends on it. RCA is the clause 8.5.2 obligation in EN ISO 13485:2016+A11:2021 to determine the cause of nonconformities as part of corrective action. The standard names the requirement plainly and leaves the method to the manufacturer. The manufacturer chooses the technique appropriate to the problem, documents the result, and uses it to drive the action. The MDR anchors the legal obligation in Article 10: a proportionate QMS that includes management of corrective and preventive actions, and the duty to take corrective action when a device may not be in conformity with the Regulation. RCA is not a single method. It is a family of techniques that share a common discipline: work backward from the observation, past the first plausible explanation, until you reach a cause that, if removed, would actually prevent the observed problem. That discipline is the whole point. Any technique that respects it works. Any technique that ignores it fails, no matter how sophisticated the diagram. RCA is not a ritual. It is not a form to fill in. It is not a sentence in a CAPA template that reads "root cause: human error" — human error is almost never a root cause. It is the thing that happens when the real cause — an unclear procedure, a missing check, an untrained operator, a broken tool — meets a human being. Stopping at "human error" means stopping before the analysis has started. RCA is also not an exercise in blame. The people closest to the problem are usually the people who should be in the room for the analysis, and they will not speak honestly if the exercise is framed as finding someone to punish. The analysis is about the system, not the individual. ## The 5 Whys technique 5 Whys is the simplest RCA method and the right starting point for most startup problems. It is sequential and linear. State the problem, ask why it happened, take the answer, ask why that happened, and repeat. The "five" is a guideline — sometimes the real cause appears at the third why, sometimes at the seventh. The discipline is not the count. A worked example. A customer complaint arrives: the device shipped with an out-of-date instructions-for-use document. 1. Why did the device ship with an out-of-date IFU? Because the packaging team pulled the IFU from a shared folder that contained the old version. 2. Why did the shared folder contain the old version? Because the document controller saved the new IFU to a different location and never removed the old file. 3. Why was the old file never removed? Because the document control procedure does not require removal of superseded documents from shared locations. 4. Why not? Because the procedure was written when the company used only the QMS document library, before the shared folder workflow was introduced. 5. Why has the procedure not been updated? Because no one owns the job of updating procedures when the underlying workflow changes. The root cause, at the fifth why, is the missing ownership of procedure maintenance when workflows change. Fixing the single out-of-date IFU addresses the symptom. Removing the out-of-date file from the shared folder addresses the next layer. Assigning clear ownership for procedure maintenance addresses the cause. Only the last one prevents the same category of problem from reappearing with a different document. 5 Whys is fast. Thirty minutes with the right people in the room is usually enough. It works best when the problem has a single dominant chain of causation. When the problem has multiple contributing factors that combine to produce the observed effect, 5 Whys can mislead by locking onto one thread and missing the others. That is where fishbone analysis earns its keep. ## Fishbone (Ishikawa) analysis Fishbone analysis, also called Ishikawa after Kaoru Ishikawa, is a structured way to surface multiple contributing causes at once. The diagram is drawn with the problem statement at the head of the fish on the right, a horizontal spine running left, and diagonal "bones" branching off the spine, each one representing a category of possible cause. The classic categories for a manufacturing or process problem are people, process, equipment, materials, environment, and measurement. For software or digital health, the categories adapt: people, process, code, infrastructure, data, and verification. The specific categories matter less than the act of forcing the team to consider different families of cause instead of fixating on the first explanation. The method is straightforward. Write the problem at the head. Draw the main branches for the categories. For each category, brainstorm contributing factors and attach them as sub-branches. Once every branch has been populated, look at the diagram as a whole and identify the factors or combinations of factors that, if removed, would prevent the observed problem. A worked situation. A startup's sterile packaging validation failed a routine audit check. 5 Whys produced one answer — an operator training gap — but the team was not convinced. Running a fishbone analysis exposed four contributing factors working together: training was incomplete (people), the sealing equipment had drifted out of calibration (equipment), the incoming film lot had shifted specification (materials), and the validation sampling plan was too small to detect the drift early (measurement). No single factor caused the failure. The combination did. The corrective action had to address all four. Fishbone analysis is slower than 5 Whys. It needs forty-five minutes to an hour and works best with two to four people in the room who know different parts of the process. The output is a picture that the team can photograph, paste into the CAPA record, and defend in front of an auditor as evidence that the causes were considered across categories rather than pursued on a single thread. ## Fault tree analysis Fault tree analysis (FTA) is the heaviest of the three techniques and the right tool for safety-critical or technically complex failures. It is used extensively in the risk management process under EN ISO 14971:2019+A11:2021 and translates directly into CAPA situations where a nonconformity has potential safety implications. The diagram starts with the undesired top event — the failure to be analysed — at the top. Underneath, the analyst draws logic gates (AND, OR) that decompose the top event into combinations of lower-level events that could produce it. Each lower-level event is decomposed further until the analysis reaches basic events that can be observed or measured directly. The result is a tree that shows, with logical precision, every combination of conditions that could lead to the top event. FTA is quantitative when probabilities are available. It is qualitative when they are not. Either way, it produces a map of failure pathways that is rigorous in a way that 5 Whys and fishbone cannot match. The cost is time. A full fault tree takes hours to days, depending on complexity, and needs participants who understand the technical system in detail. When to use FTA. A post-market report reveals that a Class IIb device produced an unexpected measurement error under a specific use condition. The error did not cause harm in the reported case, but the team needs to understand every pathway that could have produced the error so the corrective action and the risk file can be updated honestly. FTA is the right choice. A dropped pen in a meeting did not cause the problem directly, and 5 Whys will not map the failure geometry. When not to use FTA. A typo in a batch record. A missing signature. A single training gap. FTA for these situations is overkill and drains the team without producing better answers. ## Picking the right technique The choice of technique depends on three factors: the complexity of the problem, the safety implications, and the time the team has available. Use 5 Whys when the problem has a single dominant chain of causation, the safety implications are limited, and the team needs a result quickly. Most administrative and procedural nonconformities fit this profile. Use fishbone analysis when the problem has multiple contributing factors from different categories, the causes are suspected to combine rather than act alone, or the team wants a visual output that supports discussion across roles. Process and manufacturing problems fit this profile. Use fault tree analysis when the problem has safety implications, the technical system is complex, the team needs to map failure pathways with logical rigour, or the analysis will feed back into the risk management file under EN ISO 14971:2019+A11:2021. Device-level technical failures and post-market safety signals fit this profile. The three techniques are not mutually exclusive. A complex CAPA can start with 5 Whys to locate the rough area of the cause, move to fishbone to surface contributing factors, and conclude with a fault tree on the specific technical pathway that matters most. The discipline is to let the problem choose the method, not the other way around. ## Documenting RCA in a CAPA The RCA record inside a CAPA does not have to be elaborate. It has to be legible, dated, and attached to the observation and the action so an auditor can follow the thread without reconstruction. For a 5 Whys analysis, the record is the sequence of questions and answers ending with the identified root cause. A list on a single page is enough. For a fishbone, the record is the diagram itself, photographed or drawn into the CAPA record, with the identified cause or combination of causes marked. For a fault tree, the record is the tree diagram with the top event, the logic gates, and the basic events, together with any quantitative results if probabilities were used. Every RCA record should include the date, the participants, the technique used, the identified root cause (or causes), and a one- or two-sentence rationale for why removing that cause would prevent the observed problem. The rationale is the step most teams skip. Without it, the auditor cannot see the logic that connects the cause to the action, and the CAPA reads as assertion rather than analysis. The RCA record attaches to the CAPA as the investigation evidence required by EN ISO 13485:2016+A11:2021 clause 8.5.2. The corrective action that follows then traces back to the cause identified in the RCA, not to the symptom described in the observation. That trace — observation to cause to action — is what the auditor will check, and a clean trace is what turns the CAPA into a defensible record. ## Common mistakes Four mistakes show up repeatedly in startup RCA practice. **Stopping at the first plausible answer.** The team asks why once, gets a reasonable explanation, and moves on. The explanation becomes the "root cause" in the record, and the action addresses it. Two months later the same category of problem reappears because the real cause was two or three whys deeper. The fix is the discipline of one more question than feels comfortable, every time. **Labelling the human as the cause.** "Operator error" is a diagnosis, not a root cause. The cause is whatever allowed the operator error to occur — an unclear procedure, missing training, a badly designed form, an interruption at the critical moment, a tool that looks the same as the wrong tool. "Human error" in a CAPA record is a signal the analysis stopped too early. **Picking the wrong technique for the problem.** A safety-critical technical failure analysed with a quick 5 Whys produces a shallow answer. A missing signature analysed with a full fault tree produces a wasted afternoon. Matching technique to problem is part of the analysis, not separate from it. **Writing the RCA after the action is chosen.** The worst mistake is working backward from a favoured corrective action to construct a root cause that justifies it. This is common when someone already knows what they want to fix and treats the RCA as a paperwork formality. The result is a CAPA record that looks compliant and leaves the real cause in place. ## The Subtract to Ship angle Subtraction in RCA means removing every step, form field, and analytical flourish that does not help identify the cause. The complete RCA record that a small team runs well contains the problem statement, the technique used, the sequence or diagram produced, the identified cause, and a one-sentence rationale connecting the cause to the observed problem. That is usually half a page or one page. A ten-page RCA report with template sections for "context," "scope," "limitations," and "references" is almost always overhead, and the overhead crowds out the thinking that actually matters. The test for RCA is the same test that applies everywhere in Subtract to Ship. For every element of the analysis, ask what specific EN ISO 13485:2016+A11:2021 clause or MDR article it traces to. Clause 8.5.2 requires the cause to be determined. It does not require a specific format, a specific technique, or a specific length. The discipline is what the clause requires. Everything else is discretionary, and most of it can come out. A startup that runs disciplined 5 Whys, fishbone, or fault tree analyses with honest records meets MDR Article 10 and EN ISO 13485:2016+A11:2021 clause 8.5.2 more completely than a large team running elaborate RCA templates without the discipline. Notified Body auditors can tell the difference from the first page. ## Reality Check — Where do you stand? 1. For the last CAPA your team closed, which RCA technique was used and why? Was it the right match for the problem? 2. Does the RCA record for that CAPA go more than one level deep from the original observation, or does it stop at the first plausible explanation? 3. Is the identified root cause something a corrective action could actually remove, or is it a description of the symptom restated in different language? 4. Does any RCA record in your current log contain the phrase "human error" or "operator mistake" as the stated root cause? If yes, re-open the analysis. 5. Can you defend, in one sentence, why removing the identified cause would prevent the observed problem? 6. Do your RCA records name the technique used, the participants, the date, and the rationale linking cause to action — or do they just state a conclusion? 7. If a Notified Body auditor asked to see the evidence that the cause was determined under clause 8.5.2, could you show a record that demonstrates the thinking rather than just asserts an answer? ## Frequently Asked Questions **What is root cause analysis in a MedTech CAPA?** Root cause analysis is the investigation step in a CAPA where the team determines the underlying cause of a nonconformity, so the corrective action can remove the cause rather than the symptom. EN ISO 13485:2016+A11:2021 clause 8.5.2 requires the cause of nonconformities to be determined as part of corrective action, and MDR Article 10 anchors the legal obligation. The technique is chosen by the manufacturer; the discipline of reaching a real cause is what the standard and the Regulation require. **Which RCA technique should a small MedTech startup use?** Start with 5 Whys for linear problems, move to fishbone (Ishikawa) analysis for multi-factor problems, and use fault tree analysis for safety-critical or technically complex failures. Most startup CAPAs can be handled with 5 Whys or fishbone. Fault tree analysis is reserved for situations where the technical failure pathways matter and feed back into the risk management file. **Is "human error" a valid root cause?** No. "Human error" is almost always a symptom, not a cause. The real cause is whatever allowed the error to occur — an unclear procedure, missing training, a badly designed interface, an interruption at the critical moment, or a tool that looks the same as the wrong tool. A CAPA record that identifies "human error" as the root cause has stopped the analysis one step too early. **How deep should a 5 Whys analysis go?** Deep enough that removing the identified cause would actually prevent the observed problem. The "five" in 5 Whys is a guideline. Sometimes the real cause appears at the third why, sometimes at the seventh. The test is not the count — it is whether the cause, once removed, addresses the problem. **Does EN ISO 13485 require a specific RCA technique?** No. EN ISO 13485:2016+A11:2021 clause 8.5.2 requires the cause of nonconformities to be determined as part of corrective action, but it does not specify the method. The manufacturer chooses the technique appropriate to the problem and documents the result. The requirement is the discipline of determining the cause, not the form of the analysis. **How long should an RCA record be?** Long enough to show the thinking, short enough to read. A 5 Whys record is typically a single list on half a page. A fishbone record is the diagram plus a short paragraph identifying the cause. A fault tree record can be longer because the diagram itself is more complex. The test is whether an auditor could follow the logic from observation to cause without reconstruction. ## Related reading - [How to Respond to MDR Audit Non-Conformities Step by Step](/blog/respond-to-mdr-audit-nonconformities) — applying RCA discipline inside a Notified Body CAPA response. - [The Subtract to Ship Framework for MDR Compliance](/blog/subtract-to-ship-framework-mdr) — the methodology behind lean RCA practice. - [CAPA Under MDR: Using ISO 13485 for Corrective and Preventive Action in Startups](/blog/capa-mdr-iso-13485) — the full CAPA context that RCA sits inside. - [How to Run an Effective CAPA Process Without Bureaucratic Overhead](/blog/capa-without-bureaucratic-overhead) — operational companion on executing CAPAs without drowning in forms. - [Post-Market Surveillance Data Collection for MDR Startups](/blog/pms-data-collection-mdr-startups) — the detection layer that feeds RCA inputs from the field. - [Complaint Handling Under MDR and ISO 13485](/blog/complaint-handling-mdr-iso-13485) — another upstream source for nonconformities that trigger RCA. - [Internal Audits Under MDR: Clause 8.2.2 in Practice](/blog/internal-audits-mdr-clause-8-2-2) — the internal audit process that surfaces the findings RCA is applied to. - [Preventive Action Under ISO 13485 Clause 8.5.3](/blog/preventive-action-iso-13485-8-5-3) — the forward-looking counterpart where RCA is applied to potential nonconformities. - [Management Review Inputs and Outputs Under MDR](/blog/management-review-inputs-outputs-mdr) — where RCA findings feed back into QMS governance. ## Sources 1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Article 10 (general obligations of manufacturers, including the proportionate quality management system and the obligation to take corrective action when a device may not be in conformity). Official Journal L 117, 5.5.2017. 2. EN ISO 13485:2016 + A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes, clause 8.3 (control of nonconforming product) and clause 8.5.2 (corrective action, including determination of the cause of nonconformities). --- *This post is part of the Quality Management Under MDR series in the Subtract to Ship: MDR blog. Authored by Tibor Zechmeister and Felix Lenhard. Root cause analysis is where a CAPA earns its keep or fails, and the discipline described here is the one that separates records that solve problems from records that describe them.* --- *This post is part of the [Quality Management Under MDR](https://zechmeister-solutions.com/en/blog/category/quality-management) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*