Implementing a GDPR data-retention schedule

A retention document has no operational effect until records can be classified, aged, held, deleted and verified across the primary store, indexes, exports and backups.

Map purpose to record classes

List the personal-data records created by each service purpose, their system of record, owner and lawful basis. Assign retention from a defensible event such as contract end or case closure, not merely the row creation date.

Represent expiry explicitly

Calculate a review or deletion date from the governing event and preserve which policy version produced it. Handle reopened cases and changed obligations as events rather than silently replacing original evidence.

Build controlled deletion

Delete or irreversibly anonymise in bounded jobs with audit totals and failure handling. Propagate removal to search indexes, analytics extracts, attachments and supplier systems without recreating records from a later import.

Separate holds and backups

Apply legal holds through authorised, reviewable records with scope and expiry. Document how expired data disappears from active systems and then ages out of protected backups without requiring unsafe selective editing.

Prove operation

Reconcile eligible, deleted, held and failed counts by record class. Sample complete journeys from expiry through downstream removal and report exceptions to the information owner.