How to write a remediation plan that can be tested

Define the problem without overstating it

Start each finding with the applicable requirement or agreed control, the evidence reviewed, the verified position and its significance. Distinguish a confirmed weakness from an unanswered question. Missing evidence does not automatically prove the event never happened; equally, a verbal assurance cannot establish that a required decision was made.

Assess the present risk as well as the historical fact. If a document was retrieved later, credit it and reconsider the finding. If a new check was performed, show what it now establishes without backdating it. If the concern is closed, say so clearly and remove obsolete requests from the active action list while retaining the audit trail.

Address the cause and the affected population

A single corrected file may fix an instance but not the underlying process. Ask why the issue occurred: unclear ownership, unsuitable configuration, inconsistent methodology, inaccessible records, insufficient capacity or weak review. Test the explanation against evidence rather than selecting a convenient root cause.

Define the population that may be affected and how it will be identified. Separate immediate protective action, changes to the control, correction of existing cases and subsequent assurance. Avoid prescribing a particular tool or organisational structure where a proportionate alternative can achieve the same result. Explain the required outcome and let the firm propose an evidenced method where appropriate.

1. State the verified deficiency and present significance.
2. Identify the root cause and affected population.
3. Define corrective work, owner, deadline and dependencies.
4. Agree the evidence and independent test needed for closure.

Give each action a measurable end point

Use one accountable owner, a realistic target date and explicit dependencies. Where management has not assigned an owner or date, mark it as awaiting assignment instead of inventing one. A useful closure test states what record will exist, which population it covers, how exceptions are handled and who verifies it.

Different actions need different evidence. A revised method may need approval, configuration reconciliation and recalculation of affected cases. A screening decision may need an attributable identifier comparison, rationale and approval under the relevant procedure. A retrieval issue may need timed retrieval and restoration tests rather than another promise that files are available.

Keep dependencies visible. A system calculation cannot be meaningfully reconciled until the operative methodology is agreed; a look-back cannot be reported complete while its source population is unsettled. Where an action is blocked, record the decision needed and the interim risk control rather than moving its target date without explanation.

Report progress without confusing it with assurance

MEMA recommends separate fields for management’s implementation claim and the reviewer’s verification status. A completion percentage needs a defined denominator: files, tasks and control objectives are not interchangeable. Report overdue high-risk work, exceptions, decisions required and customer-impact assessment, not simply a green dashboard.

A materiality-based conclusion can recognise that a principal concern has been addressed while specific improvements remain. Explain why the remaining work does or does not prevent that conclusion. Do not turn an internal rating into a claim that the FCA has accepted closure. If a live regulatory requirement has its own conditions, track those conditions independently and maintain compliance until a formal change takes effect.