Testing Findings and Remediation

Testing findings and remediation is the loop that turns a test result into a stronger service. A finding is a weakness, gap, or unexpected behaviour discovered by testing. Remediation is the fix, workaround, or documented decision that addresses it, followed by retesting to confirm the fix worked. Without that loop, testing produces reports but no resilience. A firm can run an exemplary programme, discover important weaknesses, and still suffer the incident those weaknesses predicted, because nobody owned the fix. Under DORA, the value of testing is therefore judged not by how many tests were run, but by how findings were handled, and whether the same weakness stopped appearing.

A usable finding can be understood by someone who did not take part in the test. It names the system and the critical function affected, describes what was tested and what happened, explains why it matters for customers or for recovery, and states what was not tested that might hide a related weakness. A wealth platform example illustrates the difference. A vague finding might say that authentication needs improvement. A usable finding says that a password reset flow, under a specific condition, allowed an account to be accessed without the expected second check, affecting customer accounts, and that the related flows have not yet been checked. The second version can be owned, fixed, and retested. The first can only be discussed.

Prioritisation should follow the critical function, not the technical severity alone. A severe flaw in a peripheral system may matter less than a moderate flaw in the system that processes customer payments, because the harm, and the speed at which it spreads, differ. Other factors include whether the weakness is reachable from outside, whether customer data is involved, whether a workaround exists, and whether a supplier must act before the firm can fix it. The priority, and the reasoning behind it, should be recorded. That record protects the decision later: if a lower priority finding is later exploited or causes an incident, the firm can show what it knew, what it weighed, and what it planned, rather than searching for an undocumented judgement.

Not every finding can be fixed at once, and DORA testing does not demand instant fixes for everything. What it does demand is a conscious decision. Accepting a risk for a stated period, with a compensating control and a review date, is a decision. Leaving a finding unowned, with no date and no control, is neglect, even if nobody used the word accept. The distinction should be visible in the record. Acceptance should also be revisited: a risk accepted when a system was lightly used may become unacceptable when volumes grow or when the system becomes part of a new critical journey. Repeat findings, where the same weakness appears in successive tests, deserve particular attention, because they suggest the remediation, or the ownership, failed.

A fix that has not been retested is an intention, not a control. Retesting should reproduce the conditions that produced the finding, as closely as possible, and should also check that the fix did not break a neighbouring function. In the wealth platform example, retesting the password reset flow should confirm the second check now applies, and should also confirm that legitimate customers can still reset passwords without undue friction. Where a fix depends on a supplier, the firm needs evidence from the supplier and, where possible, its own confirmation. A remediation record that ends with a fix, but no retest, leaves the most important question unanswered: did it work.

Senior management should see a picture of findings over time, not a single test report. Which findings are open, which are overdue, which keep recurring, and which concern critical functions. That picture reveals whether testing is improving resilience or merely documenting its absence. It also reveals whether the testing programme itself needs adjustment: if findings cluster in one system, that system may need deeper testing; if findings are rare in a complex critical system, the testing may be too gentle, as the pillar guide warns. A findings record that is honest about overdue and repeat items is more reassuring than a record that shows only closures, because it shows the loop is actually operating.