A retention schedule deletes live CRM records on time, but backup tapes indefinitely retain the same personal data with no workable purge path. What does storage limitation require in this situation?
Select an answer to reveal the explanation.
Short Explanation
Deleting the live record while forever-hoarding the same person on backup tapes is like shredding the front page and framing the carbon copy. Storage limitation has to reach the copies that still identify people, within what is feasible. A schedule that ignores backups is only half a schedule.
Full Explanation
Storage limitation should be effective across operational systems and backup copies where feasible, so personal data are not kept identifiable longer than necessary simply because a backup exists. Deleting live CRM records on schedule while backup tapes indefinitely retain the same personal data with no workable purge path undermines the principle in practice: the person remains identifiable in the shadow archive.
Backups are not permanently exempt from storage limitation under every circumstance. Marketing databases are not the only systems needing retention schedules; backups that preserve identifiable personal data need governed retention and deletion or anonymisation strategies. Storage limitation is not limited to anonymised aggregates; it targets identifiable personal data precisely.
Exam caveat: retention compliance includes backups—not only production delete buttons. Operational check: define backup retention aligned to purpose limits, implement crypto-shredding or timed purge where feasible, inventory tape/object archives, and document residual backup risks. Civic IT should not quietly immortalise resident CRM data on tape after the public-facing system “deleted” them; stewards must close the shadow-copy loophole.