Scenario Testing for Data Loss

A data loss scenario rehearses what a firm does when records it needs are missing, corrupted, or no longer trustworthy, even if its systems appear to be running. Data loss is not the same as a system outage. A system can be restored quickly while the data inside it remains wrong, and acting on wrong data can cause harm that is harder to undo than a pause in service. The scenario therefore tests integrity before speed: can the firm tell which records are affected, can it reconstruct them from another source, and can it explain to customers what is uncertain? An exercise that treats backup restoration as the whole answer misses the hardest question, which is whether restored data should be trusted.

Data loss can be obvious or subtle, and the scenario should choose a form that fits the service. Obvious loss includes deleted files, a failed migration, or a store that cannot be read. Subtle loss includes records that are present but altered, duplicated, or out of sequence, so that balances, entitlements or histories no longer reconcile. Consider an insurance claims service where claim histories are corrupted during a faulty update. Customers may still be able to contact the firm, but staff cannot tell what has already been paid, what is outstanding, or which documents support a claim. A scenario of that kind forces decisions about pausing payments, seeking evidence from customers, and recording uncertainty, rather than simply restarting a system.

Reconstruction is tested by asking where a second copy or an independent check exists, and whether that source is usable under pressure. A backup may exist but may be old, incomplete, or stored in a form that takes considerable effort to restore. A counterpart may hold a copy of transactions, but obtaining it may need authorisation and time. Paper or customer held evidence may fill gaps for some records but not for others. The exercise should make participants work through those options for a specific set of records, rather than accepting a general assurance that data can be recovered. It should also test prioritisation: which records matter most for customer harm, and which can wait while the most urgent records are rebuilt and checked.

Trust in restored data is a judgement, not a technical status. Data that has been restored from a backup taken after corruption began may carry the corruption with it. Data that has been rebuilt from several sources may contain inconsistencies that only appear when records are compared. The scenario should therefore include a check stage: reconciliation against an independent source, sampling of records, or comparison with customer held evidence. Participants need to decide what level of discrepancy is acceptable, who can approve a return to normal processing, and what to tell customers whose records remain uncertain. Those decisions are easier to rehearse than to improvise, and an exercise that skips them leaves the firm unprepared for the moment when restoration looks complete but confidence is not.

Customers affected by data loss face a particular kind of harm: uncertainty about their own position. They may not know whether a payment was made, whether a claim is valid, or whether their details are correct. Communication should therefore distinguish between what is known, what is being checked, and what the customer can do in the meantime, such as providing a document or confirming a detail. Staff handling those conversations need guidance that is honest without being speculative, and they need a way to record customer provided information so it is not lost again. A scenario that includes customer contact, rather than treating data loss as a back office problem, will reveal whether front line teams have that guidance and whether the firm can track cases that remain unresolved.

A data loss exercise should leave behind a clearer map of critical records, their sources, their checks, and their owners. It may also lead to changes in how data is validated, how backups are tested, or how changes to data stores are controlled. Each change should be tied to a specific weakness found in the exercise, such as a record with no second source or a check that nobody owned. The debrief should also record what was not tested, for example a type of record that was left out of the scenario, so the next scenario can cover it. Data loss scenarios age quickly as systems change, and a library that is not refreshed will eventually rehearse a service that no longer exists.