How to prepare for a COR audit

There are two forks to getting ready for a COR audit, and most companies only think about one of them. The documents are the fork everybody expects. The people are the fork that decides the interviews, and the interviews decide most audits. Here is how I do both.

Fork one: can your documents answer every audit question?

Go through the actual audit, section by section, question by question. For each question the answer is binary: do you have the documentation to meet it, yes or no. Not "we have a policy that mentions it." Can you put the specific record in front of the auditor.

This is slower and more honest than reading a generic checklist, because you are marking your own program against the exact instrument you will be graded on. The COR audit questions page walks through what each question is really testing, and the audit readiness checklist is the free tool to do the pass. Every "no" goes on the gap report.

Fork two: can your workers answer?

This is the part companies skip, and it is the part I spend the most time on.

I print off a copy of the audit questions for every worker and we hold a toolbox meeting. I ask the first worker the first question, out loud, where everyone can hear the answer.

If he is right, or close to right, the whole crew just heard the correct answer. If he is wrong, I explain why, and where he could have found it, and now the whole crew has heard that too. Then I go to the next person, ask the next question, and we carry on around the table until everyone has answered.

The trick is what you do next, because workers are eager to please. A worker will tell you "yes" even when he has never been trained on the thing, because he does not want to look bad in front of the crew.

So after the meeting my job is to check whether the training behind each yes actually exists. If it does not, I make it available, so the answer becomes an honest yes and not a "yes, honestly." That difference is the whole game, and an auditor is very good at telling a real yes from a face-saving one.

And do not coach memorized lines. Coached answers come out in program language instead of the worker's own words, they are identical across three people, and they fall apart on the second question. The only thing that survives an interview is a crew that actually knows how the program works.

Don't forget training and tickets

While you are checking whether the answers are real, check whether the people are qualified to give them. This is where a lot of "yes" answers quietly turn into findings.

A person doing the work without the training the program says they need is a finding, no matter how good the paperwork looks.

The workers belong in the hazard assessments

One more thing that comes out of fork two. The program expects the people who do the job to be involved in building the formal hazard assessments for their tasks, because they are the ones with the experience. A formal assessment with no worker names on it reads to an auditor as one written alone at a desk, and it scores that way. If your assessments were built without the crew, that is a gap to close before the audit, and it is one the hazard assessment page covers in more detail.

The gap report is the whole point

Both forks feed one document: the gap report. It is the list of everything missing or incomplete, measured against the audit itself, and it starts full of hand-penciled items.

Then you work it. Look at the documentation, fix the gaps, and record each change in the gap report so you know exactly what is done and what is left. When the gap report is empty, you are ready, and you know you are ready, which is a very different feeling from hoping. The corrective action tracker in the template library is built for exactly this kind of close-out.

That is the honest version of audit preparation. Not tidying the site the week before, but running the audit on yourself, on paper and around the table, and closing every gap you find before somebody else writes it down.