The first audit report I ever submitted was rejected. Not revised. Not sent back with comments. Rejected. I'd spent years as an IT security consultant before moving into audit, so I knew the technical side cold. I found real problems in that organization — serious ones — and I wrote them all up. My Director of Internal Audit read it and handed it back to me. "This is not an audit report," he said. "This is a remediation plan. Go learn the difference." That was one of the most embarrassing moments of my career. It was also one of the most useful. Here's what I learned.
A finding is a communication tool, not a technical write-up. You can spend weeks in fieldwork. You can find real, business-threatening problems. You can document every one of them with precision. And if the finding is written the wrong way, none of that work matters — because management will read it, file it, and move on.
That's because a finding's entire job is to move a decision-maker to action. And decision-makers aren't reading it looking for technical detail. They're silently asking three questions:
- What is the problem?
- How bad is it?
- What do we do about it?
If a finding doesn't answer those three questions in plain language, you've already lost the reader — no matter how good the underlying audit work was.
The Five C's: the structure that gets findings accepted Most internal auditors are taught some version of a structured finding format. I use what I call the Five C's — Criteria, Condition, Cause, Consequence, Correction — and I think of them as five spans of a bridge, running from "what we found" on one side to "what management should do about it" on the other. Miss a span, and the bridge doesn't reach the other bank. Management is left to fill the gap themselves — and that's exactly where pushback and rejection come from.
- Criteria — the "should be." This is your benchmark: the policy, standard, or regulation the organization was supposed to meet. The most common mistake here is what I call the *orphaned standard* — citing a framework like NIST or ISO that your organization never formally adopted. Management's response is predictable: "we never agreed to that." Cite a specific, named policy your organization actually signed off on, and that argument disappears.
- Condition — the "what is." This is the factual, evidence-based observation of what you found. The rule is simple: facts, not conclusions. The most common mistake is the *unsupported superlative* — words like "several," "numerous," or "poor" standing in for actual numbers. "The organization has poor access controls" invites an argument. "54 of 200 sampled accounts (27%) had no documented management authorization" does not. Replace every superlative with a number management can verify themselves.
- Cause — the "why." This is where most findings fail without anyone realizing it. The most common trap is the *surface cause* — stopping at the first explanation ("staff didn't follow the procedure") instead of asking one more "why." Surface causes produce weak recommendations, like a training reminder. Root causes — usually a missing process or control, not a person who made a mistake — produce recommendations that actually prevent the problem from recurring. A closely related trap: never let budget be your stated root cause. It's a factor to acknowledge, not the cause itself, and it gives management an easy way to defer action indefinitely.
- Consequence — the "so what." This is the span that creates urgency, and it's the one most commonly reduced to a single generic sentence: "this represents an elevated risk to the organization's security posture." That sentence could appear in any report, about any finding, in any organization. It moves no one. A strong Consequence is specific: a dollar figure from a published source, a named regulation and its penalty, a statement of what's happening right now rather than what theoretically could happen. Executives think about three things when they read a finding — exposure, cost, and probability. Write to all three.
- Correction — the "what now." The recommendation should be practical, achievable, and directly aligned with the root cause you identified — not the symptom. Just as important: recommend direction, not prescription. Your job is to point toward the destination and let management choose the path, unless a specific regulation dictates otherwise. Prescribing an exact solution risks being wrong about what fits the organization, and it tends to create resistance rather than buy-in.
The real fix happens before the report is even written Here's the part most audit training never covers: by the time a finding reaches the final report, most of the damage — or most of the trust — has already been built or lost.
Early in my career, a Director of Internal Audit I worked under introduced our team to a practice that changed how I audit more than any framework or certification I've studied since. Instead of conducting fieldwork in silence and presenting management with a finished report they'd never seen, we shared each finding as we found it — before anything was finalized, before management had any reason to feel ambushed.
We called it a Fact Sheet: a one-page working document capturing a single finding in draft form, walked through with the auditee during fieldwork. Management reviews it element by element — Criteria, Condition, Consequence, and a draft Correction — and signs off on each one, or raises a disagreement while it's still small and manageable. The root Cause is deliberately left out of that conversation, since it's the auditor's analytical conclusion, not something to negotiate.
The philosophy behind it is simple: the traditional approach treats management as the audience for a verdict. The Fact Sheet approach treats management as a partner in producing the finding. And a partner who helped shape a finding is far more likely to accept it — and act on it — than someone who's reading it for the first time in a formal report.
Even with a well-run Fact Sheet process, pushback happens. Three scenarios come up more than any others:
- "We already fixed that." Verify it. If the remediation is genuine and documented, keep the finding in the report anyway, and give management credit for the proactive fix. It protects the integrity of the audit record and rewards honesty in future audits.
- "Your sample wasn't representative." Take it seriously and ask for specifics. If an expanded sample confirms the original finding, issue a new Fact Sheet rather than quietly editing the old one — a finding that survives a methodology challenge is stronger for having survived it.
- "This isn't a real risk to us." Acknowledge the organization's track record, then reframe: the question isn't whether an incident has happened, it's whether the current control would prevent or detect one if it did. Let the applicable regulation do some of the work — most don't require an actual breach for a compliance gap to exist.
The bridge only works if every span is complete A finding that's missing its Criteria is just an opinion. One missing its Cause fixes a symptom that will return. One missing its Consequence gets filed and forgotten. And a finding management never saw coming, in any form, before the final report — however well-written — starts the conversation as a dispute instead of a discussion.
Rejection isn't usually a sign the underlying audit work was wrong. It's almost always a sign that one of these pieces was missing.
This post covers the framework. The course, "Audit Findings That Land," goes further — including how to actually run the Fact Sheet meeting and handle real-time pushback when it happens.