Most teams are good at collecting data and bad at getting rid of it. Systems fill up with old customer records, files on former employees, support tickets from three years ago, and backups nobody remembers making. Then a customer asks how long you keep their data, or an auditor asks to see your retention schedule, and you realize you don't have a clear answer.

Retention is where a lot of compliance programs quietly fall apart. Keeping everything feels safe, but under GDPR it's the opposite. This guide covers what storage limitation asks of you, how to set retention periods that hold up, and how to delete data in a way you can actually prove, all as part of a living program in OptiTech.

What storage limitation actually means

Storage limitation is one of the core principles in Article 5 of GDPR. In plain terms, you can only keep personal data for as long as you actually need it for the purpose you collected it. Once that purpose is met, you delete it or anonymize it.

The catch is that "as long as you need it" isn't a number the law hands you. You have to decide it, justify it, and stick to it. A retention period that's too short can break a contract or a legal obligation. One that's too long turns every old record into risk: more to secure, more to disclose in a breach, more to dig through when someone asks to be forgotten.

The principle rewards discipline. Keep what you need for a reason you can name, and delete the rest on a schedule you can show.

Set retention periods by category and purpose

The mistake most teams make is setting one retention period for everything. Real data doesn't work that way. A signed contract, a marketing email address, a job applicant's CV, and a security log all have different reasons to exist and different clocks.

Start from purpose, not from the data itself. For each thing you do with personal data, ask two questions: why do we hold this, and what tells us we're done? The answer usually comes from one of a few places:

  • A legal obligation. Accounting records, for example, often carry a statutory retention period you don't get to choose.
  • A contract. You keep customer data for the life of the account plus a wind-down window.
  • A legitimate need. Security logs might stay for a fixed number of months to support incident investigation.
  • Consent. A marketing list lasts until the person opts out or goes cold.

Once you've grouped data by category and purpose, each group gets its own retention period with a reason attached. That reason is the part auditors care about. A retention period without a justification is just a guess.

Sometimes you have to keep data past its normal retention period, and deleting it on schedule would be a mistake. Litigation, a regulatory investigation, or a dispute can all trigger a legal hold: a deliberate freeze that overrides the clock for a specific set of records.

Legal holds are easy to get wrong in both directions. Miss one and you destroy evidence you were obligated to keep. Forget to lift one and you're back to hoarding data long after the reason expired. Either way, the fix is the same: the hold has to be a recorded decision with an owner, a scope, and a start and end, not a note in someone's inbox.

Treat the hold as a documented exception to your schedule. When it's lifted, the normal retention period takes over again and the data flows back into the deletion routine.

Deletion that actually deletes

Hitting delete in one tool isn't the same as deleting data. Copies linger in backups, exports, connected tools, and the accounts of vendors who process data on your behalf. Secure deletion means the data is genuinely gone or rendered unrecoverable everywhere it lived, including those copies.

You have two honest options when a retention period ends:

  • Secure deletion. The data is removed and can't be reconstructed. For most personal data, this is the goal.
  • Anonymization. You strip out everything that ties the data to a person, so what's left can't identify anyone. Done properly, anonymized data falls outside GDPR, which is useful when you want to keep aggregate insight without keeping the person.

The word "properly" carries weight. Weak anonymization that can be reversed with a bit of effort is really pseudonymization, and pseudonymized data is still personal data. If you can re-identify someone by combining a few fields, you haven't anonymized anything.

Write the schedule down

A retention schedule is the document that ties it all together. For every category of personal data it states the purpose, the retention period, the trigger that starts the clock, the deletion or anonymization method, and the owner. It's the artifact a customer or an auditor asks for when they want to know you've thought this through.

A schedule that lives in a spreadsheet goes stale the moment someone adds a new tool or launches a new feature. It also sits disconnected from the rest of your compliance work, so nobody notices when reality drifts away from the document.

In OptiTech the schedule isn't a standalone file. Each retention period attaches to the processing activity it belongs to, so the same register that records why you process data also records how long you keep it. Change a processing activity and the retention question is right there, instead of buried in a document someone forgot to update.

Tie retention to the activity, not the tool

Tools come and go, but the reason you hold data outlasts them. When you anchor a retention period to a processing activity instead of a specific system, a tool migration doesn't quietly reset your clock or orphan your schedule.

Prove the deletion happened

Deleting data is only half the obligation. When someone exercises their right to erasure, or when an auditor checks that you follow your own schedule, you have to show that deletion actually took place. "We definitely deleted it" isn't evidence.

Proof doesn't mean keeping the data you deleted, which would defeat the point. It means keeping a record of the event: what category was deleted, when, under which retention period, by whom, and by what method. That record is evidence, and it's exactly what closes out an erasure request or a control test without a scramble.

In the OptiTech Console, these deletion records live as evidence linked to the control and the processing activity they satisfy. When a security review asks how you handle retention, you point to a schedule that's current and a trail that shows you follow it.

Keep the schedule as living evidence

The reason retention breaks down is that it's treated as a policy you write once and never revisit. A living program flips that. Your retention schedule connects to your processing activities, your deletion records pile up as evidence, and your legal holds are tracked decisions rather than sticky notes.

That connection is what turns retention from a liability into an asset. The same work that keeps you compliant also feeds your trust center, where buyers can see that you don't hoard their data and that you delete it on a schedule you can prove. A security review that used to stall on "how long do you keep our data?" answers itself.

Getting started

You don't need a perfect schedule on day one. A realistic first pass looks like this:

  1. List your processing activities and note what personal data each one touches.
  2. Set a retention period and a reason for each category, starting with the data that carries legal or contractual clocks.
  3. Decide delete or anonymize for each category, and write down the method.
  4. Stand up a legal hold process so exceptions are recorded, not improvised.
  5. Capture deletion as evidence so proof builds up on its own.

Retention rewards the teams that treat it as a habit rather than a cleanup project. Set the periods once, tie them to the work that justifies them, and both your auditors and your buyers get the same clear answer.

Ready to turn retention into a living program? Book a demo and see how OptiTech ties your retention periods to your processing activities and keeps the schedule as evidence.