Tolerance in Data Loss

A tolerance in data loss answers a question that is easy to overlook while systems are down: when the service returns, will the data it returns with be complete, accurate, and current enough for users to rely on? A service can be restored technically while its records remain incomplete, duplicated, or out of date, and users who act on that data can suffer harm long after the outage itself has ended. The tolerance therefore states, for one service, what damage to data counts as intolerable harm, in terms that can be recognised during recovery rather than discovered weeks later.

The illustration here is a transaction record service for investment customers. If recent transactions disappear from view, if a sale appears twice, or if a balance reflects an earlier position rather than the current one, customers may make decisions based on a false picture of their holdings. The firm may also struggle to reconcile its own position. Data loss, in this sense, is not only about files disappearing. It covers any state in which the service cannot show users a trustworthy record of what has happened.

Harm to data takes several forms, and a tolerance should be able to recognise each of them. Loss is the most obvious form, where records are missing. Corruption is subtler, where records exist but are wrong, so that the service appears to work while misleading its users. Staleness is subtler still, where records are accurate for an earlier moment but do not reflect recent activity, so that a user sees a plausible but outdated picture. Duplication, where one event is recorded more than once, can be just as damaging, because it distorts balances and creates disputes about what actually occurred.

A system returns when its platform is available again. A service recovers when users can rely on it again, and reliance depends on data. If a customer logs in after an outage and finds a balance that does not include a recent payment, the customer cannot safely act, even though the login succeeded. The firm faces a parallel problem. Staff cannot answer customer queries confidently, cannot reconcile positions, and cannot be sure that further processing will not compound the error. The service is therefore still disrupted in practical terms, even if its availability measure has returned to normal.

Data harm interacts with both duration and scope, and the interaction can worsen either one. A longer interruption usually means more activity is captured uncertainly, more records need reconciliation, and more users are affected by any gap that emerges. A wider interruption means more records across more users are at risk, and reconciliation becomes harder because the firm must check a larger set of activity. Data harm can also persist after duration has ended, which means the overall harm period is longer than the outage period, a point that duration alone would miss.

Data tolerances go wrong when they are written in technical language that incident managers cannot apply. A statement about backup completeness, without any translation into what users would see, leaves the decision maker to improvise during recovery. A second failure is to assume that a backup, once restored, is automatically correct. Backups can be stale, partial, or inconsistent with activity that occurred after the backup point, and restoration itself can introduce errors. The tolerance should therefore be paired with reconciliation checks, not treated as satisfied by the existence of a backup.

A reader can test a data tolerance by asking what users would see if data were incomplete, inaccurate, or stale, and how the firm would know. Further questions concern reconciliation: who checks data after restoration, what is compared, and what happens if the check fails? If those questions have no clear answer, the data dimension is incomplete, however strong the backup arrangements may appear on paper. A data tolerance that is checked after every major restoration, and not only after a declared incident, keeps the record of trustworthiness current for the next disruption.