CAPA (corrective and preventive action) is a structured process that aims to find and eliminate the root cause of a non-conformity and prevent similar problems from occurring again. 8D (Eight Disciplines) is a problem-solving method, widely adopted in the automotive industry, that breaks this process into team formation, containment, root cause, permanent solution and closure steps. This guide brings together the templates, decision criteria and checklists you need from opening a CAPA record to closing an 8D report.
You can use the guide in two ways: to work step by step through a new problem, or to review a completed 8D report before closing it. The fields each discipline must contain in the report are listed separately.
Correction, corrective action and preventive action
These three concepts are often confused, and the confusion leads directly to weak CAPA records. Correction targets the symptom, corrective action targets the cause, and preventive action targets the cause of a potential problem that has not happened yet.
| Concept | What it targets | Example |
|---|---|---|
| Correction | Fixes the detected non-conformity | Sorting and reworking defective parts |
| Corrective action | Removes the cause of an existing non-conformity | Permanently changing the mould setting that caused the defect |
| Preventive action | Removes the cause of a potential non-conformity | Applying the same change to similar moulds |
ISO 9001:2015 removed the separate “preventive action” clause of earlier editions and moved this approach into planning through risk-based thinking (clause 6.1). Even so, the term CAPA remains widely used, especially in regulated industries such as pharmaceuticals and medical devices, and in many quality software tools.
A practical distinction: correction protects today's customer, corrective action protects the next customer, and preventive action protects products and processes that have not had the problem yet.
When should you open a CAPA?
Not every non-conformity needs a full 8D. Defining in advance, with written criteria, what to open in which situation protects resources and keeps decisions from depending on who makes them. The table below is a starting template; adapt the criteria to your own risk assessment and customer requirements.
| Trigger | Recommended record | Note |
|---|---|---|
| Customer complaint or return | 8D | The customer may require its own format |
| Recurring internal non-conformity | CAPA | Define the recurrence criterion in advance |
| Major audit finding | CAPA | Assess risk for minor findings |
| Deviation affecting safety or compliance | Always CAPA | Ask an expert about reporting duties |
| Supplier-caused defect | 8D from the supplier | Give a written request and due date |
| One-off, low-risk defect | Correction may be enough | Record the decision and rationale |
Ask three questions when you decide: Did the problem reach the customer, or could it? Is product safety or legal compliance affected? Has the problem been seen before? If you answer “yes” to any of them, you need a CAPA with root cause analysis.
Opening a CAPA for every small deviation clogs the system: records pile up, overdue actions become normal and important problems get lost in the crowd. On the other hand, settling for correction without reaching the root cause lets the same defect happen again and again. Put the criteria in writing and record decisions not to open a CAPA together with their rationale.
The 8D disciplines: D0 to D8
The steps below are the skeleton of an 8D report. Under each step are the minimum fields the report must contain for that discipline. Defining these fields as mandatory in your quality software prevents incomplete reports from being closed.
- 01D0-D1 Prepare and team
- 02D2 Problem description
- 03D3 ContainmentProtect the customer
- 04D4 Root causeOccurrence and escape
- 05D5-D6 Permanent action
- 06D7 Prevent recurrenceFMEA and control plan
- 07D8 Closure
- 01D0: Prepare and respond
Decide whether the problem needs an 8D and, if needed, start an emergency response to protect the customer. Fields: record number, source (complaint, internal defect, audit), open date, first notice, emergency response description, decision to open the 8D and its rationale.
- 02D1: Form the team
Build a small cross-functional team with product and process knowledge. Fields: team leader, sponsor, members and roles, contact details, meeting frequency.
- 03D2: Describe the problem
Describe the problem from the customer's point of view in measurable, neutral terms. Fields: problem statement, 5W2H answers, is / is-not analysis, affected product, lots and quantity, evidence photos or measurement data.
- 04D3: Implement containment
Protect the customer until the permanent solution is in place. Fields: quarantined stock locations and quantities, sorting method, sorting results, clean point definition, implementation date, evidence that containment works.
- 05D4: Find and verify the root cause
Identify both why the defect occurred and why it escaped without being detected. Fields: analysis tools used, occurrence root cause, escape root cause, systemic cause, verification method and result.
- 06D5: Choose the permanent corrective action
For each verified root cause, choose the action that eliminates it and verify that it will work before implementing it. Fields: action, targeted root cause, owner, due date, alternatives considered, rationale, verification plan.
- 07D6: Implement and validate
Implement the permanent action, remove containment in a controlled way and track the result with data. Fields: implementation date, change records, containment removal date, effectiveness criterion, monitoring period and results.
- 08D7: Prevent recurrence
Fix the system that allowed the problem and spread what you learned to similar products and processes. Fields: updated FMEA, control plan, instructions, products and lines covered by read-across, lessons learned record.
- 09D8: Recognise the team and close
Make the team's contribution visible and close the report with authorised approval. Fields: closure summary, closure approval, customer approval (if required), closure date, recognition note.
Team formation and problem description (D1, D2)
Who should be on the team?
- Team leader: knows the 8D method, runs meetings and tracks due dates.
- Sponsor: the manager who provides resources and authority and removes obstacles.
- Process expert: the engineer who knows the process and equipment where the defect occurred best.
- Quality engineer: responsible for data collection, the measurement system and analysis tools.
- Shop floor representative: an operator or shift supervisor who brings daily reality to the team.
- If needed, a supplier, design or customer representative.
Keep the team small and define why each member is there. Instead of excluding people seen as responsible for the defect, include them as a source of knowledge; you cannot get accurate information in a climate of blame.
Problem statement with 5W2H
- What: Which product, which defect, which characteristic?
- Where: Which line, station, customer site or location on the part?
- When: When was it first seen, which shift or production date?
- Who: Who detected it? (Not who made the mistake.)
- Why: Why is this a problem, which requirement does it fail?
- How: How was it detected, by which measurement or check?
- How many: How many pieces, at what rate, in which lot range?
Is / is-not analysis
Is / is-not analysis narrows down possible causes by comparing the problem with similar situations that are free of it. The distinguishing differences are the source of the hypotheses you will test in D4.
| Dimension | Is | Is not | Distinguishing difference |
|---|---|---|---|
| What | Which product and defect | Similar product, no defect | Difference between the two products |
| Where | Which line or location | Other line or location | Equipment, layout, environment |
| When | Which period or shift | Earlier period, other shift | What changed in that period |
| How many | Affected quantity | Unaffected lots | Material or parameter difference |
Containment actions (D3)
The only purpose of containment is to stop defective product from reaching the customer until the permanent solution takes effect. Containment does not solve the root cause, so its cost, duration and removal condition are defined from the start. Its effectiveness must also be verified: make sure the check used for sorting can actually catch the defect.
Root cause analysis (D4)
A good 8D looks for at least two root causes: why the defect occurred (occurrence cause) and why it escaped to the customer undetected (escape cause). A mature analysis adds a third: why the management system made both possible (systemic cause). Reports that skip this distinction usually only tighten inspection and leave the occurrence untouched.
- Why did the defect occur?
- Process, material, equipment
- Removed by permanent action
- Why was it not caught?
- Inspection and measurement
- Detection capability improved
- Why did the system allow it?
- FMEA, planning, approval
- Written into the system in D7
5 Whys
5 Whys is a simple tool that moves from symptom to cause by asking “why?” again of each answer. Its simplicity is deceptive; used carelessly, the team just writes its guesses down as a chain.
- Base the chain on observation and data; every link must be supported by evidence.
- Build separate chains for occurrence and escape.
- Five is not a rule; stop when you reach a cause you can control.
- Read the chain backwards: using “therefore”, you should reach the symptom without a break in logic.
- If a link has more than one cause, branch the chain.
- Do not stop at a link that points to a person; ask which condition allowed that person's mistake.
Ishikawa (fishbone) and the 6Ms
An Ishikawa diagram structures brainstorming by sorting possible causes into categories. The 6M categories common in manufacturing are Man, Machine, Method, Material, Measurement and Mother nature (environment). The diagram is a list of hypotheses, not evidence. Eliminate each bone using the distinguishing differences from the is / is-not analysis and turn the rest into a test plan.
Fault tree analysis
Fault tree analysis (FTA) puts the unwanted event at the top and breaks down the events that could lead to it using AND / OR gates. For complex failures that require several conditions at the same time, and for safety-related problems, it gives more reliable results than 5 Whys.
Verify the root cause
An unverified root cause is only an assumption. Where possible, recreate the cause under controlled conditions and show that the defect appears, and that it disappears when you remove the cause (turn on / turn off test). If that is not possible, collect strong evidence through data analysis, design of experiments or comparison of historical records, and write the verification method into the report.
“Operator error”, “carelessness” and “lack of training” are not root causes. They are symptoms showing that the process is open to human error. Likewise, “the operator was retrained” does not count as a permanent corrective action on its own; it must be backed by a process change that makes the error harder or impossible.
Permanent corrective action and effectiveness (D5, D6)
At least one permanent action is defined for each verified root cause. The strength of an action relates to how little it depends on human attention. The ranking below is a qualitative guide you can use to compare options.
- L1Training and awareness
- L2Instruction change
- L3Automatic detection
- L4Error-proofing (poka-yoke)
- L5Elimination by design
| Action type | Relative strength | Example |
|---|---|---|
| Elimination by design | High | Part geometry that makes reverse assembly impossible |
| Error-proofing (poka-yoke) | High | Fixture that will not run with the wrong part |
| Automatic detection and stop | Medium | In-line sensor with reject and alarm |
| Instruction or procedure change | Low to medium | Updated visual work instruction |
| Training and awareness | Low | Not sufficient on its own |
In D5 you verify that the action will work before you implement it (trial run, pilot line, simulation). In D6 you implement the action under real conditions and prove its effectiveness against a predefined criterion. The effectiveness criterion and monitoring period should be set when the action is chosen; a criterion defined afterwards, at closure, does not inspire confidence.
Preventing recurrence and lessons learned (D7, D8)
D7 is the step where you move from fixing one product to fixing the system. The question is: Where else does the same weakness exist, and why did our management system not see this risk in advance?
- Update the process FMEA: add the new failure mode and reassess occurrence and detection ratings against the new controls.
- Update the control plan: new control point, method, frequency and reaction plan.
- Revise work instructions, check sheets and training material, and control their distribution.
- Do a read-across: list products and lines that use the same design, equipment or supplier and apply the action there too.
- Keep the lesson learned as a searchable record and make sure it is used in new product development and design FMEA work.
- In D8, make the team's contribution visible; recognition increases participation in future 8Ds.
When CAPA records, revised documents and FMEA updates sit scattered across different systems, proving that D7 is complete becomes hard. OREL QMS keeps CAPA and 8D records linked to non-conformity, audit and supplier records, and OREL DMS tracks the approval and distribution of revised instructions. Whatever tool you use, the principle is the same: every action should be tied to a single record together with its evidence.
ISO 9001 and IATF 16949 context
ISO 9001:2015 clause 10.2 requires the organisation, when a non-conformity occurs, to react to it, determine its causes and evaluate whether similar non-conformities exist or could occur, implement any action needed, review the effectiveness of that action, and update risks and opportunities and the quality management system if necessary. The nature of the non-conformity, the actions taken and their results must be retained as documented information.
IATF 16949 extends these requirements for the automotive supply chain. It requires a documented process for problem solving (clause 10.2.3) and a documented process for the use of error-proofing methods (clause 10.2.4), and it defines additional expectations for customer complaints and field failures. Many automotive customers require a specific 8D format and response times as part of their customer-specific requirements.
Neither ISO 9001 nor IATF 16949 mandates a specific problem-solving method by name. 8D is a common and accepted method, but confirm which format and response times apply from your customer requirements and with your certification body.
8D report review and common mistakes
Before you send an 8D report to the customer or close it, have an experienced person who was not on the team review it with the list below; this catches weak points early.
Common mistakes
- Jumping to solutions before the problem is described.
- Blaming the operator and counting retraining as a permanent fix.
- Fixing only the escape cause by tightening inspection, leaving the occurrence cause untouched.
- Accepting the first plausible explanation without verifying the root cause.
- Letting containment become permanent, with sorting running for months.
- Setting the effectiveness criterion at closure, or never setting it.
- Not updating the FMEA and control plan, so the same defect returns in a new product.
- Treating the 8D as a form filled in to meet a customer reporting deadline.
Conclusion
CAPA and 8D are less about filling in a form well than about a disciplined way of thinking: protect the customer first, then describe the problem neutrally, verify the root cause with evidence, choose permanent actions aimed at the process rather than the person, and write what you learned into the system. By adapting the template fields and checklists in this guide to your own quality system, you can make the same quality repeatable for every new problem.