The Retention Policy Nobody Enforced
A mid-sized insurer's data retention schedule says customer records are kept for '7 years after the end of the relationship, or as required by law'. In practice: (a) the CRM never deletes anything because no deletion job was built; (b) a legacy claims system holds records from 2009; (c) marketing preferences are stored in a spreadsheet owned by one team member; (d) the privacy notice says records are kept 'only as long as necessary'. A new Head of Privacy runs a data-mapping exercise and finds 41 systems, of which 12 have no documented retention rule and 6 hold data past the schedule. The insurer is preparing for an accountability review and has no Records of Processing Activities (ROPA) in a usable form.
1. What is the core accountability failure here, and how should the Head of Privacy sequence remediation?
Read the worked answer
The core failure is that the insurer has a policy but no operationalised accountability - retention is declared, not enforced, and there is no evidence trail. Accountability is not 'we have a policy'; it is being able to demonstrate compliance. The symptoms (no deletion job, legacy data, spreadsheet preferences, no usable ROPA) all point to the same gap: no one owns the controls and nothing is measured.
Sequencing (do not start with a tool purchase):
- Build the ROPA first. You cannot enforce retention across 41 systems without knowing what is in them, why, and for how long. Prioritise the 12 undocumented systems and the 6 over-retained ones.
- Assign owners. Each system needs a business owner and a documented retention rule tied to a lawful basis and any legal minimum.
- Fix the highest-risk items first. Legacy claims data from 2009 and the uncontrolled marketing spreadsheet are the clearest exposures - special-category or contact data outside any control.
- Automate deletion. Build deletion/suppression jobs into systems; a policy without a job is decorative.
- Align the privacy notice. The notice must reflect what actually happens; 'only as long as necessary' is only true once retention is enforced.
- Evidence and review. Keep records of deletions, reviews, and decisions; set a review cadence.
The exam point: remediation starts with knowing what you hold (ROPA) and assigning ownership, not with buying a tool.
2. The insurer argues the legacy claims data from 2009 must be kept 'in case of future claims'. Is that defensible? What should it do?
Read the worked answer
'In case of future claims' is not, on its own, a defensible retention basis. Storage limitation requires that data be kept no longer than necessary for the purpose; a vague future possibility does not establish necessity. The insurer must be able to point to a specific legal or contractual obligation, a live limitation period, or a documented legitimate need with a defined end date.
What it should do:
- Identify the actual driver. Is there a statutory limitation period that genuinely requires retention? If so, retain only what the limitation requires, for only as long as it requires - not the whole record indefinitely.
- Apply the limitation period properly. Once the period for a claim has expired, the data should go. 'Future claims' cannot mean forever.
- Minimise. If some fields are needed for a live limitation period, retain those and delete the rest.
- Document the decision. Record why each retained dataset is kept, the basis, and the disposal date.
- Delete the rest. Where no basis exists, deletion is required; keeping data 'just in case' is the exposure.
The defensible position is a documented, field-level retention rule tied to a real limitation period - not a blanket 'keep in case'.
3. What should the ROPA contain, and how does it support the accountability review?
Read the worked answer
A usable ROPA should record, for each processing activity:
- Purpose and the lawful basis (including any special-category condition).
- Categories of data subjects and personal data.
- Recipients (internal and external, including processors and any transfers).
- Transfers to third countries and the mechanism.
- Retention rule and disposal method.
- Security measures at a level sufficient to demonstrate controls.
- Owner and review date.
How it supports the review: the ROPA is the spine of accountability. It lets the insurer answer 'what do you hold, why, for how long, who sees it, and how is it protected?' - the questions an accountability review will ask. It also drives the retention schedule (each activity has a rule), the privacy notice (the notice should mirror the ROPA), and the DPIA programme (high-risk activities surface). Without it, the insurer cannot demonstrate compliance even where it is compliant.
The practical point: a ROPA that lives in a spreadsheet nobody updates is not a ROPA. It needs an owner, a review cycle, and a link to the systems it describes.