An audit finding is not a corrective action

The last page of most audit reports is a table. Finding on the left, recommendation in the middle, management comment on the right. Six months later, someone opens the table to check progress and finds that half the recommendations were copied straight into a project plan, a quarter were marked complete because a meeting happened, and the rest have an owner who no longer works there.

The problem is not lazy follow-up. It is that the table treats two different things as one. A finding is a statement of fact, made by the reviewer, about the gap between what is and what should be. A corrective action is a decision, made by management, about what to do. They have different authors, different evidence and different tests of completion. When they are blurred, the organisation loses both the independence of the finding and the ownership of the fix.

Cedarberg Logistics is fictional, and its systems and figures are illustrative. Its technology health check, described in Part 1, produced 14 findings. This part follows the first of them, the missing alert for silent temperature probes, from finding to closure, and one that went wrong.

The anatomy of a finding

A well-formed finding has four parts, the conventional structure used in internal audit and assurance work.

• Condition: what the reviewer found. No alert fired when a trailer probe stopped sending readings for three hours.
• Criteria: what should have been true, and the source of that expectation. The customer service level requires a reading every five minutes, and Cedarberg's own operating procedure says excursions are escalated within fifteen minutes.
• Cause: why the condition exists, stated only as far as the evidence goes. The alert configuration export showed rules for high and low temperature but none for missing data.
• Effect: why it matters. The consignment could not be evidenced, and the customer's claim could not be contested.

Notice how narrow the cause is. The reviewer saw the configuration and could say that no rule existed. The reviewer did not know why: whether the rule was never specified, was specified and forgotten, or was removed during a vendor upgrade. A report that wrote "the cause was inadequate vendor management" would have been claiming more than the evidence showed, and it would have pointed management at the wrong fix.

Unsupported root-cause claims are one of the commonest weaknesses in audit reports. They read as insight and they are often wrong. The honest form is to state the proximate cause the evidence supports and, where the deeper cause matters, to say that management should establish it.

Why the reviewer should not write the fix

It is tempting, and often requested, for the reviewer to go one step further and specify the solution. They know the problem well, and management is busy. There are three reasons to resist.

Independence. A reviewer who designs the corrective action will later review whether that action worked. They are now assessing their own design, which is the conflict the independence ladder in Part 4 exists to avoid.

Context. Management knows constraints the reviewer does not: budget already committed, a vendor contract under renegotiation, a team about to be reorganised. The best fix for the finding may not be the obvious technical one.

Ownership. An action designed by someone else is easy to treat as someone else's problem. An action management chose is one it has to stand behind.

A reviewer can and should say what a satisfactory outcome looks like, for example "missing readings are detected and escalated within the service-level window". That is a restatement of the criteria, not a design. How Cedarberg achieves it is management's call.

Management's three honest responses

For each finding, management chooses one of three responses, and all three are legitimate.

1. Accept and act. Management agrees with the finding and commits to a corrective action.
2. Accept the risk. Management agrees with the finding but decides not to act, because the cost outweighs the exposure or another change will remove it. This must be made by someone with the authority to accept that level of risk, recorded with a reason and a review date.
3. Dispute. Management disagrees with the condition or the criteria and provides evidence. A reviewer who has done the work well should welcome this; occasionally the evidence changes the finding.

What is not a response is silence, or a comment such as "noted". Cedarberg's board asked for every one of the 14 findings to carry an explicit choice within 30 days.

What a corrective action needs

A corrective action is a small project with a definition of done. At minimum it needs:

Two fields do most of the work. Closure evidence turns "done" from an opinion into something a follow-up review can test. Addresses forces the question of whether the action fixes the cause or just the instance. Cedarberg's first version said "investigate the disputed consignment", which would have closed the claim and left every other trailer exposed.

From finding to closure

The two lanes show the division of labour. The reviewer issues the finding and, later, verifies closure. Management owns everything in between: the response, the plan, the owner, the date and the work, and keeps the evidence that the work was done. The follow-up review does not ask "is it complete?". It asks to see the closure evidence and, where it matters, re-runs the test.

When the lanes break

Finding 1 closed cleanly. Another did not. A finding about undocumented administrator access to the warehouse system was accepted, given an owner and a date, and then stalled. The owner moved roles in a reorganisation, nobody inherited the action, and the status report kept saying "in progress" because nobody updated it. The assurance review in Part 4 found it overdue with no owner.

Three changes fixed the pattern rather than just that action. Actions are owned by a role as well as a name, so a move triggers a handover. The action register is reviewed monthly by the executive who owns technology risk, not only by the project office. And status is backed by evidence at each review, so "in progress" has to show what has been done.

Bringing the series together

This series has argued that a technology audit is most useful when it examines systems rather than people (Part 1), reads gaps across every dimension and admits what it does not know (Part 2), rests on a repository that is managed rather than stored (Part 3), scales its independence and scope to the decision (Part 4), feeds evidence into the next procurement (Part 5), and keeps findings and fixes in separate hands. Together, those habits turn an audit from an event people survive into a control the organisation runs.

Back to the start: Part 1, A technology audit is a system health check. All parts are on the series page.

How CloudNala can help

We write findings that state condition, criteria, cause and effect only as far as the evidence supports, and we help management teams turn them into owned corrective actions with closure evidence and honest risk acceptance where action is not justified. Follow-up reviews test that evidence rather than status reports, so a closed action means the gap is actually closed.

Work with CloudNala

CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.

Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.

Book a Technology Health Check or write to us at consult@cloudnala.co.za