Common Evidence Gaps
The gaps that recur in resilience files: missing links, undated records, unowned actions, and tests that never touched the dependency that matters most.
The short answer
Common evidence gaps are the missing pieces that recur across firms, services, and examinations, and recognising them in advance makes them easier to find in your own file. They include records that are not tied to a named service, maps that no longer match the service as it runs, tolerances that have never been tested, test records that do not say what was exercised, incident reviews without owned actions, and supplier arrangements that are asserted rather than shown. None of these gaps is exotic, and that is why they are dangerous: they are easy to overlook precisely because they are ordinary.
This guide works through the gaps in the order a reader meets them when following a service trail, and suggests, for each one, what to look for and what a fix looks like. The point is not to produce a perfect file, but to find the gaps that matter most for the services that matter most, and to close them in order of risk, with owners and dates, before an auditor or supervisor finds them first.
What happens when records are not tied to a service?
The most basic gap is a record that cannot be tied to a service. A test report, a plan, or a review that speaks about resilience in general, without naming the service, the dependency, or the tolerance concerned, cannot support assurance for any particular service, however well written it is. A reader trying to follow the trail for one service will find general material everywhere and specific material nowhere, and will reasonably conclude that the firm cannot show what it claims for that service.
Why do stale maps cause so many gaps?
A map that no longer matches the service is a gap that creates other gaps. Tests are designed against the old map, so they exercise dependencies that no longer matter and miss the ones that do. Incident records are interpreted against the old map, so the failed dependency is misidentified. Tolerances are judged against a service that no longer exists in the form described. The file may look complete, but its completeness is an illusion, because its central reference is out of date.
Maps go stale quietly, through ordinary change: a supplier is replaced, a system is migrated, a team is reorganised, a channel is added. The remedy is to treat the map as a living record, reviewed whenever the service changes and checked after each test or incident, rather than as a document produced for a project and then filed. A map review need not be elaborate; it needs to ask, for each dependency shown, whether it still exists, whether it still matters, and whether anything material is missing.
What does an untested tolerance hide?
A tolerance that has never been tested hides the central question of resilience, which is whether the firm can actually remain within it under disruption. The tolerance may be well worded and senior-approved, but without a test or an incident measured against it, nobody knows whether the recovery arrangements are fast enough, whether the right people can be reached, or whether the supplier steps work in sequence. The firm is, in effect, assuring itself on the basis of a hope.
Why is missing follow-up so common?
Missing follow-up is common because the hard part of a review happens after the meeting ends. A test or incident review produces lessons, but lessons become actions only when someone owns them and a date is set, and actions become improvements only when their completion is evidenced in the service trail. At each step, the work can quietly fade: the lesson is recorded as an observation, the action is assigned to a team rather than a person, the date slips, and the next test rehearses the same weakness.
Where do supplier evidence gaps sit?
Supplier evidence gaps sit where the firm's trail stops at its own boundary. The firm may hold a contract and a summary of a supplier's assurances, but no record of what the supplier actually does for the service, how its performance is monitored, or what happens if the supplier itself is disrupted. That gap matters because many important services depend on suppliers for a step that the firm cannot perform alone, and a disruption in the supplier is, for the user, a disruption in the service.
Closing the gap does not require the firm to audit its suppliers in the same way it audits itself, but it does require specific evidence: which service steps the supplier performs, what the firm expects of those steps, how the firm knows whether they are being met, and what the fallback is if they are not. Where that evidence cannot be obtained, the gap should be recorded honestly and treated as a risk to the service, rather than papered over with a general statement about supplier management. A known gap can be managed; a hidden gap cannot.
Primary sources on the record
- Regulation (EU) 2022/2554 on digital operational resilience for the financial sector, Official Journal text on EUR-Lex.
- National Institute of Standards and Technology, Computer Security Resource Center: resilience and security practice, cited as practice, not law.
Legal status: Regime-dependent and labelled in the guide. DORA applies from 17 January 2025. The UK regime has its own policy statements and dates, stated separately where the guide compares regimes. Application position for this topic: DORA: from 17 January 2025. UK: see the UK line for its own dates.