Module 06 · Core module

Issue validation

This is the deepest module in the training, because it is where your judgment is most exposed. Everything before this produces raw material; issue validation is where you decide what is real, how serious it is, whether management's answer is good enough, and when it is genuinely fixed. Every one of those decisions is yours, and every one of them can be challenged.

What "validation" covers

The word gets used for two distinct activities and conflating them causes real confusion in a team. Be explicit about which one you mean:

Issue validation (at raising)

Deciding whether an observed exception is a legitimate finding: is the evidence sufficient, is the criteria real, is the condition accurately described, is the cause understood, and does the effect justify raising it?

Closure validation (at remediation)

Deciding whether management's completed action actually fixed the thing: is there evidence the new control exists and operates, and does it address the cause rather than the symptom?

This module walks the full life: exception → finding → severity → response → remediation → closure → quality review.

Stage 1 — Evidence review

Before anything else, the evidence has to hold. A finding built on weak evidence will collapse at exactly the worst moment — in front of the process owner's manager, or in front of the committee. Five tests:

Test	The question	Common failure
Sufficiency	Is there enough of it to support the conclusion?	One exception in a sample of 40, described as systemic
Reliability	Where did it come from, and how much do we trust that source?	A figure verbally confirmed by the process owner, never inspected
Relevance	Does it actually speak to the control being tested?	Evidence of the payment, not of the approval
Completeness and accuracy	If it came from a system report, has the report itself been validated?	Testing a review of a report nobody proved was complete
Period coverage	Does it cover the period under review?	Sample drawn entirely from one quarter, conclusion drawn for the year

Run every piece of evidence through these five before you accept the conclusion:

Sufficient — enough of it to support the conclusion drawn
Reliable — from a source strong enough for the weight placed on it
Relevant — speaks to the control tested, not an adjacent activity
Complete and accurate — if system-generated, the report itself is validated
Covers the period — not one quarter used to conclude on a year

The reliability hierarchy

Not all evidence is equal. In descending order of strength:

Auditor re-performance — you did the control yourself and compared the result
Direct external confirmation — obtained by you from an independent third party
System-generated record whose completeness and accuracy you established
Auditor observation — you watched it happen (but only proves it happened while watched)
Internal documentation provided by the auditee
Inquiry — what someone told you. On its own, this supports nothing.

Worked example — evidence sufficiency

A junior tests a monthly management review control. The workpaper contains one signed review sheet from March and a note that "the owner confirmed this is performed every month".

Your review point: one month is not a monthly control tested across a year, and the rest is inquiry. Ask for the sample per methodology, and for evidence of what the reviewer actually compared — a signature alone does not show the review happened.

Worked example — evidence sufficiency (banking)

Testing the daily nostro reconciliation control. The junior obtains five reconciliations, all signed by the preparer and the reviewer, and concludes the control is effective.

Your review point: signatures show the form was completed, not that breaks were investigated. Ask for reconciliations that actually contained ageing breaks and evidence of what was done about them. A control that only ever gets tested on clean days has not been tested.

Worked example — evidence sufficiency (insurance)

Testing the claims authority-limit control. The junior inspects ten claims all settled within the handler's limit and concludes the control operates.

Your review point: the sample only demonstrates that in-limit claims were in limit — it says nothing about whether an over-limit claim would be stopped. Ask for evidence of claims that exceeded the limit and the referral that followed, or for a test of the system configuration that enforces it.

Worked example — evidence sufficiency (healthcare)

Testing access controls over patient records. The junior obtains a current user list, confirms it looks reasonable with the system owner, and concludes access is appropriate.

Your review point: a point-in-time list plus inquiry proves nothing about the period. Ask for evidence of the periodic access review — who performed it, what they compared the list against, and what happened to the accounts they challenged. Also establish that the user list itself is complete.

Worked example — evidence sufficiency (technology)

Testing the change-approval control. The junior exports 20 changes from the pipeline, sees an approver recorded on each, and concludes the control is effective.

Your review point: two gaps. First, is the export complete — could a change have reached production without appearing in it? Second, can the approver be the same person as the author? Test the configuration, not just the field.

Inquiry alone is never sufficient

If the only support for a conclusion — positive or negative — is that someone said so, there is no conclusion yet. This applies to clean results as much as to findings. A junior who concludes "control operating effectively" because the owner said they perform it monthly has documented a conversation, not a test. Check for this pattern specifically; it is common and it is the kind of thing external assessors find.

Stage 2 — Finding validation

A finding is not "something we noticed". It is a structured argument with five required elements. If any one is missing, it is not ready to leave your department.

Element	Answers	Test of quality
Criteria	What should be happening?	Cite the actual policy, regulation, contract clause or control design. "Best practice" is not criteria.
Condition	What is actually happening?	Factual, quantified, no adjectives. "7 of 25 payments over $50k lacked secondary approval."
Cause	Why is it happening?	The real reason, not a restatement of the condition. Ask why until you hit something that can be fixed.
Effect	What is the consequence?	Actual or potential, quantified where possible. This drives severity.
Recommendation	What should change?	Addresses the cause, not the symptom. Specific enough to be actionable, not so specific you are designing their process for them.

Every finding must have all five. Missing one means it is not ready to leave the department:

Criteria — a citable policy, regulation, contract or control design
Condition — quantified fact, no adjectives, population and sample stated
Cause — survives three "why"s and points at something fixable
Effect — actual or potential consequence, sized where possible
Recommendation — targets the cause, states the outcome required, does not design their process

In plain terms

A finding is an argument, and it has to answer five questions in order: what were they supposed to do, what did they actually do, why did that happen, why does it matter, and what needs to change. If you cannot answer all five in one sentence each, you do not have a finding yet — you have something you noticed.

Cause is where most findings are weak

"Secondary approvals were not obtained" is a condition, not a cause. Keep asking:

Condition: 7 of 25 high-value payments lacked secondary approval.

Why? They were processed by the overnight batch team.

Why? The overnight team uses an emergency workflow that bypasses the second approver.

Why? The emergency workflow was built for system-outage scenarios and never restricted afterwards.

Cause: An emergency bypass workflow, designed for outages, is available for routine overnight processing with no restriction or after-the-fact review.

Note what this changes: a recommendation aimed at the first answer would be "remind staff to obtain approvals". Aimed at the real cause, it is "restrict the emergency workflow and require after-the-fact review of every use". The second one actually fixes it.

The tests before you accept a draft finding

Criteria is citable, and you have read the source — not a paraphrase from the auditee
Condition is quantified and factually correct
The population and sample basis are stated
Cause survives at least three "why"s
Effect is plausible and, where possible, sized
Evidence is attached to the record, not sitting on a laptop
The process owner has confirmed the facts — facts, not the rating
You could defend every sentence of it to a hostile reader

Validate facts with the business before issuing

Factual accuracy confirmation is not negotiation, and the distinction must be explicit to your team. You are asking "is it true that 7 of 25 lacked approval?" You are not asking "do you agree this is a high?" Blur the two and the business learns that ratings are negotiable — a precedent that takes years to undo.

Stage 3 — Severity classification

The most challenged decision you will make. Severity has to be reproducible: two competent auditors applying your methodology to the same facts should land in the same place. Six factors drive it:

Factor	Raises severity when…
Magnitude of effect	Financial, operational, regulatory or reputational impact is large in the organization's terms
Likelihood / pervasiveness	The failure is systemic rather than isolated; high exception rate; affects the whole population
Regulatory exposure	Failure is reportable, breaches a legal obligation, or attracts penalty regardless of amount
Compensating controls	There are none, or the ones claimed do not detect this specific failure
Duration and detection	It has persisted for a long time undetected — a detection failure on top of a control failure
Repeat status	Previously raised and either not remediated or remediated ineffectively. This is an escalation on its own.

A working severity scale

Rating	Meaning	Typical characteristics	Escalation
High	Requires immediate senior attention	Material impact plausible; systemic; regulatory breach; no compensating control; or a repeat of a prior high	Audit committee, named in report, tracked to closure individually
Medium	Requires timely correction	Meaningful but contained impact; partial compensating control; not pervasive	Senior management; summarized to committee
Low	Improvement opportunity	Limited impact; isolated; effective compensating control exists	Process owner; aggregate reporting only

Worked example — severity

Three of forty purchase orders above the approval threshold were released without the second approval. No loss occurred. The bypass has existed for at least two years.

Working it through: effect is moderate and no loss crystallised — but the failure is systemic rather than isolated, no compensating control detected it, and it ran undetected for two years. Duration plus absence of detection carries this above the "no harm done" reading. Medium at minimum, and High if the threshold protects a regulatory obligation.

Worked example — severity (banking)

Seven of twenty-five payments above the dual-authorization threshold were released by the overnight team using an emergency workflow. All seven were legitimate. The workflow has been available for routine use since a system migration eighteen months ago.

Working it through: no loss, but a dual-authorization control over outbound payments is precisely the control that prevents fraud, it failed systemically, nothing detected it for eighteen months, and payment controls typically sit inside regulatory expectations. High — the absence of loss is luck, not control.

Worked example — severity (insurance)

Reserve adjustments above the delegated limit were posted by two handlers without the required actuarial sign-off in four of thirty cases. The amounts were individually small but the practice appears routine in one team.

Working it through: individually immaterial, but reserves feed financial reporting and regulatory returns. Pervasiveness within a team plus a reporting linkage raises it. Medium, escalating to High if the aggregate is material to the reserve balance or the pattern extends beyond that team — which is the next thing to test.

Worked example — severity (healthcare)

Nine terminated employees retained active access to systems containing patient data for between three weeks and four months after leaving. No evidence of access after termination was found in the logs reviewed.

Working it through: the absence of misuse in the logs you reviewed is reassuring but not decisive. Retained access to patient data is a reportable exposure in most regimes regardless of whether it was used, it recurred nine times, and the joiners- movers-leavers process failed to detect it. High — regulatory exposure does not scale with the amount involved.

Worked example — severity (technology)

Six of thirty production deployments were self-approved by the engineer who wrote the change. All six were routine, and the platform has automated rollback.

Working it through: automated rollback is a genuine compensating control and it does reduce the effect — say so explicitly in the finding. But segregation between author and approver is the control, it failed in a fifth of the sample, and rollback addresses availability rather than unauthorized change. Medium, and note the compensating control in the rationale so the rating is defensible when challenged.

Severity drift

The most common quality problem in an audit function, and it is a leadership failure rather than an auditor one. It happens two ways: inflation, where everything becomes high so the committee stops distinguishing; and deflation, where sustained pushback quietly softens ratings over a year. Both are invisible from inside a single engagement. Test for it by periodically re-reading last year's highs and asking whether you would rate them the same today.

Stage 4 — Management responses

The response is management's commitment, but its adequacy is your call. A weak response accepted today is a repeat finding twelve months from now — with your name on both.

What an adequate response contains

Acceptance or a documented disagreement — ambiguity is not an answer
Specific actions — what will actually change, in verifiable terms
A named owner — a person with authority to deliver, not a department
A committed date — proportionate to severity
Treatment of the cause, not just the instances found
Interim mitigation where the fix is long-dated and the risk is high

In plain terms

Management tells you what they are going to do about it. You decide whether that is good enough. If their answer would not stop the same thing happening again, it is not good enough — no matter how senior the person who wrote it.

Responses to push back on

Response	Why it fails	What to ask for
"Staff have been reminded of the procedure"	Training as a control for a design failure. Fixes nothing structural.	What changes so this cannot recur, or is detected if it does?
"This will be addressed by the ERP programme in 2028"	Ties your issue to a programme you do not control, on a horizon beyond your visibility.	Interim mitigation with a near-term date, and the programme dependency noted separately.
"Management accepts the risk"	May be legitimate — but only from someone with the authority to accept it, on the record.	Formal risk acceptance, at the right level, with an expiry date and committee visibility.
"The exceptions were corrected"	Fixes the seven items you found; leaves the cause untouched.	What stops the eighth?
"We disagree" with no alternative	Leaves the risk unaddressed and undocumented.	Documented disagreement, with management's rationale recorded and escalated per methodology.
An action plan with no owner or no date	Untrackable by definition. It will not close.	Both, before you accept it.

Worked example — testing a response

"The process has been reinforced with the team and a reminder has been added to the monthly checklist. Owner: Operations Manager. Date: next quarter."

Not adequate. A reminder on a checklist is the same manual control that already failed, with a note attached. Ask: what detects it if someone skips it again? Push for a system restriction or an exception report reviewed by someone independent.

Worked example — testing a response (banking)

"The overnight team has been instructed to stop using the emergency payment workflow for routine processing. Owner: Head of Payment Operations. Date: immediate."

Not adequate on its own. The instruction addresses behavior; the cause is that the workflow is available at all. Ask for the access restriction, plus an after-the-fact review of every emergency use — so if it is invoked legitimately during a genuine outage, someone independent still sees it.

Worked example — testing a response (insurance)

"The four reserve adjustments have been reviewed retrospectively by the actuarial team and confirmed appropriate. Owner: Claims Director. Date: complete."

Not adequate. This corrects the four you found. It does nothing about the fifth. Ask what enforces the delegated limit going forward — a system block at the point of posting, or a report of all above-limit adjustments reviewed monthly.

Worked example — testing a response (healthcare)

"The nine accounts have been disabled and HR has been reminded to notify IT of leavers. Owner: IT Service Manager. Date: complete."

Not adequate. Two problems: it fixes the nine instances, and the fix for the cause is a reminder to a different department. Ask for an automated feed from the HR system to access management, or at minimum a monthly reconciliation of active accounts to active employees, owned by someone with authority over both.

Worked example — testing a response (technology)

"We will add a policy requiring a second reviewer on all production changes. Owner: Engineering Lead. Date: end of next sprint."

Close, but test it. A policy is a statement of intent; the control is whether the pipeline enforces it. Ask whether the branch protection rule will block self-approval, and whether anyone retains a bypass. If bypass exists for incidents — which is reasonable — ask what reviews its use.

Disagreement is a legitimate outcome

You are not required to negotiate until management agrees. If they will not accept the finding, the professional answer is a documented disagreement — their position recorded, your position unchanged, escalated per methodology and visible to the committee. What you must never do is soften the finding to manufacture agreement. That is the failure that ends audit's independence, and it happens one small compromise at a time.

Stage 5 — Remediation and closure validation

Closure is the second validation, and it deserves the same rigour as the first. "Management says it is done" is inquiry — and inquiry alone is never sufficient.

Re-read the original finding. Not the action plan — the finding. What was the cause? That is what closure has to address.
Obtain evidence of the new state. The revised procedure, the changed system configuration, the new report, the amended access list.
Test that it operates. A control that exists on paper and has never run is not remediated. Where the control has only just been implemented, test what instances exist and state the limitation.
Check it addresses the cause. If the cause was an unrestricted emergency workflow and the evidence is a training deck, it is not closed.
Consider whether the effect is actually reduced. Residual risk should now be at an acceptable level. If it is not, closure is premature regardless of what was delivered.
Record the conclusion and the evidence on the issue record, then transition the status yourself.

Valid closure

Cause addressed
Evidence of design and operation
Evidence attached to the record
Audit — not management — concluded
Residual risk acceptable

Invalid closure

Closed on management's assertion
Only the found instances corrected
Closed because the due date passed
Closed because the auditor rotated off
Closed to clear an overdue metric

The metric trap

Once "overdue issues" is reported to the committee, there is pressure — sometimes explicit, usually not — to make the number look better. Closures that happen near reporting dates deserve more scrutiny, not less. If you ever find yourself closing something to improve a chart, stop: that is the moment the function's credibility starts to go, and it is very hard to recover.

Stage 6 — Quality review

Before an issue leaves your department, and again before it is reported closed, run the same review. It takes ten minutes and it is what separates a function that survives external assessment from one that does not.

Criteria cited, verified at source, and current
Condition factual, quantified, population and sample stated
Cause is genuinely causal and fixable
Effect sized or clearly reasoned
Severity matches the methodology and is consistent with comparable issues this year
Recommendation addresses the cause and is actionable
Response has substance, a named owner and a date
Evidence complete, attached, and named to convention
Cross-references set: control, engagement, risk
Review trail visible — reviewer, date, review notes and their resolution
Writing is defensible to a hostile reader with no context

Archer refresher

Issues in Archer, end to end

The record shape

Field group	Typical contents	Watch for
Identification	Issue ID, title, source (audit, self-identified, regulatory), engagement link	Source drives reporting splits — get it right at creation
Description	Condition, criteria, cause, effect, recommendation	Use the discrete fields, not one narrative blob — reporting depends on them
Assessment	Severity/rating, risk theme, impacted process, business unit	Often drives calculated due dates and escalation routing
Ownership	Issue owner, action owner, audit contact	Owner field usually drives record permissions and notifications
Response	Management response, action plan, agreed date, revised date(s)	Original vs. revised date is what "date slippage" reporting is built on — never overwrite the original
Remediation	Status, evidence attachments, validation conclusion, closure date	Validation conclusion is your field, not management's
Links	Control, risk, engagement, prior related issues	Drives repeat-issue and thematic reporting

Typical status path

Draft → Pending Audit Review → Issued to Management → Response Received → Remediation In Progress → Pending Validation → Closed

Two states matter disproportionately. Issued to Management usually locks the finding text — get it right before you transition. Pending Validation is your queue: everything sitting there is waiting on you, and it is the queue that quietly grows.

Reports to have running

Open issues by severity and age
Issues past agreed date, by owner
Issues where the date has been revised more than once
Issues awaiting my validation, oldest first
Repeat issues — linked to a prior issue in the same process
Closed in the last 90 days, for QA sampling

Audit leader perspective

Holding the line

The conversation you will have most often

A process owner asks for a high to be reduced to a medium. Handle it the same way every time:

Separate facts from rating. "Are the facts wrong, or do you disagree with the rating applied to correct facts?" These have completely different answers.
If the facts are wrong — stop, correct them, and thank them properly. You want people telling you when you are wrong.
If the facts stand — walk them through the methodology. Not your opinion; the criteria the organization agreed to.
Ask what they know that you do not. A genuine compensating control you missed changes the rating legitimately. Ask for the evidence, and test it.
If nothing changes, nothing changes. "I understand your position, and I'll record it in the response. The rating stands." Then record their disagreement properly — it is part of the story the committee should see.

What you must decide personally

Whether a finding is raised at all
The severity rating
Whether a management response is adequate
Whether an issue is closed
Whether an issue is a repeat
What goes into the committee report

Your six juniors draft all of these. None of them decide any of them. Be explicit about that split — it is not a lack of trust, it is where the accountability sits, and saying so out loud prevents a lot of quiet resentment.

Consistency is your reputation

A committee's confidence rests on whether a "high" means the same thing in March and in November. Two habits protect that: keep a short internal file of rating precedents — the issue, the facts, the rating, the reasoning — and before finalizing any high, ask "what else did we rate high this year, and is this comparable?" It takes two minutes and it is the single best defence against drift.

When you are wrong, be visibly wrong

You will occasionally raise a finding that does not stand up. Withdraw it clearly, document why, and tell the process owner directly. A function that never withdraws anything is not more accurate — it is less honest, and everyone can tell.

Team management perspective

Getting six people to write defensible findings

The most common defects, and the coaching for each

Defect	What you will see	Coaching
Criteria is opinion	"Best practice suggests…"	"Show me the policy, the regulation, or the control design. If it does not exist, we have a design gap, not a compliance finding — and that is a different finding."
Condition has adjectives	"Approvals were frequently missing"	"Give me the number, the population and the basis. Adjectives get argued with; numbers do not."
Cause restates condition	"Cause: approvals were not obtained"	Ask why three times, out loud, with them. Do not write it for them.
Effect is boilerplate	"Could result in financial loss and reputational damage"	"How much? To whom? Under what circumstances? If we cannot answer, our severity is a guess."
Recommendation designs their process	Three paragraphs of system specification	"We say what outcome is required. They choose how. Otherwise we are auditing our own design next year."
Rating by feel	"It felt like a high"	Walk the methodology factors together, in order, every time until it is automatic.

Calibration: the highest-value hour you will run

Once a quarter, put three or four real findings — anonymized, from prior periods — in front of all six. Each rates independently, then you discuss the spread. You will discover that your team's understanding of "medium" varies more than you expected. This is the cheapest possible way to find that out, and the discussion teaches more than any methodology document.

Protect them from the pushback

A junior auditor should not be alone in a room with a senior stakeholder defending a rating. They do not have the standing, and losing that argument badly damages their willingness to raise the next finding. Your rules:

Juniors confirm facts with process owners — that is appropriate and useful
Rating discussions involve you, always
Escalations come to you the moment they start, not after they have gone badly
You back your team publicly, and correct them privately

Distributing validation work

Closure validation is genuinely delegable — a junior can obtain and inspect the evidence, test the new control, and draft the conclusion. What they cannot do is make the closure decision or transition the record. Set that split explicitly, or you will find issues closed by people who did not have the authority and did not know it.

The validation backlog

Closure validation is always the first thing to slip, because nothing external is chasing it — the auditee thinks it is done and has moved on. Put "issues awaiting my validation" on your dashboard and give it a standing slot every fortnight. A backlog here is invisible until the committee asks why nothing has closed all quarter.

Deep dive technical

Configuration, edge cases and hard calls

How severity should be derived, not asserted

Where possible, severity should be a calculated outcome of methodology inputs rather than a free choice. A typical configuration: impact and likelihood pick-lists drive a calculated rating via a lookup, with regulatory-breach and repeat-issue flags acting as overrides that escalate. The advantage is consistency across six auditors; the cost is that you need a documented, evidenced override path for the genuine exception. Both matter — a scale with no override forces people to game the inputs to reach the answer they know is right, which is worse than an honest override.

Date fields and what they reveal

Original agreed date — set once, never overwritten. This is the baseline for slippage reporting.
Current / revised date — the live commitment.
Extension count and rationale — the field that tells the real story. Two extensions on a high issue is a governance matter regardless of the reason given.
Validation date — when audit concluded, not when management asserted completion. Keep these distinct; conflating them destroys your ability to show how long validation actually takes.

If your instance overwrites the original date on extension, raise it with your administrator. Without the baseline you cannot demonstrate slippage, and slippage is one of the most informative things you can show a committee.

Repeat-issue detection

Repeat status materially escalates severity, so it needs to be reliable rather than dependent on someone's memory. Mechanisms, in order of robustness: a cross-reference to the prior issue (best), a linked control ID that appears on a previously closed issue, and a risk-theme or process tag that supports a "have we been here before" search. Whatever exists in your instance, make checking it a mandatory step before finalizing any rating — and note that a repeat is evidence of two failures: the original control, and the closure validation that let it through.

Aggregation and thematic issues

Five low findings across five business units, all with the same cause, may collectively be a high. The mechanics: raise the individual issues for local ownership, then raise a thematic issue cross-referenced to all five, owned at the level that can actually fix the common cause. Reporting on the theme rather than five separate lows is usually what makes a committee actually act. The trap is double-counting — be explicit in the report about which numbers include the thematic issue and which do not.

Hard cases worth thinking about before you meet them

The control changed mid-period

Test both states separately and conclude separately. A finding on the old control is still a finding — it governed real transactions — but severity should reflect that it has been superseded, and the report should say so.

Management fixes it during fieldwork

Still raise it. The exposure existed during the period. Note the remediation, validate it, and it may close on issue — but a finding that quietly vanishes because it was fixed quickly teaches the business the wrong lesson.

The cause sits outside the audited unit

Raise it against the owner who can fix it, not the unit where you found it. An issue owned by someone with no authority to remediate will not close, and everyone will be frustrated.

A single exception with severe effect

One instance can be a high. Pervasiveness is one factor among six, not a gate. A single unauthorized payment of material size is not a low because it happened once.

Evidence exists but you cannot access it

A scope limitation, and it is reportable in its own right. Do not conclude "effective" on evidence you did not see, and do not let it disappear into a workpaper note.

The auditee self-identified it first

Record the source accurately. Self-identified issues should be tracked and are a healthy sign — but they do not become lower severity because the business found them.

Sampling and projection

If a junior found 7 exceptions in 25 and writes "28% of payments lack approval", check the sampling basis before that sentence leaves the building. Statistical projection requires a statistically drawn sample. Judgmental samples — which is most audit sampling — support a statement about the sample and a qualitative conclusion about the population, not a projected rate. Getting this wrong in a committee paper is the kind of error a numerate committee member will catch, and it costs you disproportionately.

Quick reference

Issue validation card

Five elements of a finding

Element	Question
Criteria	What should be happening?
Condition	What is happening? (quantified)
Cause	Why? (three whys minimum)
Effect	So what? (sized)
Recommendation	What outcome is required?

Evidence tests

Sufficient
Reliable (inquiry alone is never enough)
Relevant to the control tested
Complete and accurate at source
Covers the period

Severity factors

Magnitude of effect
Pervasiveness
Regulatory exposure
Compensating controls
Duration undetected
Repeat status

Reject a response that lacks

A named owner
A committed date
Action addressing the cause
Interim mitigation if long-dated and high

Closure requires

Evidence of the new control's design
Evidence it has operated
The cause addressed, not just instances
Audit's conclusion, not management's assertion
Evidence attached to the record

Never

Close to improve a metric
Soften a rating to obtain agreement
Let a junior defend a rating alone
Project a judgmental sample statistically
Conclude on evidence you did not see