Live chat is a GDPR-rich product. Visitors send personal data ("my email is …", "my order number is …"); agents reply with more; the conversation lives in a database somewhere and gets emailed to a human inbox. Every step has an article that touches it. Here's the practical version, with what muro does for each.
Article 6, lawful basis
You need a legal reason to process visitor data. For live chat, that's legitimate interest (running the support service the visitor is asking for) for the conversation itself, plus consent if you set non-essential cookies. muro keeps essential cookies (session, CSRF) off the consent banner, you only ask consent for analytics, which we don't set by default anyway.
Article 7, proof of consent
"The user consented" is not enough, you need to prove it. muro stores every consent decision in cookie_consent with timestamp, IP, user-agent, and a fingerprint. If a regulator asks "did this user consent on March 4th?", we have the receipt.
Article 12-15, right of access
A visitor can ask: "what do you have on me?" You have one month to answer with all of it. muro's /api/account/export endpoint produces a JSON dump of everything, user record, accounts, sessions, organisations, websites the user belongs to, conversations, audit entries, in a single download. The dashboard exposes a button on /app/profile.
Article 17, right to erasure ("right to be forgotten")
A user (or visitor whose email we have) can ask for full erasure. Soft delete is not enough, the data must actually be gone. muro's /api/account/delete does cascade DELETE through every table (sessions, accounts, member rows, sole-owned orgs and their websites/conversations/messages). The audit log entry survives but only contains the action, no PII.
Article 20, data portability
Same export as Article 15 but in a structured, machine-readable format. JSON satisfies this. We were tempted to ship a "competitor migration ZIP" format too, but JSON is cleaner, anyone can write a 30-line script to import into anything else.
Article 25, privacy by design
You can't bolt privacy on at the end. In muro, every database query is WHERE organization_id = :orgId, there's literally no path in the codebase that would let one customer see another customer's data. We have unit tests that fail if a query forgets the predicate.
Article 28, processor agreements (DPA)
Your customers (controllers) have us (processor) handling personal data on their behalf. They need a signed DPA from us. We have a standard one at /legal/dpa; for enterprises we sign their custom one too. Includes the obligatory bits: technical safeguards, sub-processors list, breach notification clock (72 h to your team, you decide what to tell your users).
Article 30, records of processing
Every action that touches personal data should leave a trail. muro's audit_log records: sign-ins, password changes, API key creation/revoke, message sends, plan changes, billing events, GDPR requests. Retained 90 days, then automatically deleted by a cron job (you don't want infinite retention either, that's its own privacy problem).
Article 32, security
Vague but important. Means: encryption in transit (TLS 1.3), at rest (Postgres native), strong passwords (scrypt via better-auth), 2FA available, rate limiting on credentials endpoints, brute-force protection. We do all of these, it's in /security.
Article 44, international transfers
You can't ship EU citizen data outside the EU without specific safeguards. muro keeps your conversations in the EU, Hetzner Falkenstein for Postgres, eu-west-1 for AWS SES email. Payments go through Stripe under the EU Standard Contractual Clauses, the Article 46 safeguard for that one transfer. We don't merge data across regions.
What we explicitly don't do
- →No Google Analytics, Mixpanel, Hotjar, Pendo, or other US analytics on the dashboard. Self-hosted Plausible for marketing pages, no fingerprinting.
- →No advertising pixels (Facebook, Google Ads, LinkedIn).
- →No cross-customer data joins. Even our own analytics queries respect organization_id.
- →No "AI training on your data" clause. Your conversations are yours.
GDPR isn't a checklist you finish, it's a posture. Build it into the architecture, document it in your DPA, surface it in the product (export buttons, consent records, audit log), and the compliance work mostly does itself. Anything in your stack that fights you on this is a candidate for replacement.