Product teams treat recordings like assets: capture everything, keep it forever, search it later. Security teams treat recordings like inventory that can explode. Both are describing the same files. A retention policy is where you decide which description wins. After the first month, the risk usually outgrows the value.
The value decays; the liability doesn't
A recording is most useful in the days after the call: the summary gets shared, action items get extracted, someone checks exactly what was promised. Six months later, almost nobody replays the audio. But the file is still there, still holding every offhand remark, every customer detail, every candid assessment of a partner. Its usefulness decayed. Its exposure did not. Anything you store can be breached, subpoenaed, or swept into a data-subject request, and a recording is among the most sensitive artifacts a product can hold, because nobody in the room chose their words for an archive.
Default to 30 days, allow 1 to 365
Few tenants ever touch a retention setting, so the number you ship becomes the retention policy for nearly every recording you hold. Thirty days covers the real use cases (notes, follow-ups, the occasional "what exactly did they say") with room to spare, and it caps the exposure from everything above. Make the window configurable, one day to a year, because legitimate needs differ. A sales team wants weeks. A regulated customer may want a year, on purpose, in writing. What nobody should get silently is forever.
Retain for the reason you recorded
Ask why the recording exists, and let the answer set the clock. If the point was notes, the transcript and summary are the product; keep those and let the raw media expire in days. If the point is compliance, keep the media for the mandated period, and write that period down where auditors can find it. The expensive mistake is one retention rule stretched across both: media kept for a year to serve a notes use case, or compliance recordings deleted by a default nobody reviewed.
The artifacts do not have to share one expiry date either. The media is the heaviest and most sensitive thing you hold. The transcript is smaller and easier to search. The summary is what people actually reopen. Expire them in order of risk, and most of the product value survives the deletion of most of the exposure.
Deletion is a feature
Build deletion as a first-class operation, not a cleanup script. A host should be able to delete one recording on request, because the request will come. An admin should be able to delete everything for a departing customer. Your API should expose deletion so your product can honor its own promises programmatically. If deleting a recording feels dangerous in your architecture, that is the architecture telling you it was designed for accumulation. Test the delete path the way you test the record path. An untested delete is a promise you have not kept yet.
What "deleted" should mean
Deleted has to mean something you could defend in front of the customer who asked. Three things, specifically.
- The media, transcript, and summary leave primary storage and expire from backups on a documented schedule.
- Derived artifacts go with the source: embeddings, search indexes, cached snippets. A searchable index of a deleted call is not deletion.
- An audit record stays behind: the fact that a recording existed, when, and when it was purged. Content goes; accountability remains.
Horato's recorder defaults to this posture: 30-day retention, configurable from 1 to 365 days, with completed transcripts snapshotted and retrievable by API until the window closes. Shorter is safer, so configure up from safe rather than down from forever.