Governance of Testing and Findings

Testing tells the management body whether recovery arrangements work in conditions that resemble real disruption. Governance of testing therefore involves more than approving a testing plan. It involves judging whether the scope and severity of tests match the risks to services, understanding what results actually prove, and ensuring that findings are owned, fixed and retested. A test programme that produces reports but no changes has informed the board without improving resilience.

The management body should be able to answer three questions about testing. What was tested, and was it the whole service or only a part? How severe was the scenario, and did it challenge recovery assumptions? What changed afterwards, and how was that change evidenced? If any answer is vague, governance has a gap, however busy the testing calendar appears.

Scope should follow services and their dependencies. A test that exercises one system in isolation may prove that system, while leaving the end to end service untested. The board should therefore ask whether tests covered the customer journey, including channels, providers and manual workarounds where those form part of recovery. A testing programme that never tests the full service leaves the most important resilience question unanswered.

Test results should be read as evidence with limits. A successful test shows that recovery worked under the conditions tested, not that recovery will work under all conditions. A failed test is not necessarily a governance failure. It can be a successful test in governance terms, because it revealed a weakness before a real incident did. The governance failure would be to ignore the result, to explain it away, or to record it without action.

Results should therefore be reported with their conditions attached: what was tested, what was assumed, what was excluded, and what did not work. Reporting that strips away those conditions turns a qualified result into an unqualified reassurance. Board members should be wary of summaries that report only that testing took place, without describing what was learned. Learning is the product of testing. Activity is only its cost.

Every finding needs an owner, a remediation plan, and a completion check. Ownership should sit with a named role, not with a team in general, so that progress can be chased and delays can be explained. Remediation should address the underlying cause where possible, rather than only the immediate symptom, because a symptom fix that leaves the cause intact invites repetition.

Completion should be evidenced, not merely asserted. Evidence might include a retest, a revised procedure that has itself been exercised, or a provider confirmation that has been checked against the service. Where a finding is accepted without full remediation, that acceptance should be a recorded decision, with reasoning and a review point, rather than silent drift. An accepted risk that no one remembers accepting is indistinguishable from an overlooked risk.

Within DORA, certain entities participate in threat-led penetration testing, often shortened to TLPT, which simulates realistic adversary behaviour against live production systems under controlled conditions. Governance of TLPT involves the management body understanding its purpose, its scope, and its findings, and ensuring that remediation follows. TLPT is not a general security check. It is a demanding exercise designed to reveal how defences and recovery behave under a realistic attack scenario.

Board oversight of TLPT should focus on the same governance questions as other testing: what was in scope, what was found, what was fixed, and what was retested. The technical detail belongs to specialists, but the judgement about whether findings have been addressed, and whether residual risk is acceptable, belongs to the management body. A TLPT report that is received with admiration and no follow-up has not been governed. It has been admired.

Testing governance is undermined when testing becomes routine. A programme that repeats the same scenario, with the same people, under the same favourable assumptions, will produce consistent passes and diminishing learning. Rotation of scenarios, inclusion of provider dependencies, and occasional testing of less familiar services can restore challenge. The board can encourage that variety by asking what was different about the latest tests, and what surprised the teams involved.

Another weakness is the separation of testing from incident learning. Incidents reveal failure modes that testing should then probe, and testing reveals weaknesses that incident plans should reflect. When the two streams are managed separately, lessons circulate slowly. Governance should join them: incident reviews should generate test ideas, and test findings should update incident and recovery plans. The record of that joining, in updated plans and retests, is evidence that testing is part of resilience rather than a parallel exercise.