A CRM Migration Reset the Lawful-Basis Review Clock: Restore the True Due Date

A CRM migration can replace or overshadow an older evidence date with a current-looking system date (created or updated) or import date. That creates a bad review queue if the team treats the new system timestamp as proof that the lawful basis was reviewed recently.

The correction is operational: preserve the migration timestamp for audit history, then restore the date of the original basis evidence as the review anchor and calculate the next internal review deadline from it. This is a governance method, not a legal opinion or a statutory review interval.

UK GDPR Article 5 requires personal data to be processed lawfully and accurately, and makes the controller responsible for demonstrating compliance. It also says data must not be kept in identifiable form longer than necessary for the processing purpose. https://www.legislation.gov.uk/eur/2016/679/article/5

• Freeze automated deletion or outreach changes for records whose basis date is uncertain until the record is classified.
• Keep both the imported system timestamp and the restored evidence date.
• Record who restored the date and what evidence supported it. Record what happened to the review deadline.

How do you detect a lawful-basis review date reset by CRM migration metadata?

Start with fields that changed during the migration: created date, last modified date, import batch ID, source-system ID, activity history, and any lawful-basis or assessment fields. A broad cluster of records with the same recent timestamp is a migration signal, not evidence that each record received an individual review.

Then compare the new CRM record with the source export, archived assessment, consent record where relevant, contract record where relevant, or the record of the processing activity. Article 30 requires controllers to maintain written records of processing activities, including purposes, categories of people and data, recipients, and, where possible, erasure time limits. https://www.legislation.gov.uk/eur/2016/679/article/30

Do not overwrite uncertain history with a guessed date. Mark the record as unresolved, retain the import metadata, and send it to the person accountable for the processing decision.

Which original evidence date controls the next review deadline?

Use the date on which the organization last had evidence for the specific processing purpose and lawful basis now recorded. A contact creation date controls only when it is also the documented date of that assessment.

A later date can replace the earlier anchor when there was a real, documented reassessment of the relevant processing. For example, a documented reassessment following a new purpose or material change in the data used, or a fresh documented basis assessment may create a new evidence event. Do not substitute a bulk import date for that event.

Article 6 says processing is lawful only if and to the extent that at least one listed condition applies. The applicable condition must match the processing at issue. https://www.legislation.gov.uk/eur/2016/679/article/6

• Original evidence date: the date of the actual documented assessment.
• Migration date: retain as technical provenance.
• Restored deadline: the original evidence date plus the organization's documented review cadence.
• Reassessment date: use only after a real reassessment is completed and recorded.

How should overdue records be reassessed after the true clock is restored?

Work oldest and highest-risk records first. Confirm the purpose, categories of personal data, recipients, retention position, and the lawful basis recorded for the specific processing. If the team cannot recover the evidence, it should not pretend the import date resolves the gap.

Document the outcome at record level or processing-activity level, depending on how the organization maintains its records. The ICO says documentation should be granular and meaningful, with links between the processing purpose, people, data, retention periods, and other relevant details. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/documentation/how-do-we-document-our-processing-activities/

The ICO also describes records of processing as a living document that should reflect the current processing situation and receive regular review. That supports preserving a correction trail rather than replacing old evidence without explanation. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/documentation/how-do-we-document-our-processing-activities/

• Confirm whether the recorded purpose still describes the processing.
• Confirm the lawful basis and the evidence supporting it.
• Check whether retention and erasure handling still fit the processing.
• Record the reviewer, evidence reviewed, decision, date, and any required remediation.
• Escalate records with missing evidence, changed processing, or unresolved retention questions.

What should the migration correction ledger contain?

Keep the ledger separate from the field used to schedule ordinary reviews. It should make the correction reproducible without making the migration date disappear.

At minimum, include the record or processing ID, source-system reference, import batch, false current date, original evidence date, evidence location, restored deadline, reviewer, decision, and correction timestamp. Avoid copying unnecessary personal data into the ledger.

The ICO lists purposes, categories of individuals and personal data, recipients, retention schedules where possible, and security measures among the information controllers should document. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/documentation/what-do-we-need-to-document-under-article-30-of-the-gdpr/