I documented 14 critical observations in a single engagement. The auditee looked at the draft report and told me clearly: he was not presenting 14 findings to management. Not because they were wrong. Because the number itself would reflect on his team before anyone read a single word. I held my position — no observation would be removed without remediation. What followed was a conversation about how to present the truth in a way that could actually be heard.
That conversation produced a technique I have used in every complex engagement since. But before the technique, the structure: the reason most IT audit findings don't drive change isn't the auditor's writing. It is three structural problems that exist in most organisations before the audit report arrives. Understanding them changes how you write every audit finding..
This article covers the structural reasons IT audit findings fail, the finding count psychology and how to manage it without compromising integrity, the ISACA ITAF framework gap that produces accurate but ignored findings, and five before/after rewrites of real ITGC observations.
Why Most Audit Findings Don't Drive Change
The most honest answer to why IT audit findings are ignored is not that management doesn't take security seriously. The real reasons are structural — built into how organisations make budget decisions, how they staff remediation, and how knowledge gets lost across management transitions. An auditor who understands these three patterns writes findings differently.
The Budget Problem
Information security controls prevent loss. They don't generate revenue. Management evaluates investment against monetary return — and the return on a security control is invisible when it works. The finding gets deferred to next year's budget cycle. Next year arrives. The finding is still open.
not just the control gap. A finding that quantifies what the risk costs the organisation makes the budget case management needs to act.
The Workforce Problem
The finding requires someone to implement the remediation. That person either doesn't exist in the organisation or is already at capacity running existing operations. The finding sits open because there is no one with both the authority and the competency to close it.
not just an instruction to fix something.
The Remediation Loop
The finding is logged. A remediation plan is submitted. Management changes — a new CIO, a new CISO, a new compliance head. The new management has no context for the finding. The next audit cycle begins. The previous remediation is still incomplete. The finding appears again. I have seen findings open for four consecutive audit cycles — not because management disagreed with the risk, but because the remediation plan required a budget approval that never came.
without the original auditor present to add context.
The Finding Count Problem
In the engagement that opened this article, I documented 14 critical observations. The auditee's position was not that the findings were wrong. His position was that presenting 14 findings to management would reflect on his team before a single word was read. His team had been operating the environment. Fourteen critical findings implied fourteen points of failure on their watch. Management would arrive at the report looking for accountability — not for a remediation plan.
My position was equally clear: no observation would be removed without evidence of remediation. The resolution was the clustered finding approach. Observations that share a root cause, a control domain, or a remediation owner represent a single control failure — not multiple failures. Clustering them is accurate representation, not dilution. The root cause is the observation. The sub-findings are the evidence. Fourteen observations became six findings with documented sub-points. The underlying evidence was preserved. The severity was preserved. The number changed. Management read the report. Three findings had remediation plans within 30 days.
The rule for clustering: findings that share a root cause become one finding with sub-points. Findings that share a remediation owner become one finding with documented instances. Findings with different root causes and different owners always remain separate. Finding count is a communication variable, not a quality variable. An audit with six well-clustered, well-evidenced findings will drive more remediation than an audit with 14 atomised findings that overwhelm the auditee and invite defensive responses.
14 atomised findings
- 14 individual user access findings across 4 systems — management response: methodology challenge
- 6 change management observations across 2 systems — auditors perceived as cataloguing rather than assessing
- 4 backup and recovery findings with different ownership — remediation path unclear, deferred indefinitely
6 clustered findings
- 1 finding: User access review controls insufficient across 4 systems — sub-points evidence each system, one remediation owner
- 1 finding: Change management lacks consistent pre-approval — 23 unapproved changes across 2 systems, root cause in shared process
- 1 finding: Backup and recovery presents 3 risk exposures — clustered by recovery impact, phased remediation recommended
The ISACA Framework — and What It Doesn't Tell You
The ISACA IT Audit Framework (ITAF) defines the structure every IT audit finding should follow: condition (what we found), criteria (what the standard requires), cause (why the gap exists), effect (what happens if it continues), and recommendation (what to do about it). The structure is correct. Following it exactly as taught still produces ignored findings. The gap is in how the effect is stated. For IT audit's connection to the broader ISMS control framework, see the ISO 27001 framework reference.
"Access controls are insufficient to prevent unauthorised access to critical systems." That is ITAF-correct. It is also ignored. Compare it to: "The current access control configuration allows any user with a valid domain credential to query the payment transaction database directly — including contractors and former employees whose accounts have not been deprovisioned. In the last 18 months, 847 transactions passed through this system. The audit cannot confirm that all query access during this period was authorised." That is also ITAF-correct. The first version is technically accurate in the same way that "the weather could improve" is technically accurate. The second version makes the decision-maker understand exactly what they are accepting if they defer remediation.
I have reviewed findings that were three paragraphs of passive voice about a control that allowed any authenticated user to export the entire customer database to a USB drive. The word "database" did not appear once. The right question is not "is this finding accurate?" It is "could the decision-maker who receives this finding explain, in their own words, what the risk is?" If the answer is no, the impact statement needs to be rewritten. The methodology is correct. The effect statement is where findings fail.
The finding that gets remediated is not the most accurate finding. It is the finding written in the language the decision-maker uses to think about risk.
Here is what the difference looks like in practice. Five real ITGC finding scenarios — weak version and the rewrite that makes it actionable.
Before/After: Five Finding Rewrites
User access reviews are not conducted quarterly as required by policy.
Quarterly user access reviews have not been completed for any of the 4 in-scope systems during the 12-month audit period. As of the review date, 147 active accounts exist across these systems, including 23 accounts belonging to former employees and 11 generic or shared accounts. No evidence of periodic review was produced. Without regular access reviews, unauthorised access by former employees or misuse of shared credentials cannot be detected or prevented.
Changes to production systems are not always approved before implementation.
Of 83 production changes reviewed during the audit period, 23 (28%) lacked documented pre-approval. Unapproved changes were identified across the core banking system and the customer portal. One unapproved change to an access control rule — implemented during the audit period — was not reviewed until identified during this assessment. The organisation cannot confirm the change was authorised or that it did not introduce a security vulnerability during the period it was active.
Backup restoration testing is not performed regularly.
The last documented backup restoration test for the core banking system was conducted 14 months ago. The organisation's stated Recovery Time Objective is 4 hours. No test has been conducted against current backup configurations to confirm this RTO is achievable. If a recovery event occurs and restoration fails or exceeds the RTO, the organisation faces extended system unavailability — the direct operational cost of which, based on transaction volumes processed, accumulates with each hour of downtime.
Segregation of duties conflicts exist in the ERP system.
17 users in the ERP system hold combined roles that allow them to both create and approve payment transactions without secondary review. This configuration allows a single user to initiate and complete an unauthorised payment with no second approver required. During the audit period, 4 of these 17 users processed transactions where both the initiation and the approval were recorded under the same user ID. The audit cannot confirm whether these transactions were legitimate without additional investigation.
Privileged account management requires improvement.
34 privileged accounts exist across in-scope systems. 12 are generic or shared accounts with no individual owner assigned. Privileged session activity logging is inconsistent — 3 systems do not log privileged sessions at all. A privileged account compromise on any of these systems provides direct access to customer data, payment infrastructure, and audit logs. The absence of session logging means that a compromise that has already occurred may not be detectable from existing records.
Writing for the Reader Who Wasn't in the Room
Every finding is written by someone who was in the assessment room — who saw the evidence, asked the follow-up questions, understood the context. That person will not always be present when the finding reaches the decision-maker. The finding will be read by a new compliance head who joined two months ago, by a board member who received the executive summary, by a regulator who requested the report as part of a supervisory review. The management response "accepted risk" to a segregation of duties finding is not a risk acceptance — it is a finding that was not written clearly enough to make the risk visible to the person who signed the acceptance.
Before signing off any finding, test it against the six questions below. If it cannot answer all six without verbal explanation, rewrite it. The same principle applies when defining the scope of what an audit covers — a clear scope statement that survives management transitions is the starting point for findings that do the same. See the ISO 27001 scope definition guide for the parallel in ISMS implementation work.
- Condition: Does the finding state clearly what was found — specific systems, accounts, or instances — not just what should have been found?
- Criteria: Is the control standard, policy requirement, or regulatory expectation referenced explicitly?
- Cause: Does the finding explain why the gap exists — not just that it exists?
- Effect: Could a decision-maker who was not in the assessment room explain the business risk, in their own words, after reading this finding alone?
- Recommendation: Is the recommended action specific — with a named owner and a defined timeframe — not just "management should strengthen controls"?
- Survival test: If the original auditor is unavailable, does the finding contain enough context to be understood, actioned, and followed up without them?
Tap each step as you prepare. Progress saves in your browser.
A finding that accurately describes the risk but cannot be understood without the auditor in the room has already failed — regardless of how correct it is.