Reconfirming the Record: An Eighteen-Month Audit for Lawful Basis Drift

A record of processing activities can be accurate on the day it is approved and misleading eighteen months later. The change is rarely dramatic. A product team adds a field, a supplier introduces a new sub-processor, a retention rule is copied from an old policy, or the person who understood why data was collected leaves the organisation. The documentation remains in place, but it no longer describes the processing.

This is lawful basis drift. It matters because UK GDPR accountability depends on records that reflect reality, not just records that exist. Article 30 records and internal data maps are evidence of governance only if they are maintained. Under the UK GDPR and the Data Protection Act 2018, the organisation must be able to explain its purposes, lawful bases and retention decisions. A stale map weakens that explanation.

The answer is not a perpetual rewriting exercise. It is a repeatable audit that reconfirms assumptions at purpose level, uses change as a trigger and treats the data map as a hypothesis to be tested.

How lawful basis drift occurs

Drift usually enters through four routes. Product change is the most common: a new feature extends the purpose, a new analytics tool changes the recipients, or a 'temporary' process becomes permanent. Organisational change is the second: accountability moves, but the register does not. Supplier change is the third: a processor adds a sub-processor or changes its location, and the third-party section of the record becomes outdated. Documentation change is the fourth: a retention schedule is refreshed centrally, but local practice and system configuration remain as they were.

None of these events necessarily makes processing unlawful. The risk is that the organisation continues to rely on an unexamined lawful basis or retention assumption. Consent may have become stale. A legitimate interests assessment may no longer reflect the context. A contract necessity argument may have been stretched to cover a purpose that is not necessary at all.

Why eighteen months

An annual questionnaire is often too shallow and too late. An eighteen-month cycle is long enough to capture annual planning, product release and procurement patterns, but short enough to prevent drift from becoming embedded. The cycle should sit alongside trigger-based reviews, so that significant change does not wait for the next full audit.

Step one: set the baseline by purpose

Scope the audit at purpose level, not system level. A system may support several purposes, each with a different lawful basis and retention rule. The data map and ROPA provide the starting point, but they should not be treated as the answer. Select a sample that includes high-risk processing, recently changed purposes, long-standing purposes and purposes dependent on third parties. Record the assumptions as they appear in the documentation before interviewing anyone.

Step two: define change triggers

A trigger is an event that requires a targeted review of affected purposes. Typical triggers include a new product or feature, a new vendor or sub-processor, a reorganisation, a new data-sharing arrangement, a significant incident, a change to retention rules, or new regulatory guidance. Each trigger should prompt a short review of the relevant entries, not a full audit. This is how the organisation avoids discovering drift only at the eighteen-month mark.

Step three: interview purpose owners

Speak to the people who understand why the data is collected, not only the data stewards who maintain the register. Ask what decision the data supports, who is accountable, what lawful basis was intended, whether the purpose has changed, what retention trigger applies and what evidence exists. Compare the answers with the documented position. The gap between the two is the audit finding.

Purpose-level interviews are more revealing than system-level questionnaires because they expose changes in intent. A system may still be described as 'customer administration' while it now supports profiling, marketing or service personalisation. Those are different purposes and may require different bases.

Step four: test lawful basis and retention

For each sampled purpose, reconfirm the lawful basis rather than rewriting it by default. Test whether contract necessity is genuinely necessary, whether a legal obligation is correctly identified, whether legitimate interests have a current assessment and whether consent is specific, fresh and withdrawable. Where special category data is involved, check the additional condition separately.

Retention deserves equal attention. Identify the trigger event, the retention period and the evidence that deletion occurs. Check backups, archives and supplier-held data. A retention rule that exists only in a policy is not a control. The output should be a decision: confirm, amend or escalate.

Step five: record decisions and remediate

Maintain a drift register that shows the documented position, the observed position, the risk, the owner, the decision and the due date. Severity should reflect likely harm, volume, special category data, transparency and the number of affected purposes. Update the ROPA only after the decision is made. Avoid mass editing, which creates the appearance of accuracy without the evidence.

Step six: close the cycle

A workable eighteen-month cycle might use months one to two for baseline and sampling, months three to six for fieldwork, months seven to nine for remediation, months ten to seventeen for trigger reviews and month eighteen for reassessment. Report a small set of measures to the DPO and governance forum: percentage of purposes reconfirmed, exceptions closed, trigger reviews completed and overdue decisions.

The purpose of the audit is not to produce a perfect record. It is to provide evidence that the organisation knows what it is doing with personal data and why. A data map is a claim. The audit is how the claim is tested.