Meeting recording and UK GDPR: a practical view

Recording a meeting means processing personal data. The moment a microphone picks up the first word, UK GDPR is in play, and the obligations land on whoever is responsible for that recording. If you are in HR, compliance, in house legal or charity governance, this tends to reach your desk when the organisation is choosing a meeting tool, and the real question is not “are we allowed to record”, it is “what does our setup have to look like for this to be defensible”. Let me lay out a working framework for that.

This is a framework, not legal advice. It is written for the person who has to get a recording setup past their own DPO, audit committee or trustee board, and it is worth thinking through before you buy a tool, because some of the choices below close themselves off once you commit to a particular vendor.

Lawful basis

Every act of processing needs a lawful basis, and UK GDPR gives you six. For workplace meeting recording the realistic ones are:

• Consent. Participants are told in advance that the meeting is recorded and what it will be used for, and they actively agree.
• Legitimate interests. There is a genuine business reason, the participants would reasonably expect it, 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 fits some advisory and clinical work.
• Legal obligation. A specific law requires it. The examples are narrow.

Most internal recordings sit on legitimate interests, with a documented assessment behind them. Most external facing ones, client interviews, witness statements, patient consultations, sit on consent, because the participant’s understanding of the recording is part of the trust.

The tool does not pick your lawful basis, you do, against the meeting type. But the tool’s privacy posture changes how easy each basis is to defend. A tool that uploads the audio to a third party makes a legitimate interests case harder, because the impact on the participant grows with every extra party that gets to read the conversation.

The controller and processor question

UK GDPR splits the world into controllers (who decide what happens to the data) and processors (who act on the controller’s instructions), and the controller carries responsibility for the processor.

A tool that runs on your 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 receives the data. Your legal position is the same as if the meeting had been recorded on a dictaphone and typed up in Word.

A tool that runs in a vendor’s cloud is a processor, and that brings a stack of work:

• A signed data processing agreement.
• A record of processing activities (Article 30) that names them.
• A risk assessment covering the specific risks they add.
• Where they are outside the UK, a transfer mechanism (the UK IDTA, the Addendum to the EU SCCs, or an adequacy decision).
• A data subject rights process that can reach into their systems on request.

None of that is unworkable, and plenty of organisations do it at scale. The point is only that a processor relationship is real, ongoing work, and a tool that never creates one is simply a smaller thing to govern.

DPIA scope

A Data Protection Impact Assessment is required where processing is “likely to result in a high risk to the rights and freedoms” of people, and the ICO’s guidance puts recording conversations in many sensitive settings firmly on the “DPIA required” side.

The tool is the single biggest variable in that DPIA. One that runs on the user’s own machine, keeps the audio, transcript and document in a local workspace, makes no external call while it works, can use an encrypted local workspace, and has no telemetry or usage tracking, gives you a DPIA that is several pages shorter than a cloud tool’s. The risks under that model sit on the device itself: who can get at it, what happens if it is lost, how recordings are deleted at the end of their life. Your existing laptop security regime already handles most of that.

A cloud tool’s DPIA carries all of those local risks, and then the processor risks, the cross border transfer risks, the vendor staff access risks and the “secondary use for service improvement” risks on top. All surmountable. Just more work.

Retention and deletion

UK GDPR says personal data is kept no longer than necessary, and for recordings the practical answer is a retention schedule by meeting type. Internal management meetings, say twelve months. Client interviews, the life of the matter plus six years. Disciplinary and grievance meetings, the life of the case plus a set period. Clinical consultations, per the relevant regulator.

A tool that keeps everything in local files makes retention an ordinary IT job: delete files past their date, log what was deleted, the same lifecycle as any other working document. A tool that holds copies in a vendor’s cloud adds a step to every cycle, you delete your copy and then confirm the vendor has deleted theirs, backups included, on your schedule. Most vendor delete features promise removal of “active” data within so many days and keep backups longer, and your retention schedule and DPIA both have to say so.

Data subject rights

Anyone whose voice is in a recording is a data subject, and they can ask to see their data, correct it, in some circumstances delete it, or have the processing restricted.

With a local setup the response is bounded. The data is in known files in a known place, so it can be exported, redacted or deleted within the request window, and the actions are auditable. With a cloud setup the same request also has to be honoured against the vendor’s copy, which works as long as their rights tooling is good and your agreement obliges them to act inside a tight window. Not all of them are, and that is a procurement check, not something to discover after a request has arrived.

A short procurement checklist

For HR, compliance and governance buyers, the questions I would put to any candidate tool:

1. In normal use, does it send audio, transcript or document to any third party?
2. If yes: who is the processor, where are they based, what is the transfer mechanism, what is the standard DPA, what is their secondary use position?
3. Where do a meeting’s files live, and is the workspace under our control?
4. What deletion guarantees does it offer, and do they line up with our retention schedule by meeting type?
5. What is the audit trail for access to recordings?
6. What does it do on the network in normal use, and can it run with the network disconnected?

A tool that answers question one with “no” makes two, four and five much smaller. That is the practical case for a local tool in regulated work, and it is most of why Whistle Enterprise was built the way it is.

The security notes cover what it does at a system level. If you have a DPIA in flight and want to test this framework against a real meeting on a real machine, download the trial and run one through. What gets written, where, and when will tell you whether it fits the regime you already run.