7 steps to writing better root causes.

 This is the second installment of a two-part series on writing better root causes. In part 2 we discuss strategies to determine if findings really need root cause analysis (RCA) and tips for discussing RSA with the audit client. In part one we provide some strategies to use in writing and communicating root cause in audit findings.

Picking up where we left off in part one of this two-part series, here we discuss strategies to determine if findings really need RCA and tips for discussing RCA with the audit client.

Determine severity of the condition

The IIA practice advisory describes RCA as a “core competency necessary for delivering insights to identify the need for RCA and, as appropriate, actually facilitate, review, and/or conduct a root cause(s) analysis.”

With that said, some findings won’t require a full root cause analysis. When the finding lacks severity, it may be too insignificant to pursue a root cause. If you believe the audit client can solve the problem and is willing, you might not need to report root cause. However, a repeat issue from previous audits is a red flag that perhaps the root cause needs to be assessed. The audit client may also need additional help to resolve their problem.

If the finding is severe, then it presents significant risk to the company. In this case, root cause analysis is important to make sure the condition is stopped and not repeated. Severe findings often point to systemic issues that the company needs to address. Audit is in a perfect third-party position to define causes and recommend solutions.

bulbReport root cause when the issue is severe enough to cause significant risk to the company or if the audit client needs help and can prove they need help.

Locate lost root causes

As an editor, over and over again I see the finding just launch directly into the thick of evidence and conclusions without ever touching upon the root cause. Sometimes I never find the root cause, but often the root cause is hidden way down in the recommendations.

Recommendations should solve what has already been presented in the finding, but not introduce new ideas. When I see a recommendation (e.g., “Create training to...”), I can see that the auditor paid attention to the root cause, but just needed to report the root cause earlier in the finding.

bulbDuring your editing, if the root cause makes its first appearance in the recommendation, reconsider how you can use that recommendation to create a marvelous topic sentence for the finding itself.

Set expectations with the audit client

Finally, sometimes auditors skirt the root cause because of possible contention with the audit client. It can be intimidating to tell the audit client why you think that the issue took place or even implicate a job position or process. However, if you have evidence and conclusions in place, present those during fieldwork and allow you and the client to engage in a thoughtful conversation to determine the root cause together and develop potential solutions.

It’s best to address your audit team’s take on root cause analysis in the opening meeting. Let the auditee know that you’ll bring them findings and will expect to engage in a discussion to determine root cause together. Setting expectation goes a long way in helping the client feel at ease with reporting root causes.


Auditors only have so many words or pages to convey the health of a company to their larger audience (i.e., management, executives, audit committee) before losing their attention. There are few areas where you can make more of a difference than in defining and reporting root cause. Happy root-cause sleuthing!