Choosing a retention policy

The question underneath "how long should we keep this"

GDPR's storage-limitation principle (Art. 5(1)(e)) says personal data should be kept "for no longer than is necessary for the purposes for which [it is] processed." That's a real legal obligation, whatever channel you're running — but "necessary" isn't self-defining, and a company setting up a channel from scratch has to translate it into actual numbers before day one, not after an auditor asks. The framework below is how to think about that translation; how Provoxis has implemented it is one worked example, not the only correct answer.

A case's outcome should drive how long it's kept, not a single blanket window

The mistake to avoid is picking one retention period and applying it to everything that comes through the channel. A matter that turns out to have nothing to do with the channel at all doesn't need the same retention as a substantiated finding, and a substantiated finding that's still under active legal or disciplinary proceedings needs different treatment again — deleting evidence a company is legally required to preserve is a far bigger problem than deleting it a few months earlier than ideal. A sound retention design starts by asking what a case's outcome actually implies about how long the record still matters, not by picking one number for every case.

A reasonable general shape, independent of any specific vendor:

• Out of scope — a matter that wasn't really something this channel should have been handling. Short retention is defensible; there's little ongoing purpose served by keeping it long.
• A founded case with no ongoing proceedings — retained for a meaningful, multi-year window, long enough to be useful as a record if the same pattern recurs or a claim is raised later, short enough that it isn't kept indefinitely by default.
• A case under active or reasonably anticipated legal or disciplinary proceedings — retained indefinitely, or at least until those proceedings actually conclude, and never subject to automatic deletion in the meantime. This is where GDPR's own erasure-right exemption for establishing, exercising, or defending legal claims (Art. 17(3)(e)) becomes directly relevant — see the legal hold section below for how that gets exercised case by case, on top of whatever schedule the other tiers follow.

How Provoxis has implemented this today

Provoxis's own defaults follow exactly that shape. When a handler closes a case, they record the outcome (Substantiated, Partially substantiated, Unsubstantiated, or Referred externally) and, separately, which retention tier applies — the two are independent, so an Unsubstantiated case can still sit in the same tier as a Substantiated one:

• Out of scope — kept 60 days after closing, then eligible for automatic purge.
• Standard — the default for a founded case with no ongoing proceedings. The window follows your account's own registered country: where that country's national law implementing the Directive sets a specific period, Provoxis uses it — we've found figures ranging from 3 months (Cyprus) to 5 years (Italy, among others) across the EU, with Germany and Poland both at 3 years. Where a country's law sets no specific period, the default is 5 years. Either way, once the window closes the case becomes eligible for automatic purge.
• Disciplinary or legal — for a case where proceedings are still ongoing. Kept indefinitely; never auto-purged. The only way off this tier is a handler reopening the case once proceedings actually conclude and choosing a different tier when it's re-closed.

The out-of-scope and disciplinary-or-legal windows are fixed and apply the same way across every company using Provoxis today; the standard window is set automatically from your account's registered country rather than something you configure yourself. That's a deliberate starting position, not a gap: the defaults — including the per-country figure — are built to satisfy the storage-limitation principle from the moment a channel goes live, rather than leaving a company to design its own schedule from scratch before it can be compliant on day one. If your own reasoning lands somewhere different from these specific numbers, that's a legitimate outcome of running the framework above yourself — the framework matters more than matching Provoxis's exact figures.

The override every framework needs: legal hold

Whatever schedule you land on, automated deletion running unattended against a case under active or reasonably anticipated legal proceedings would be a genuine problem, not just an inconvenience — and GDPR's Art. 17(3)(e) exemption exists precisely so preservation can override the default schedule when that happens. In Provoxis, an admin sets a hold — a reason is required, and it's logged — and the case is excluded from automatic purge entirely, independent of whatever tier it's actually sitting in. Releasing a hold also requires a reason and is logged the same way; only once it's released does the case go back to being governed by its tier again.

Separately, a tenant admin can manually erase a case's data on demand — to action a data-subject erasure request that isn't covered by the legal-claims exemption, for instance. That's blocked outright while a legal hold is active: the hold has to be explicitly released first, itself a logged action, so a hold can never be quietly worked around by a manual delete.

Legal basis

• Art. 5(1)(e), GDPR — the storage-limitation principle: personal data kept no longer than necessary for the purpose it was processed for.
• Art. 17(3)(e), GDPR — the erasure-right exemption for establishing, exercising, or defending legal claims, the basis for legal hold overriding automatic purge.