Recording a meeting is processing personal data. From the moment a microphone captures the first word, UK GDPR applies, and the obligations sit with whoever is responsible for the recording. For HR teams, compliance leads, in-house counsel and charity governance staff this comes up most when the organisation is choosing a meeting tool. The question they have to answer is not “is recording allowed” but “what does our regime have to look like for it to be defensible”.
This article is a working framework, not legal advice. It is written to be useful to people doing the practical work of getting a meeting-recording setup approved by their own DPO, audit committee or trustee board. It is also a thinking aid before you buy a meeting tool, since some of the choices below close themselves off when you commit to a particular vendor.
Lawful basis
Every act of processing personal data needs a lawful basis. There are six in UK GDPR. For meeting recording in a workplace context the realistic options are:
- Consent. The meeting participants are told in advance that the meeting will be recorded and how the recording will be used, and they actively agree.
- Legitimate interests. The organisation has a real business reason to record, the participants would reasonably expect the recording, and the impact on them is proportionate.
- Performance of a contract. The recording is necessary to deliver something the participant signed up for. Rarer, but it covers some advisory and clinical contexts.
- Legal obligation. A specific law requires the recording. Examples are narrow.
Most internal recordings sit on legitimate interests with a documented assessment behind them. Most external-facing recordings (client interviews, witness statements, patient consultations) sit on consent because the participant’s understanding of the recording is part of the trust relationship.
The lawful basis is not chosen by the tool. It is chosen by the organisation against the meeting type. A meeting tool’s privacy posture matters because it changes how easy each basis is to defend. Specifically: a tool that uploads audio to a third party makes a legitimate-interests argument harder, because the impact on the participant grows with each additional party that gets to read the conversation.
The processor relationship
UK GDPR distinguishes between a controller (decides what to do with the data) and a processor (acts on the controller’s instructions). This matters because the controller is responsible for the processor.
A meeting tool that runs on the organisation’s own machines, with no upload of audio or transcript, is not a processor. There is nothing it can do with the data because it never sees the data. The legal posture for the organisation is unchanged from the situation where the meeting was recorded on a dictaphone and the transcript typed into Word.
A meeting tool that runs in a vendor’s cloud is a processor. That triggers a stack of requirements on the controller side:
- A written data-processing addendum, signed.
- A record of processing activities (Article 30) that names the processor.
- A risk assessment that names the processor and addresses the specific risks they introduce.
- Where the processor is outside the UK, a transfer mechanism (UK IDTA, Addendum to the EU SCCs, or an adequacy decision).
- A data-subject-rights process that can pull data back from the processor on request.
None of this is unworkable, and most organisations doing meeting recording at scale are doing it. The point is just that the processor relationship is a real piece of work. A tool that does not create one is a smaller surface to govern.
DPIA scope
A Data Protection Impact Assessment is required when processing is “likely to result in a high risk to the rights and freedoms” of data subjects. The ICO’s lists put recording of conversations in many sensitive contexts on the side of “DPIA required”.
The meeting tool’s behaviour is the largest single variable in the DPIA. A tool that:
- Runs on the user’s own machine.
- Stores audio, transcript and document in a local workspace.
- Does not call any external service during processing.
- Is configurable to use an encrypted local workspace.
- Has no telemetry, no analytics, no usage tracking.
Has a DPIA that is several pages shorter than a tool that does any of those things on a vendor’s infrastructure. The risks under the local-tool model are concentrated on the device itself: who has access to it, what happens when it is lost, how recordings are deleted at the end of their retention. These are problems your existing IT and information-security regime already handles for laptops generally.
A cloud meeting tool’s DPIA has all the local risks plus the third party processor risks plus the cross-border transfer risks plus the vendor employee access risks plus the secondary use (“for service improvement”) risks. None of these are insurmountable; they are just extra work.
Retention and deletion
UK GDPR requires that personal data is kept no longer than necessary. For meeting recordings the operational answer is usually a retention schedule by meeting type. Internal management meetings: 12 months. Client interviews: matter-life plus six years (legal). Disciplinary or grievance meetings: case-life plus a defined retention. Clinical consultations: per professional regulator.
A tool that keeps the audio, transcript and document on local files makes retention a normal IT problem: scripts to delete files past their retention date, audit logs of what was deleted, the same lifecycle as any other working file.
A tool that keeps copies in a vendor’s cloud adds a step to every retention cycle. You have to delete the local copy and confirm that the vendor has also deleted theirs, including in their backups, on the schedule you have set. Most vendor delete features promise within-N-days deletion of “active” data and longer retention of backups. That is something the retention schedule and the DPIA both have to acknowledge.
Data-subject rights
Anyone whose voice is in a recording is a data subject. Under UK GDPR they can request access to their data, ask for it to be corrected, ask for it to be deleted (in some circumstances) and ask for processing to be restricted.
For a local-tool setup, the response is bounded. The data is in known files in a known location. It can be exported, redacted, deleted on demand within the request window. The actions are auditable.
For a cloud-tool setup, the same request has to be honoured against the vendor’s copy as well. That works as long as the vendor has good rights-management tooling and your processor agreement requires them to act on your instructions inside a tight window. Not all of them do, and this is something to check at procurement, not after a request has come in.
A short procurement checklist
For HR, compliance and governance buyers, a short list to put against any candidate meeting tool:
- Does the tool send audio, transcript or document to any third party in the course of normal operation?
- If yes, who is the processor, where are they based, what is the transfer mechanism, what is the standard DPA, what is the secondary-use position?
- Where do the artefacts of a meeting live? Is the workspace under our control?
- What deletion guarantees does the tool offer? Are they aligned to our retention schedule by meeting type?
- What is the audit trail for access to recordings?
- What does the tool do on the network in normal operation? Can it be run with the network disconnected?
A tool that answers question 1 with “no” makes questions 2, 4 and 5 much smaller. That is the practical case for choosing a local meeting tool in regulated work, and it is most of the reason Whistle Enterprise was built the way it was.
The security notes on this site cover what Whistle Enterprise does at a system level. If you have a DPIA in flight and want to test the framework above against a real meeting on a real machine, download the trial and run a meeting through it. What gets written, where, and when will tell you whether the tool fits the regime your organisation already has.