Recording, Consent and Retention for Voice Products

Whether you may record a call, whom you must tell, what you may keep and for how long are legal questions whose answers differ by jurisdiction, by industry and by what you are recording for. This page gives you the shape of those questions and the architecture that holds up whichever way they are answered.

What this page is and is not

There is a genre of article that presents a table of countries and states with “one-party” or “two-party” next to each. Those tables are frequently out of date, frequently wrong about the exceptions that actually decide cases, and always missing the sectoral rules that override them. Following one without advice is a way to be confidently non-compliant.

What is genuinely transferable is the structure: the same six or seven questions determine the answer everywhere, and the engineering needed to satisfy any answer is the same engineering. That is what follows.

The axes jurisdictions differ on

Notice and consent, mechanically

Whatever the answer turns out to be, the implementation problems are the same, and each has a wrong version that is very common:

1. The notice must be heard, not merely played. A recording announcement that plays while the caller is still connecting has not been delivered. Play it after the media path is established and confirm it completed — and do not let barge-in cancel it, which is exactly the class of utterance that must be marked non-interruptible.
2. Record the consent event, not the consent flag. Store what was said, which version of the wording, at what time, on which call, and what the caller did in response. A boolean column proves nothing eighteen months later; the wording will have changed twice by then, so store the version identifier with it.
3. Handle refusal as a real path. If a caller declines, the call must still be able to proceed — without recording, with a transfer, or with a clear explanation of why it cannot. A system whose only branch is “consent granted” will get the wrong flag written rather than the right behaviour.
4. Start recording after the notice, never before. This sounds obvious and is routinely violated by platforms that begin capture on answer. Check what your telephony provider actually does; “we discard the first ten seconds” is not the same as not recording it.
5. Handle transfers and conferences. A third party joining mid-call has not heard the notice. This is a common gap, and it is a state machine problem: re-announce on every participant change.
6. Make withdrawal reachable. If someone asks mid-call to stop being recorded, there must be a control that does it and a record that it happened. If withdrawal also entails deletion of what was already captured, that must be a job that exists.

Retention is a schedule, not a setting

“How long do we keep it” has no single answer, because different pieces of the same call are kept for different reasons and for different periods. Design it as a table from the start; retrofitting per-artefact retention onto a system that stored everything in one bucket is a large project.

One row per artefact, not one policy per system:

  artefact              typical driver of the period
  --------------------  ------------------------------------------
  raw audio             the shortest of everything here. Usually
                        kept only as long as the purpose that
                        justified recording requires.
  transcript            often longer than the audio, because it
                        serves the business purpose with less
                        personal data in it
  redacted transcript   longer still; the point of redaction is to
                        allow a longer life
  extracted fields      the structured outcome of the call
  speaker embedding     shortest and strictest if it is treated as
                        biometric data
  model training copy   a SEPARATE purpose needing a separate
                        basis, and frequently a separate consent
  audit log             usually the longest, and usually required
                        to be immutable

For each row, record and be able to show:

  purpose        why this exists at all
  basis          what makes keeping it lawful
  period         the number, and what it was derived from
  trigger        what starts the clock -- call end, case closure,
                 contract end, last contact
  deletion       the job that enforces it, and its last run
  exceptions     legal hold, dispute, regulatory retention -- and
                 how an exception is lifted again

Two implementation notes that are the difference between a policy and a fact. Deletion must reach backups, replicas, search indexes, analytics warehouses and the caches in front of them — a retention job that only clears the primary store leaves the data in four other places, and it is generally the analytics copy that gets discovered. And deletion must be observable: a job whose last successful run is unknown is not a control, and being able to produce a deletion certificate per record is worth building before you need it.

Transcripts, embeddings and derived data

The most common architectural mistake in this area is treating the audio as the sensitive asset and the derivatives as harmless. The derivatives are frequently more exposed, because they are the ones that get copied into systems designed for analysis.

• The transcript is the personal data, in the form most useful to everyone. It is indexed, searchable, joined to customer records and shipped to analytics. Redact at capture rather than on request; the general approach is set out in keeping PII out of logs and redaction techniques, and it applies unchanged here.
• Redact the audio too, if you keep it. You have word timestamps from alignment, so silencing the spans containing a card number is a solved problem. Very few systems do it, and it is the single most effective control available for payment audio.
• A speaker embedding is not anonymous. It is derived specifically to identify the individual, which is the definition it will be assessed against. Treat it as at least as sensitive as the audio, and consider whether you need to store it at all.
• Training on recordings is a separate purpose. Consent to be recorded for quality assurance is not obviously consent to have the recording used to train a model, and this distinction is attracting increasing attention. It needs its own basis, its own record, and — practically — its own copy of the data with its own retention.
• Your vendors inherit all of it. A speech API, a model provider and a storage provider are all processing this data. Their sub-processors matter, their retention defaults matter, and whether they train on your inputs matters. See data processing agreements for what to establish before sending the first request.

The build that survives the answer

You can build most of this before counsel has answered anything, because the same architecture supports every answer. What you cannot do is bolt it on afterwards.

1. Make recording a decision, not a default. A per-call evaluation with inputs — jurisdiction of each party, purpose, consent state, sector — that returns whether to record and what notice to play. Even if today it always returns yes, the seam exists.
2. Tag every artefact at creation with purpose, basis, jurisdiction and retention class. Retention that is computed from tags is enforceable; retention that depends on somebody remembering which bucket a file went into is not.
3. Separate the stores by retention class, so the shortest-lived data is not sitting in the same place as the longest-lived. This makes deletion a cheap operation instead of a scan.
4. Build deletion before you build retention. The deletion path is the one that will be tested under pressure. Write it first, run it on a schedule from day one, and log every execution.
5. Log access to recordings and transcripts. Who listened to what and when is the question every investigation opens with, and it cannot be answered retrospectively.
6. Write down the questions you could not answer and take that list to counsel. The list in the axes table above is a reasonable starting agenda, and arriving with it is worth several hours of anyone’s time.

One last practical point. Automated outbound calling is regulated separately and often more strictly than recording, in ways that involve consent registers, permitted hours and disclosure requirements. If your phone agent dials out rather than answering, that is a second body of rules and it needs its own conversation.