Most UK contact centres think they have call recording solved because the files exist on a server somewhere. The FCA, the ICO, and the Financial Ombudsman Service have a more specific view: a recording that cannot be produced, indexed, redacted, and properly retained on demand is not a compliant recording. It is a liability that happens to take up disk space.
This article is the practical checklist Telebyte applies when reviewing a UK firm's call-recording posture. It is sector-aware (most readers will be in insurance, claims, mortgage advice, or consumer credit), built for FCA-regulated operations specifically, and written by people who run a regulated UK contact centre on the same stack they recommend. The longer version, with templates and worked examples, is available as a 14-page PDF on the Resources page.
What the rules actually require
The UK regulatory stack on call recording in 2026 is multi-layered. No single document tells you what to do; the obligations are distributed across:
- FCA SYSC 10A — the original recording obligation for relevant communications relating to investment services, derived from MiFID II and retained in UK rules post-Brexit. Five years for most investment-service calls, seven where the FCA has indicated.
- Consumer Duty (PRIN 2A) — does not impose a recording duty directly, but the evidence requirement around delivering "good outcomes" effectively forces firms to retain enough call data to demonstrate the outcome.
- PECR (the Privacy and Electronic Communications Regulations 2003) — governs how recording must be disclosed to the caller and the lawful basis for processing.
- UK GDPR / DPA 2018 — governs storage, retention, access, and the data-subject rights regime (SARs, erasure requests, rectification).
- DISP rules — the Financial Ombudsman Service evidence regime. FOS expects firms to produce specific recordings, with timestamps and context, within reasonable timeframes when a complaint is referred.
- ICO guidance on direct marketing and recording — non-binding but routinely cited.
The practical effect of stacking those obligations is that any UK call centre processing financial-services calls needs a recording posture that satisfies all of them simultaneously. The checklist below is the minimum that meets that bar.
The Telebyte FCA call-recording checklist
The format is deliberately blunt. Each item is something Telebyte either finds in place during a review or flags as a gap. Most reviews surface gaps in at least four of the items below.
1. Retention period: seven years, applied per call
The FCA's standard expectation for investment-services calls is five years; for retail consumer-credit and insurance-distribution contexts the practical floor is seven, partly because of the FOS evidence regime and partly because of HMRC tax-recordkeeping rules that often catch the same data. Seven years is the safe default.
The retention is per call, not per dataset. Calls from 2018 may have expired; calls from 2019 may not. A blanket "we keep everything from the last seven years and delete the rest annually" policy is fine in principle, but only if your indexing supports a per-call deletion decision. Most filesystem-only approaches do not.
2. A configurable retention engine, not a manual purge
The purge of expired recordings has to be auditable. A nightly job that walks the recording-log table, identifies calls past the retention window, and deletes the file plus an associated SHA-256 manifest entry is the right pattern. Manual deletion or annual mass deletion fails both the audit trail test and the data minimisation principle of UK GDPR.
A subtle point: the audit trail of the deletion must itself be retained, typically for one year past the deletion event. That is what allows a future ICO query of "did you delete recording X" to be answered authoritatively.
3. Legal-hold flag that overrides the retention engine
Any recording subject to an active complaint, FOS referral, regulatory investigation, civil litigation, or SAR cannot be deleted, even if it crosses the retention horizon. A boolean legal_hold column on the recording-log table, set explicitly by the compliance team, that the purge job respects, is the standard pattern. Combined with a short audit table of when the hold was applied, by whom, and against which incident reference.
The most common audit finding here is firms that have no legal-hold mechanism and rely on the compliance team remembering not to delete things. That is not a defensible position.
4. Encryption at rest
Recording files are personal data under UK GDPR. Storing them on an unencrypted filesystem is technically possible and operationally indefensible. Telebyte's standard is LUKS encryption on the recording volume with the unlock key held in a secrets manager separate from the host. A managed cloud equivalent is server-side encryption (AES-256) with KMS-managed keys.
The technical control matters; so does the documentation. The ICO's expectation in a breach scenario is that the firm can produce written evidence that encryption was in place at the time of the breach. A cryptsetup status output is necessary but not sufficient.
5. Disclosure to the caller
PECR Regulation 6 plus the more recent ICO guidance puts the disclosure-to-caller requirement on solid ground. A pre-recorded message at the start of inbound calls — "Calls may be recorded and monitored for quality and regulatory purposes" — is the floor. Outbound calls have the same requirement, typically delivered as the first line of the agent script.
The disclosure must be in the recording. The agent-introduction practice of saying "this call is recorded" but not capturing that statement on the recording itself fails the audit. The disclosure has to be inside the artefact it concerns.
6. Indexing by phone, agent, disposition, date, and campaign
The "find that specific call" lookup is what separates a real compliance posture from a theoretical one. The minimum required indexes:
phone_number— to satisfy a SAR for all recordings of a given individual.agent_id— to satisfy a FOS query about a specific representative's conduct.disposition— to retrieve all calls with a specific outcome, e.g. all sales completions in a campaign window.call_date— for date-range queries during an investigation.campaign_id— to scope investigations to a specific product or channel.
Each of these is a SQL index on the dialler's vicidial_log and recording_log tables. ViciDial provides them out of the box. Most homebrew recording setups against generic Asterisk do not, which is why migration projects from those setups tend to surface compliance gaps.
7. Transcript indexing and full-text search
Optional in 2024. In 2026, increasingly expected for any firm above 50,000 calls per year. The pattern: each recording is transcribed via Whisper (or a cloud equivalent) at the point of completion, the transcript is stored alongside the recording, and a FULLTEXT index on the transcript text supports queries of the form "return all calls in 2025 where the customer used the word cancel".
The compliance value is twofold. First, it makes content-based searches across the archive a SQL query rather than a multi-day project. Second, it allows the surveillance regime — sampling, sentiment analysis, keyword alerts — that Consumer Duty's "act in good faith" obligation effectively requires for any firm at meaningful scale.
Telebyte runs this on its reference deployment across over 9 million recordings, on roughly £200/month of GPU-accelerated VPS infrastructure. The cost is not the obstacle people often think it is.
8. Redaction policy for cardholder data and other sensitive payloads
Where the call captures cardholder data (PAN, CV2, expiry date) the recording must be redacted before retention, or the call recording must be paused-and-resumed during the sensitive segment. PCI-DSS makes this explicit; the FCA and ICO concur via UK GDPR's principle of data minimisation.
The pause-and-resume approach is simpler to implement in ViciDial (a dialplan-level recording pause triggered by the agent screen). The post-call redaction approach — silence-stamp the relevant segment of the WAV based on speech-to-text detection of payment-card patterns — is more reliable but more expensive to operate. Both are acceptable; doing neither is not.
9. SAR fulfilment within one calendar month
A subject access request gives the data subject the right to receive their personal data within one calendar month (extendable by two further months in genuinely complex cases). Recordings count. The practical bar is: from receipt of a valid SAR, can the firm retrieve every recording featuring the named individual's phone number, redact any third-party data on the recordings, and produce them in a portable format, inside 30 calendar days?
Most UK contact centres fail this on the retrieval step alone. The phone-number index above is what makes retrieval take minutes rather than days. Without it, the firm is searching by manual review or by reconstructing from CRM logs, and the SAR clock runs out.
10. FOS evidence within the FOS deadline
The Financial Ombudsman Service routinely requests specific calls — by call date, claimant identity, or a transaction reference — as part of complaint investigation. The deadline varies but eight weeks is typical. The retrieval pattern is the same as for SAR; the audit posture is different, because FOS will form an opinion about the firm's general posture from the speed and completeness of the response.
The recurring lesson here is that the firms with the worst FOS uphold-rates are often the firms with the worst recording posture, because the inability to produce evidence is read by FOS — fairly, in most cases — as evidence of absence. A robust recording stack is partly a compliance investment and partly an investment in defendability against complaints.
11. Access controls and audit logging
Who can listen to recordings, and when, is itself audited under UK GDPR. The standard pattern: every recording playback is logged with the listener's identity, the recording ID, the timestamp, and (if recorded over the dialler agent screen) the duration listened. Access is restricted to compliance, supervisors, and named technical operators. Bulk export of recordings requires a separate authorisation flow.
ViciDial provides the access log out of the box on the agent web interface. Bespoke recording-search portals — common in larger operations — need to implement this from scratch. It is the single most-overlooked control in custom-build environments.
12. Offsite backup with the same encryption posture
Recordings need to survive a recording-server failure, and that survival requires offsite storage. The compliance constraint is that the offsite copy needs the same encryption and access posture as the primary, or better. Sending nightly rsyncs to a NAS in someone's garage is not compliant, however convenient.
Telebyte's standard: nightly rsync to S3-compatible object storage in a separate region, server-side encrypted with KMS-managed keys, with lifecycle rules mirroring the primary retention policy. Versioning enabled; bucket policy denying delete from the dialler IAM role.
13. A documented operating procedure
The technical posture above is necessary; documentation is what makes it auditable. A short operating procedure document — typically four to six pages — covering retention policy, encryption, access control, SAR fulfilment workflow, FOS workflow, and breach notification, signed off by an accountable senior manager. Updated annually or after any material change to the recording stack.
The ICO and FCA do not expect a 50-page manual. They expect to be able to read the controls in plain English, see the sign-off, and form a view that the firm has thought about the problem.
14. Annual review and tested SAR response
The whole stack should be exercised at least once a year. The standard pattern is a fire-drill SAR: the compliance team picks a random phone number from the archive, requests all recordings, and the operations team produces them within the regulatory window. Anything that breaks is documented and fixed.
Operations that do not exercise the stack annually discover the breakage when the first real SAR arrives, which is the worst possible time.
The common failure modes
In Telebyte's experience reviewing UK contact-centre installations, the same handful of gaps appear over and over:
- Recordings exist on a NAS with no index. Retrieval is by manual review.
- Retention policy exists on paper but no automated purge is running, so recordings from 2014 are still present.
- No legal-hold mechanism; the compliance team relies on memory.
- No access logging on the recording search portal.
- Disclosure to the caller is in the agent script but not captured on the recording.
- Offsite backup exists but to an unencrypted target.
Each of these is fixable. The order of fix matters: indexing first (because without it the rest is academic), then retention engine, then encryption posture, then access controls, then disclosure, then offsite. Most operations can close all six gaps inside a calendar quarter.
The longer version
This article is a high-level checklist. The longer version — a 14-page PDF with worked examples, template documents, the relevant ICO and FCA citations, and a worked-example SAR response — is available free on the Resources page. No qualification gauntlet; an email address is all that's required.
The PDF is updated annually as the regulatory expectations move. If your firm is preparing for an FCA or ICO review and the recording stack is an open question, it is the right place to start.
Want a Telebyte engineer to spend an hour reviewing your call-recording posture against this checklist? Tell Telebyte what you're running — Telebyte does these as free 60-minute reviews for UK regulated firms, no pitch attached.