Follow-Up — Retest of a Prior Finding

Pattern

A past audit already wrote up a finding with a baseline number and a fix that management promised. Now it's time to check the fix actually happened. "Management says it's fixed" isn't evidence — the retest needs to compare against the exact baseline from the original finding.

Common thread

The test ties back to one already-documented finding. It isn't exploratory — it exists to determine whether the particular line item can be closed or should stay open.

Where this shows up

Orders missing approval signatures, retested against the original finding rate
Dormant accounts with active access, retested against the original count
Late vendor payments, retested against the baseline in the finding
Backup restoration failures, retested against the rate first reported

Worked example

Does the retest support closing the defect-rate finding, or should it stay open?

A prior audit cycle logged a finding: defect rate on a key production line was running high, averaging 0.24, and flagged as a quality risk. Management's remediation plan was a switch to a new component supplier, expected to bring the rate down. This cycle, the auditor's job isn't to explore whether something changed — it's to retest specifically against the 0.24 baseline already on record and decide whether the finding can close.

The quality team reports the average has since dropped to 0.20 and is confident the fix worked. Before writing that into the follow-up report, the auditor pulls fifteen batch defect rates from before the supplier switch and fifteen from after, and runs both sets through the tool.

Data

Defect rate — finding baseline (data0)
0.18
0.36
0.15
0.27
0.22
0.41
0.16
0.28
0.12
0.25
0.19
0.24
0.38
0.15
0.28

Defect rate — after supplier switch (data1)
0.17
0.35
0.01
0.25
0.22
0.01
0.16
0.28
0.12
0.25
0.19
0.24
0.38
0.15
0.28

What the tool returned

The auditor pastes the finding's original baseline batches alongside the post-remediation batches and runs the analysis. The following result came back:

Analyser

🔍

Before the change (data0), the metric averaged 0.24, typically ranging between 0.1 and 0.4. Since the change (data1), it now averages 0.20. With 94% confidence the true figure sits between 0.1 and 0.3. Results are mixed — 78.1% of samples point to a decrease and 6.5% point to an increase. 15.5% of effects fall in the negligible-effect zone. The evidence is not yet good enough to draw a firm conclusion.

Size of the change

−0.038

Verdict

Inconclusive

Model: Normal (auto-detected) n₀ = 15 · n₁ = 15 · ESS = 429

Audit conclusion

The defect rate did drop from the 0.24 baseline to 0.20, and management is already crediting the new supplier. But retesting the fifteen baseline batches against the fifteen post-switch batches shows the data is too noisy to back that up.

So the finding stays open, logged as inconclusive rather than closed. It shouldn't be reported as evidence that the supplier change fixed the defect problem. The recommendation is to keep collecting batch data and reverify at the next cycle before recommending closure.

Tool usage benefits

It's tempting to close a finding the moment the average moves the right direction. ChangeVerifier stops that from happening too early: it shows the real split between decrease, increase, and negligible-effect samples, and calls the retest inconclusive instead of letting a good-looking average close a finding it can't yet support. The same retest, run against the same baseline, is what eventually lets the finding close with confidence — or stay open with a documented reason why.