Customer GDPR Compliance Guide
For Organizations Using [PLATFORM PROVIDER] Event PlatformLast Updated: [DATE]
Introduction
This guide explains your GDPR obligations as a Data Controller using the [PLATFORM PROVIDER] platform. [PLATFORM PROVIDER] acts as your Data Processor — we handle the technical infrastructure, but you are legally responsible for how your attendees' data is collected and used.
This is not legal advice. Consult a qualified data protection lawyer for your specific situation.
1. Your Role as Data Controller
Under GDPR, you are the Data Controller for your event attendees' personal data. This means:
- You decide why data is collected (purposes) and what data is collected
- You are responsible for ensuring a legal basis for each processing activity
- You must provide transparent information to attendees (Privacy Policy, Cookie Policy)
- You must honor data subject rights requests from attendees
- You must sign a Data Processing Agreement (DPA) with [PLATFORM PROVIDER] before using the platform
[PLATFORM PROVIDER] is your Data Processor — we process data on your behalf, following your instructions, within the limits of the DPA.
2. Before You Go Live — Checklist
2.1 Legal Documents
- [ ] Sign the DPA with [PLATFORM PROVIDER] before processing any attendee data
- [ ] Customize and publish your Privacy Policy using the template in privacy-policy.md. Fill in all
[PLACEHOLDER]values. Have it reviewed by a lawyer. - [ ] Customize and publish your Cookie Policy using cookie-policy.md
- [ ] Customize and publish your Terms of Service using terms-of-service.md
- [ ] Appoint a DPO (Data Protection Officer) if required — required if you process data on a large scale, process special category data, or are a public authority. If not required, designate a privacy contact.
2.2 Platform Configuration
- [ ] Review the consents the registration form actually collects — the form presents one required checkbox covering both data processing and acceptance of your terms, and, where you enable it, one optional email-marketing checkbox. See Section 5.1 before you describe your consent collection in your Privacy Policy.
- [ ] Review your cookie consent banner — ensure your published Cookie Policy matches how the banner actually behaves, as described below.
- [ ] Set your organization's data retention preferences in the dashboard (Settings → Retention), noting the limitation described below
- [ ] Configure your Privacy Policy and Terms of Service URLs in dashboard settings (Settings → Forms) — these appear in the registration form's consent checkbox label
- [ ] Review your staff accounts and assign the least-privileged role to each — see Section 2.4
- [ ] Decide whether to enable the simulated attendee count on any session — see Section 2.5
The cookie consent banner. The banner is a self-contained script built and served by the [PLATFORM PROVIDER] API. It is not a Google Tag Manager template. Google Consent Mode v2 defaults are emitted only where you configure a Google Tag Manager container in your integration settings; the Meta Pixel, the TikTok Pixel and Microsoft Clarity are injected directly by the platform and do not pass through Google Tag Manager or Consent Mode. All banner and preferences-modal text is hardcoded Romanian with no language switch, which you should assess against the Article 7(2) requirement that a request for consent be intelligible to the audience you address. The banner contains no link to any policy, so the "informed" limb of Article 4(11) is not satisfied by the banner itself.
The cookie banner's outcome is stored only in a first-party cookie on the visitor's device (rx_cookie_consent, a JSON value recording the necessary, analytics and advertising choices, a timestamp and a version, retained for twelve months). It is never written to the consent ledger, so the platform holds no server-side record of who accepted or rejected cookies, and cannot evidence a cookie-consent decision after the fact.
GAP-CONSENT-11 · CODE — KNOWN GAP, REMEDIATION PENDING
This guide previously described the cookie banner as powered by Google Tag Manager with Google Consent Mode v2 applying deny-by-default to all consent signals. The banner is in fact a platform-provided script that loads the Meta Pixel, the TikTok Pixel and Microsoft Clarity outside Google Tag Manager, Consent Mode v2 defaults are emitted only where a container is configured, and the banner's outcome is recorded only in a first-party cookie on the visitor's device rather than in the consent ledger. This divergence is recorded on the compliance remediation register and is under review.
Retention configuration. Retention periods are configured per organisation, and no default policy is seeded. The retention enforcement job acts only on policies that exist, so an organisation that has configured none has no data deleted by age. The retention settings screen currently submits eight data types while the API accepts five, and the API validates the whole submission before writing any of it, so every save attempt is rejected and no retention policy can be configured through the product.
Where an enabled policy would delete more than ten thousand rows in a single run, the job records a warning and deletes nothing, so a table whose backlog has crossed that threshold is not brought back within its retention period by subsequent runs.
GAP-RET-01 · CODE — KNOWN GAP, REMEDIATION PENDING
This guide previously instructed Customers to set their retention preferences in a dashboard section called Settings → Privacy. That section does not exist; the screen is Settings → Retention, and every save it submits is rejected by the API, so no retention policy can currently be configured. Retention is in any event opt-in with no platform default, so data is not deleted by age unless a policy exists. This divergence is recorded on the compliance remediation register and is under review.
2.3 Sub-Processor Review
Review the [PLATFORM PROVIDER] Sub-Processors Annex (annex-sub-processors.md). [PLATFORM PROVIDER] engages eleven sub-processors, listed in Annex III. Two of them process personal data under [PLATFORM PROVIDER]'s own credentials and cannot be switched off for a single organisation: Anthropic PBC (USA), which receives AI generation prompts, and Cloudflare, Inc., which proxies attendee traffic. Both are described in Section 9.
If you use your own integrations (Newsman email account, your Firebase project for push notifications, SendSMS.ro for SMS messaging, ad platforms), you must:
- Maintain your own DPAs with those providers
- Disclose them in your Privacy Policy
- Ensure they are GDPR-compliant
2.4 Staff Access Control
The platform defines four staff roles — admin, moderator, marketer and staff — mapped to three permission groups (marketing, live, settings). staff holds no permission group and is effectively read-only; marketer holds the marketing group; moderator holds the live group; admin holds all three. A role is chosen explicitly when the account is created; there is no read-only default. Administrator privileges are required for exactly one endpoint, the audit-log listing. Every other destructive action — deleting webinars, sessions, funnels, segments, pages, offers, polls, uploads and testimonials — is authorised by the marketing or live permission group, which the non-administrator marketer and moderator roles satisfy.
Two consequences for your access-control assessment under Article 32: the marketer role can export contact personal data and send segment broadcasts without administrator rights, and an administrator creating an account with a password may set one as short as six characters. Issue one account per person rather than a shared account, assign the least-privileged role that allows the person to do their work, and impose your own credential standards.
2.5 Simulated Attendee Count
Session configuration includes an optional simulated online count. Where it is enabled, the figure shown to attendees beside the live indicator on the watch page is not the number of people present: it is a configured base value plus the real online count multiplied by a configured factor, recalculated each minute with a small random variation so that the number drifts as organic traffic would. Attendees are shown only the simulated figure and cannot distinguish it from a real count; the true count is available to staff only.
Enabling this is a decision you take as Data Controller. Displaying a fabricated audience figure engages Directive 2005/29/EC on unfair commercial practices, including the Annex I list of practices that are unfair in all circumstances, and, in Romania, Legea nr. 363/2007. Where the figure contributes to a decision to register or to purchase, it also engages the fairness principle in GDPR Article 5(1)(a). Take your own advice before enabling it, and do not enable it unless your published Terms of Service disclose that the displayed figure is an estimate rather than a count.
3. Legal Bases for Processing
You must have a valid legal basis for every processing activity. Here are the bases used by the [PLATFORM PROVIDER] platform and what you need to do:
| Processing Activity | Legal Basis | Your Responsibility |
|---|---|---|
| Event registration (email, name) | Contract performance (Art 6(1)(b)) | Inform attendees in Privacy Policy |
| Event delivery (reminders, access) | Legitimate interest (Art 6(1)(f)) | Disclose in Privacy Policy; allow opt-out |
| Behavioral tracking (chat, polls, offers) | Consent (Art 6(1)(a)) | Collect explicit opt-in consent. Note that this consent gates only the behavioural event rows in the analytics database — see Section 4 |
| Marketing emails | Consent (Art 6(1)(a)) | Collect explicit opt-in consent at registration. Note that this consent gates only the marketing email provider's list sync — see Section 5.4 |
| Push notifications — transactional | Consent (Art 6(1)(a)) | Collect the push_notifications opt-in; the platform sends no transactional push to a contact without a granted, unrevoked grant for that purpose |
| Push notifications — marketing | Not implemented | The push_marketing purpose is collected and displayed to attendees but gates nothing, because there is no marketing push send path. Do not declare this activity and do not present the opt-in as if it were operative |
| WhatsApp/SMS | Consent (Art 6(1)(a)) for SMS; WhatsApp not implemented | An SMS is sent only where the contact holds a granted, unrevoked sms_notifications consent. The whatsapp_notifications and whatsapp_marketing purposes are collected and displayed but gate nothing, because there is no WhatsApp send path |
| Ad conversion tracking | Legitimate interest (Art 6(1)(f)) for server-side conversion and page-view events; consent (Art 6(1)(a)) only for the cookie-setting state of the client-side pixels | Run and document your own legitimate-interest assessment. Disclose in your Privacy Policy that a hashed email address, telephone number, first name, last name and registration identifier are transmitted to Meta and TikTok on every registration, together with the unhashed IP address and user agent, and provide an Article 21 objection route. A GDPR Article 18 processing restriction — not withdrawal of cookie consent — is the only control that stops these transfers |
| Geo/device enrichment | Legitimate interest (Art 6(1)(f)) | Disclose in Privacy Policy |
| Security and fraud prevention | Legitimate interest (Art 6(1)(f)) | Disclose in Privacy Policy |
| Funnel page-view measurement | Legitimate interest (Art 6(1)(f)) | Unique-visitor measurement on funnel pages runs without a consent gate and records a persistent pseudonymous identifier derived from the visitor's IP address and user agent. Assess it against Article 5(3) of the ePrivacy Directive and disclose it in your Cookie Policy and Privacy Policy |
| Funnel attribution (UTM parameters, click identifiers, landing and referrer URL, country, city, device, operating system, browser, time zone) | Legitimate interest (Art 6(1)(f)) | List these categories in your Privacy Policy. Note that where a visitor follows a tracked link, the campaign parameters and the fbclid, gclid, ttclid and li_fat_id click identifiers are forwarded onto the destination URL, which is frequently a third-party site |
| E-commerce and form webhook ingestion | Determined by you | Where you configure an order or form webhook, the entire raw request body is stored as entry metadata for generic and form-provider webhooks, and order identifier, total amount, currency and payment status are stored for e-commerce orders and joined to an identified contact. Declare this purchase and transaction data in your own record of processing activities |
| AI-assisted content generation | Determined by you — as implemented, legitimate interest (Art 6(1)(f)) | Approved attendee testimonials, including the author's name and free-text quote, and any staff-uploaded reference images are transmitted to a model provider in the USA. See Section 9 |
| Segment broadcasts | Determined by you | The segment broadcast lane sends without checking any marketing consent purpose. See Section 5.4 |
Key principle: Only collect consents for activities you actually intend to use. Do not add consent checkboxes "just in case" — GDPR requires consent to be specific and informed.
How the Meta Pixel and the TikTok Pixel actually load. The Meta Pixel and the TikTok Pixel are classified as strictly necessary scripts and are therefore loaded on every page view, before and irrespective of the visitor's cookie-banner decision. Each sends a single page view to Meta and to TikTok respectively at that point, so both platforms receive the visitor's IP address, user agent and page URL before any consent is given. Both are loaded in a consent-withheld state — fbq('consent','revoke') for Meta and ttq.holdConsent() for TikTok — which is intended to prevent the identifying advertising cookies (_fbp, _fbc, _ttp, _ttclid) from being written until the visitor accepts the advertising category, at which point the consent state is flipped to granted. The absence of a cookie is the basis on which these scripts are currently classified as necessary; it is not a determination that the pre-consent load is permitted under Article 5(3) of the ePrivacy Directive, and the classification is under review.
GAP-CONSENT-01 · CODE — KNOWN GAP, REMEDIATION PENDING
This document previously stated that the Meta and TikTok pixels load only where the attendee accepts advertising cookies. Both pixels are in fact classified as necessary and fire a page view before any consent decision, in a configuration intended to be cookie-less until advertising consent is granted. This divergence is recorded on the compliance remediation register; the classification is under review.
Server-side conversion and page-view events. Independently of the browser pixels, a server-side Meta Conversions API PageView is sent for every human visitor to a funnel landing page where the organisation has enabled the Meta integration. It carries the visitor's raw IP address, raw user agent, the page URL, the fbclid click identifier and the _fbp / _fbc cookie values where these are present; where the cookie is absent — which is the case for a visitor who has not accepted advertising cookies — the click identifier alone is used to reconstruct an fbc value. There is no consent check on this path; the only condition is that the organisation has enabled the Meta integration.
The same posture applies to registration conversions. Where you enable the Meta or TikTok integration, a server-side conversion event is sent to that platform on every registration, carrying the hashed identifiers and the unhashed IP address and user agent described in the table above. No advertising consent is consulted.
GAP-CONSENT-05 · CODE — KNOWN GAP, REMEDIATION PENDING
This guide previously told Controllers that ad conversion tracking is carried out on the basis of consent and that a cookie consent banner is the control that governs it. Server-side conversion and page-view events are sent to Meta and TikTok on the basis of legitimate interest with no consent gate of any kind; a GDPR Article 18 processing restriction is the only condition that suppresses them, and the advertising-consent value collected at registration is not read anywhere in the platform. This divergence is recorded on the compliance remediation register and is under review.
4. Transparency — What to Tell Attendees
Under GDPR Articles 13 and 14, you must inform attendees at the point of data collection about:
- Who you are — your organization name and contact details
- What data you collect — registration data; behavioral data (chat messages, poll votes, reactions, offer clicks, feedback); technical data (IP address, user agent, device type, operating system, browser, time zone, country and city); and campaign attribution data (UTM parameters, advertising click identifiers, landing page and referrer URL)
- Why you collect it — the purposes and legal bases for each
- Who you share it with — [PLATFORM PROVIDER] (your processor) and the further recipients it engages, including Google LLC, Railway Corp., NewsmanApp SRL, Cloudflare, Inc., Anthropic PBC, Meta Platforms, Inc., TikTok Pte. Ltd. and Microsoft Corporation; SendSMS.ro; the video host you embed on the watch page; and your own ad accounts. See Sections 9 and 10
- How long you keep it — retention periods per data category
- Their rights — access, erasure, rectification, portability, restriction, objection
- International transfers — if data leaves the EEA (see Annex III and Annex IV for [PLATFORM PROVIDER]'s transfers)
- Right to complain — to their national data protection authority
The Privacy Policy template covers all of these. Customize it for your organization — do not publish the template as-is with placeholders unfilled.
What behavioural-tracking consent does and does not control. Where an attendee has not granted behavioural-tracking consent, their chat messages, poll votes, reactions, offer clicks and feedback are still written to the live-session database and remain visible to staff on the live dashboard, and their attendance is still recorded against their registration. Only the granular behavioural event rows in the analytics database are suppressed. Describe this accurately in your Privacy Policy; do not tell attendees that declining behavioural tracking prevents their live-session activity from being recorded.
Chat moderation. Attendee chat messages are automatically screened against a banned-word list configured per session. A plain occurrence of a listed word is masked in place; a message whose obfuscated spelling still matches is removed from the visible stream entirely and moved to a staff-only record that retains the original full text together with the author's actor data. The attendee is not notified in either case. Disclose this screening in your Terms of Service and your Privacy Policy.
Live-session retention. Live-session data in the Realtime Database is retained indefinitely. There is no scheduled cleanup function: the Cloud Functions codebase exports ten functions, of which nine are database triggers and one is a minutely presence reconciler, and none deletes session data. Moving a session to replay or archived status does not prune it either — the lifecycle job writes a statistics snapshot to Firestore and performs no deletion in the Realtime Database. The only operations that remove a live-session node are the manual deletion of a session and the manual deletion of the parent webinar. Chat message text, attendee display names, presence and attendance records, poll votes, reactions, offer clicks and feedback responses therefore persist for the lifetime of the webinar record. State a truthful retention period on this basis under Article 13(2)(a).
No time-to-live policy is configured on any Firestore collection. Registration documents and contact PII documents are removed only by an erasure request or by the manual deletion of the parent webinar or session.
Your own staff users are also data subjects. You are the Controller for the account data of the staff users you create in the dashboard, and you owe them an Article 13 notice in your capacity as their employer. Beyond the account record itself — email address, name, role and authentication identifier — every audited staff action records the acting user's IP address, user agent and request identifier in the audit log, and the audit log is not among the data types the retention job recognises, so those records are retained without limit. The dashboard presents no privacy notice or terms at the point of login, so the notice must be served by you through your own channels.
5. Consent Management
5.1 Collecting Consent
The [PLATFORM PROVIDER] registration form presents exactly two checkboxes:
- One required checkbox covering both data processing (
data_processing) and acceptance of your terms of service (tos_acceptance) - One optional email-marketing checkbox (
email_marketing), shown only where you enable it
Configure the label text and the Privacy Policy and Terms of Service links in your dashboard (Settings → Forms). That screen controls the consent template text, the link labels, the two policy URLs and the marketing checkbox label; it does not control which consent purposes the form collects.
Two further purposes are collected outside the registration form. behavioral_tracking is requested in the attendee application after registration and is toggleable by the attendee on the preferences page. push_notifications is granted through the notification preferences available to the attendee, not through the registration form.
The consent ledger recognises exactly ten purposes: data_processing, tos_acceptance, email_marketing, push_notifications, push_marketing, behavioral_tracking, whatsapp_notifications, whatsapp_marketing, sms_notifications and sms_marketing. Of these, whatsapp_notifications, whatsapp_marketing, push_marketing and sms_marketing are accepted and displayed to attendees but gate nothing, because the corresponding send paths do not exist. data_processing and tos_acceptance cannot be withdrawn through the preferences page. The consent policy version currently in force is "1.0".
How consent is actually bundled. On the public funnel form a single checkbox records acceptance of both the terms of service and the processing of personal data, and a telephone number entered in the form grants consent to SMS notifications without a separate checkbox; where the marketing checkbox is also ticked, that marketing consent is extended to SMS marketing. The attendee application applies the same bundling for the terms and processing consents.
Requirements for valid GDPR consent:
- Must be freely given — not a condition of attending the event
- Must be specific — separate checkbox per purpose (no bundled "I agree to everything")
- Must be informed — link to Privacy Policy must be visible before consent is given
- Must be unambiguous — opt-in only (no pre-ticked boxes)
The platform does not enforce all of these by default. The required checkbox bundles two purposes, and the SMS notification and SMS marketing grants are inferred rather than collected. Grants that the data subject was never asked for do not satisfy Article 4(11) or Article 7(2) and should not be relied on as consent; if you intend to send SMS, collect that consent through a mechanism of your own until the form collects it separately.
GAP-CONSENT-04 · CODE — KNOWN GAP, REMEDIATION PENDING
This guide previously stated that the platform enforces specific, unbundled, per-purpose consent by default and instructed Controllers not to alter the consent user experience. The registration form presents one required checkbox that records two purposes at once, records an SMS notification consent because a telephone number was entered, and records an SMS marketing consent from the email-marketing tick. This divergence is recorded on the compliance remediation register and is under review.
5.2 Consent Records
[PLATFORM PROVIDER] stores all consent records in your attendees' contact records (timestamp, purpose, method, policy version). These are accessible in the dashboard (Contacts → [Contact] → Consents). No IP address is recorded on any consent record, in either the ledger or the Firestore copy, so the ledger cannot evidence the origin of a grant.
Two further properties of the ledger affect what it proves:
- Consent is recorded only as a grant. Leaving the marketing checkbox unticked records nothing — no refusal is stored and no consent event is written — and registering again with the box ticked re-grants a marketing consent that was previously withdrawn. A contact who declined and a contact who was never asked are therefore indistinguishable in the record.
- Consents are organisation-wide and persist across every future event in your organisation. Per-webinar consent scoping was removed from the data model, so an attendee who consents once has consented for all of your subsequent events, which may not match what the attendee understood at the point of collection.
Imported contacts. Contacts loaded through the bulk importer are written with granted consents for data processing and acceptance of the terms, recorded with the current policy version and a method of "import", and with marketing consent where the imported row carries that flag. These records are created on the import date for people who have never interacted with the platform, so they are not in themselves evidence that consent was obtained; you must be able to produce the original consent evidence from the source system. Importing a contact also creates a registration and triggers a confirmation email.
Keep these records — if challenged by a supervisory authority, you need to prove consent was obtained.
5.3 Consent Withdrawal
Attendees can withdraw consent as follows:
- Marketing emails — unsubscribe link in every email, or the attendee preferences page
- Behavioral tracking — the attendee preferences page, or by contacting you
- Push marketing — in-app notification preferences (the purpose is recorded but gates no send path)
- SMS — the attendee preferences page, or by contacting you. There is no inbound keyword handling: a reply of "STOP" to an SMS is not processed by the platform
Withdrawal is not immediate in every case, and its effect is narrower than the phrase "suppresses the attendee from the relevant communications" implies:
- Withdrawing
email_marketingstops the contact being synchronised into the marketing email provider's list and segments. It does not stop registration confirmations, reminders, "starting now" and replay messages, automation email, resends or segment broadcasts, all of which run on the transactional gate alone. - Withdrawing behavioural-tracking consent takes effect from the next session. Within a session already in progress the consent decision is cached against the attendee's actor record with no expiry and is not invalidated when the consent changes.
- Withdrawing cookie consent stops further use of the advertising and analytics services but does not delete cookies that were already placed on the device. When consent is withdrawn the platform opts Microsoft Clarity out, returns the Meta and TikTok pixels to their consent-withheld state and reloads the page; cookies such as
_fbp,_fbc,_ttp,_gaand_clckremain in the browser until they expire naturally or the visitor deletes them.
Honor withdrawal requests promptly — delays are a GDPR violation.
5.4 Features That Operate Outside the Marketing-Consent Gate
email_marketing gates exactly one thing: whether the contact is synchronised into the marketing email provider's list and segments. Every other email path — registration confirmation, reminders, "starting now", replay, automation email, resend and segment broadcast — runs on the transactional gate alone (not suppressed, not restricted).
Three product features consequently allow a message or an export to reach a contact who never granted marketing consent, or who withdrew it. Using them is your decision as Controller and the compliance consequences are yours:
- Segment broadcasts. A one-off email can be composed and sent to the members of a saved segment without any marketing consent being checked. The only limits enforced are a GDPR Article 18 processing restriction and the bounce, complaint and global opt-out suppression flags. The feature is intended as a transactional lane. Sending promotional content through it engages Article 13 of the ePrivacy Directive and, in Romania, art. 12 of Legea nr. 506/2004, including the narrow soft opt-in exception; do not use it for marketing to contacts who have not opted in.
- The "Missing Consent" segment condition. A segment condition is provided that selects precisely those contacts who hold no active grant for a given purpose. This makes it possible to build and address an audience of contacts who have declined or withdrawn marketing consent. Do not use such a segment as the recipient list for a marketing message.
- Segment CSV export. Exporting a segment returns the plaintext email address and name of each member and does not require marketing consent; with the flagged option enabled it also returns contacts who have bounced, complained or globally opted out. Contacts whose only signal was an unsubscribe are included in the default export, because unsubscribing revokes the marketing consent without setting a suppression flag. An exported file leaves the platform's consent, suppression and erasure controls entirely, and you own every copy of it.
A GDPR Article 18 processing restriction is enforced consistently as a hard stop: a restricted contact cannot be granted or re-granted any consent, receives no email, SMS or push message, is excluded from contact and segment exports and from segment broadcasts, and no server-side conversion event is sent for them.
6. Data Subject Rights
Attendees have the following rights under GDPR. You are responsible for honoring them. [PLATFORM PROVIDER] provides tools to help:
| Right | How to Handle | [PLATFORM PROVIDER] Dashboard Tool |
|---|---|---|
| Access (Art 15) | Provide copy of all attendee data | GDPR → New Request → Access, then Process |
| Erasure (Art 17) | Delete all attendee data | GDPR → New Request → Deletion, then Process |
| Rectification (Art 16) | Correct inaccurate data | Contacts → [Contact] → Edit. Rectification cannot be logged as a GDPR request — the request register accepts only deletion, access, portability, objection and restriction — so the audit log is your evidence that the correction was made |
| Restriction (Art 18) | Freeze processing without deleting | GDPR → New Request → Processing Restriction, then Process |
| Portability (Art 20) | Provide machine-readable export | Same as Access — JSON export |
| Objection (Art 21) | Stop processing based on legitimate interest or marketing | GDPR → New Request → Objection; and revoke the relevant consent in Contacts → [Contact] → Consents |
The GDPR request register is a top-level section of the dashboard, reached from the main navigation as GDPR. There is no Privacy section.
Response deadline: GDPR requires a response within 1 month of receipt, extendable by 2 further months where the request is complex or numerous, with notification to the Data Subject within the first month (Art 12(3)).
[PLATFORM PROVIDER]'s SLA: We will assist with your processing of DSAR requests within 5 business days of you submitting the request in the dashboard. This is an operational commitment, not a platform behaviour: a request is created with a pending status and is executed only when a member of your staff presses Process. Nothing in the product drains the queue or enforces a deadline, and an attendee's own self-service deletion request is likewise created as pending rather than executed. Where the pipeline does run, it completes within 24 hours.
What the erasure pipeline reaches, and what it does not. Processing an erasure removes the contact record and everything that cascades from it, the email, push and device-token records keyed to the contact's email hash, the funnel entries linked to the contact, the Firestore PII and consent documents, and the attendee's live-session actor data. It does not reach everything:
- Two tables holding personal data keyed by email hash are not reached by the erasure routine and have no foreign key to the contact record, so they are not removed by cascade either: the SMS delivery log and the segment-broadcast recipient log. A per-person record of SMS messages sent — email hash, webinar and session, template type, tracking code, provider message identifier, delivery status and delivery and click timestamps — therefore persists after an Article 17 erasure, and neither table is included in the Article 15 data export.
- AI generation records are keyed to the generated entity and the member of staff who started the job rather than to a contact, so a testimonial quote and the name of its author persist in the stored prompt and output after the contact has been erased.
- Live-session cleanup covers the attendee's actor node and the activity recorded against it, but not the per-actor synchronisation markers and message counters written by the background functions.
- A registration records a single attendee actor identifier, so where the same person joined a session from more than one device only the most recently recorded actor is cleaned up.
- Where an attendee changes their email address through the preferences page, the platform files an erasure request against the previous email hash while simultaneously updating the contact record to the new hash. The request finds no contact under the old hash and completes without deleting anything, so records keyed to the previous address remain.
- The audit log and the data-subject request register are not among the data types the retention job recognises, and nothing else in the platform deletes from them, so both grow without limit. The audit log records the acting user's IP address and user agent, and entries created by the data-subject rights workflow record the subject's email hash in their metadata, so an erased subject's email hash remains in the audit log after erasure. The application database role holds only select and insert privileges on the audit log, which makes it append-only for the application but also means it cannot be purged through the application's connection.
What the Article 15 and Article 20 export does not include. The export omits funnel entries — and therefore all campaign attribution, click identifiers, landing and referrer URLs, country, city, device type, operating system, browser and time zone — together with the SMS delivery log, the segment-broadcast recipient log and automation history.
GAP-RET-03 · CODE — KNOWN GAP, REMEDIATION PENDING
This guide previously presented platform-side erasure and export as complete, subject only to the Customer handling its own third-party accounts. The erasure pipeline does not reach the SMS delivery log, the segment-broadcast recipient log, AI generation records, per-actor live-session markers, sessions joined from a second device, or records held under a previous email address, and the data export omits funnel and attribution data, SMS sends and automation history. Completing an Article 15 or Article 17 response therefore requires manual work beyond the dashboard. This divergence is recorded on the compliance remediation register and is under review.
What you must do yourself:
- Verify the identity of the person making the request (to prevent unauthorized data disclosure)
- Communicate the outcome to the Data Subject
- Complete the parts of an erasure or an export that the pipeline does not reach, as listed above
- For Erasure: also delete the attendee's data from your own Firebase project (for push notifications) and from any other system you operate — [PLATFORM PROVIDER] handles its own systems but cannot access your Firebase account
Erasure and the email provider. Erasure at the email provider is a suppression, not a deletion. On completing an erasure the platform submits the contact's email address to the email provider with a permanently-rejected status, so that no future message can be delivered to it. By design this keeps the plaintext email address on file at the provider indefinitely. This call is made automatically by the platform, on the email provider account configured for your organisation, as part of processing the erasure; it is not an action you need to take and there is no per-organisation switch to disable it. Retaining the address in a suppression list is ordinarily justified under Article 17(3) as necessary to comply with the objection or erasure request itself, but it means the address is not removed from the provider. If you require full removal, delete the subscriber record in your own email provider account separately, accepting that this removes the safeguard against a future send. Note also that a platform-level email provider account exists alongside the per-organisation accounts.
7. Data Breach Obligations
If a personal data breach occurs (whether at [PLATFORM PROVIDER] or in your own systems):
[PLATFORM PROVIDER]'s obligation to you: Notify you within 24 hours of becoming aware of a breach affecting your attendees' data (per DPA Section 9 and Breach Response Plan data-breach-response-plan.md).
Your obligation as Controller:
- Assess the breach risk (likelihood and severity of harm to Data Subjects)
- Notify your supervisory authority within 72 hours if the breach is likely to result in a risk to individuals' rights and freedoms
- Notify affected attendees without undue delay if the breach is likely to result in a high risk to their rights and freedoms
- Keep a breach register documenting all breaches (even those that don't require notification)
The 24-hour processor notification and the 72-hour supervisory-authority notification are different obligations running on different clocks. The processor commitment is contractual; the 72-hour deadline is yours under Article 33 and runs from the moment you become aware.
Detection. Incident detection is currently manual. The platform emits structured application logs to standard output, which the hosting provider retains and makes searchable, and exposes an administrator-only system-health endpoint reporting request counters and database read counters. Those counters are held in process memory and reset on every restart or deployment. There is no error-tracking service, no on-call paging integration and no automated alerting: incident detection depends on a person observing logs, the health endpoint or a customer report. Take this into account when you assess when the processor's awareness clock realistically starts.
Contact for breaches: [PLATFORM PROVIDER SECURITY EMAIL] — 24/7 for critical incidents.
8. Conducting Your Own DPIA
You may need to conduct your own Data Protection Impact Assessment (DPIA) for your use of [PLATFORM PROVIDER]. A controller-level DPIA is required when your specific use case involves high-risk processing.
You likely need a DPIA if:
- You process behavioral data for automated decision-making that significantly affects attendees
- You target vulnerable populations (e.g., health-related events with medical advice)
- You combine [PLATFORM PROVIDER] data with data from other sources for profiling
- Your events operate at very large scale (tens of thousands of attendees)
You likely do NOT need a separate DPIA if:
- Your use of [PLATFORM PROVIDER] is straightforward (registration, email reminders, basic analytics)
- You do not make automated decisions based on behavioral data
- [PLATFORM PROVIDER]'s platform-level DPIA (dpia.md) adequately covers your use case
When in doubt, consult your DPO or GDPR counsel.
9. International Data Transfers
[PLATFORM PROVIDER] processes your data within the EEA (Romania). Some sub-processors are based in the USA (Google LLC, Railway Corp., Anthropic PBC, Meta Platforms, Inc. and TikTok Pte. Ltd.), Cloudflare, Inc. processes attendee traffic across a global edge network, and Microsoft Clarity is contracted in Ireland with an onward transfer to the USA. These transfers are covered by [PLATFORM PROVIDER]'s SCCs and EU-US Data Privacy Framework participation (see annex-sccs.md); the transfer mechanism for Anthropic PBC is not yet established and is recorded as outstanding in Annex III.
Transfers made by [PLATFORM PROVIDER] that you cannot switch off per organisation:
- Anthropic PBC (USA). AI generation of landing-page briefs, landing-page HTML, marketing copy and webinar poll questions is performed by a model provider in the United States, engaged by [PLATFORM PROVIDER] under a single platform-wide credential. Approved attendee testimonials — the author's display name, their free-text quote, their company and their rating — are embedded in the generation prompt, as are staff-uploaded reference images from your media library and the text of any third-party reference page a member of your staff supplies. Chat message content, registration records, contact email addresses, telephone numbers, poll answers and behavioural events are not sent. Every system prompt, user prompt and model output is retained in the platform database with the identifier of the member of staff who started the job, and is not subject to any retention period. Disclose this recipient in your Privacy Policy, and do not upload images depicting identifiable people as AI references unless you have a basis for that transfer.
- Cloudflare, Inc. Cloudflare is a mandatory reverse proxy in front of attendee traffic in production. It terminates TLS for and sees every attendee request, including registration submissions carrying plaintext email address, name and telephone number, and for that traffic the platform takes the client IP address it records or forwards from a Cloudflare-supplied header, which its IP-extraction helper checks before any other proxy header. Cloudflare Turnstile is additionally injected into published landing pages outside the consent bundle, and server-side verification transmits the visitor's IP address to Cloudflare. Cloudflare is a [PLATFORM PROVIDER] sub-processor, not an optional integration of yours.
Transfers caused by content you publish or configure:
- Your chosen video host. The attendee watch page embeds the stream in an iframe pointing at the playback URL you configure. Where that is YouTube, the standard
www.youtube.comdomain is used rather than the no-cookie variant, with no consent gate and no click-to-load placeholder, so a YouTube-hosted webinar transmits the attendee's IP address, user agent and viewing behaviour to Google and sets Google cookies for the duration of the session. Another third-party video host configured in the same field behaves the same way. Disclose the video host in your Cookie Policy and Privacy Policy. - Google Fonts. The page-generation prompts instruct the model to include a Google Fonts
<link>whenever the chosen typography calls for one, and the design-brief path instructs it in every case. When a published page is served, the public application rewrites those links to the page's own domain (/fonts/…) and fetches the stylesheets and font files from Google server-side, so the visitor's browser never contactsfonts.googleapis.comorfonts.gstatic.comand the visitor's IP address and user agent do not reach Google. Google receives only the platform's own server requests, which carry no visitor data. The page editor's preview is not rewritten: when a staff member previews a generated page in the dashboard, their browser loads the fonts from Google directly. The platform's own public and dashboard applications self-host their fonts. - Content delivery networks referenced during page generation. The AI page-generation prompts instruct the model to reference
cdn.tailwindcss.comandunpkg.com. Both are removed before publication: the icon script is replaced by inlined markup and the stylesheet is compiled at publish time. The compilation step fails open — if the compiler is absent from the runtime image it logs a warning and leaves the page unchanged, in which case the content delivery network reference would survive into a published page and be fetched by every visitor. Separately, the dashboard's page-preview panel loads the Tailwind content delivery network in the staff member's own browser while a page is being edited. These hosts are not sub-processors and should not be recorded as such, but the conditions above should be recorded as known.
Your responsibility for customer-provided integrations:
If you use your own accounts for Newsman, Google Firebase (push notifications), SendSMS.ro, or ad platforms (Meta, Google Ads, TikTok), you are responsible for ensuring those transfers comply with GDPR:
- NewsmanApp SRL — based in Romania (EEA); no SCCs required. Note that Newsman's role is wider than message delivery: a scheduled job bulk-synchronises plaintext email address, first name and last name into your list, per-subscriber segment membership is pushed, and Newsman returns view, click, bounce, complaint and unsubscribe events which the platform persists. Newsman therefore holds open and click behavioural data about your contacts, not only delivery logs
- Google Firebase (your FCM project) — Google Cloud DPA auto-applies; no separate SCC action required
- SendSMS.ro — based in Romania (EEA); no SCCs required, but a DPA is. The provider receives the attendee's telephone number in plaintext and the full message body, which contains the webinar title, the time remaining until start and a per-recipient tracked join URL. These values, together with the account username and password, are carried as URL query-string parameters on the outbound request and should be assumed to be recorded in the provider's request logs. The recipient's mobile network operator processes the message on delivery
- Meta / Google Ads / TikTok — your ad accounts; review each platform's DPA and transfer mechanisms
Disclose all international transfers in your Privacy Policy.
10. Your Sub-Processor List
Under GDPR, as a Data Controller, you must maintain records of the processors and sub-processors you use. Your list includes at minimum:
| Processor/Sub-Processor | Role | Location | DPA |
|---|---|---|---|
| [PLATFORM PROVIDER] | Event platform (Data Processor) | Romania (EU) | Signed DPA with [PLATFORM PROVIDER] |
| Google LLC (via [PLATFORM PROVIDER]) | Firebase, Cloud Storage ([PLATFORM PROVIDER]'s sub-processor) | USA/EU | Google Cloud DPA (auto-applies) |
| Railway Corp. (via [PLATFORM PROVIDER]) | Database hosting ([PLATFORM PROVIDER]'s sub-processor) | USA/EU | ⚠️ Not executed — Railway's data processing terms have been requested and not obtained; see Annex III and Annex IV |
| Cloudflare, Inc. (via [PLATFORM PROVIDER]) | Mandatory reverse proxy for attendee traffic, TLS termination, client IP determination, Turnstile challenge verification | Global edge network | Cloudflare Customer DPA — see Annex III |
| Anthropic PBC (via [PLATFORM PROVIDER]) | AI generation of pages, copy and poll questions; receives approved attendee testimonials and staff-uploaded reference images | USA | ⚠️ Transfer mechanism outstanding — see Annex III |
| Microsoft Corporation, contracted for EU customers via Microsoft Ireland Operations Limited (MIOL) | Microsoft Clarity session analytics on funnel pages, loaded only after analytics consent. Microsoft acts as an independent data controller for Clarity, not as a sub-processor acting on your behalf | Ireland (EU), with onward transfer to the USA | Microsoft Products and Services DPA — see Annex III |
| NewsmanApp SRL (your account) | Transactional email delivery; marketing list synchronisation (subscriber list contents and segment membership); engagement tracking (opens, clicks, bounce and complaint classification) | Romania (EU) | Your Newsman DPA |
| SendSMS.ro (your account) | Transactional SMS delivery | Romania (EU) | Your SendSMS DPA |
| Google LLC (your Firebase account) | Push notifications (FCM) | USA | Google Cloud DPA (auto-applies to your account) |
| Meta Platforms, Inc., Google LLC, TikTok Pte. Ltd. (your ad accounts) | Conversion tracking — client-side pixels and server-side conversion and page-view events | USA | Each platform's DPA |
| Your video host (e.g. Google LLC for YouTube) | Video playback on the attendee watch page; sets cookies and receives attendee IP address, user agent and viewing behaviour | Depends on host | Each platform's terms |
Keep this list updated. GDPR Art 30 requires Controllers to maintain Records of Processing Activities (ROPA).
11. Contact and Support
For GDPR and DPA questions: Email: [PLATFORM PROVIDER LEGAL EMAIL]
For data breach reporting: Email: [PLATFORM PROVIDER SECURITY EMAIL] (24/7 for critical incidents)
For DSAR processing assistance: Use the dashboard: GDPR
Documentation:
- DPA: dpa.md
- Sub-Processors: annex-sub-processors.md
- Security Measures: annex-security-measures.md
- SCCs: annex-sccs.md
- Privacy Policy Template: privacy-policy.md
Document Version: 1.0 (DRAFT) Prepared by: [Legal Team] Review Status: ⚠️ REQUIRES LEGAL REVIEW — Must be reviewed before sharing with customers.
Last Updated: [DATE]