Recovery and Data Corruption

Recovery and data corruption is about what happens when the records a service relies on are themselves wrong, altered, or incomplete, rather than merely unavailable. A system can be rebuilt cleanly and still serve corrupted data, and customers may not notice until a balance, instruction, or entitlement proves wrong. Recovery in this situation is not just restoring a copy. It is finding how far corruption spread, deciding which records can be trusted, and choosing, record by record or set by set, whether to repair, to rebuild from independent sources, or to accept a gap openly.

Corruption is difficult because it is often silent. Unlike an outage, which announces itself, corrupted data may sit quietly until it is used, and a backup process may faithfully copy it before anyone notices. The firm therefore needs ways to detect corruption that do not rely on the corrupted data itself: independent records, reconciliations, and checks of behaviour that would look odd if the data were wrong. Without an independent view, a firm can restore, test, and reopen a service while still carrying the original error forward.

Corruption is often found through inconsistency rather than through a single alarm. A balance that does not reconcile with an independent ledger, a customer instruction that does not match its authorisation, or a pattern of errors concentrated in one period or one data set can all point toward a data problem rather than a systems problem. Staff reports and customer queries are valuable signals here, because customers often notice that their own records are wrong before any monitoring does. Treating those reports as data, and aggregating them, can reveal a pattern that single cases hide.

Establishing scope is the hardest part of corruption recovery. Corruption may affect a single field, a set of records, a whole data store, or records that have since been copied into other systems and used to create further records. Each step outward makes the problem harder to bound, because later records built on corrupted earlier records may themselves be wrong even though they were created legitimately. The firm needs a method for tracing that spread, following records from their origin through the systems that used them, and marking the boundary of what is known to be affected, what is suspected, and what has been checked and cleared.

Once scope is understood, the firm faces a choice for each affected set: repair the records, rebuild them from independent sources, or accept that some records cannot be reliably restored. Repair may be possible where the correct value can be established from another record, such as a provider confirmation or a customer instruction held elsewhere. Rebuilding may be possible where a clean earlier copy exists and later legitimate activity can be reapplied or reconstructed. Accepting a gap is the hardest option, because it means telling affected customers that something cannot be put right from records alone, and finding another way to resolve their position.

For customers, corruption is personal in a way an outage is not. An outage delays access. Corrupted records may mean a balance is wrong, a payment went to the wrong place, or an entitlement is misstated, and the customer may discover the error before the firm does. Recovery should therefore include a way to identify affected customers, to check their positions individually where needed, and to put right what can be put right. That work is slow and detailed, and it should not be treated as an afterthought to systems restoration.

Prevention starts with understanding how corruption entered and spread. Was it introduced by an attacker altering records, by a faulty process writing incorrect values, or by a restore that copied already corrupted data. Each cause points to a different remedy: stronger controls on who can change records, better validation before records are accepted, or earlier detection through reconciliation. A remedy that addresses a different cause from the one that actually occurred may improve general hygiene while leaving the real route open.

Detection is as important as prevention. Regular reconciliation against independent sources, checks for unusual changes, and prompt investigation of customer reports can catch corruption earlier, when its scope is smaller and its repair is easier. Under DORA, which applies from 17 January 2025, the EU frame expects resilience that includes recovery of data, labelled here as the EU line, while the UK regime under FCA PS21/3 and PRA PS6/21 carries its own expectations with separate dates. In both frames, the practical lesson is the same: a firm that can detect corruption early, bound its scope honestly, and repair records deliberately is in a far stronger position than a firm that discovers corruption only when customers complain.