Record of Processing Activities (ROPA)

[PLATFORM PROVIDER] — Acting as Data ProcessorGDPR Article 30(2)Last Updated: [DATE]

---

Introduction

This Record of Processing Activities (ROPA) documents the categories of personal data processing carried out by [PLATFORM PROVIDER] as a Data Processor on behalf of its customers (Data Controllers).

Legal Requirement: GDPR Article 30(2) requires all processors to maintain written records of processing categories.

Availability: This ROPA is maintained internally and made available to supervisory authorities (ANSPDCP in Romania) upon request. It is additionally served from [PLATFORM PROVIDER]'s public legal documentation site, which requires no authentication.

Scope and role. This record is an Article 30(2) processor record. Two production processing operations are not, as implemented, determined by the Customer. AI-assisted content generation runs on a single platform-level credential held by [PLATFORM PROVIDER]; the model provider, the models and the retention of prompts and outputs are chosen by [PLATFORM PROVIDER], there is no per-organisation credential and no per-organisation switch (Processing Activity 7). The server-side advertising measurement described in Processing Activity 3 operates on a legitimate-interest assessment set out in the Data Protection Impact Assessment rather than on an instruction recorded in a Data Processing Agreement. Where a processor determines the purposes and means of processing, Article 28(10) treats it as a controller for that processing. Neither an Article 30(1) controller record nor an Article 13/14 notice has been produced for either operation.

GAP-GOV-02 · GOVERNANCE — KNOWN GAP, REMEDIATION PENDING

This record previously presented [PLATFORM PROVIDER] as acting exclusively as a processor for every operation it performs. Two operations — AI-assisted content generation and server-side advertising measurement — are decided by [PLATFORM PROVIDER] on its own credentials and its own asserted legal basis, which is a controller determination under Article 28(10), and neither the corresponding Article 30(1) record nor the corresponding Article 13/14 notice exists. This divergence is recorded on the compliance remediation register; the classification is under review.

---

Processor Information

Field	Value
Processor Name	[PLATFORM PROVIDER]
Company Registration Number	[Romanian CUI Number]
Address	[Street Address] [City, Postal Code] Romania
Contact Email	[email protected]
Representative (if applicable)	[Name, Title]
Data Protection Officer (DPO)	[Name, Email] (if appointed)
DPO Contact (if applicable)	[email protected]

---

Processing Activity 1: Event Hosting and Attendee Management

Name and Description of Processing

Event platform operation: Hosting live and recorded events, managing attendee registrations, providing real-time features (chat, polls, offers, Q&A).

Data Controller(s)

Organizations subscribing to [PLATFORM PROVIDER] services (multiple Data Controllers, one per organization)

• Each customer organization is an independent Data Controller
• [PLATFORM PROVIDER] processes data on behalf of each Controller per individual Data Processing Agreement (DPA)

Representative of Data Controller

As specified in each DPA with customer organization

Categories of Data Subjects

1. Event Attendees (B2C end users)

   • Individuals who register for and attend events hosted by customer organizations
   • Estimated volume: 10,000 - 100,000 attendees per year (across all customers)

2. Customer Staff Users (B2B employees)

   • Employees and contractors of customer organizations with dashboard access
   • Roles: admin, moderator, marketer, staff (see Staff roles below)
   • Estimated volume: 500 - 2,000 staff users per year

Staff roles. 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.

GAP-GOV-05 · GOVERNANCE — KNOWN GAP, REMEDIATION PENDING

This record previously described a two-role model consisting of an administrator with full access and staff with read-only analytics access, and relied on that model as an access-control safeguard. Four roles exist, two of which are non-administrator roles that can perform destructive actions, and only the audit-log listing is restricted to administrators. This divergence is recorded on the compliance remediation register and is under review.

Categories of Personal Data

Category	Data Elements	Source
Registration Data	- Email address - First name - Last name - Phone number (optional)	Provided directly by Data Subject during event registration
Behavioral Data	- Chat messages - Poll votes (answers) - Offer clicks - Reactions (emojis) - Q&A questions - Attendance timestamps (join/leave time) - Session duration - Session count (rejoins)	Generated automatically during event attendance
Technical Data	- Registration country (ISO 3166-1 alpha-2 code, e.g. "RO") — derived from IP via local MaxMind GeoLite2 database; raw IP not stored on the registration record - Registration city (English name, e.g. "Bucharest") — derived from IP; raw IP not stored on the registration record - Device type (mobile / tablet / desktop / bot) — derived from User-Agent; the raw User-Agent string is additionally stored in the registration's attribution metadata - Operating system family (ios / android / windows / macos / linux / other) — derived from User-Agent; the raw User-Agent string is additionally stored in the registration's attribution metadata - Browser family (chrome / firefox / safari / edge / opera / samsung / other) — derived from User-Agent; the raw User-Agent string is additionally stored in the registration's attribution metadata - Timezone (IANA, e.g. "Europe/Bucharest") — sent by browser's Intl API at registration time - Firebase Anonymous Auth UID (actor_id) — ephemeral per-browser pseudonymous identifier for RTDB participation - Firebase Auth UID (firebaseUid) — stored on mobile app contact doc in Firestore; enables UID→contact lookup for API-proxied auth. Not linked to attendee's email in RTDB. - FCM push token (device token) — pseudonymous device identifier used to deliver push notifications via Firebase Cloud Messaging. Stored in Postgres device_tokens table keyed by (org_id, email_hash, fcm_token). Platform: android or ios. One contact may have multiple tokens (multiple devices).	Derived at registration time from three sources: HTTP request (IP → geo lookup via local MaxMind database, User-Agent → device/OS/browser classification) and browser's Intl.DateTimeFormat API (timezone). The raw IP address is not stored as an attendee attribute on the registration record. The raw user agent string is additionally written into the registration's attribution metadata — held on the funnel entry and on the Firestore registration document — by the registration form's client script, and is read from there when a server-side conversion event is transmitted. Both values are additionally persisted or transmitted elsewhere: a stable SHA-256 hash of the IP address and the User-Agent is stored per visitor in funnel_page_views (Processing Activity 5), the acting user's raw IP address and User-Agent are stored on every staff action in audit_log, and both raw values are transmitted to advertising platforms on the server-side paths described in Processing Activity 3. FCM tokens are registered by the mobile app after OS push permission is granted. Firebase Auth UID is stored only for mobile app users. Legal basis: legitimate interest (Art 6(1)(f)) — product analytics, fraud detection, and service delivery (push notifications).
Attribution Data	- UTM parameters (utm_source, utm_medium, utm_campaign, utm_content, utm_term) - Advertising click IDs (fbclid, gclid, ttclid, li_fat_id) - Click platform (meta, google, tiktok, linkedin) - Landing page URL - Referrer URL - Referral share token (if arrived via share link from another attendee)	Captured from URL parameters on landing page visit and stored as columns on funnel_entries, linked to the contact (see Processing Activity 5)
Referral Sharing Data	- Share token (12-char random ID) - Sharing channel (whatsapp, email) - Share source (lobby, watch, confirmation email, reminder email, etc.) - Click count per share link - Registration count per share link	Generated when Data Subject uses share buttons in event lobby, watch page, or transactional emails
Email Delivery Data	- Send ID (Newsman correlation) - Email type (confirmation, reminder, starting, replay) - Delivery status (delivered, bounced, spam, rejected) - Engagement events (opened, clicked, unsubscribed) - Timestamps	Recorded by email delivery provider (Newsman) via webhooks. Linked to hashed email, not plaintext.
Consent Records	- Consent granted/revoked dates - Consent purposes — there are exactly ten valid purposes in the ledger: data_processing, tos_acceptance, email_marketing, push_notifications, push_marketing, behavioral_tracking, whatsapp_notifications, whatsapp_marketing, sms_notifications, sms_marketing. Any request naming a purpose outside this list is rejected. data_processing and tos_acceptance cannot be withdrawn through the preferences page. - Consent method (checkbox at registration or in the preferences page / app_onboarding for mobile app / import for bulk-loaded contacts / newsman_sync_reconcile where an unsubscribe recorded at the email provider revokes email_marketing). The cookie banner is not a consent method here — see the note below. - Consent version (privacy policy version at time of consent; the version in force is "1.0") Note on purposes that gate nothing: whatsapp_notifications and whatsapp_marketing are accepted and displayed but gate nothing — there is no WhatsApp send path. push_marketing and sms_marketing likewise gate nothing. Note on push consents: Transactional push notifications (reminders, starting, replay) require an explicit granted push_notifications consent row combined with OS-level push permission; they are not covered by data_processing. The push_marketing consent is collected as a marketing push opt-in via the mobile app post-registration preferences flow, but no marketing push send path is implemented. Note on cookie-banner consent: 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. Cookie-banner categories (necessary, analytics, advertising) are a separate vocabulary and are not valid consent-ledger purposes. Note on GTM and Consent Mode v2: Google Tag Manager (GTM) is loaded as a "necessary" technology. The container itself does not collect personal data or set cookies. All tags inside GTM respect Google Consent Mode v2 signals, which default to "denied" for all consent types (analytics_storage, ad_storage, ad_user_data, ad_personalization). Signals are updated to "granted" only when the attendee grants consent via the cookie banner. The Meta and TikTok pixels are not GTM tags and are not governed by those signals — see Processing Activity 3.	Recorded when Data Subject checks consent boxes during registration, in lobby (phone-based purposes), via mobile app onboarding/post-registration flow, when a contact is loaded through the bulk importer, or when the email provider reports an unsubscribe. Cookie-banner choices are not recorded here.
Push Delivery Data	- Push notification send record (template type, FCM message ID, send status: sent / failed / unregistered) - Open event (timestamp when user taps the push notification — client-reported) - Event and session context (event_id, session_id for delivery analytics) - Error details if send failed	Recorded when transactional push notifications are sent. No marketing push send path is implemented, so no marketing push record is created. Open tracking is client-reported via POST /v1/attendee/push-opened. Data linked to email_hash (pseudonymous), not plaintext email. Mirrors email_sends delivery analytics pattern.
Staff Data	- Email address - Name - Role (admin, moderator, marketer, staff) - Firebase Auth UID - Audit-log record of every staff action: acting user identifier, role, action, target type and identifier, action metadata, raw IP address, raw User-Agent and request identifier	Provided by customer organization (employer) when creating staff user account. The audit-log fields are generated automatically on every write action a staff user performs in the dashboard.
Funnel Measurement Data	- Persistent pseudonymous visitor identifier: an SHA-256 hash of the visitor's IP address and User-Agent, recorded once per visitor per funnel step per day in funnel_page_views. The hash is stable over time — the same visitor produces the same value on every visit — and is therefore a persistent pseudonymous identifier. - Campaign, device and approximate-location columns on funnel_entries (see Attribution Data above)	Generated on every non-bot visit to a published funnel or landing page by a server-side tracking pixel that operates without a consent gate (see Processing Activity 5)
Purchase / Transaction Data	- Order identifier, order total, currency and payment status, stored as funnel entry metadata - The purchaser's email address, used to match an existing contact record - For generic and form-provider webhooks, the entire raw request body, stored verbatim as funnel entry metadata, which may contain arbitrary form answers	Customer's e-commerce or form platform (MerchantPro, WooCommerce, Tally or a generic sender) via inbound webhook — not collected from the Data Subject (see Processing Activity 5)
Automation Execution Records	- Enrolment record: contact identifier, current step, status, enrolment and completion timestamps, and a JSON copy of the triggering event - Step execution record: status, execution timestamp and a JSON result document - The step execution result document contains the recipient's plaintext email address for email steps and their plaintext telephone number for SMS steps	Generated when a contact is enrolled in an automation and each step is executed (see Processing Activity 6)
AI Generation Records	- Full system prompt, user prompt, custom instructions, model identifier, full model output, input and output token counts and duration - Approved attendee testimonials embedded in the generation prompt: the attendee's display name, their free-text quote, their company and their rating - Identifier of the member of staff who started and who accepted the generation	Generated when a member of staff initiates an AI generation from the dashboard page editor or the poll editor (see Processing Activity 7)
SMS Delivery Data	- Email hash, webinar and session identifiers, template type, tracking code - Provider message identifier, delivery status, error text, delivery and click timestamps	Recorded when a transactional or automation message is submitted to the messaging provider and when the provider reports delivery (see Processing Activity 8). The telephone number itself is read from Firestore at send time and is not stored in PostgreSQL.
Segment Broadcast Records	- Recipient log: email hash, segment identifier, campaign key and send timestamp - Message content: subject, title, body, call-to-action label and URL, and the identifier of the member of staff who composed it	Generated when a member of staff sends a one-off email to the members of a saved segment (see Processing Activity 9)
Moderation Records	- Removed chat message: the full original message text, the author's actor identifier and display name, the removal timestamp and the removal reason - Masked chat message: the message as altered in place; the original text is not retained in this case	Generated automatically when a chat message matches a per-session banned-words list, and when a member of staff removes a message manually
Stored Files (Cloud Storage)	- Organisation media library, branding assets, page templates, offer and webinar imagery, staff assets and published landing-page files. These are Customer marketing assets and may depict identifiable individuals.	Uploaded by customer staff through the dashboard, imported from a URL supplied by staff, or written by the platform when a landing page is published

Special Categories of Data (Art 9): None intentionally collected. If Data Subjects voluntarily disclose sensitive information (health status, political opinions, religion) in chat messages, customer organization (Data Controller) is responsible for reviewing and removing the message. Automated screening of chat content is described below and does not detect special categories of data.

Automated moderation of chat content. Every chat message is screened by a Cloud Function against a per-session banned-words list configured by the Customer's staff. Plain matches are masked in place with a fixed-length replacement. Where an obfuscated spelling survives masking, the message is removed from the live stream and the full original text, together with the author's actor identifier and display name, is written to a staff-readable removed-message store. The attendee is given no notice that their message was altered or removed. The same masking and removal can be applied retroactively to messages already sent.

GAP-PROD-02 · PRODUCT — KNOWN GAP, REMEDIATION PENDING

This record previously listed chat messages as a behavioural data category and placed responsibility for moderation and removal entirely on the Customer as controller, with no mention of automated screening. Chat messages are in fact screened automatically, may be altered in place or silently removed without notice to the attendee, and the full original text of a removed message is retained in a separate staff-readable store. This divergence is recorded on the compliance remediation register and is under review.

Cloud Storage. The Cloud Storage security rules grant unconditional public read access to all seven organisation-scoped paths — webinars/, pages/, offers/, media/, page_templates/, branding/ and staff/ — so any object stored under an organisation's prefix is readable by anyone who knows or can guess its path, without authentication. Write access on those same paths requires only that the caller be authenticated; the organisation identifier in the path is never compared against the caller's token, so an authenticated user of one organisation can overwrite another organisation's branding, media, page templates and landing-page files. A final catch-all rule grants read and write access to every remaining object in the bucket to any authenticated user, which includes every anonymous attendee. No retention period applies to stored objects and the Article 17 erasure pipeline does not delete any object from the bucket.

GAP-ISO-03 · CONFIG — KNOWN GAP, REMEDIATION PENDING

This record previously contained no entry for files held in Cloud Storage, and the sub-processor annex described the bucket as holding landing-page files only. The bucket holds the organisation media library, branding assets, page templates and staff assets in addition to landing-page files; every organisation-scoped path is publicly readable without authentication and writable by any authenticated user; and no retention period or erasure path reaches stored objects. This divergence is recorded on the compliance remediation register and is under review.

Purposes of Processing

Purpose	Legal Basis (determined by Controller)	Description
Event Access Delivery	Contract performance (Art 6(1)(b))	Provide access to event room, display attendee name in chat, enable real-time participation (polls, chat, offers, Q&A)
Registration Confirmation	Contract performance (Art 6(1)(b))	Send email confirming successful registration, provide event access link
Event Reminders	Contract performance (Art 6(1)(b))	Send reminder emails (1 hour before start, "starting now") to ensure attendees don't miss live event
Replay Notifications	Contract performance (Art 6(1)(b))	Notify attendees when replay recording is available
Lead Qualification	Consent (Art 6(1)(a))	Analyze behavioral data (chat activity, poll engagement, offer clicks) to score attendee engagement for sales follow-up. Only if Data Subject consents to "behavioral tracking"
Marketing Communications	Consent (Art 6(1)(a)) for synchronisation into the marketing email provider; otherwise determined by the Controller	Send future event invitations and educational content. email_marketing consent 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, staff-initiated resend and segment broadcast — runs on the transactional gate alone (the contact is not suppressed for bounce, complaint or global opt-out, and is not subject to an Art 18 processing restriction). Withdrawing email_marketing does not remove a contact from a segment broadcast — see Processing Activity 9.
SMS Notifications	Consent (Art 6(1)(a))	Send event reminders, "starting now" and "replay available" messages, and automation SMS steps. Only sent where the contact holds a granted, unrevoked sms_notifications consent and is not subject to an Art 18 processing restriction. On the public funnel form that consent is granted implicitly by the presence of a telephone number in the submission; there is no separate SMS checkbox. See Processing Activity 8.
WhatsApp Notifications and WhatsApp/SMS Marketing	No processing occurs	The preferences interface collects whatsapp_notifications, whatsapp_marketing and sms_marketing consents, but no WhatsApp send path exists and sms_marketing gates no send path either. These opt-ins are recorded in the consent ledger and displayed to the Data Subject; no message is ever sent on the basis of them and no processing is carried out under these purposes.
Push Notifications (Transactional)	Consent (Art 6(1)(a)) + OS push permission	Send transactional push notifications to mobile app users: registration confirmation, event reminder (default 15 min before start), "starting now", replay available. Requires an explicit granted push_notifications consent row, OS push permission granted by the Data Subject, and a registered FCM token. data_processing consent alone is not sufficient.
Push Notifications (Marketing)	No processing occurs	The push_marketing consent is collected via the mobile app post-registration preferences flow, but no marketing push send path is implemented and no marketing push notification is sent.
Ad Conversion Tracking	Legitimate interest (Art 6(1)(f))	Send server-side conversion events (hashed identifiers, raw IP address, raw User-Agent, click IDs) to advertising platforms for campaign attribution. There is no advertising-consent gate on this path. The only enforced suppression is a GDPR Art 18 processing restriction. See Processing Activity 3 and the balancing test in the DPIA, Section 3.3.
Staff-Initiated Transactional Sends	Contract performance (Art 6(1)(b))	A member of staff may, on demand, re-issue a specific registrant's confirmation email or resend a previously sent email to a named recipient. Both actions mint fresh personalised join, cancel and preferences links for that contact and bypass the organisation's automatic-confirmation setting. Both are recorded in the audit log as sent_registration_confirmation and resent_email, and both are available to the marketing permission group — not to administrators only.
Automated Content Moderation	Legitimate interest (Art 6(1)(f))	Screen every chat message against a per-session banned-words list configured by the Customer's staff; mask plain matches in place and remove messages whose obfuscated spelling survives masking, retaining the full original text and the author's identity in a staff-readable removed-message store. No notice is given to the attendee.
Platform Security	Legitimate interest (Art 6(1)(f))	Prevent spam in chat, detect fraudulent registrations (e.g. bot detection via device_type), protect against security threats. Legitimate interest: platform integrity and other attendees' rights outweigh minimal privacy impact
Registration Geo/Device Enrichment	Legitimate interest (Art 6(1)(f))	Derive country, city, device type, OS family, browser family, and timezone at registration time from three sources: client IP (MaxMind GeoLite2, local lookup — no data sent to MaxMind per request), User-Agent string (device type, OS, browser), and browser Intl API (IANA timezone). Stored as columns on funnel_entries — country_code, city, device_type, device_os, device_browser, device_timezone — linked to the contact record. The raw IP address and raw User-Agent are not stored on that record, but a stable SHA-256 hash of both is stored per visitor in funnel_page_views, and both raw values are transmitted to advertising platforms on the server-side paths in Processing Activity 3. Used for audience analytics, optimal event scheduling (timezone), and product improvement.
GDPR Compliance	Legal obligation (Art 6(1)(c))	Process Data Subject rights requests (access, deletion, portability, objection, restriction), maintain audit logs, respond to supervisory authority inquiries. Rectification is performed but cannot be recorded as a request type — see Processing Activity 4.

How consent is actually collected and recorded. The following statements qualify every consent-based legal basis in the table above.

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.

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.

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. The import also creates a registration record and triggers a confirmation email.

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.

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.

GAP-CONSENT-06 · CODE — KNOWN GAP, REMEDIATION PENDING

This record previously presented consent as the operative gate on marketing communications, on WhatsApp and SMS messaging, on marketing push and on server-side advertising measurement, and described transactional push as covered by data_processing consent. In the implemented system email_marketing gates only synchronisation into the marketing email provider, the WhatsApp, marketing-push and SMS-marketing purposes gate no send path at all, server-side advertising measurement has no advertising-consent gate, and transactional push requires an explicit push_notifications consent that this record did not list among the valid purposes. This divergence is recorded on the compliance remediation register; the classification is under review.

Categories of Recipients

Recipient Category	Purpose	Location	Safeguards
Customer Organization (Data Controller)	Access to all processed data via dashboard and API (customer is the Controller)	As specified by customer	N/A (Controller receives data from Processor)
Google LLC (Firebase, Google Cloud)	Database storage (Firestore, RTDB), authentication, cloud functions, file storage, secret management	EU — Cloud Functions in europe-west3, Realtime Database in europe-west1, Firestore in the EU multi-region. ⚠️ The Cloud Storage bucket location is not evidenced in [PLATFORM PROVIDER]'s records and must be confirmed against the project configuration	Google Cloud DPA, SCCs, ISO 27001, SOC 2
Railway Corp.	PostgreSQL database hosting, API hosting, app hosting	EU region	Railway DPA (requested), SOC 2 Type II
NewsmanApp SRL	Transactional and marketing email delivery; bulk synchronisation of plaintext email address, first name and last name in batches of up to one hundred thousand subscribers; per-subscriber segment membership; and the return of view, click, bounce, complaint and unsubscribe events, which the platform persists. Newsman therefore holds open and click behavioural data, not only delivery logs. A platform-level Newsman account exists alongside the per-organisation accounts.	EU (Romania)	Newsman DPA (requested), GDPR-compliant
Meta Platforms, Inc.	Server-side ad conversion tracking on registration, and a server-side PageView for every visitor to a funnel landing page (whenever the customer enables the Meta integration; no attendee consent is checked)	USA	Meta Business Tools Terms, SCCs, hashing of directly identifying fields. Raw IP address and raw User-Agent are transmitted unhashed.
Google LLC (Google Ads)	Server-side ad conversion tracking — not implemented; receives no data	USA	Not applicable while the integration is unimplemented
TikTok Pte. Ltd.	Server-side ad conversion tracking (CompleteRegistration on every registration) — active since 8 May 2026, whenever the customer enables the TikTok integration; no attendee consent is checked	USA / Singapore	⚠️ No DPA or SCCs on file. Hashing of directly identifying fields; raw IP address, raw User-Agent, raw ttclid and raw _ttp are transmitted unhashed.
LinkedIn Corporation (Microsoft)	LinkedIn Insight Tag and Conversions API — not implemented; receives no data	USA	Not applicable while the integration is unimplemented
Cloudflare, Inc.	Mandatory in-path reverse proxy for attendee domains in production: terminates TLS for and sees every attendee request, including registration submissions carrying plaintext email address, name and telephone number. 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.	Global edge network	Cloudflare DPA and SCCs; TLS in transit
Microsoft Corporation, contracted for EU customers via Microsoft Ireland Operations Limited (MIOL)	Microsoft Clarity — session recordings, heatmaps and behavioural analytics on public pages, where the customer enables it. Loads only after the visitor accepts the analytics cookie category, and is skipped entirely in the attendee application.	USA / EU	Microsoft Clarity terms; EU-US Data Privacy Framework (Microsoft certified); SCCs
SendSMS.ro	Transactional SMS and automation SMS delivery, where the customer configures SendSMS credentials. Receives the recipient's plaintext telephone number and the full message body.	EU (Romania)	⚠️ No DPA on file. Per-organisation credentials held in Google Secret Manager. ⚠️ Credentials and personal data are transmitted as URL query-string parameters on an HTTP GET request, so the recipient's telephone number, the message body and the account password should be assumed to be recorded in the provider's request logs.
Anthropic PBC	AI generation of landing-page briefs, landing-page HTML, marketing copy and poll questions. Engaged by [PLATFORM PROVIDER] under a single platform-wide credential — not a customer-provided integration and not switchable off per organisation. Receives approved attendee testimonials (display name, quote, company, rating) embedded in the generation prompt, staff-uploaded reference images and Customer content.	USA	⚠️ DPA and transfer mechanism not established. Server-side only; no attendee device contacts the provider and no cookies are set.
Google LLC (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. The public application serves those fonts from the page's own domain and fetches them from Google server-side, so visitors' IP addresses and User-Agents do not reach Google. 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. Served under Google's own terms, not the Google Cloud DPA.	Global (Google edge)	⚠️ Staff preview only; no separate DPA
Third-party video hosts (typically Google LLC / YouTube)	The attendee watch page embeds the stream in a www.youtube.com iframe — not 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. The playback URL is organisation-supplied, so another third-party video host may be embedded the same way.	As determined by the host (Google: global)	⚠️ No consent gate. The choice of host is the Controller's; the cookies and transfers it causes are the Controller's responsibility.
Customer's own staff, outside the platform (CSV export)	Segment and contact exports download plaintext email addresses and names to the exporting staff member's device. The export deliberately does not require email_marketing consent, and an option widens it to contacts suppressed for bounce, spam complaint or global opt-out. Contacts who have unsubscribed remain in the default export, because unsubscribing revokes email_marketing without setting the suppression flag.	As determined by the customer	Restricted to the marketing permission group and recorded in the audit log. Contacts subject to an Art 18 processing restriction are always excluded.
Supervisory Authorities	Regulatory inquiries, audits, breach notifications	EU (ANSPDCP in Romania, others)	Legal obligation to cooperate

Onward Transfers: [PLATFORM PROVIDER] does not transfer personal data to recipients outside the table above other than as follows. Where a visitor follows a tracked redirect link, the platform forwards the campaign parameters and the advertising click identifiers — utm_source, utm_medium, utm_campaign, utm_content, utm_term, fbclid, gclid, ttclid, li_fat_id and the referral source — onto the destination URL, which is frequently a third-party site chosen by the Customer. Where a member of staff supplies a reference URL for AI generation, the platform issues a request to the operator of that page.

GAP-CONTRACT-02 · CONTRACT — KNOWN GAP, REMEDIATION PENDING

This record previously listed eight recipient categories, described the TikTok and LinkedIn integrations as future, described Cloudflare as a conditional content-delivery network and named no messaging provider, no AI provider, no analytics provider and no third-party video host. The TikTok Events API has been live since 8 May 2026 and transmits hashed identifiers together with the attendee's unhashed IP address and User-Agent on every registration without a DPA or Standard Contractual Clauses on file; Cloudflare is a mandatory in-path proxy that sees every attendee request; and the messaging, AI, analytics and video recipients above receive personal data today. The thirty-day sub-processor notice recorded below was not given for the recipients newly disclosed in this revision. This divergence is recorded on the compliance remediation register and is under review.

International Transfers (Outside EEA)

Destination Country	Recipient	Safeguards
USA	Google Cloud (Firebase)	EU-US Data Privacy Framework (Google certified) + Standard Contractual Clauses (2021) + ISO 27001
USA	Meta (Conversions API)	Standard Contractual Clauses (2021) + Hashing (SHA-256) of directly identifying fields. ⚠️ Raw IP address and raw User-Agent are transmitted unhashed, on registration and on every landing-page visit.
USA	Google Ads (Enhanced Conversions)	⚠️ Not implemented — no data transferred
USA	Railway (if using US region)	⚠️ Not used — EU region enforced
USA / Singapore	TikTok (Events API) — active since 8 May 2026	⚠️ No Standard Contractual Clauses and no DPA on file. Hashing (SHA-256) of email, first name, last name and external identifier — no telephone number is transmitted; raw IP address, raw User-Agent, raw ttclid and raw _ttp transmitted unhashed.
USA	LinkedIn (Microsoft)	⚠️ Not implemented — no data transferred
USA	Anthropic PBC (Claude API)	⚠️ Transfer mechanism not established. Prompts containing approved attendee testimonials, staff-uploaded reference images and Customer content are transmitted server-side to api.anthropic.com.
USA / EU	Microsoft Corporation (Microsoft Clarity), contracted for EU customers via Microsoft Ireland Operations Limited	EU-US Data Privacy Framework (Microsoft certified) + Standard Contractual Clauses. Loads only after analytics consent.
Global edge	Cloudflare, Inc. (reverse proxy, Turnstile)	Cloudflare DPA + Standard Contractual Clauses. Sees every attendee request in cleartext after TLS termination, including registration submissions.
Global edge	Google LLC (Google Fonts)	⚠️ No separate transfer mechanism recorded. A staff member's IP address and User-Agent reach Google when they preview a generated page in the page editor. Landing-page visitors' browsers do not contact Google Fonts.
As determined by the host	Third-party video hosts (typically Google LLC / YouTube)	⚠️ No consent gate. Host selection is the Controller's; the transfer it causes is the Controller's responsibility.

Transfer Impact Assessment (Schrems II): Completed [DATE] — risks assessed as acceptable given: (1) EU-US DPF certifications, (2) SCCs in place, (3) data minimization (hashed PII for ad platforms), (4) no special categories of data. ⚠️ That assessment covers only the recipients recorded at the time it was carried out. It does not cover TikTok Pte. Ltd., Anthropic PBC, Cloudflare, Inc., Microsoft Corporation, SendSMS.ro, Google Fonts or third-party video hosts, and it predates the disclosure that raw IP addresses and raw User-Agents are transmitted unhashed to advertising platforms. The assessment must be repeated before this record is relied on.

Annual Review: Transfer risks reviewed annually. If US surveillance laws pose unacceptable risk (per supervisory authority guidance), transfers will be suspended.

Data Retention Periods

Data Type	Retention Period	Reason	Deletion Method
Registration Data (email, name, phone)	Duration of active org-contact relationship. No automated deletion — see the note on retention configuration below.	Controller's legitimate interest in ongoing business relationship and service delivery	Hard delete from Firestore (orgs/{orgId}/contacts/{emailHash}/pii/private) + PostgreSQL contacts table (CASCADE)
Behavioral Events (chat, polls, offers)	No automated deletion in practice. The enforcement job supports behavioral_events, but no default policy is seeded and no policy can currently be saved — see the note below.	Consent-based lead qualification (short-term analytics)	Hard delete from PostgreSQL behavioral_events table. The corresponding live-session records in the Realtime Database are not deleted — see the row below.
Live-Session Data (Realtime Database)	No automated deletion. Retained indefinitely for the lifetime of the webinar record.	Live session functionality; no retention control implemented	Manual deletion of the session or of the parent webinar. No other operation removes a live-session node.
Attendance Records	Duration of active org-contact relationship. No automated deletion.	Contract records + analytics — needed for service delivery, replay access, and attendee history	Hard delete from PostgreSQL webinar_registrations by CASCADE from contacts. Attendance is held as the attended_via and attended_at columns on that table; there is no separate attendance table. Campaign, geo and device enrichment lives on funnel_entries (country_code, city, device_type, device_os, device_browser, device_timezone) and is deleted by explicit query in the erasure pipeline.
Consent Records	Deleted together with the contact record (CASCADE on GDPR erasure request or org termination). No independent time-based deletion.	Legal obligation (proof of valid consent — GDPR Art 7(1))	Hard delete from PostgreSQL consents + Firestore consents/{id}. consent_events, the append-only history, is a deliberate exclusion: its contact reference is set to null on erasure and the row itself is retained, holding the organisation, webinar and registration identifiers, the purpose, the action, the method, the policy version and the timestamp, as Article 7(1) accountability evidence.
Audit Logs (staff PII access)	No automated deletion. The audit log is not among the data types the retention job recognises, and the application database role holds only select and insert privileges on it, which makes it append-only for the application but also means it cannot be purged through the application's connection.	Security accountability (Art 5(2))	No deletion path and no anonymisation. 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, alongside the acting staff member's raw IP address and User-Agent.
Staff User Accounts	Duration of employment + 30 days	Contract performance (employer-employee relationship, customer org is employer)	Delete from Firestore orgs/{orgId}/users/{userId} + Firebase Auth. The staff member's audit-log history, including their IP addresses and User-Agents, is not deleted.
FCM Device Tokens	No automated deletion. Configurable per customer but disabled by default, and no policy can currently be saved. Deleted on an FCM UNREGISTERED response (stale token), on GDPR erasure, or on explicit revocation by the app user.	FCM tokens expire if the app isn't opened (tokens become stale).	Hard delete from PostgreSQL device_tokens table (matched by org_id + email_hash). No FK dependency — deletion is by explicit query.
Email Delivery Records (email_sends)	No automated deletion. The enforcement job supports this table, but the API does not accept it as a configurable data type, so no policy can be saved. Deleted on GDPR erasure or org termination.	Delivery analytics + accountability	Hard delete from PostgreSQL email_sends (matched by org_id + email_hash) in the erasure pipeline.
Push Delivery Records (push_sends)	No automated deletion. Same position as email_sends. Deleted on GDPR erasure or org termination.	Delivery analytics + accountability (mirrors email delivery tracking). Open timestamps (client-reported) are analytics data, not service-critical.	Hard delete from PostgreSQL push_sends table (matched by org_id + email_hash). No FK dependency.
SMS Delivery Records (sms_sends)	No automated deletion. The enforcement job supports this table but the API rejects it as a configurable data type, so no policy can be saved.	Delivery analytics + accountability	No deletion path. Keyed by email_hash with no foreign key to contacts, so the table is reached neither by the erasure pipeline nor by cascade, and it is absent from the Article 15 export.
Segment Broadcast Records (segment_broadcasts, segment_broadcast_sends)	No automated deletion — neither table is a configurable data type.	Duplicate-suppression on repeat sends; reuse of previous broadcast content	No deletion path. The recipient log is keyed by email_hash with no foreign key to contacts, so it is reached neither by the erasure pipeline nor by cascade, and it is absent from the Article 15 export.
Funnel Entries (funnel_entries)	No automated deletion — not a configurable data type.	Campaign attribution and conversion measurement	Explicit delete by contact in the erasure pipeline; CASCADE from the parent funnel or step. Omitted from the Article 15 and Article 20 export.
Funnel Page Views (funnel_page_views)	No automated deletion — not a configurable data type.	Unique-visitor measurement per funnel step	CASCADE from the parent funnel or step only. Not reached by erasure — the row carries no link to a contact record.
Automation Enrolments and Step Executions	No automated deletion — none of the four automation tables is a configurable data type.	Journey execution history	CASCADE from contacts for enrolments and from the enrolment for step executions. This cascade is the only mechanism that removes the plaintext email addresses and telephone numbers held in the step result documents.
AI Generation Jobs (ai_jobs)	No automated deletion — not a configurable data type.	Cost tracking, versioning and reproducibility of generations	No deletion path. Rows are keyed to an entity and a staff user, not to a contact record, so they are not reached by the erasure pipeline or by cascade. A testimonial quote and the name of its author persist in the stored prompt and output after the contact has been erased.
Lead Scores (lead_scores)	No automated deletion in practice. lead_scores is one of five data types the API accepts, but the retention settings screen cannot save any policy — see the note below. Deleted via CASCADE on contact erasure (GDPR Art 17). Scores are not computed for contacts with processing_restricted = true.	Derived from behavioral events (consent-based). Stale scores from old events can be purged independently.	Hard delete via retention enforcement job or CASCADE from contacts table. Included in GDPR data export (Art 15).
Stored Files (Cloud Storage)	No automated deletion. No retention period applies to any object in the bucket.	Marketing assets and published landing-page files	No deletion path. The Article 17 erasure pipeline does not delete any object from Cloud Storage.
Scoring Configuration (scoring_configs)	Duration of org subscription (org-level, no PII)	Org configuration data, not personal data	Deleted on org termination
GDPR Request Records	No automated deletion. The request register is not among the data types the retention job recognises and nothing else in the platform deletes from it.	Legal obligation (evidence of compliance)	No deletion path and no anonymisation. The register retains the request type, the subject's email hash, the dates and the resolution method indefinitely.

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 a policy does exist, the configurable bounds are 30 to 3,650 days.

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 record previously described per-customer configurable retention with a thirty-day minimum and a ten-year maximum as an operating control, assigned fixed retention periods of two years to the audit log, three years to the request register and sixty days to device tokens, and stated that live-session data in the Realtime Database is ephemeral and automatically deleted after a session. No retention policy can currently be saved through the product, none is seeded by default, none of those three fixed periods is implemented, and nothing deletes live-session data other than the manual deletion of a session or of its parent webinar. This divergence is recorded on the compliance remediation register and is under review.

GAP-RET-05 · CODE — KNOWN GAP, REMEDIATION PENDING

This record previously stated that personal data in the audit log is anonymised by replacing the email hash with a placeholder value, and that the identifying details in the data-subject request register are anonymised after resolution. Neither routine exists: no anonymisation is performed on either table and neither can be purged through the application's database connection. This divergence is recorded on the compliance remediation register and is under review.

Early Deletion: Data Subjects may request deletion before retention period expires (GDPR Art 17). The erasure pipeline is automated once triggered, but the trigger is a manual staff action: a member of staff holding the settings permission group must process the request. The twenty-four hour figure is an operational target, not system behaviour — no timer, queue drain or service-level enforcement exists. Attendee self-service deletion is available only to contacts already flagged for an automatic bounce or rejection and not marked as a spam trap; every other Data Subject must go through the customer organisation.

GAP-RET-10 · CODE — KNOWN GAP, REMEDIATION PENDING

This record previously stated that [PLATFORM PROVIDER] executes deletion within twenty-four hours via an automated pipeline. The pipeline runs only when a member of staff processes the request, and attendee self-service deletion is restricted to contacts whose email address has already been flagged for bounce or rejection. This divergence is recorded on the compliance remediation register and is under review.

Push Data Deletion: The GDPR deletion pipeline (POST /v1/gdpr/requests/:id/process) covers device_tokens and push_sends rows matched by (org_id, email_hash). When consent is revoked server-side (including data_processing revocation), a silent push notification is sent to the mobile app to trigger a /me sync — the app then detects the revocation and stops registering new tokens. Existing tokens are deleted by the pipeline.

Tables the erasure pipeline reaches. The pipeline deletes email_sends, push_sends, device_tokens and funnel_entries by explicit query, then deletes the contact record, which cascades to behavioral_events, segment_members, consents, webinar_registrations and shares. It also removes the contact's plaintext details from Firestore and submits the address to the email provider's suppression list.

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 jobs and funnel page views are likewise not reached, and no object in Cloud Storage is deleted.

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.

GAP-RET-03 · CODE — KNOWN GAP, REMEDIATION PENDING

This record previously identified the tables the erasure pipeline touches as the device-token and push-delivery tables alone and did not disclose any exclusion from erasure. The SMS delivery log, the segment-broadcast recipient log, the AI generation job log, funnel page views and every object in Cloud Storage survive an Article 17 erasure, and the append-only consent history is retained with its contact reference set to null. This divergence is recorded on the compliance remediation register and is under review.

Backup Deletion: Backups retained 30 days (PostgreSQL) or 7 days (Firestore). ⚠️ Neither figure is evidenced in [PLATFORM PROVIDER]'s records; both must be confirmed against the hosting providers' actual configuration. Personal data in backups deleted as backups age out (cannot selectively delete from immutable backups).

Technical and Organizational Security Measures (Art 32)

See Annex II: Technical and Organizational Security Measures (separate document: annex-security-measures.md).

Summary:

• Encryption in transit (TLS 1.2+) and at rest (AES-256)
• Pseudonymization (email hashing with SHA-256 in analytics database) — qualified below
• Row Level Security (RLS) on PostgreSQL tables (org_id isolation) — qualified below
• Firestore security rules (org-scoped access control for organisation configuration, staff records, page records, private webinars, consent records and the registration PII subcollection) — qualified below
• Role-based access control across four staff roles mapped to three permission groups (see Staff roles above)
• A full security-header set on API responses, including a content security policy of default-src 'none'; frame-ancestors 'none'
• An audit log that is append-only at the database grant level: the application's database role holds only select and insert privileges on it
• A boot-time production guard that refuses to start the API unless the Row Level Security-enforced database connection is configured
• Breach notification within 24 hours (processor to controller)
• Confidentiality agreements for all personnel

Qualifications to the summary above.

No multi-factor authentication. The Services provide no multi-factor or two-factor authentication for dashboard users: staff sign in with an email address and password, or with Google OAuth, and authentication is single-factor. The four-digit one-time code described in Annex II is an alternative to the attendee magic link, not a second factor. Any multi-factor requirement applied to [PLATFORM PROVIDER]'s own accounts on third-party hosting and console providers is an internal administrative practice and is not a control of the Services.

No security audits or penetration testing. No third-party security audit or penetration test is evidenced in [PLATFORM PROVIDER]'s records.

Staff data-protection training. ⚠️ Neither a formal data-protection training programme nor training records are evidenced in [PLATFORM PROVIDER]'s records. See Annex II.

Vulnerability management. Dependency and vulnerability scanning is performed manually. There is no continuous integration pipeline in the repository, no automated dependency-update service and no automated security scanning of commits, dependencies or container images. Vulnerabilities are identified through manual review of dependency advisories and through the security notices published by the hosting providers and the framework maintainers, and are remediated by a developer raising and deploying the change directly.

Secure development lifecycle. Changes are authored and reviewed by the engineering team and verified locally using the repository's lint, vet, type-check and build targets before deployment. There is no automated pipeline that enforces those checks: no continuous integration configuration exists in the repository, so the checks are advisory and depend on the developer running them. Automated test coverage is limited to five unit-test files in the Go API covering email-tracking handlers, email utilities, tracked-link redirects and page-utility helpers; there are no automated tests covering authentication, authorisation, Row Level Security or tenant isolation, and no automated test simulates a cross-organisation query.

Monitoring and alerting. 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.

GAP-SEC-01 · CODE — KNOWN GAP, REMEDIATION PENDING

This record previously asserted multi-factor authentication for staff access, annual security audits and penetration testing, and a two-role access model, and relied on all three as Article 32 measures. No multi-factor mechanism exists, no third-party audit or penetration test is evidenced, and the role model is the four-role model described above. There is additionally no continuous integration pipeline, no automated dependency or security scanning, no automated test coverage of authentication, authorisation, Row Level Security or tenant isolation, and no error-tracking or alerting infrastructure. This divergence is recorded on the compliance remediation register and is under review.

Pseudonymisation. No PostgreSQL table holds a plaintext email address, telephone number or personal name. Contacts are keyed by an SHA-256 hash of the lowercased, trimmed email address, and plaintext contact details are held only in Firestore at orgs/{orgId}/contacts/{emailHash}/pii/private.

Two exceptions apply. First, the automations engine records the outcome of each executed step as a JSON document in PostgreSQL, and for email and SMS steps that document includes the recipient's plaintext email address or telephone number; those records are removed when the contact is deleted, by cascade, but they are not otherwise pseudonymised. Second, the ai_jobs table stores the full prompt text of each AI generation, which may contain an approved attendee testimonial together with the name and company recorded on it; those rows carry no contact link and are not removed on erasure.

The API holds an in-process cache of plaintext contact details (email address, name and telephone number), keyed by organisation and email hash, to avoid repeated Firestore reads. The cache has no expiry, and entries are invalidated only within the process that performs the write. Where more than one API instance is running, a correction or a deletion applied on one instance does not evict the copy held by another.

Tenant isolation in PostgreSQL. Tenant isolation in PostgreSQL is enforced by Row Level Security. Thirty-two of the thirty-three tables carry an org_id column and have Row Level Security enabled with a policy restricting both reads and inserts to rows whose org_id matches the organisation identifier set on the connection; the single exception is the platform-wide scheduler job-run log, which holds no personal data. The organisation identifier is set with SET LOCAL inside a transaction at the start of every request, and the application connects as a dedicated non-superuser role that Row Level Security applies to. The API refuses to start in production if that dedicated connection string is absent, so the request path cannot fall back to the privileged connection.

Its residual limits are as follows:

• Row Level Security is enabled but not forced. A table owner or superuser connection is not subject to the policies, so isolation depends on the application continuing to connect as the restricted role.
• Certain public request paths deliberately use the privileged connection because they must resolve an opaque token before any organisation is known: share-token lookup, funnel tracking-token lookup, funnel step and page-view lookup, and funnel webhook-secret lookup. Row Level Security provides no backstop on those queries.
• The organisation identifier is interpolated into the SET LOCAL statement as a string rather than bound as a parameter. In normal operation it originates from a verified token claim; under the service-authentication and development-stub paths it originates from a caller-supplied header.
• Helper functions for an administrative bypass context exist in the database layer but are unused, and no policy in any migration references the session variable they set, so they confer nothing.

Isolation in the Realtime Database. Access to live-session data in the Realtime Database is authorised by the role claim in the caller's authentication token alone. The security rules contain no organisation identifier and make no comparison between the caller's organisation and the organisation that owns the session, so an authenticated dashboard user holding any of the admin, moderator, marketer or staff roles — in any organisation on the platform — can read any live session's data given only its session identifier. This includes the chat stream, the moderated-message stream, presence, attendance, presence timelines, per-actor message counts, offer clicks, feedback responses and the identity cache that maps an attendee's anonymous actor identifier to the hash of their email address. Separately, the chat stream, the actor directory (which holds attendee display names), the banned and muted actor lists, the feedback definition and the tracked-link table are readable by any authenticated user, which includes every anonymous attendee of every session. All organisations share a single Firebase project per environment, so a single rule set governs the whole platform.

GAP-ISO-01 · CONFIG — KNOWN GAP, REMEDIATION PENDING

This record previously described tenant isolation as applying uniformly across the platform's databases. Organisation-level isolation is enforced in PostgreSQL as described above, but the Realtime Database security rules contain no organisation identifier and authorise staff-privileged reads solely on the role claim in the caller's token, and several live-session nodes are readable by any authenticated user including anonymous attendees. This divergence is recorded on the compliance remediation register and is under review.

Limits of the Firestore rules. The Firestore security rules restrict organisation configuration, staff user records, page records, private webinars, contact-level consent records and the registration PII subcollection to authenticated members of the owning organisation, and they deny all client access to the top-level collections that hold verification codes and magic links. They do not restrict two categories of personal data:

• Contact PII. The document at orgs/{orgId}/contacts/{emailHash}/pii/private, which holds the contact's plaintext email address, name and telephone number, may be fetched by any authenticated Firebase user — including any anonymous web attendee and any email-verified mobile user, from any organisation — provided they know the organisation identifier and the email hash. The email hash is an unsalted SHA-256 of the lowercased, trimmed email address, so the document path can be computed directly by anyone who knows the target's address. Listing the collection still requires staff of the owning organisation.
• Registration documents. Documents at orgs/{orgId}/webinars/{webinarId}/sessions/{sessionId}/registrations/{registrationId} are readable without authentication, exposing the registration status, the email hash, the registration timestamp and the registration metadata. The rule grants read, which covers both individual fetches and collection listings, notwithstanding an inline comment in the rules file stating that listing requires staff. Registration documents may also be created without authentication, which is how the public registration form works.

Session documents, non-private webinar documents, polls, offers and testimonials are likewise publicly readable, and testimonials and abuse reports are publicly creatable, by design.

GAP-ISO-02 · CONFIG — KNOWN GAP, REMEDIATION PENDING

This record previously described the Firestore security rules as providing organisation-scoped access control over the personal data held in Firestore. The rules leave the contact PII document readable by any authenticated Firebase user who knows the organisation identifier and the email hash — which is computed from the email address without a salt — and leave registration documents readable without authentication. This divergence is recorded on the compliance remediation register and is under review.

---

Processing Activity 2: Marketing Analytics and Lead Qualification

Name and Description of Processing

Behavioral analytics and segmentation: Analyzing event attendee engagement (chat activity, poll participation, offer interest) to qualify leads for customer's sales teams.

Data Controller(s)

Same as Processing Activity 1 (customer organizations)

Categories of Data Subjects

Event attendees who consented to "behavioral tracking" during registration

Categories of Personal Data

• Email (hashed with SHA-256 in analytics database)
• Name — resolved from Firestore at export or send time; not stored in the analytics database
• Behavioral events:
  • Chat messages (full content, timestamp, event_id)
  • Poll votes (poll_id, option_id, timestamp)
  • Offer clicks (offer_id, timestamp, clicked boolean)
  • Attendance duration, session count
• Segment memberships (derived data: "high engagement", "interested in Product X", etc.)
• Lead scores (materialized engagement scores per event + aggregate):
  • Score (integer, weighted sum of behavioral events)
  • Breakdown (per-event-type point totals: chat_message, chat_reply, poll_vote, offer_clicked, reaction, feedback_submitted, event_joined, attendance_duration_bonus)
  • Computed timestamp
• Scoring configuration (per-org weights for each event type — org-level, no PII)

Purposes of Processing

• Lead scoring (engagement level calculation)
• Segmentation (rule-based: "attended 3+ events", "voted in poll about pricing")
• Marketing campaign targeting (export segment members to customer's CRM/email platform)
• Bulk export of segment members as a CSV file containing each member's plaintext email address and name, downloaded to the exporting staff member's device. The export does not require email_marketing consent, and an option widens it to contacts suppressed for bounce, spam complaint or global opt-out. Contacts subject to an Art 18 processing restriction are always excluded.
• Composing and sending a one-off email to the members of a segment — see Processing Activity 9

Legal Basis (determined by Controller)

Consent (Art 6(1)(a)) — Data Subject explicitly checks "I consent to behavioral tracking for lead qualification" during registration.

That consent governs the recording of behavioural events and the scores derived from them. It does not gate the two export and broadcast operations listed above: segment export and segment broadcast filter only on the contact not being subject to an Art 18 processing restriction and, by default, not being suppressed for bounce, complaint or global opt-out. Membership of a segment may itself be derived from behavioural events recorded under this consent. See Processing Activity 9.

Recipients

• Customer organization (Data Controller) — receives analytics reports, segment lists, behavioral event exports
• Sub-processors: Same as Processing Activity 1 (Google Cloud for storage, Railway for PostgreSQL analytics queries)

International Transfers

Same as Processing Activity 1

Retention Period

No automated deletion in practice. Behavioural events are one of the five data types the API accepts as configurable, but no default policy is seeded and no policy can currently be saved through the product, so behavioural events are retained for the duration of the business relationship. Where a policy does exist, the configurable bounds are 30 to 3,650 days and the enforcement job deletes nothing for a policy whose backlog exceeds ten thousand rows in a single run. See Retention configuration under Processing Activity 1.

Consent Withdrawal: If Data Subject revokes behavioral tracking consent post-event, future behavioral events are no longer recorded to the analytics database (consent gate in Cloud Functions prevents writes). Existing behavioral events remain subject to the configured retention policy and can be deleted via a separate erasure request (see Privacy Policy Section 8.2). Lead scores are not recomputed for contacts with processing_restricted = true — existing scores remain until the contact is deleted or the retention policy purges them.

Security Measures

Same as Processing Activity 1 + additional consent gate:

• Consent Gate in Cloud Functions: Before writing behavioral event to PostgreSQL, Cloud Function checks Firestore consents/{id} subcollection. If behavioral_tracking = false, event is NOT written.

The scope of that gate is narrow. 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.

---

Processing Activity 3: Server-Side Ad Conversion Tracking

Name and Description of Processing

Advertising attribution: Sending registration and landing-page-view events to advertising platforms for campaign performance measurement, and serving the client-side advertising pixels that accompany them. Two distinct operations are covered:

1. Server-side conversion events on registration — CompleteRegistration sent to Meta Platforms, Inc. and to TikTok Pte. Ltd. for every registration where the Customer has enabled the corresponding integration.
2. Server-side PageView on every landing-page visit — sent to Meta Platforms, Inc. for every human visitor to a funnel landing page where the Customer has enabled the Meta integration, whether or not that visitor ever registers.

Data Controller(s)

Customer organizations who have enabled ad platform integrations in dashboard (Settings → Integrations)

Categories of Data Subjects

1. Every visitor to a published funnel or landing page of a customer organisation that has enabled the Meta integration, whether or not they register and irrespective of any cookie-banner decision (operation 2).
2. Every registrant for an event hosted by a customer organisation that has enabled the Meta or TikTok integration, irrespective of any cookie-banner decision (operation 1).

No advertising-consent gate applies to either operation. The only enforced suppression is a GDPR Art 18 processing restriction, which applies to operation 1.

Categories of Personal Data Processed

Operation 1 — server-side conversion events on registration:

• Hashed email (SHA-256, lowercase, trimmed before hashing) — never sent in plaintext
• No telephone number. The field is left empty when the event is assembled, whatever number is held on the contact, so none is transmitted to either platform
• Hashed first name and hashed last name (SHA-256, lowercase, trimmed) — never sent in plaintext
• External identifier (registration ID) — hashed for TikTok, transmitted to Meta unhashed
• Raw client IP address and raw User-Agent — transmitted unhashed to both platforms
• Click ID (fbclid, ttclid) and the raw _fbp, _fbc and _ttp cookie values where present — from URL parameters and cookies on the landing page
• Event metadata: registration timestamp, event identifier (deduplication against the browser pixel), landing page URL and referrer URL

Operation 2 — server-side PageView on every landing-page visit:

• Raw client IP address and raw User-Agent
• 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
• Event identifier for deduplication against the browser pixel

NOT Processed:

• Plaintext email or name (hashed before transmission); no telephone number is sent at all. The registration identifier is not in this category: Meta receives it unhashed
• Chat messages, poll votes, offer clicks (not sent to ad platforms)

Server-side PageView is deliberately not mirrored to TikTok, because PageView is not on TikTok's standard events list.

Purposes of Processing

• Ad campaign attribution: Match registrations and landing-page visits to ad clicks to measure return on advertising spend
• Audience optimization: Ad platforms use the transmitted data to improve targeting (lookalike audiences, retargeting)

No exclusion-list processing is performed. No hashed email address is uploaded to Meta Custom Audiences or to any other audience-management interface, no negative or suppression audience is maintained at any advertising platform, and completing a GDPR erasure makes no call to Meta or to TikTok. The only integrations that exist are the two fire-and-forget conversion senders described above.

GAP-CONSENT-08 · CODE — KNOWN GAP, REMEDIATION PENDING

This record previously stated that hashed email addresses are uploaded to Meta Custom Audiences as negative audiences so that registered, opted-out and erased contacts are excluded from advertising targeting, and presented that exclusion as a safeguard operating in the data subject's interest. No audience-management call of any kind is made to any advertising platform, and erasure triggers no communication with Meta or TikTok, so no such exclusion occurs. This divergence is recorded on the compliance remediation register and is under review.

Legal Basis (determined by Controller)

Legitimate interest (Art 6(1)(f)) for both operations. Server-side conversion events and server-side PageViews are sent irrespective of any cookie-banner decision. See DPIA Section 3.3 for the balancing test; ⚠️ that test was drawn for an advertising click-through who goes on to register and does not address operation 2, which reaches every landing-page visitor including those who never register.

GDPR Art 18 processing restrictions are the operative suppression for operation 1: no conversion event is sent for a restricted contact. Operation 2 has no suppression at all, because the visitor is not yet identified as a contact.

An advertising_consent value is still collected on the registration record and stored, but no code path reads it as a condition of any transmission. It is an audit-only snapshot of the banner state at registration and has no effect on processing.

Transparency: ⚠️ The Privacy Policy states that hashed, not plaintext, email addresses and names are sent to advertising platforms. It does not disclose that the raw IP address and raw User-Agent are also transmitted, that the transmission is not gated on advertising consent, or that a PageView is sent for every landing-page visitor. The Privacy Policy must be corrected before this record is relied on.

Recipients

• Meta Platforms, Inc. (USA) — Meta Conversions API: CompleteRegistration on registration and PageView on every landing-page visit. Active.
• TikTok Pte. Ltd. (USA/Singapore) — TikTok Events API: CompleteRegistration on registration. Active since 8 May 2026.
• Google LLC (USA) — Google Ads Enhanced Conversions: not implemented; receives no data.
• LinkedIn Corporation (USA) — LinkedIn Conversions API: not implemented; receives no data.

GAP-CONTRACT-02 · CONTRACT — KNOWN GAP, REMEDIATION PENDING

This record previously described the TikTok Events API as a future integration. The server-side integration has been live since 8 May 2026 and transmits hashed contact identifiers together with the attendee's unhashed IP address and User-Agent to TikTok on every registration, without a DPA or Standard Contractual Clauses on file and without an advertising-consent gate. This divergence is recorded on the compliance remediation register and is under review.

International Transfers

All transfers to USA (Meta) and USA / Singapore (TikTok):

• Safeguards: Meta — Standard Contractual Clauses (2021) and hashing of directly identifying fields. TikTok — ⚠️ no Standard Contractual Clauses and no DPA on file, hashing of directly identifying fields only.
• ⚠️ Raw IP addresses and raw User-Agents are transmitted unhashed to both platforms, so the description of these transfers as hashed-only data minimisation no longer holds.
• Transfer Impact Assessment: must be repeated to cover TikTok Pte. Ltd. and the transmission of unhashed IP addresses and User-Agents.

Retention Period

By [PLATFORM PROVIDER]: Conversion events and PageViews are fire-and-forget transmissions; no local event table records them. The underlying registration and funnel data is retained as set out under Processing Activities 1 and 5. By Ad Platforms: 7-28 days (per platform policies, e.g., Meta retains hashed data 7 days for matching, then deletes)

Security Measures

• Hashing before transmission: SHA-256 with lowercase + trim preprocessing (industry-standard for Conversions APIs) applied to email address, first name and last name, and — for TikTok only — to the external identifier. No telephone number is transmitted on this path: the field is left empty when the event is assembled, whatever number is held on the contact. The IP address and User-Agent are not hashed, and Meta receives the external identifier unhashed.
• HTTPS API calls: All conversion events sent over TLS 1.2+ (encrypted in transit)
• Event deduplication: event_id prevents double-counting between the browser pixel and the server-side event
• Suppression: contacts subject to a GDPR Art 18 processing restriction are excluded from operation 1.

Client-side advertising pixels. Meta and TikTok pixels are classified as necessary and fire a page view before any consent decision, in a consent-withheld, cookie-less state (fbq('consent','revoke') / ttq.holdConsent()); IP address, user agent and page URL still reach Meta and TikTok pre-consent. Lawfulness under Art 5(3) ePrivacy is not established — see KNOWN GAP.

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.

Google Tag Manager, Google Analytics and Microsoft Clarity are not affected by the classification above. Google Analytics is not implemented by [PLATFORM PROVIDER]: no Analytics tag is emitted, and Analytics reaches a visitor only through a Google Tag Manager container the customer organisation configures or a script it pastes into its tracking-script settings. The Google Consent Mode v2 deny-by-default signals for analytics_storage, ad_storage, ad_user_data and ad_personalization are emitted only alongside such a container and govern only the tags inside it; they have never governed the directly injected Meta Pixel, TikTok Pixel or Microsoft Clarity tag. Microsoft Clarity is categorised as an analytics script that loads only after analytics consent and is skipped entirely in the attendee application.

Server-side Meta PageView. 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.

GAP-CONSENT-05 · CODE — KNOWN GAP, REMEDIATION PENDING

This record previously scoped this activity to attendees who had accepted advertising cookies and had registered for an event, and stated that conversion events are sent once at registration. A server-side PageView carrying the visitor's raw IP address and raw User-Agent is sent to Meta for every human visitor to a funnel landing page, whether or not they register and irrespective of any cookie-banner decision, and the balancing test relied on for this activity does not cover non-registrants. This divergence is recorded on the compliance remediation register; the classification is under review.

---

Processing Activity 4: GDPR Data Subject Rights Management

Name and Description of Processing

Data Subject rights requests: Processing access, deletion, portability, objection and restriction requests on behalf of customer organizations. Rectification is performed as an operational action — a member of staff edits the contact record, or the Data Subject uses the public change-of-address flow — but it cannot be recorded in the request register, because the register rejects rectification as a request type. A rectification is therefore evidenced only through the audit log.

Data Controller(s)

Customer organizations ([PLATFORM PROVIDER] assists as Processor)

Categories of Data Subjects

Event attendees who submit GDPR requests

Categories of Personal Data Processed

• The categories included in the Article 15 and Article 20 export: contact record, registrations, behavioural events, consents, consent events, segment memberships, email delivery records, push delivery records, device tokens, lead scores, the Firestore contact PII, Firestore consents and Firestore registrations, and the contact's live-session records.
• ⚠️ The export does not cover every category recorded in this document. Funnel entries — where all campaign parameters, click identifiers, landing and referrer URLs, country, city and device data live — are omitted, as are the SMS delivery log, the segment-broadcast recipient log, the AI generation job log, funnel page views, automation enrolments and step executions, and every object in Cloud Storage.
• GDPR request metadata:
  • Request type — the register accepts access, deletion, portability, objection and restriction. rectification is rejected and cannot be logged.
  • Request date, resolution date
  • Data Subject identity verification details (email confirmation)

GAP-RET-04 · CODE — KNOWN GAP, REMEDIATION PENDING

This record previously stated that an access request produces a full export of all categories from Processing Activities 1 to 3, and listed rectification among the request types the register holds. The export omits funnel entries and therefore all attribution, geographic and device data, as well as SMS delivery records, segment-broadcast records, automation records and AI generation records; and a rectification request is rejected by the register and can only be evidenced through the audit log. This divergence is recorded on the compliance remediation register and is under review.

Purposes of Processing

• Legal obligation (Art 6(1)(c)): Fulfill Data Controller's obligations under GDPR Articles 15-22

Recipients

• Customer organization (Data Controller) — the JSON export is returned to the member of staff who processed the request
• Data Subject — onward delivery of the export or of a confirmation to the Data Subject is performed by the customer organisation; the platform sends no export or confirmation to the Data Subject itself

Retention Period

GDPR request records: No automated deletion. The request register is not among the data types the retention job recognises and nothing else in the platform deletes from it, so records are retained indefinitely as Article 5(2) accountability evidence. Exported data: The export is returned inline in the response to the processing request; no file is stored on [PLATFORM PROVIDER] systems and no download link is issued. Any copy retained thereafter is held by the member of staff or the Data Subject who received it.

Security Measures

• Identity verification: Email confirmation link (sent to registered email address)
• Transport: the export is returned as JSON over TLS in the response to the processing request. There is no expiring download link and no separately stored export file.
• Audit logging: All GDPR request actions logged (who processed, when, what data exported/deleted). Audit entries created by this workflow record the subject's email hash in their metadata, which therefore survives an erasure.
• Access control: Processing a GDPR request requires the settings permission group, which only the admin role holds. Creating a request is open to any authenticated staff user, including the read-only staff role.

GAP-RET-05 · CODE — KNOWN GAP, REMEDIATION PENDING

This record previously stated that exported data is held for fourteen days and made available through a secure download link that expires, that the request register is purged three years after resolution with the Data Subject's details anonymised, and that only administrators can act on requests. No download-link mechanism exists — the export is returned inline; the register is never purged and no anonymisation routine exists; and any authenticated staff user, including a read-only one, can create a request. This divergence is recorded on the compliance remediation register and is under review.

---

Processing Activity 5: Funnel Operation, Campaign Attribution and Landing-Page Measurement

Name and Description of Processing

Acquisition funnels: operating multi-step acquisition funnels — public landing and registration pages, tracked share and redirect links, unique-visitor measurement on funnel pages, and inbound order and form webhooks — and attributing contacts and conversions to marketing campaigns.

Data Controller(s)

Customer organisations, as for Processing Activity 1.

Categories of Data Subjects

• Visitors to a Customer's funnel landing pages, whether or not they register
• Event attendees and registrants
• Customers of the Customer's e-commerce store, where an order webhook is configured

Categories of Personal Data

• Pseudonymous visitor identifier: an SHA-256 hash of the visitor's IP address and user agent, recorded once per visitor per funnel step per day. The hash is stable over time — the same visitor produces the same value on every visit — and is therefore a persistent pseudonymous identifier.
• Attribution data on the funnel entry, linked to the contact: utm_source, utm_medium, utm_campaign, utm_content, utm_term, advertising click identifier and click platform, landing page URL, referrer URL and free-form attribution metadata.
• Device and approximate location, linked to the contact: country code, city, device type, operating system, browser and browser time zone. The IP address itself is used only to derive the country and city and is not stored on the funnel entry.
• Referral chain: referral source and the identifier of the share link that introduced the contact.
• Webhook payloads: for generic and form-provider webhooks the entire raw request body is stored as entry metadata, which may contain arbitrary form answers. For e-commerce order webhooks the customer's email address is used to match an existing contact and the order identifier, total amount, currency and payment status are stored as entry metadata — a purchase and transaction data category, sourced from the Customer's store rather than collected from the data subject.

Purposes of Processing

• Measuring unique visitors and conversion rates for each step of a funnel
• Attributing registrations and purchases to marketing campaigns and to individual share links
• Triggering downstream automations on form submission

Legal Basis (determined by Controller)

Determined by the Customer as controller. As implemented, unique-visitor measurement and tracked-link click recording operate without a consent gate and are relied on as a legitimate interest (Art 6(1)(f)); the source migration describes the page-view pixel as consent-free. Form submission relies on consent recorded as data_processing and tos_acceptance, collected together behind a single checkbox.

Recipients

• Customer organisation (controller)
• Sub-processors: Railway (PostgreSQL), Google LLC (Firestore, Cloud Storage), Cloudflare
• Meta Platforms, Inc., which receives a server-side PageView with the visitor's raw IP address and user agent for every landing-page visit where the Meta integration is enabled
• The destination of any tracked link. Where a visitor follows a tracked redirect, the platform forwards the campaign parameters and the advertising click identifiers — utm_source, utm_medium, utm_campaign, utm_content, utm_term, fbclid, gclid, ttclid, li_fat_id, referral source — onto the destination URL, which is frequently a third-party site
• Inbound sources: the Customer's e-commerce or form platform (MerchantPro, WooCommerce, Tally or a generic sender), which transmits personal data into the platform

International Transfers

As for Processing Activity 1, plus transfers to Meta Platforms, Inc. (USA) on the server-side PageView path, and any transfer implied by the Customer's chosen tracked-link destination.

Retention Period

No automated deletion. Neither funnel entries nor funnel page views are among the data types the retention job recognises, and neither can be configured on the retention settings screen. Funnel entries are deleted when the data subject's contact record is erased and when the parent funnel is deleted; funnel page views are removed only when the parent funnel or step is deleted, and are not reached by erasure because they carry no link to a contact.

GAP-TRACK-01 · CODE — KNOWN GAP, REMEDIATION PENDING

The funnels subsystem was absent from this Record of Processing Activities and from the Data Retention Policy. Funnel entries carry campaign, device and approximate-location data linked to an identified contact, and funnel page views carry a persistent pseudonymous visitor identifier derived from the visitor's IP address and user agent, collected without a consent gate; neither is subject to any automated retention period, and funnel entries are omitted from the Article 15 and Article 20 data export. This divergence is recorded on the compliance remediation register and is under review.

Security Measures

As for Processing Activity 1. Note that the public token-resolution queries used by tracked links, funnel page views and funnel webhooks run on the privileged database connection, which is not subject to Row Level Security, because an opaque token must be resolved before the organisation is known.

---

Processing Activity 6: Automated Contact Journeys (Automations)

Name and Description of Processing

Automations: enrolling contacts in configurable journeys that are triggered by a form submission, a webinar registration, entry into a segment, the opening of a session or a manual action, and then executing an ordered sequence of wait and action steps against that contact.

Data Controller(s)

Customer organisations, as for Processing Activity 1.

Categories of Data Subjects

Contacts enrolled in an automation — in practice registrants, waitlist entrants and segment members.

Categories of Personal Data

• Enrolment record: contact identifier, current step, status, enrolment and completion timestamps, and a JSON copy of the triggering event
• Step execution record: status, execution timestamp and a JSON result document
• The step execution result document contains the recipient's plaintext email address for email steps and their plaintext telephone number for SMS steps, and therefore holds directly identifying data in PostgreSQL

Purposes of Processing

• Sending follow-up email and SMS on a schedule relative to a trigger
• Adding contacts to, and removing them from, segments
• Registering contacts for a session on their behalf

Legal Basis (determined by Controller)

Determined by the Customer as controller. As implemented, email steps are gated only on the contact not being suppressed for bounce, complaint or global opt-out and not being subject to an Art 18 processing restriction — no marketing consent is checked — and are therefore relied on as necessary for the performance of the service or as a legitimate interest. SMS steps additionally require a granted, unrevoked sms_notifications consent.

Recipients

• Customer organisation (controller)
• NewsmanApp SRL (email delivery)
• SendSMS.ro (SMS delivery)
• Sub-processors: Railway (PostgreSQL), Google LLC

International Transfers

As for Processing Activity 1. Email and SMS delivery are performed within the EU.

Retention Period

No automated deletion. None of the four automation tables is among the data types the retention job recognises. Enrolments are linked to the contact record and are removed by cascade when the contact is erased, and step execution records are removed by cascade from the enrolment — which is the only mechanism that removes the plaintext email addresses and telephone numbers held in the step result documents. Automation definitions and step definitions persist for the lifetime of the organisation.

GAP-SEC-03 · CODE — KNOWN GAP, REMEDIATION PENDING

The automations subsystem was absent from this Record of Processing Activities, from the Data Retention Policy and from the erasure documentation. Automation step execution records hold the recipient's plaintext email address and telephone number in PostgreSQL, which departs from the architectural boundary described elsewhere in this document, under which PostgreSQL holds only pseudonymised identifiers. This divergence is recorded on the compliance remediation register and is under review.

Security Measures

As for Processing Activity 1, with Row Level Security applied to all four automation tables.

---

Processing Activity 7: AI-Assisted Content Generation

Name and Description of Processing

AI generation: generating and refining landing-page briefs, landing-page HTML and marketing copy, and generating webinar poll questions, by transmitting a staff-composed prompt to a third-party large-language-model provider and storing the prompt and the model's output.

Data Controller(s)

Customer organisations, as for Processing Activity 1. Note that the model provider is engaged by [PLATFORM PROVIDER] under a single platform-level credential, not by the Customer.

Categories of Data Subjects

• Event attendees who have submitted a testimonial that has been approved by staff
• Individuals depicted in staff-uploaded reference images, where any
• Members of the Customer's staff who initiate a generation

Categories of Personal Data

• Approved attendee testimonials — the attendee's display name, their free-text quote, their company and their rating — embedded in the generation prompt
• Staff-uploaded reference images from the organisation media library, transmitted inline; these are Customer marketing assets and may depict identifiable individuals
• Text extracted from third-party reference pages supplied by a member of staff
• Organisation name, webinar title, description and type, page brief and staff-authored custom instructions
• The identifier of the member of staff who started and who accepted the generation
• The full system prompt, user prompt and model output, retained in PostgreSQL

Purposes of Processing

• Producing marketing copy and landing-page markup for the Customer's campaigns
• Producing poll questions for a webinar
• Cost tracking, versioning and reproducibility of generations

Legal Basis (determined by Controller)

Determined by the Customer as controller. As implemented, generation is a staff-initiated action relied on as a legitimate interest in producing marketing content (Art 6(1)(f)). No consent is sought from the testimonial author for transmission to the model provider, and no consent gate exists on this path.

Recipients

• Anthropic PBC (USA) — the model provider, engaged by [PLATFORM PROVIDER] as a sub-processor
• The operators of any third-party reference page a member of staff supplies, which receives a request from the platform's scraper
• Sub-processors: Railway (PostgreSQL), Google LLC

International Transfers

USA — prompts and images are transmitted to Anthropic PBC at api.anthropic.com. The transfer mechanism must be confirmed; see Annex III, sub-processor 11.

Retention Period

No automated deletion. The generation-job table is not among the data types the retention job recognises, and its rows are not linked to a contact record, so they are not removed by the erasure pipeline or by cascade. A testimonial quote and the name of its author therefore persist in the stored prompt and output after the contact has been erased.

GAP-CONTRACT-03 · CONTRACT — KNOWN GAP, REMEDIATION PENDING

AI-assisted content generation was absent from this Record of Processing Activities, and the model provider was absent from the sub-processor annex. Approved attendee testimonials — the author's name and free-text quote — are transmitted to a United States model provider without a specific consent or notice, and the stored prompt and output are not reached by the erasure pipeline, so that content survives an Article 17 erasure. This divergence is recorded on the compliance remediation register and is under review.

Security Measures

As for Processing Activity 1. Requests are made server-side over TLS; no attendee device contacts the model provider and no cookies are involved.

---

Processing Activity 8: SMS Notifications

Name and Description of Processing

Transactional messaging: sending webinar reminder, "starting now" and "replay available" messages, and automation SMS steps, to attendees who have provided a telephone number and opted in, and recording delivery and click outcomes.

Data Controller(s)

Customer organisations, as for Processing Activity 1.

Categories of Data Subjects

Registrants and attendees who have provided a telephone number and hold an sms_notifications consent.

Categories of Personal Data

• Telephone number, in plaintext, read from the Firestore contact PII document at send time and transmitted to the messaging provider. It is never stored in PostgreSQL.
• Message body, containing the webinar title, the time remaining until start or the replay deadline, and a per-recipient tracked join URL
• Delivery record: email hash, webinar and session identifiers, template type, tracking code, provider message identifier, delivery status, error text, and delivery and click timestamps

Purposes of Processing

• Notifying registrants that a webinar is about to start, is live, or that a replay is available
• Executing SMS steps within an automation
• Measuring delivery success and click-through

Legal Basis (determined by Controller)

Consent (Art 6(1)(a)) — an SMS is sent only where the contact holds a granted, unrevoked sms_notifications consent and is not subject to an Art 18 processing restriction. On the public funnel form, however, this consent is granted implicitly by the presence of a telephone number in the submission; there is no separate SMS checkbox.

Recipients

• SendSMS.ro (Romania) — the messaging provider
• The recipient's mobile network operator
• Sub-processors: Railway (PostgreSQL), Google LLC (Firestore, Secret Manager)

International Transfers

Message submission is to an endpoint in Romania (EU). No transfer outside the EEA arises on this path.

Retention Period

No automated deletion in practice. The retention enforcement job is capable of purging the SMS delivery log by age, but the API's list of configurable data types does not include it, so no organisation can configure that policy through the product. The delivery log is additionally not deleted by the erasure pipeline — it is keyed by email hash with no foreign key to the contact record — and is not included in the Article 15 data export.

GAP-RET-03 · CODE — KNOWN GAP, REMEDIATION PENDING

SMS notifications were absent from this Record of Processing Activities and from the Data Retention Policy, and the messaging provider was absent from the sub-processor annex. The SMS delivery log is not removed by the erasure pipeline and is not included in the Article 15 data export, so a per-person record of messages sent persists after an Article 17 erasure. This divergence is recorded on the compliance remediation register and is under review.

Security Measures

As for Processing Activity 1, plus: per-organisation credentials held in Google Secret Manager, and a consent and processing-restriction check before every send. Note that the provider's API is called over TLS with the recipient's telephone number, the message body and the account password carried as URL query-string parameters, which should be assumed to be recorded in the provider's request logs; and that the platform's own application logs record the recipient's telephone number on a send failure.

---

Processing Activity 9: Segment Broadcasts

Name and Description of Processing

Segment broadcasts: composing a one-off email — subject, title, body and call to action — and sending it to the members of a saved segment, recording each recipient so that a repeat send under the same campaign key reaches only members who have not already received it.

Data Controller(s)

Customer organisations, as for Processing Activity 1.

Categories of Data Subjects

Contacts who are members of the selected segment at the time of sending.

Categories of Personal Data

• Recipient identification: email hash, segment identifier, campaign key and send timestamp
• Message content: subject, title, body, call-to-action label and URL, and the identifier of the member of staff who composed it
• The recipient's plaintext email address and name are resolved from Firestore at send time and passed to the email provider; they are not stored in either broadcast table
• Where the segment is exported rather than broadcast, the export file contains the plaintext email address and name of every member

Purposes of Processing

• Sending a one-off communication to a defined audience
• Preventing duplicate delivery on a repeat send
• Reloading and reusing a previous broadcast's content

Legal Basis (determined by Controller)

Determined by the Customer as controller. As implemented, no marketing consent is checked: the recipient query filters only on the contact not being subject to an Art 18 processing restriction and not being suppressed for bounce, complaint or global opt-out. The feature is documented internally as a transactional lane and the responsibility for its use as a marketing channel rests with the sender. A segment condition is additionally provided that selects precisely those contacts who hold no active grant for a given purpose, which makes it possible to build and address an audience of contacts who have declined marketing consent.

GAP-CONSENT-07 · CODE — KNOWN GAP, REMEDIATION PENDING

This Record of Processing Activities previously described marketing consent as the gate on every marketing communication. The segment broadcast lane sends to segment members without checking any marketing consent purpose, and a segment condition is provided that selects contacts holding no active grant for a purpose, so the product supports addressing contacts who have declined marketing consent. The only enforced limits are the Article 18 processing restriction and the bounce, complaint and global opt-out suppression flags. This divergence is recorded on the compliance remediation register and is under review.

Recipients

• NewsmanApp SRL (email delivery)
• Customer organisation (controller), including as the recipient of segment CSV exports
• Sub-processors: Railway (PostgreSQL), Google LLC (Firestore)

International Transfers

As for Processing Activity 1. Email delivery is performed within the EU.

Retention Period

No automated deletion. Neither the broadcast content table nor the recipient log is among the data types the retention job recognises. The recipient log is keyed by email hash with no foreign key to the contact record, so it is not removed by the erasure pipeline or by cascade, and it is not included in the Article 15 data export.

Security Measures

As for Processing Activity 1. Segment exports and broadcasts are recorded in the audit log.

---

Sub-Processors

See Annex III: List of Sub-Processors (separate document: annex-sub-processors.md).

[PLATFORM PROVIDER] engages eleven sub-processors, listed in Annex III.

Summary:

1. Google LLC (Firebase, Google Cloud) — Database, authentication, cloud functions, storage, Secret Manager (stores per-org FCM and messaging credentials). Note: FCM push delivery uses customer-provided Firebase projects — see "Customer-Provided Integrations" section in Annex III.
2. Railway Corp. — PostgreSQL hosting (contacts, behavioral events, consents, device_tokens, push_sends, sms_sends, funnel entries and page views, automation records, AI generation jobs, segment broadcasts), API hosting, app hosting
3. NewsmanApp SRL — Transactional and marketing email delivery, bulk subscriber synchronisation, and the return of view, click, bounce, complaint and unsubscribe events
4. Meta Platforms, Inc. — Ad conversion tracking on registration and a server-side PageView on every landing-page visit (opt-in per organisation; no attendee consent gate)
5. Google LLC (Google Ads) — Ad conversion tracking: not implemented; receives no data
6. TikTok Pte. Ltd. — Ad conversion tracking: active since 8 May 2026 (opt-in per organisation; no attendee consent gate)
7. LinkedIn Corporation (Microsoft) — not implemented; receives no data
8. Cloudflare, Inc. — Mandatory in-path reverse proxy for attendee domains, plus Turnstile bot protection on published landing pages
9. Microsoft Corporation, contracted for EU customers via Microsoft Ireland Operations Limited (MIOL) — Microsoft Clarity session recordings and heatmaps, where the customer enables it
10. SendSMS.ro — Transactional SMS submission and delivery-status callbacks.
11. Anthropic PBC — AI generation of landing-page briefs, landing-page HTML, marketing copy and poll questions, engaged by [PLATFORM PROVIDER] under a single platform-wide credential

Change Management: Customers notified 30 days in advance of new sub-processors, with right to object. ⚠️ That notice was not given for the sub-processors first disclosed in this revision, several of which were already in production.

---

Data Breaches

Documentation Obligation (Art 33(5)): [PLATFORM PROVIDER] is required to maintain a register of all personal data breaches, recording:

• Facts of the breach (date, time, nature, affected systems)
• Effects and consequences (data subjects affected, data categories compromised)
• Remedial action taken (containment, notification, fixes)

Breach Register Location: ⚠️ No breach register is currently maintained. The register must be established as a maintained internal record, available to the supervisory authority on request, and backfilled with the matters identified below; the column structure it must take is set out in Section 8 of the Data Breach Response Plan. Entries are to be retained for three years, matching the commitment in Section 9.4 of the Data Processing Agreement.

GAP-PROC-01 · PROCESS — KNOWN GAP, REMEDIATION PENDING

This record previously stated that a register of all personal data breaches was maintained at a named internal location. No such register exists in any location and no incident has been assessed or recorded in one, so compliance with Article 33(5) cannot presently be evidenced. This divergence is recorded on the compliance remediation register and is under review.

Notification to Controllers: Within 24 hours of becoming aware (per DPA Section 9)

Breach Register Status: As of [DATE], [PLATFORM PROVIDER] has not notified any personal data breach to a supervisory authority or to a controller. Two matters have been identified that require assessment and an entry in the Article 33(5) register; neither has yet been assessed, and no determination has been made as to whether either is notifiable.

1. Live-session statistics node readable without authentication. Until 11 June 2026 the Realtime Database node holding per-session statistics was world-readable, while per-actor ledgers were written beneath it — per-actor message counts and per-actor synchronisation markers. Because the actor directory, which maps an actor identifier to an attendee's display name, is readable by any authenticated user, an attendee could join real names to per-person message counts and offer-click flags. The read rule was replaced with a role-gated expression on 11 June 2026, and the per-actor ledgers were moved out of the statistics node on 31 July 2026.
2. Re-subscription of previously unsubscribed contacts. Between 16 May 2026 and 3 July 2026 the synchronisation job with the email provider re-subscribed contacts who had previously unsubscribed. The behaviour was changed on 3 July 2026 so that unsubscribes recorded at the provider are honoured.

GAP-PROC-01 · PROCESS — KNOWN GAP, REMEDIATION PENDING

This record previously stated without qualification that [PLATFORM PROVIDER] had not experienced any notifiable personal data breach. Two matters are described above that have not been assessed and are not recorded in the Article 33(5) register, so the unqualified statement could not be supported. A reasoned decision that no notification is required is itself the evidence Article 33(5) calls for, and no such decision has been recorded. This divergence is recorded on the compliance remediation register and is under review.

---

Data Protection Impact Assessment (DPIA)

DPIA Status: ⚠️ REQUIRES SIGN-OFF — Draft completed (see dpia.md). Must be reviewed and signed by DPO or GDPR counsel before production deployment.

Conclusion: Processing is high-risk due to systematic monitoring (behavioral tracking). The mitigations relied on, and their implemented scope, are:

• Explicit consent for behavioural tracking — which suppresses only the granular event rows in the analytics database, not the live-session records or the attendance record
• Row Level Security in PostgreSQL (organisation isolation), with the residual limits recorded under Processing Activity 1; the Realtime Database rules contain no organisation check
• Encryption in transit and at rest, and pseudonymisation in PostgreSQL, subject to the automations exception recorded under Processing Activity 1
• A Data Subject erasure pipeline that is automated once a member of staff triggers it, and which does not reach the SMS delivery log, the segment-broadcast recipient log, the AI generation job log, funnel page views or Cloud Storage
• Sub-processor safeguards, which are ⚠️ outstanding for Railway Corp., TikTok Pte. Ltd., SendSMS.ro and Anthropic PBC

⚠️ The DPIA predates the funnels, automations, AI generation, SMS and segment-broadcast subsystems recorded in Processing Activities 5 to 9, the server-side landing-page PageView recorded in Processing Activity 3, and the automated moderation of chat content recorded under Processing Activity 1. It must be revised to cover them.

Review Cycle: Annually or when processing significantly changes (new features, new sub-processors, new high-risk activities)

---

Cooperation with Supervisory Authorities

Designated Authority: ANSPDCP (National Authority for the Supervision of Personal Data Processing, Romania) Contact: https://www.dataprotection.ro, [email protected]

Cooperation Obligations:

• Provide this ROPA upon request
• Respond to inquiries within 30 days (or as specified by authority)
• Allow on-site inspections (with reasonable notice)
• Implement corrective measures ordered by authority

To Date: No supervisory authority inquiries or inspections.

---

Document Control

Version: 1.0 (DRAFT) Last Updated: [DATE] Next Review: Annually (or when processing activities change) Owner: Data Protection Officer (or CTO if no DPO appointed) Approved By: [Legal Team, Management] Access: Internal document, available to supervisory authority on request, and additionally served from the public legal documentation site

Maintenance Triggers (Update ROPA when):

• New sub-processor added
• New processing purpose introduced (e.g., new feature collecting personal data)
• Significant change to security measures
• Data breach occurs
• Supervisory authority requests update
• Annual review cycle

Review Status: ⚠️ REQUIRES LEGAL REVIEW — This is a draft for lawyer consultation

---

End of ROPA

---

Annex: Template ROPA for Customer Organizations (Data Controllers)

[PLATFORM PROVIDER] provides guidance to help customer organizations fulfill their own GDPR Article 30(1) obligations. Customers should adapt it with their specific details.

⚠️ No ROPA template is currently distributed. Earlier revisions of this document directed customers to a "Settings → GDPR Compliance → Download ROPA Template" screen in the dashboard. No such settings area and no template download exists. Until a template is published, customers should use the Article 30 guidance in the Customer GDPR Compliance Guide, together with the categories of data, purposes, recipients, transfers and retention periods recorded in this document.