How to write an audit finding someone can act on

Write the finding so another person can identify the applicable requirement, retrieve the evidence and understand the specific gap. Keep the conclusion within what you actually checked. “The approval process is ineffective” gives a process owner much less to investigate than a bounded statement about reports released before their required approval.

This article is for UAE quality managers and internal management-system auditors preparing a nonconformity record. It offers a completed fictional example and a way to challenge it before issue. It is not financial-statement audit guidance, a UAE legal rule or a substitute for the criteria governing a certification audit.

The ISO 9001 Auditing Practices Group’s educational paper on documenting nonconformities identifies three components: supporting evidence, the applicable requirement and a clear statement of the gap. It explains that a requirement can come from an organisation’s own management system, among other sources. Its emphasis is on information the audited organisation can locate and verify. Source 1

The APG website expressly says its papers are not specified requirements or criteria every auditor must follow. Use the paper as guidance; establish your actual audit criterion separately. Source 2

For the example below, that criterion is an invented internal release procedure. No ISO clause is quoted or claimed to require this particular workflow. In your own record, verify which approved document version applied on the event date, which activities it covered and whether an exception route existed. A newer rule cannot automatically be applied to an earlier event.

All organisations, identifiers, dates, records and results in this example are invented. They demonstrate drafting and checking; no audit was performed.

A fictional service company’s procedure RP-04, revision 3, effective 1 September 2026, requires a technical lead to approve each final service report in the release system before it is emailed to a customer. In this scenario it applies to all final reports, including urgent work, and permits no alternative approval route.

On 14 October, the fictional auditor examines 12 reports selected from 60 September releases because the 12 were marked urgent. This is a targeted selection, not a representative sample of all 60. Nine show approval before sending. Three show the opposite sequence, with the same final file version recorded in both systems:

• SR-217, 8 September: customer email at 09:10; first approval at 11:40. Approval followed release by 2 hours 30 minutes.
• SR-224, 15 September: customer email at 14:05; first approval at 16:20. Approval followed release by 2 hours 15 minutes.
• SR-231, 22 September: customer email at 08:30; first approval at 09:00. Approval followed release by 30 minutes.

All times are Dubai local time on the stated date. The scenario assumes the system clock settings, report versions and event meanings have been checked. “Approval time” means the actual approval event, not a later synchronisation or export time. The corresponding records are fictional evidence references E1, E2 and E3; none are downloadable client records.

Finding reference: NC-2026-014. Process: final service-report release. Scope: the 12 urgent September reports selected for this review.

Criterion: RP-04 revision 3, section 4.2, as summarised above. The fictional controlled copy and its effective date were checked against the three release dates.

Evidence: E1 links SR-217’s final file to its customer-email event and approval history. E2 and E3 do the same for SR-224 and SR-231. In the scenario, the process owner confirms that these were customer releases and supplies no earlier approval event or applicable exception. The nine other selected reports show the required sequence.

Statement of nonconformity: “The required technical-lead approval before customer release was not met for three of the 12 urgent September service reports examined: SR-217, SR-224 and SR-231. For each, the recorded approval occurred after the final report was emailed, contrary to RP-04 revision 3, section 4.2.”

Boundary: The record establishes the specified timing failures in those three cases under the scenario assumptions. It does not establish that the reports were technically wrong, that every release route failed, or why the sequence was reversed.

Follow-up ownership: The service-quality manager is assigned to assess the affected releases and investigate the cause through the company’s corrective-action process. A response date and any immediate controls must be set through the organisation’s authorised process. They are not invented universal deadlines.

That record gives the owner a defined issue to investigate without inserting an untested cause or a predetermined solution.

Before issuing your own record, try to overturn the conclusion. In this example, three checks matter particularly.

Was the event really a customer release? An internal draft circulated for comment would not meet the example’s definition of final customer release. Match the recipient, file version and event type. A file’s creation date alone does not prove when it was sent.

Was approval really late? Suppose a reliable event log showed SR-224 was approved at 13:50, while 16:20 was only the upload time. The finding must change. Two of the 12 selected reports would remain exceptions; SR-224 would be removed from the exception list and the correction recorded. Do not retain the original count because the report has already been drafted.

Did the rule allow another route? If the actual procedure permitted a named delegate’s approval by another channel, check that evidence and its timing before alleging nonconformity. A genuine authorised exception can change the conclusion. An informal explanation that urgent work “usually goes out first” cannot, by itself, create an exception to the fictional rule above.

If the relevant archive is inaccessible, describe the unresolved evidence limitation and obtain suitable alternative evidence. Do not convert “I could not access the approval history” into “no approval occurred.” A separate record-retention or access finding would need its own applicable criterion and supporting evidence.

Three of 12 is 25% of the selected urgent reports. It is not a demonstrated 25% failure rate across all 60 September releases. The selection favoured a particular condition, and the other 48 were not examined. In the alternative timeline above, two of 12 is 16.7%, rounded to one decimal place; the same boundary still applies.

Neither percentage decides whether the finding is major or minor. Use the classification rules applicable to your audit and document the reason; this example deliberately assigns no universal severity label. A single serious failure can matter, while a larger count can still leave important questions about extent and consequence unanswered.

For the separate task of establishing the population and selection method, see why your audit sample can miss records. Here the task is to make one finding accurate enough to act on, not to prescribe a sampling plan.

Use the completed example as a drafting pattern, replacing every fictional field with your own verified information. Retain the criterion and revision, scope, record identifiers, evidence location, relevant dates, statement, unresolved limitations and responsible owner in your approved audit record. Restrict access to sensitive customer or employee information; do not paste it into public templates or unapproved AI tools.

Write a potential consequence as a possibility unless you have evidence that it occurred. In this example, release before approval could allow an unchecked report to reach a customer. The supplied facts do not establish an incorrect report, customer loss or deliberate misconduct. Likewise, “staff need training” is a proposed explanation or action, not a cause demonstrated by these timestamps.

Keep the finding separate from the later action and closure decision. A late approval added after release does not change the historical sequence. Once the owner proposes corrective action, check effectiveness before closure rather than treating a completed task as proof the cause has been resolved.

Before issue, ask a colleague to use the record to locate each event and challenge the link to the criterion. If they need to guess which report, rule or time you meant, revise the record. The useful outcome is a finding that can be investigated and challenged on evidence, with a clear boundary around what remains unknown.

1 — ISO 9001 Auditing Practices Group, Nonconformity Documenting, edition 1, 13 January 2016, pages 1–2 and disclaimer on page 4. 2 — APG guidance and disclaimer. Both read on 16 October 2026. The older paper remains available through the current APG site; this article does not treat it as a newly issued standard or binding requirement.

Worked record, timing tests and interpretation: original QSE Advisory editorial analysis using fictional inputs, prepared with AI assistance. Publisher and author: QSE Advisory, office@qseadvisory.com.

Spotted an issue? Contact our editorial desk.