REVIEWITDocumentation
ConceptUp to date · verified on 30 August 2026

Retention

Machine translation, not yet reviewedThis page was translated by a model from the French version, which is authoritative. Read the French version.

01Keep with a reason, delete with proof #sec_9021b67c

Retention is not about applying the same duration to an entire database. A governance platform contains data of very different natures: replaceable work information, probative decisions, cryptographic secrets, technical logs and anonymized statistics. Keeping or deleting them in the same way would result in either unjustified accumulation or the premature destruction of evidence.

REVIEWIT therefore associates each data category with a class, a trigger, and an end-of-life rule. Duration is only part of the rule. For some objects, eligibility for purging depends on a relationship: a still-alive attestation can extend its snapshot, an open remediation obligation cannot be deleted, a verification package follows exactly the attestation it serves.

The guiding principle is twofold: keep nothing without purpose, and never make evidence unverifiable by deleting one of its components too soon.

02Four classes, four end-of-lives #sec_9eecf111

C1 — Operational data. They are alive, replaceable or reproducible: temporary files, caches, generated exports, notifications, technical logs. Their end-of-life is generally a direct physical deletion after a short duration or the end of their usefulness.

C2 — Probative data. They tell an act or support an attestation: certification decisions, audit trail, remediation obligations, manifests and findings. They do not purge like an ordinary line. When they participate in a chain of integrity, the purge works by coherent set and leaves a marker that allows to detect that a content has legitimately disappeared.

C3 — Cryptographic data. Keys, secret generations, receipts and authority states have their own cycle governed by SEAL. Their duration is not mechanically aligned with the business data, but it can never be shorter than that of the evidence that depends on it.

C4 — Derived data. Statistics and aggregates can be kept beyond the source data only if their irreversible anonymization is demonstrated.

The class describes the end-of-life mechanism, not the apparent importance of the data. An accounting document kept for ten years can remain operational data if, when the time comes, its deletion is ordinary.

03One policy per profile, with limits #sec_bf13aace

The Standard profile provides an immediately usable framework. For example, certification results and business audit are kept for three years, security audit for twelve months, technical logs for ninety days, exports for thirty days, and backups in a dedicated sliding window.

Regulated or Customized profiles can extend certain durations. Customization is never a free-form entry « forever »: it carries a reason, an approver, an effective date and a review date. Without renewal, the rule reverts to the reference profile.

Two limits prevent inconsistent configurations:

  • an absolute high limit, which can only be exceeded by a nominative, motivated and re-examined derogation;
  • a low limit for data exposed to an external consumer by incremental flow, so that the replay window remains truly usable.

The backup window is not a minimum retention period. It indicates the maximum delay before complete erasure of all copies. A data can disappear from active systems after thirty days and only become completely erased after the expiration of the backups that contained it.

04Dependencies take precedence over the calendar #sec_3bbd8efa

A date alone is not always sufficient to authorize a purge.

The snapshot of a campaign is kept as long as a live attestation references it. A remediation obligation becomes eligible only after entering a terminal state, then remains protected by the attestations to which it is linked. Dispatches, findings and runbook acts follow the obligation they document. The verification package follows the attestation as an inseparable unit.

Conversely, technical execution logs do not acquire long retention simply because they contributed to a probative operation. REVIEWIT keeps the result and the useful evidence, not indefinitely every operational detail.

This dependency graph avoids two classic mistakes: deleting a still-necessary support, or keeping everything « just in case » for lack of knowing what is really indispensable.

05Prove the purge without keeping the purged data #sec_6d46e81c

Each retention cycle produces an execution log: evaluated scope, applied rule, processed volumes and reasons for non-purges. This log is not deleted by the mechanism it documents.

For chained or sealed data, REVIEWIT keeps a non-identifying technical proof of the purge. It allows to distinguish an authorized withdrawal from a clandestine alteration, without recreating an object identifier or keeping the deleted content.

Archiving and purging remain two different operations. Archiving moves content to cold storage while maintaining its restitution capability. Purging destroys it without return. The system makes this boundary visible in its states and in the produced reports.

06In summary #sec_e5d20280

Retention in REVIEWIT is a governance engine, not a global timer. It takes into account the nature of the data, their dependencies and the expected guarantees. It can explain why one data remains, why another leaves, and produce durable proof of deletion without keeping what was supposed to disappear.

Esc
↑↓ navigate↵ openSee all results →