Proportionate Testing Programmes

A proportionate testing programme is one whose depth, breadth, and frequency fit the firm. Under DORA, testing is proportionate to risk profile, complexity, and scale, and it must cover the systems that support critical functions. That sentence does two jobs at once. It relieves a small, simple firm of the need to mimic the programme of a large, complex group, and it prevents a large, complex firm from defending a thin programme on the grounds that testing is expensive. Proportionality is not a discount. It is a reasoned match between what could go wrong, what customers would lose if it did, and how hard the firm looks for weaknesses before an incident finds them.

Proportionality starts with the critical functions, not with the testing catalogue. A firm first identifies which functions matter most to customers and to financial stability, then maps the ICT systems that support them, including systems run by third parties. A lending platform, for example, might depend on a credit decisioning service, a document store, and a payment rail. If any of those fails, applications stall and customers are left without answers. The testing programme should spend its effort there, in proportion to that harm, rather than spreading the same light touch evenly across every system the firm happens to own.

For a smaller firm, proportionality may mean fewer methods, simpler scenarios, and heavier reliance on a supplier's own testing, checked rather than repeated blindly. For a larger firm, it may mean a wider range of methods, testing of interconnections between business lines, and exercises that involve several teams and suppliers at once. The difference is not about caring less. It is about where complexity lives. A firm with a single core system and a handful of suppliers has fewer interactions to test. A group with shared platforms across countries has failure paths that only appear when those platforms interact, and its programme needs exercises designed to reveal them.

Size alone is a poor guide. A small firm running a payment service that settles a large share of its customers' daily transactions may carry more testing need than a larger firm whose critical functions are slower moving and easier to work around. Risk profile brings in the sensitivity of the data, the speed at which harm spreads, the availability of manual workarounds, and the dependence on a single supplier. A service with no credible workaround needs more searching tests than a service where staff can safely pause, inform customers, and resume later without loss. The programme document should show that reasoning, so a reviewer can follow why each system received the testing it did.

Two failures are common. One is the programme that tests everything at the same shallow depth, producing a long list of passes and no insight into the systems that matter. The other is the programme copied from a peer or a vendor, with methods that fit the peer's architecture but not the firm's own. Both share a symptom: findings are rare, generic, or unrelated to critical functions. A proportionate programme, by contrast, will sometimes be uncomfortable. It will concentrate effort, find weaknesses in important places, and leave less important systems with lighter, clearly justified coverage. That unevenness is the evidence that judgement was applied.

Proportionality is not fixed at the first plan. New products, new suppliers, a migration to a different platform, or a change in customer mix can all shift which functions are critical and which systems support them. When that happens, the testing plan should be revisited, and the reasons for any change recorded. Testing after a major change, covered elsewhere in this cluster, is part of that cycle. So is the review of findings: if testing repeatedly finds nothing in a supposedly critical system while incidents keep occurring elsewhere, the plan may be looking in the wrong place, and that itself is a finding worth acting on.

Reviewing the plan in this way also helps a firm explain its choices to a supervisor or an auditor. The explanation is not that testing was extensive in every direction, but that it was concentrated where harm would be greatest, lighter where harm would be lower, and revisited when the underlying risks changed.