ISO 9001 Blog

Mark Hammar

Seven Steps for Corrective and Preventive Actions to support Continual Improvement

Do you think that corrective and preventive actions are a waste of time, or something that is only useful as a showcase for the registrar? I have found that many companies struggle with implementing effective corrective action systems, but here are some ideas on how you can use these tools more effectively in your company.

Correction vs. corrective action in ISO 9001

One of the biggest difficulties is in understanding the difference between “correction” and “corrective action.” Correction is when you find a problem and fix the immediate problem, such as changing the oil in a machine that has run out and is making bad parts, while corrective action goes deeper and finds the underlying root cause of the problem (in this case, waiting too long to change oil) and fixes that root cause (implementing a preventive maintenance program to change the oil on a schedule before bad parts are made).

While every problem needs a correction, the best bang for the buck is to use corrective actions on bigger problems that are repetitive and recurring. If a problem has only surfaced once, then performing and documenting a seven-step corrective action process may be too expensive, but if it occurs several times a month an investigation and corrective action will likely save money in the long run, since time will be saved when fewer problems occur.

Remember, ISO 9001 does not require that the documented corrective action system be used on every little problem that arises, but that the system is documented and in use for addressing problems to support continual improvement.

Process for ISO corrective action

I have found that there are a few simple steps that we all go through, subconsciously, when we are trying to solve a difficult problem, and these work well when properly documented as a Corrective Action system in an ISO 9001 company (and it works with any other ISO management system as well). There are many ways to document these, from fancy computer programs to simple paper or PDF forms, but the steps all seem to follow the same flow.

1) Define the problem. First, make sure the problem is, in fact, a real problem, and not a perceived problem. A good test is if you can write the problem with a requirement to compare, what is often called a “Should Be” and “Is” statement (e.g. Parts should be nickel plated, parts were received painted black). If you can’t say what the outcome should be (or is expected to be), then you may not have identified a real problem.

2) Define the scope. Make sure you understand how big the problem to be addressed is. Is it just today’s product, or was yesterday’s product affected too? Is it just this one product, or is it on more than one product? Make sure you know what the problem is, and more importantly, what it is not. If the problem only happens on Wednesday, this may be important information.

3) Containment Actions. Make a correction to stop the problem for right now while you look for the ultimate cause and fix that. Basically, what immediate checks or stop gap measures are you putting in place to make sure that we will definitely catch the problem again if it recurs while you are fixing it.

4) Find the Root Cause. This is the trickiest part. How do you make sure you have found the underlying issue? There are many different ways to do this, from asking “Why” five times until you find the ultimate cause, to more difficult methods like a classic Ishikawa (or Fishbone) Diagram. Whole training courses have been dedicated to this topic, but suffice it to say that you want to try to identify the underlying problem, not just a surface problem. After this step, it is wise to make sure that your scope has not become bigger, making further containment actions necessary.

5) Plan a Corrective Action. Decide what steps are needed to eliminate the root cause of the problem. Here, depending on the problem, you will need to identify the cost and return on investment. How will it be funded (if it is a complicated and expensive fix), and who needs to approve the expense?

6) Implement the Corrective Action. This is as simple as following through on your plan and making it happen. It could be as simple as implementing the preventive maintenance program already described, or buying and installing a new piece of equipment because the old one could no longer keep the accuracy you need.

7) Follow up to make sure the Plan worked. Simply put, after you have made your updates, wait a suitable amount of time and make sure the problem doesn’t recur. If it does, you need to question if you got the actual root cause. This is the most important step, but also the step that most companies have trouble with. Often, people want to close out the paperwork quickly, or think the registrar requires closure early to demonstrate timeliness, but proper follow-up is essential.

ISO 9001 Corrective Action – The Seven-Step Process

And that is it.

One further note is that corrective action is used when you are reacting to a problem that has already happened, while preventive action follows the same seven-step process except that it is applied to a problem that is found before something bad happens. A corrective action would be rounding the corners of a table after someone gets hurt, but a preventive action would be rounding the corners before someone is hurt because you noticed they were sharp and might cause an accident.

Corrective & Preventive Actions – the best way to save money

It may seem redundant, but the biggest benefits can be realized by properly fixing the biggest problems. Wisely using corrective actions for the biggest problems is the most effective way to save money by driving continual improvement, and saving money through improvement is the best reason to implement an ISO 9001 Quality Management System.

Enroll in this free online training: ISO 9001 Foundations Course to learn more about corrective actions.

If you enjoyed this article, subscribe for updates

Improve your knowledge with our free resources on ISO 9001 standard.

You may unsubscribe at any time.

For more information on what personal data we collect, why we need it, what we do with it, how long we keep it, and what are your rights, see this Privacy Notice.

5 responses to “Seven Steps for Corrective and Preventive Actions to support Continual Improvement”

  1. Pinkumoni Borah says:

    Control mechanism for the corrective action

  2. Pinkumoni Borah says:

    What is the mechanism for correctin action in control process

    • Strahinja Stojanovic says:

      Dear Pinkumoni,

      THe corrective action process is the same as described in the article. First you need to define the problem, take the containment actions, find the root cause, conduct the corrective action and finally review the effectiveness of the corrective action taken.

      Best regards,


  3. tj hessmon says:

    Use the 7 or 8 step process for “Corrective Action” and you are assured failure. After 30 years in the business I have discovered there is no such thing as “Root Cause” related to any process. There is variation related to all the inputs associated with a process and the control of that variation, however attempting to attribute a process failure to a single root cause is near impossible except in the case of a specific machine.

    Its better for folks attempting to correct processes to look at the possible causes of variation inherent with the process, Think of the analysis much like creating a FEMA as that is closer to the discovery and resolution of issues related to a process than attempting root cause. An assignment of causes of variation which indicate their probability of causing failure (severity, detection, occurrence), will be far more useful in the end than hunting down a root cause.

    Why would I state that there is no factual root cause related to a process? If one has ever used the 7 or 8 step process for problem solving, one quickly understands it starts with an ishikawa diagram, which in most cases is absent Management as a cause. Once probable causes are determined based on the 4 Ms, the team votes the most likely contributor and moves in that direction…. That’s correct the determination of root cause is based upon a team vote, not data and facts. Therefore the determination of root cause is completely subjective. This is why the determination of root cause via the 7 or 8 step process rarely solves the problem

    So what does work in my experience
    1) Integrated process map by cross function (swim lane) integrated with ones systems of transaction (software) with Inputs and outputs identified. I probably solve more issues with a process map than any other process tool

    2) Process risks (variation by severity) related to each process step (FEMA format), this quickly assigns the causes of variation and possible risks of their occurrence and the severity of that occurrence in a FEMA format (Severity, detection, occurrence). If done correctly the process variation will be easy to understand as will its relevant severity. The results will be analytical not supposition. The group may not resolve every single cause of variation related to the process, however they will address the most severe causes by according to their rank. Further causes will not be overlooked by a vote where personal feelings tend to get in the way of results.

    The next time someone asks you to use a 7 or 8 step problem solving process, ask them to perform a simple gauge R&R study across 3 teams for the same failure mode. You will be astounded at the results as you find the process is not reliable as repeatable in its outcome.

    • Mark Hammar says:

      Thank you for your perspective.

      It is true that coming to one root cause is often not possible for very complex problems, and you end up with taking action to prevent many possible or most likely causes. One of the most important things about corrective action is to plan the change before you take action and then to ensure your change is effective and has fixed the problem when you are done.

Leave a Reply

Your email address will not be published. Required fields are marked *



  • Advisera is Exemplar Global Certified TPECS Provider for the IS, QM, EM, TL and AU Competency Units.
  • ITIL® is a registered trade mark of AXELOS Limited. Used under licence of AXELOS Limited. All rights reserved.
  • DNV GL Business Assurance is one of the leading providers of accredited management systems certification.