Root Cause and Corrective Action Requirements in ISO 9001

[Kurt Smith]

In a recent surveillance audit we were giving minor findings for our root causes not being effective on Corrective Action Reports from Internal Audits. From discussions with the auditor while they were here, it seemed they expected more detail and evidence thought the report. This is fine and I will be the first to admit that the reports we have made are very minimal and a good area for improvement.
However, I am confused as to what the requirements per ISO 9001 actually are. Per our manual we are expected to record our Root Cause Analysis, and Corrective Action, and several other. But no definitions are given for these terms. No requirements listed for evidence or template, or of the steps needed to make an adequate report.
I want to be certain in the future that we understand the requirements of ISO. Any advice?

 

[Randy]

It doesn't matter a flip what the auditors expected!

There are 3 questions

Were the problems fixed YES or NO?

Did the problems happen again YES or NO?

Did the new problems have the same cause as the original problems YES, NO or N/A?

Technically there isn't any requirement to document "cause" in 10.2.2

 

[Golfman25]

Sounds to me like you boxed yourself in by requiring a formal root cause analysis. You don't necessarily have to do that for smaller, easily solved, issues. So make sure your systems gives you the flexibility needed.

Second, the only way once can determine whether root cause analysis failed was did the problem reoccur. Did he give any such evidence?

 

[Kurt Smith]

It doesn't matter a flip what the auditors expected!

There are 3 questions

Were the problems fixed YES or NO?

Did the problems happen again YES or NO?

Did the new problems have the same cause as the original problems YES, NO or N/A?

Technically there isn't any requirement to document "cause" in 10.2.2

That is what I expected. They did find a reoccurrence of a finding (work traveler operations not signed off by operators, its a constant struggle for us), but that isn't how they wrote it. I am grateful they didn't write it that way, as that could have been construed as a major finding. But I am not sure how to respond to this as they didn't write up the real issue.

 

[Kurt Smith]

I guess my issue is that if I am going to make corrective action and potentially update our manuals requirements for 10.2, how do I define what those should be?

 

[Golfman25]

I guess my issue is that if I am going to make corrective action and potentially update our manuals requirements for 10.2, how do I define what those should be?

Define it however you want, so long as your in line with the standard. Summarized, 10.2.1 of The standard requires -- when a NC occurs:

a) react, and as applicable take some action.
b) evaluate the need for action to eliminate the cause of the NC (this is the root cause stuff) -- note that it requires an evaluation of the need, not necessarily root cause analysis.
. . .

Importantly, note the last line: "Corrective actions shall be appropriate to the effects of the nonconformities encountered." That's kind of your risk balancing. So keep your options open. And pick you battles -- use root cause for the big problems. For the small problems, something less my be fine.

So using your example, operators not signing off on travelers -- there could be dozens of root causes based on each operator. But who cares if they do or don't -- what are the consequences to your products? Depending on the situation, you could simply remind the person to sign off, all the way to having some type of failsafe that the process can't proceed without the signoff.

 

[Randy]

I am grateful they didn't write it that way, as that could have been construed as a major finding.

If you'd have gotten a Major for a piddly thing like that it would have been BS. Unless you stated in your NC/CAR procedure/program/process or whatever that "all" NC's required formal CA you don't even need to, just document, fix and move on. Not all NC's require formal, documented CA's, and you get to decide the what's and wherefore's, not some %%% auditor.