Why data gets out of date, and what to do about it

Every record is a snapshot, not a fact

A customer record looks permanent. A phone number, a job title, a company name, a mailing address. Once typed, it sits there and looks settled. But most of what you store about a person or a business is not a fixed fact. It is a snapshot of something that was true on the day it was entered.

People change jobs. Companies move office. Numbers get reassigned. A contact who signed off on last year's order now reports to someone new, or has left entirely. None of these changes announce themselves to your database. The record stays exactly as you left it while the thing it describes drifts away underneath.

This is worth naming plainly, because it changes how you should think about the data you already hold. A record does not have to be wrong in some absolute sense to be useless. It only has to be wrong for the decision you are about to make with it. An old address is fine for a tax return and useless for a delivery. So "is this data accurate" is really the question "accurate enough for what."

The law that governs personal data works the same way. Under the accuracy principle, personal data must be "accurate and, where necessary, kept up to date" [1]. The phrase *where necessary* is doing quiet work there. Accuracy is judged against the purpose, not against some ideal of a perfect record. That is the right instinct for a business too.

Where stale records actually come from

Stale data is not one problem. It arrives through several different doors, and each door needs a different habit to close it.

The world changes and nobody tells you

This is the largest source and the hardest to see. A meaningful share of your contact data goes wrong every year through no fault of anyone in your business. People move roles. Businesses rebrand, merge, or close. Email addresses tied to a former employer stop working the day that person leaves. The record was correct when you wrote it. Time made it wrong.

You cannot prevent this. You can only design for it, by treating every field as something with a shelf life rather than a permanent truth.

The record is entered once and never touched again

Most records are created in a rush at the start of a relationship, when someone is trying to close a sale or open a ticket, not to build a tidy archive. The fields get filled to the minimum needed to move on. After that, the record is read hundreds of times and edited almost never. Reading does not refresh data. Only editing does, and nothing in a normal day forces an edit.

Two systems disagree and nobody reconciles them

When the same customer lives in a spreadsheet, an email tool, an accounting package, and a support inbox, each copy ages on its own schedule. Someone updates the phone number in one place. The others keep the old one. Now you have four versions of the truth and no way to tell which is current. This is closely tied to why integrations break quietly: a sync that silently stops does not shout, so the copies drift apart while everything looks fine.

Nobody owns the field

When everyone can edit a field and no one is responsible for it, it rots. If "account status" is updated by whoever happens to notice something, it will be updated inconsistently, and eventually not at all. A field with no owner has no one to keep it current.

Why stale data costs more than empty data

An empty field is honest. It tells you it does not know, so you go and find out. A stale field lies. It looks complete, so you act on it, and the cost lands later. You post an invoice to an old address. You call a number that now belongs to a stranger. You email a decision-maker who left months ago and wonder why the deal went quiet.

This is one of the ways good opportunities die without a clear cause. Much of what looks like a lead losing interest is really a team acting on a record that quietly went out of date, as we set out in the anatomy of a lead that goes cold. The data did not fail loudly. It failed silently, which is worse.

There is a legal edge to this as well. A person has the right to have wrong information about them put right: the data subject can "obtain from the controller without undue delay the rectification of inaccurate personal data concerning him or her" [2]. If your systems make correction slow or impossible, that is not only bad service. It is a compliance risk.

The habits that keep records current

You will never freeze the world. The goal is not perfect data. It is data that stays accurate enough for the decisions you make with it. A small set of habits does most of the work.

Correct on contact

The cheapest moment to fix a record is the moment you are already looking at it for another reason. A call, a reply, a delivery, a payment. Each contact is a chance to confirm one thing quietly. Guidance on personal data puts it well: "every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay" [1]. In practice this means correction is a habit woven into daily work, not a project you schedule once a year and dread.

Give every field an owner and a source

For each field that matters, answer two questions. Who is responsible for it being right? Where does the true version come from? Once a field has an owner and a source, drift becomes visible and fixable. This is part of deciding what a customer record should contain in the first place: a field nobody owns and nobody sources is a field that will go stale.

Let the record show its age

A record should carry the date it was last confirmed, not only the date it was created. "Verified in March" and "verified two years ago" are different levels of trust, and the person reading the record should be able to tell them apart at a glance. Age is information. Hiding it means everyone treats a two-year-old address with the same confidence as yesterday's.

Reconcile the systems that copy each other

If the same customer exists in several places, decide which one is the master copy and make the others defer to it. When a sync exists, check that it is actually running, because a broken one fails without a sound. The aim is a single place where the current version lives and everything else reads from it.

Review the small, high-value set on a schedule

You cannot verify everything, and you should not try. The regulation itself says "every reasonable step should be taken to ensure that personal data which are inaccurate are rectified or deleted" [3] — *reasonable*, matched to purpose. So pick the records that would hurt most if they were wrong: your active customers, your open opportunities, your top accounts. Review that small set on a rhythm. Leave the long tail alone until it matters.

What "current enough" means

The honest target is not a clean database. It is a database you can trust for the specific thing you are about to do. That standard is reachable. "Perfect and permanent" is not, and chasing it wastes the effort that should go into the records that actually drive decisions.

Data staying current is a habit, not a feature, which is why your CRM is only as good as your habits that surround it. Tools help by making the right habit the easy one. When a customer's whole history lives in one place, correcting on contact takes a second, the last-confirmed date is visible, and there is only one copy to keep current. This is one of the reasons 360REV keeps a customer's records, conversations, and money in a single system rather than scattered across separate tools. The system removes the friction; the discipline still has to be yours.