Retention & deletion

Storage limitation is the principle most often violated in practice, because nobody actively breaks it: people simply do not delete. SimpleAct therefore separates two things that often get mixed up – the deadline, which comes from the records of processing, and the evidence that deletion actually happened.

The deadline lives in the register, not here

Every record of processing carries a retention period – as text for readability and additionally in days for evaluation. That value is the only source for deadlines; nothing is maintained twice here. If the deadline changes, you change the processing record.

What this module produces is the other half: the proof that deletion took place. Without it, a retention period in the register is merely a statement of intent.

What a deletion run records

• The processing activity concerned. The reference is validated – a deletion run without a valid link to a processing record cannot be created.
• The time of execution. Without a value, the time of recording is used.
• The number of objects affected – records, files, accounts. This is the figure an auditor uses to judge plausibility.
• Who executed the run, plus notes on the approach – for example which script or which service provider was involved.
• The execution method. Recorded runs are tracked as manual; the field is prepared to distinguish scheduled runs later.

How to work with it

1. 1In the records of processing, store a retention period in days and a deletion concept for every activity.
2. 2Set a fixed cadence at which deletions are actually carried out – quarterly is enough in most organizations.
3. 3After each run, record a deletion run with the number of objects affected and notes.
4. 4The overview shows how many runs there have been in total and when the last one was – the first question an audit asks.