# Interview recording retention: how long, and how to delete — Criterio Talent > How to set a retention period for an interview, what is deleted and what survives aggregated, and why storage must expire after the promise does. URL: https://criteriotalent.com/en/recursos/retencion-y-gobierno-de-datos/ --- **Issue 09 · May 2026** # Retention of interview recordings: how long to keep them, where, and how to actually delete them The period is the easy part. The hard part is deletion that actually happens, leaves a record, and does not block itself — which is exactly what happens when storage expires before the promise does. Method · Retention and data governance Published on 29 August 2026 · 6 min read **In short** The period is set by the concrete use that justifies keeping the material, written into the contract, and executed automatically. The purge has to record what it deleted, and storage expiry must be strictly longer than the promised period: if it expires first, the purge cannot find what it was going to delete, never closes the cycle, and personal data in the database quietly stops being cleaned. A recorded interview produces sensitive material in several places at once: the video, the word-by-word transcript, the assessment per competency, the contact details, and the logs recording who looked at what. Setting a retention period is the visible part of the problem, and also the easiest. The hard part comes afterwards, and it is almost never discussed at the table where things get signed: that deletion happens, that it can be demonstrated, and that the mechanism does not sabotage itself through a mismatch of dates nobody looks at. ## The period is decided by the use, not by convenience The right question is not how long the material can be kept, it is what concrete use justifies keeping it. Standing behind a decision when somebody challenges it is a real use, and it has an identifiable shelf life. “Just in case” is not a use: it is the absence of a decision, shaped like one. From that come different periods for different materials, and that is as it should be. The raw recording is usually the first thing that stops being needed, because its function — checking a conclusion against what was said — is largely covered by the transcript. What cannot happen is that none of them has a date. A quick test on a written period: if nobody on the team can explain what could be done with that material in the final month of the period, the period is longer than it needs to be and only adds surface to protect. ## What gets deleted and what survives aggregated Deleting cannot mean emptying the database and losing track of how many interviews ran last year. The distinction that resolves the conflict is between material that identifies a person and the accounting of the process, which does not need them. - Deleted: the recording, the transcript, the assessments with their verbatim quotes, the contact details, and anything from which who spoke could be reconstructed. - Survives: how many interviews there were, how many were completed, how long they ran on average, which competencies were assessed. Numbers about the process, not about the person. - The record of the deletion also survives, and it is the only thing that later allows compliance to be demonstrated. The trap is in aggregates over small samples. A statistic about a role with two candidates re-identifies the person the long way round, and it is worth treating as what it is rather than as an innocent figure. ## The purge has to record what it deleted A deletion process that leaves no trace is indistinguishable from a deletion process that never ran. And that distinction is exactly what has to be demonstrable when somebody asks: it is not enough that the record is gone, you have to be able to say when it went and why. What is worth keeping from each run is little and re-identifies nobody: which record expired, on what date, what was removed of each kind of material, and whether the cycle closed completely. With that, the answer to a review is a fact; without it, it is a promise. ## The hard lesson: storage has to expire later Almost every system has two clocks. One is the application’s promise: on the date, the purge walks the expired records and deletes. The other is the expiry of storage itself, that lifecycle rule which removes old objects on its own and gets configured once, on day one, and is never looked at again. If the two periods are equal, which one wins is a race. And if storage wins, something worse than losing a file early happens: the application purge goes looking for the object it expects to delete, does not find it, cannot declare the cycle closed, and leaves the record pending. It tries again the following night. And the next. The consequence is not the obvious one. What breaks is not the deletion of the recording — that is already gone — but everything queued behind it: the turns, the assessments, the contact details living in the database that the purge was going to clean in the same pass. They stop being deleted, indefinitely, and the only symptom is a pending counter climbing slowly on a dashboard nobody watches. The rule, then, is an invariant and not a preference: storage expiry has to be strictly longer than the promised period, with enough margin to cover several nights of failed purges. It stops being the thing that deletes and becomes what it should be: the net that catches whatever the application did not reach. An uncomfortable corollary: shortening the promised period means shortening the net too, or you end up keeping far more than you promised. The two dates move together, always in that order, and the margin is preserved. ## Who can download, and why a download is an event A retention period governs material inside the system. A download takes it out, and from that moment the file lives on a laptop, in an email, or in a shared folder no purge will ever reach. That is why downloading has to be a permission separate from viewing, not a consequence of having access to the report. And why every download has to land in the log with who, when and what: it is the one point where data governance stops being technical and starts depending on a person, and it is worth knowing which one. On what else that log should record, the [January issue](https://criteriotalent.com/en/recursos/evidencia-por-turno-trazabilidad/) goes into detail. ## What to ask a provider about deletion Six questions that get answered quickly and separate a real mechanism from an intention. The second column is what is worth listening to closely. An illustrative table for a provider review. The concrete answers for each implementation are delivered in writing, not summarised here. | Question | The answer that should worry you | Is deletion automatic, or does somebody trigger it? | “We do it on request.” Deletion that depends on somebody remembering is not a period, it is a habit. | What record remains of each purge? | “It gets deleted, that is all.” Without a record there is no way to demonstrate compliance. | How long is the storage rule against the promised period? | That they are equal, or that the question comes as a surprise. That is where the silent blockage in point 4 lives. | What happens with backups? | “We had not thought about that.” A backup with a life of its own reintroduces what was deleted. | Is downloading a different permission from viewing? | That it is the same permission. Then anyone who can read can take the material out of the system. | Do subprocessors delete when you delete? | A general answer. They should be able to name them and say what each one receives. ## What this does not solve A good deletion mechanism does not legitimise having collected material that was not needed. If more was recorded than the process required, deleting it on time reduces the harm but does not correct the original decision, which is taken much earlier and communicated at the moment of [consent](https://criteriotalent.com/en/recursos/voz-y-video-con-consentimiento/). Nor does it replace the analysis of which obligations apply to a given company, which depends on its activity and its jurisdiction and is not settled by an article. What is described here are the architectural decisions that let such an analysis find a system capable of meeting whatever is decided; the full position is in [security and data governance](https://criteriotalent.com/en/seguridad/). ## Questions about this issue ### Can material be kept longer if the person authorises it? It can be framed as a separate acceptance, with its own period and its own explanation, and it makes sense when the use is also different: being considered for future roles, for instance. What does not work is hiding that extension inside acceptance of the interview. ### What about backups? They are the usual blind spot. A backup with its own retention reintroduces material already deleted, so its cycle has to be declared and bounded, and its period counts alongside the rest. ### How is compliance demonstrated without keeping what was deleted? With the purge record: which file expired, when, what was removed, and whether the cycle closed. It is a record about the process, not about the person, which is why it can outlive the material. **To keep reading on this site** ### [Solutions](https://criteriotalent.com/en/soluciones/) How it is configured for high volume, technical profiles, leadership, and multi-round processes. ### [Platform](https://criteriotalent.com/en/plataforma/) How it runs the interview, follows up, and cites the evidence behind each conclusion. ### [Integrations](https://criteriotalent.com/en/integraciones/) How your ATS requests the interview and receives the report, with nobody retyping anything. ### [Contact](https://criteriotalent.com/en/contacto/) A 30-minute demo on a real role of yours. **Other issues** **Method · Consent and recording** ### [Voice and video interviews: what consent has to say, and when you ask for it](https://criteriotalent.com/en/recursos/voz-y-video-con-consentimiento/) Consent asked for after the microphone is on is no longer consent. What it has to contain, when to ask, and what to keep as proof that it was given. **Method · Evidence and traceability** ### [Turn-level evidence: what to keep from an interview so you can still defend it six months later](https://criteriotalent.com/en/recursos/evidencia-por-turno-trazabilidad/) The uncomfortable question does not arrive on decision day: it arrives half a year later, once the team has changed. This is what has to be stored to answer it. **Method · Interview design** ### [How to design a structured AI interview that leaves useful evidence and keeps the decision human](https://criteriotalent.com/en/recursos/entrevista-estructurada-con-ia/) Eight design decisions, in order. The first is the one almost everyone skips: you do not ask a model to judge, you ask it to document. **Next step** ## See it with a role of yours on the table. Thirty minutes: an interview is defined from your job post, walked through the way the candidate sees it, and a report is read with its evidence.