Meeting Data Privacy and GDPR for Developers: What You Need to Know

Why this matters more than you think

Meeting transcripts are some of the most sensitive data your product will handle. They contain people's voices, their words, their opinions, their arguments, their personal details mentioned in passing — and they're attributable to specific named individuals.

Under GDPR (and equivalent regulations like CCPA, UK GDPR, and Canada's PIPEDA), this isn't just generic "personal data" — voice recordings and biometric identifiers derived from voice fall under special categories that attract stricter requirements.

If your product records and transcribes meetings and you haven't thought carefully about data privacy, you are almost certainly non-compliant in at least one jurisdiction your users are in.

This isn't a post about legal advice — get a real lawyer for that. But it is a practical developer's guide to the technical decisions that determine your compliance posture.

The consent question

The most important question for any meeting transcription product: do you have consent from everyone in the meeting?

Your customer's consent: If a user signs up for your product and enables meeting transcription, they've consented to being recorded in the meetings they control. That's the easy part.

Other participants' consent: Every other person in the meeting is also being recorded. They may not be your customers. They may not have any relationship with you at all.

The legal standard varies: - EU/UK (GDPR): You need a lawful basis for processing. Legitimate interest is possible but requires a balancing test. Explicit consent is the cleanest basis but the hardest to obtain from meeting participants who aren't your users. - US (varies by state): All-party consent states (California, Florida, Illinois, and others) require every participant to consent. One-party consent states only require one participant (your user) to consent. - Enterprise contexts: Many enterprise contracts include provisions about data processing that supersede individual consent — if the company has deployed your product, consent may flow from the employer-employee relationship.

The practical minimum: the bot must be visible to all participants, the meeting host must be able to remove the bot, and your privacy policy must describe what happens to the transcript data.

Data minimisation

GDPR Article 5(c) requires that personal data be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed." Applied to meeting transcripts, this means: don't collect more than you need.

Do you need the full audio recording? If your product only needs the text transcript, you don't need to store the audio after transcription is complete. Delete it.

Do you need speaker voice prints? If you're doing diarization but don't need to identify speakers across meetings, you don't need to store the speaker embedding vectors.

Do you need the full transcript? If your product extracts action items and discards the rest, you don't need to store the full transcript. Only store what you display to users or use in downstream processing.

Each piece of data you don't store is a piece of data you can't lose in a breach, can't be required to produce in a legal discovery, and can't be used against you in a complaint.

Retention policies: what to actually implement

Retention policies are the specific time limits after which data is automatically deleted. "We retain data as long as the account is active" is not a retention policy — it's a data accumulation strategy.

A reasonable starting point:

• Raw audio: Delete immediately after transcription is complete. There's almost never a reason to store it.
• Full transcript: Retain for the duration of the user's subscription, plus 30 days after cancellation for export.
• Processed output (summaries, action items): Retain indefinitely if it's genuinely useful to the user.
• Access logs: Retain for 90 days for security purposes, then delete.

Build the deletion as an automated background job, not a manual process. Manual deletion processes fail — someone forgets, the job ticket gets deprioritised, the data accumulates. Automated expiry is the only reliable approach.

// Example: nightly cleanup job
async function deleteExpiredTranscripts() {
  const cutoff = new Date();
  cutoff.setDate(cutoff.getDate() - 90); // 90-day retention

await db.transcripts.deleteMany({ createdAt: { $lt: cutoff }, userDeletedAt: { $ne: null }, // user already deleted });

// Also: users who cancelled their subscription > 30 days ago const cancelledCutoff = new Date(); cancelledCutoff.setDate(cancelledCutoff.getDate() - 30);

const cancelledUsers = await db.users.find({ cancelledAt: { $lt: cancelledCutoff } });

for (const user of cancelledUsers) { await db.transcripts.deleteMany({ userId: user.id }); } } ```

Right of erasure (the "right to be forgotten")

Under GDPR Article 17, individuals have the right to request deletion of their personal data. For meeting transcripts, this creates an interesting challenge: a transcript may contain data about multiple people, not all of whom are your users.

Practical implementation:

For your users: Implement a "delete account and all data" flow that actually deletes everything. Don't archive deleted accounts "in case they come back" — that's a retention policy violation. Schedule real deletion.

For meeting participants who aren't your users: This is harder. You probably don't have a direct relationship with them. The minimum: provide a contact mechanism in your privacy policy for erasure requests. Log and process them promptly. If the transcript contains one person's voice and they request deletion, and you can't remove just their segments, you may need to delete the full transcript.

Downstream data: If you've sent transcript summaries to a CRM or logged them in another system, deletion from your database doesn't help. You need to track where data has flowed and have a mechanism to delete it from downstream systems.

What your privacy policy must actually say

Not legal advice, but your privacy policy should address:

1. What data you collect (audio, transcript, speaker labels, metadata)
2. Why you collect it (the specific purpose)
3. Who you share it with (your LLM providers, storage providers, etc.)
4. How long you retain it (specific time periods, not vague language)
5. How to request deletion
6. The legal basis for processing (consent, legitimate interest, contract)
7. Whether data is transferred outside the EU/EEA (and what protections apply if so)

"We take your privacy seriously" is not a privacy policy. Specific answers to specific questions are.

Technical controls checklist

The privacy compliance requirements map to specific technical implementations:

• Encryption at rest: Transcripts should be encrypted in your database (AES-256 or equivalent)
• Encryption in transit: TLS 1.2+ on all API endpoints (table stakes, but verify it)
• Access controls: Not all employees should be able to read customer transcripts. Audit logs on who accessed what.
• Deletion is actually deletion: Soft-deletes that keep the data in a "deleted" column are not compliant. Physical deletion or cryptographic erasure (destroying the encryption key).
• Sub-processor agreements: Your LLM provider, your cloud storage provider — if they process personal data on your behalf, you need Data Processing Agreements with them.
• Breach notification: You need a process to detect a breach and notify affected users within 72 hours (GDPR requirement). Have this written down before you need it.

Using Gregnote in a privacy-compliant way

Gregnote processes audio and produces transcripts — it's a data processor in GDPR terms. This means:

• You're the data controller (you determine the purpose and means of processing)
• Gregnote is the data processor (they process on your behalf)
• You need a Data Processing Agreement with Gregnote (available on request)
• You remain responsible for the legality of the processing — Gregnote processing it doesn't transfer your compliance obligations

For technical implementation of the integration, see building meeting intelligence into your SaaS product. For how to structure your webhook handling to support deletion flows, see webhook reliability patterns.