Annex III: List of Sub-Processors

Data Processing Agreement between [CUSTOMER] and [PLATFORM PROVIDER]Last Updated: [DATE]

---

Introduction

This Annex lists all third-party sub-processors engaged by [PLATFORM PROVIDER] to process Personal Data on behalf of Customer, in compliance with GDPR Article 28(2) and 28(4). [PLATFORM PROVIDER] engages eleven sub-processors, listed below.

Customer Rights:

• Customer has granted general authorization for [PLATFORM PROVIDER] to engage sub-processors listed below
• Customer has the right to object to new sub-processors (30-day notice period per DPA Section 5.3)
• Customer may audit sub-processor compliance (through [PLATFORM PROVIDER], per DPA Section 11)

Change Management:

• [PLATFORM PROVIDER] shall notify Customer at least 30 days in advance of any addition or replacement
• Notification via: email to the registered organisation contact, and publication of the updated Annex on the documentation site. The dashboard contains no sub-processor page and no announcement surface — its settings area exposes only the general, users, integrations, forms, emails, SMS, push, chat-announcement, lead-scoring, retention and jobs screens.
• Updated list published on the documentation site at the path /legal/platform/annex-sub-processors

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

This Annex previously stated that changes to the sub-processor list are announced through a dashboard page at Settings → Integrations → Sub-Processors and published at a separate address reserved for the sub-processor list. Neither surface exists: the dashboard has no sub-processor screen and no notification screen, and this Annex is served only by the documentation site at the path given above, so notice depends on an email to the registered organisation contact and on the publication of this document. This divergence is recorded on the compliance remediation register and is under review.

---

Sub-Processor List

#	Sub-Processor	Service Provided	Data Categories Processed	Data Location	Safeguards	DPA/SCCs
1	Google LLC (Firebase, Google Cloud)	- Firestore database - RTDB (real-time database) - Firebase Authentication - Cloud Functions (event bridge) - Cloud Storage (landing-page files, organisation media library, branding assets, page templates, offer and webinar imagery, staff uploads) - Secret Manager (API tokens, including per-org mobile Firebase service account credentials) - Google Fonts (web fonts for AI-generated landing pages, fetched server-side by the public application; loaded directly only by staff browsers in the page-editor preview) and YouTube (video embed on the live watch page) — outside the scope of the Google Cloud Data Processing and Security Terms	- Registration: email, name, phone - Behavioral: chat, polls, offers, attendance - Technical: IP, user agent - Staff: email, name, role - FCM device tokens (stored in PostgreSQL by [PLATFORM PROVIDER]; Secret Manager stores org's Firebase credentials) - Google Fonts: the IP address and user agent of a staff member previewing a generated page in the page editor. Landing-page visitors' data does not reach Google Fonts - YouTube: the IP address, user agent and viewing behaviour of every attendee on a watch page whose stream is hosted on YouTube, together with the Google cookies the embed sets	Storage: EU — europe-west3 for Cloud Functions, europe-west1 for the Realtime Database, EU multi-region for Firestore Importer: Google LLC is established in the United States, so the relationship is treated as a transfer to a third country and is addressed in Annex IV ⚠️ The Cloud Storage bucket location is not evidenced in [PLATFORM PROVIDER]'s records and must be confirmed against the project configuration	- Google Cloud Data Processing and Security Terms - EU-US Data Privacy Framework (Google certified) - Standard Contractual Clauses (2021) - ISO 27001, SOC 2, SOC 3 - Encryption at rest and in transit - ⚠️ The Google Cloud Data Processing and Security Terms do not cover Google Fonts or YouTube embeds; those services are governed by Google's own terms and are loaded without a consent gate	✅ Google Cloud DPA ✅ SCCs embedded
2	Railway Corp.	- PostgreSQL database hosting - Go API hosting - Next.js apps hosting (public website, dashboard)	- Contacts: email_hash together with suppression and processing-restriction flags and counters — the contacts table holds no name and no telephone number - Behavioral events: poll votes, offer clicks, chat messages - Consents (all purposes, including push_marketing) - Funnel entries: campaign attribution (UTM parameters, advertising click identifier and click platform, landing-page and referrer URL), country, city, device type, operating system, browser, browser time zone, and raw inbound webhook payloads - Funnel page views: a persistent pseudonymous visitor identifier derived from the visitor's IP address and user agent - Automation step execution records, whose result documents contain the recipient's plaintext email address and telephone number - SMS delivery records, segment-broadcast content and the per-recipient broadcast log, keyed by email_hash - AI generation jobs: full system prompt, user prompt and model output, which may contain an approved attendee testimonial and its author's name - Audit log and scheduler job-run log, which record the acting staff user's IP address and user agent - FCM device tokens (pseudonymous, keyed by org_id + email_hash + fcm_token) - Push delivery records (push_sends: send status, open timestamp, FCM message ID) - Application logs captured by the hosting platform, which include plaintext email addresses	EU region (specific: [germany-west or similar])	- Railway Data Processing Terms (requested) - SOC 2 Type II certified - Hosted on Google Cloud EU infrastructure - Encryption at rest (AES-256)	⚠️ ACTION REQUIRED: Request DPA from Railway [https://railway.app/legal]
3	NewsmanApp SRL	- Transactional email delivery (registration confirmations, reminders, replay notifications) - Marketing email delivery (if Customer opts in) - Bulk synchronisation of subscriber lists and per-subscriber segment membership - Return reporting of delivery and engagement events (view, click, bounce, complaint, unsubscribe) - Operated both under a platform-level [PLATFORM PROVIDER] account, which is the default sender for any organisation without its own enabled Newsman integration, and under each Customer's own account where configured	- Email addresses (recipients) - First and last name, for personalisation and for bulk list import - Segment membership, per subscriber - Subscriber status, including the permanent-suppression status written on erasure - Open, click, bounce, complaint and unsubscribe events, returned to the platform and stored against the contact - A placeholder opt-in IP address (0.0.0.0) transmitted on server-side re-subscription - Event metadata (title, date, URL)	EU (Romania)	- Newsman Data Processing Agreement - GDPR-compliant (Romania-based, EU law applies) - Encryption in transit (TLS) - Email delivery logs retained 90 days - ⚠️ Erasure at the email provider is implemented as permanent suppression rather than deletion, so the email address remains on file indefinitely	⚠️ ACTION REQUIRED: Request DPA from Newsman [Contact Newsman support]
4	Meta Platforms, Inc. (Facebook)	- Client-side: Meta Pixel (page tracking) — active - Server-side: Conversions API — CompleteRegistration on every registration and PageView on every visit to a published funnel landing page - Client-side pixel is injected whenever Customer enables the Meta integration; it loads before any cookie-banner decision in a consent-withheld state (see the Cookie Policy) - Server-side events are sent whenever Customer enables the Meta integration, independently of the attendee's cookie choice	- Client-side (browser): page view, IP address, user agent, page URL; _fbp and _fbc cookies only after the attendee accepts advertising cookies - Server-side (API): SHA-256 hashed email, hashed first name, hashed last name; the registration identifier transmitted unhashed as external_id; raw client IP address, raw user agent, the fbclid click identifier and the _fbp / _fbc cookie values where present; page URL and referrer; the platform's internal webinar, session and funnel identifiers with a zero value and currency code; event identifier for deduplication against the browser pixel. No telephone number is transmitted — the field is left empty when the event is assembled, whatever number is held on the contact	USA (Meta data centers)	- Meta Business Tools Terms - Meta Data Processing Terms - Standard Contractual Clauses (EU Model Clauses) - Hashing of directly identifying fields before transmission (server-side) - Server-side events are suppressed for contacts subject to a GDPR Art 18 processing restriction - Limited data categories (no chat content) - ⚠️ No advertising-consent gate on the server-side Conversions API. The server-side mirror is operated on the legal basis determined by the Customer as controller - ⚠️ 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.	✅ Meta Business Tools Terms ✅ Meta DPA ✅ Meta Privacy Policy
5	Google LLC (Google Analytics / Google Ads)	- Client-side: Google Analytics — not implemented by the platform. No Google Analytics integration exists in the product and [PLATFORM PROVIDER] emits no Analytics tag. Analytics reaches visitors only through a Google Tag Manager container the Customer configures, or through a script the Customer pastes into Settings → Integrations → Tracking Scripts - Server-side: Google Ads Enhanced Conversions API — planned, not yet active	- Client-side (browser): where the Customer deploys Analytics through its own container or pasted script: _ga, _ga_*, _gid cookies, page views, session data, IP address, user agent. The categories collected and the settings that govern them are determined by the Customer's own tag configuration - Server-side (API): none — no Google Ads conversion event is sent	USA (Google Ads infrastructure)	- Google Ads Data Processing Terms - EU-US Data Privacy Framework (Google certified) - Standard Contractual Clauses - A Customer-pasted Analytics script is categorised as an analytics script by the consent bundle and is loaded only after the visitor grants analytics consent; a tag inside a Customer's GTM container is governed by the Google Consent Mode v2 defaults the platform emits alongside that container - ⚠️ [PLATFORM PROVIDER] does not control IP anonymisation or any other Analytics setting, because it does not emit the tag. Scripts a Customer adds are governed by DPA Section 3.5	✅ Google Ads Data Processing Terms ✅ Google Privacy Policy
6	TikTok Pte. Ltd.	- Client-side: TikTok Pixel (page tracking) — active - Server-side: TikTok Events API (CompleteRegistration on every registration) — active since 8 May 2026 - Client-side pixel is injected whenever Customer enables the TikTok integration; it loads before any cookie-banner decision in a consent-withheld state (see the Cookie Policy) - Server-side events are sent whenever Customer enables the TikTok integration, independently of the attendee's cookie choice	- Client-side (browser): page view, IP address, user agent, page URL; _ttp and _ttclid cookies only after the attendee accepts advertising cookies - Server-side (API): SHA-256 hashed email, hashed first name, hashed last name, hashed external identifier (registration ID); raw client IP address, raw user agent, raw ttclid click identifier and raw _ttp cookie value; page URL and referrer; the platform's internal webinar, session and funnel identifiers with a zero value and currency code; event identifier for deduplication against the browser pixel. No telephone number is transmitted — the field is left empty when the event is assembled, whatever number is held on the contact	USA / Singapore (TikTok data centers)	- TikTok Business Products Terms - Standard Contractual Clauses (requested) - Hashing of directly identifying fields before transmission (server-side) - Server-side events are suppressed for contacts subject to a GDPR Art 18 processing restriction - ⚠️ No advertising-consent gate on the server-side Events API. The server-side mirror is operated on the legal basis determined by the Customer as controller, on the same footing as the Meta Conversions API - ⚠️ The client-side pixel is classified as a necessary script and issues a Pageview before, and irrespective of, the attendee's consent decision; it is held in ttq.holdConsent() state so that no advertising cookies are set until advertising consent is granted	⚠️ ACTION REQUIRED: Request DPA/SCCs from TikTok — now required, integration is live TikTok Privacy Policy
7	LinkedIn Corporation (Microsoft)	- Not implemented. No LinkedIn Insight Tag is emitted by the platform, no LinkedIn Conversions API integration exists, and the dashboard integrations screen offers no LinkedIn option - A LinkedIn configuration structure is present in the organisation data model but has no reader anywhere in the platform	- None. No data is transmitted to LinkedIn by [PLATFORM PROVIDER] - Where a Customer has itself deployed a LinkedIn Insight Tag, the li_fat_id cookie that tag sets is read by the platform's attribution code only after the visitor accepts advertising cookies and is stored as campaign attribution on the registration; it is not sent to LinkedIn	Not applicable — no transfer occurs	- Not applicable while the integration is unimplemented - ⚠️ This Annex previously declared the Insight Tag and the Conversions API active; see the KNOWN GAP in Section 5-7	Not required while unimplemented LinkedIn Privacy Policy
8	Cloudflare, Inc.	- Mandatory reverse proxy in front of attendee traffic in production. Cloudflare terminates TLS for and sees every attendee request, and for that traffic the platform takes the client IP address it records or forwards from a Cloudflare-supplied header, which its IP-extraction helper checks before any other proxy header - Turnstile bot protection: where the Customer has configured a Turnstile site key, the widget script is injected into every published landing page that carries a funnel form, outside the consent bundle, and server-side verification transmits the visitor's IP address to Cloudflare - CDN caching and cache purge for public landing pages, where Customer configures its own Cloudflare zone	- All request content of proxied traffic, including registration form submissions carrying plaintext email address, name and telephone number - Visitor IP addresses, user agents and request metadata - Visitor IP address submitted to Cloudflare for Turnstile verification - Public landing-page HTML content	Global (Cloudflare edge network, nearest PoP)	- Cloudflare Customer DPA - Standard Contractual Clauses - ISO 27001, SOC 2 Type II - TLS in transit - Customer provides its own Cloudflare Zone ID and API token for the cache-purge and Turnstile functions - ⚠️ Cloudflare is not a conditional sub-processor and personal data does reach it: it is in the request path for all attendee traffic irrespective of any Customer configuration - ⚠️ The Turnstile widget script loads before, and irrespective of, the visitor's cookie-banner decision	✅ Cloudflare DPA
9	Microsoft Corporation (Microsoft Clarity) — contracted via Microsoft Ireland Operations Limited (MIOL) for EU customers	- Client-side: Microsoft Clarity JavaScript tag (cookies, session recordings, heatmaps, rage-click/dead-click detection) - Independent data controller under Microsoft's terms (not a GDPR Art 28 processor acting on Customer's behalf) - Conditional: only active if Customer enables Microsoft Clarity integration (Settings → Integrations → Microsoft Clarity) AND attendee grants analytics consent via cookie banner	- Client-side (browser): Session recording (mouse movements, clicks, scrolls, page navigation, text is masked in Balanced/Strict mode), pseudonymous user ID (_clck, CLID, MUID cookies), session ID (_clsk), page URLs, viewport/device info, IP address (used by Microsoft to derive approximate location and for bot detection), user agent - Form inputs are always masked (even in Relaxed mode) per Microsoft's documentation	EU (MIOL, Microsoft Ireland) with onward transfer to USA (Microsoft Corporation) under SCCs	- Microsoft Products and Services DPA (Customer Agreement) — Microsoft acts as independent data controller for Clarity - Microsoft Ireland Operations Limited is the EU contracting entity; Microsoft Corporation (US) receives data under Standard Contractual Clauses between Microsoft affiliates - EU-US Data Privacy Framework (Microsoft certified) - Cookie consent required — script only loads if attendee grants analytics consent via banner - Consent signal enforcement for EEA/UK/CH visitors (since Oct 31, 2025) — full functionality requires the clarity("consent", true) Consent API call after consent - ISO 27001, SOC 2 Type II (Microsoft cloud infrastructure)	✅ Microsoft DPA ✅ Microsoft Privacy Statement ✅ Clarity Terms of Use
10	SendSMS.ro (bulk messaging provider, Romania)	- Transactional SMS delivery (webinar reminder, "starting now", replay available, automation SMS steps) - Per-message delivery-status callbacks to the platform (report_url) - Only if Customer configures SendSMS credentials (Settings → Integrations → SendSMS)	- Attendee mobile telephone number in plaintext (not hashed) - Full message body, which includes the webinar title, the time remaining until start and a per-recipient tracked join URL - Sender ID (Customer's brand, max 11 characters) - Delivery status, provider message identifier and delivery timestamp returned to the platform	EU (Romania) for SendSMS.ro Onward delivery via the recipient's mobile network operator	- Per-organisation credentials held in Google Secret Manager (org-{orgID}-sendsms-api-key); only the secret reference is stored in Firestore - Consent gate: 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 - TLS in transit - ⚠️ Credentials and personal data are transmitted as URL query-string parameters on an HTTP GET request (to, text, username, password). Query-string parameters are conventionally recorded in web-server access logs, so the recipient's telephone number, the message body and the account password should be assumed to appear in the provider's request logs; the provider's actual logging and retention practice is not evidenced in [PLATFORM PROVIDER]'s records - ⚠️ The contracting legal entity behind sendsms.ro, its registered address and its retention period for message logs are not evidenced in [PLATFORM PROVIDER]'s records and must be confirmed against the executed service agreement before this Annex is published	⚠️ ACTION REQUIRED: Execute DPA https://www.sendsms.ro
11	Anthropic PBC (Claude API)	- AI generation of landing-page briefs, landing-page HTML and marketing copy (Customer-initiated, from the dashboard page editor) - AI generation of webinar poll questions - Vision calls that include staff-uploaded reference images - Platform-level sub-processor: engaged by [PLATFORM PROVIDER] under a single platform API key, not a Customer-provided integration and not switchable off per organisation	- Attendee personal data: approved testimonials submitted by attendees — display name, free-text quote, company name, rating — are embedded in the generation prompt - Customer content: organisation name, webinar title, description and type, page brief, staff-authored custom instructions - Staff-uploaded reference images from the organisation media library, inlined as base64 (these are Customer marketing assets and may depict identifiable individuals) - Text content scraped from third-party reference URLs supplied by staff - Not sent: chat message content, registration records, contact email addresses, telephone numbers, poll answers or behavioural events	USA (api.anthropic.com)	- Server-side only; no attendee device ever contacts Anthropic and no cookies are set - Single platform-wide API key held in an environment variable (not Google Secret Manager) - Every request's system prompt, user prompt, custom instructions, model identifier, full model output and token counts are retained in PostgreSQL (ai_jobs) together with the initiating staff user identifier - ⚠️ No consent gate. Attendee testimonials are transmitted without a specific consent for AI processing and without notice to the testimonial author - ⚠️ ai_jobs rows are not linked to a contact record and are therefore not reached by the erasure pipeline, so a testimonial quote and its author's name persist in the stored prompt after the contact has been erased - ⚠️ Anthropic's retention period for API inputs and outputs, and its transfer mechanism for EEA personal data, must be confirmed against the executed agreement	⚠️ ACTION REQUIRED: Execute Anthropic Commercial Terms + DPA and confirm SCCs / transfer mechanism https://www.anthropic.com/legal/commercial-terms https://privacy.anthropic.com

---

Sub-Processor Details

1. Google LLC (Firebase / Google Cloud)

Entity Name: Google LLC Address: 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA Parent Company: Alphabet Inc. Website: https://cloud.google.com, https://firebase.google.com

Services:

• Firestore: NoSQL database for event configuration, registrations, PII (encrypted at rest, EU multi-region)
• RTDB (Realtime Database): Live session data (chat, polls, offers, presence) — retained indefinitely; no automated deletion (see the retention note below)
• Firebase Authentication: Anonymous auth for attendees, email/password auth for staff, email link auth (magic link) for mobile app users (API-proxied via Go API)
• Cloud Functions: Event bridge (Firestore/RTDB triggers → Go API calls)
• Cloud Storage: Landing-page HTML files (customer-generated or AI-generated), the organisation media library, branding assets, page templates, and offer, webinar and staff uploads. Media-library assets are staff-uploaded marketing imagery and may depict identifiable individuals.
• Secret Manager: Encrypted storage of API tokens (Meta, Cloudflare, Newsman, SendSMS credentials, per-org mobile Firebase service accounts)
• Google Fonts: the generation prompts instruct the model to include a Google Fonts <link> whenever the chosen typography calls for one, and the design-brief path instructs it in every case. When a published page is served, the public application rewrites those links to the page's own domain (/fonts/…) and fetches the stylesheets and font files from Google server-side, so the visitor's browser never contacts fonts.googleapis.com or fonts.gstatic.com and the visitor's IP address and user agent do not reach Google. Google receives only the platform's own server requests, which carry no visitor data. The page editor's preview is not rewritten: when a staff member previews a generated page in the dashboard, their browser loads the fonts from Google directly. The Next.js applications self-host their fonts.
• 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.

Retention of Live-Session Data (Realtime Database): Live-session data in the Realtime Database is retained indefinitely. There is no scheduled cleanup function: the Cloud Functions codebase exports ten functions, of which nine are database triggers and one is a minutely presence reconciler, and none deletes session data. Moving a session to replay or archived status does not prune it either — the lifecycle job writes a statistics snapshot to Firestore and performs no deletion in the Realtime Database. The only operations that remove a live-session node are the manual deletion of a session and the manual deletion of the parent webinar. Chat message text, attendee display names, presence and attendance records, poll votes, reactions, offer clicks and feedback responses therefore persist for the lifetime of the webinar record.

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

This Annex previously described live-session data in the Realtime Database as ephemeral and session-scoped. No scheduled cleanup function exists: the Cloud Functions codebase exports ten functions, of which nine are database triggers and one is a minutely presence reconciler, and none of them deletes session data. Live-session records — chat message text, attendee display names, presence, attendance, poll votes, reactions and feedback — are removed only when a staff member deletes the session or the parent webinar. This divergence is recorded on the compliance remediation register and is under review.

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

This Annex previously scoped the Google relationship to the services governed by the Google Cloud Data Processing and Security Terms. The YouTube iframe on the live watch page receives personal data outside that agreement, disclosing the visitor's IP address and user agent to Google without a consent gate. This divergence is recorded on the compliance remediation register and is under review.

Data Processing:

• Registration PII: orgs/{orgId}/contacts/{emailHash}/pii/private (email, name, phone)
• Behavioral data: Chat messages, poll votes, offer clicks (RTDB + Firestore mirrors)
• Staff data: orgs/{orgId}/users/{userId} (email, name, role)
• Consent records: orgs/{orgId}/contacts/{emailHash}/consents/{consentId} (consent granted/revoked timestamps, org-scoped only — one grant per organisation, contact and purpose, covering every future event in that organisation; the webinar-scoped consent model was removed by a data migration)
• Firebase Auth UID: orgs/{orgId}/contacts/{emailHash} → firebaseUid field (mobile app users only — enables UID→contact lookup)
• Secret Manager: Stores per-org mobile Firebase service account JSON credentials (encrypted; used by the Go API to call FCM on Customer's behalf — see "Customer-Provided Integrations" section below)

Note on Mobile Push / FCM: [PLATFORM PROVIDER]'s own Firebase project (this sub-processor entry) does not handle FCM push delivery. Push delivery uses each Customer's own Firebase project via Customer-provided credentials. See the "Customer-Provided Integrations" section for the GDPR classification of that relationship.

Security Certifications:

• ISO/IEC 27001, 27017, 27018
• SOC 2 Type II, SOC 3
• GDPR-compliant, EU-US Data Privacy Framework certified
• Penetration tested regularly, bug bounty program

DPA: Auto-applies when using Google Cloud Console (no signature needed) SCCs: Embedded in Google Cloud Data Processing and Security Terms Location Guarantees: europe-west3 for Cloud Functions, europe-west1 for the Realtime Database, EU multi-region for Firestore. ⚠️ The Cloud Storage bucket location is not evidenced in [PLATFORM PROVIDER]'s records and must be confirmed against the project configuration Data Residency Options: Customer can request all data stay in EU (requires Firestore config change)

Breach Notification: Google notifies within 24 hours (per Google Cloud DPA)

---

2. Railway Corp.

Entity Name: Railway Corporation Address: [Railway Address — contact Railway for details] Website: https://railway.app

Services:

• PostgreSQL hosting: Contacts, behavioral events, segments, consents, GDPR requests, audit logs
• Go API hosting: Backend services (Gin framework, authentication, GDPR pipelines)
• Next.js apps hosting: Public website (ISR landing pages), Admin dashboard

Data Processing:

• Contacts table: email_hash (SHA-256 of the lowercased, trimmed email address), together with suppression and Article 18 processing-restriction flags, first- and last-seen timestamps and a webinar counter. The table holds no name and no telephone number.
• Behavioral events: Poll votes, offer clicks, chat messages (consent-gated)
• Consents: Mirror of Firestore consent records (all purposes, including push_marketing)
• Funnel entries: Campaign attribution (UTM parameters, advertising click identifier and click platform, landing-page and referrer URL), country and city derived from the IP address, device type, operating system, browser and browser time zone, referral source, and the raw body of any inbound order or form webhook
• Funnel page views: A persistent pseudonymous visitor identifier derived from the visitor's IP address and user agent, recorded once per visitor per funnel step per day
• Automation enrolments and step executions: The step execution result document contains the recipient's plaintext email address for email steps and their plaintext telephone number for SMS steps
• SMS delivery records: sms_sends table — email hash, webinar and session identifiers, template type, tracking code, provider message identifier, delivery status, error text, and delivery and click timestamps
• Segment broadcasts: Broadcast content (subject, title, body, call to action, author) and a per-recipient send log keyed by email hash
• AI generation jobs: ai_jobs table — full system prompt, user prompt, custom instructions, model output and token counts, which may contain an approved attendee testimonial together with its author's name and company
• Audit log and scheduler job runs: Both record the acting staff user's IP address and user agent
• Device tokens: device_tokens table — FCM push tokens (pseudonymous, keyed by org_id + email_hash + fcm_token, platform: android/ios). No automated deletion — see the retention note below.
• Push delivery records: push_sends table — push send status, FCM message ID, open timestamp (client-reported), event/session context (linked to email_hash, not plaintext email)
• Application logs: The hosting platform captures the application's structured logs, several of which record plaintext email addresses and, on an SMS send failure, the recipient's plaintext telephone number, which makes log retention a location at which personal data is processed

Pseudonymisation Boundary: 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.

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

This Annex previously described the PostgreSQL contacts table as holding a name and a telephone number alongside the email hash, and presented the hashed key as the boundary that keeps plaintext contact details out of PostgreSQL. The contacts table in fact holds neither a name nor a telephone number, while the automation step execution records hold the recipient's plaintext email address and telephone number in PostgreSQL, and the API keeps an unexpiring in-process cache of plaintext contact details. This divergence is recorded on the compliance remediation register and is under review.

Retention of Device Tokens and Other Configurable Data: Retention periods are configured per organisation, and no default policy is seeded. The retention enforcement job acts only on policies that exist, so an organisation that has configured none has no data deleted by age. The retention settings screen currently submits eight data types while the API accepts five, and the API validates the whole submission before writing any of it, so every save attempt is rejected and no retention policy can be configured through the product.

Where an enabled policy would delete more than ten thousand rows in a single run, the job records a warning and deletes nothing, so a table whose backlog has crossed that threshold is not brought back within its retention period by subsequent runs.

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

This Annex previously stated that FCM device tokens are subject to a 60-day retention period. Sixty days is an unsaved default value on a settings screen; no retention policy is seeded for any organisation, and the settings screen cannot save one because it submits data types the API rejects, so no automated deletion of device tokens or of any other data type takes place. This divergence is recorded on the compliance remediation register and is under review.

Security Certifications:

• SOC 2 Type II (Railway advertises this)
• Hosted on Google Cloud Platform infrastructure (inherits GCP security)

DPA: ⚠️ Not yet obtained — ACTION REQUIREDLocation: EU region deployment available (germany-west or similar) Encryption: AES-256 at rest, TLS in transit Backups: Automated daily backups, 30-day retention, encrypted separately

Breach Notification: [Request SLA from Railway — should be 24-48 hours]

Action Item: Contact Railway support to request signed DPA or confirm auto-applying terms.

---

3. NewsmanApp SRL

Entity Name: NewsmanApp SRL Address: [Bucharest, Romania — request exact address] Website: https://www.newsman.comContact: [support email]

Engagement Model: Newsman is used through two separate APIs — a transactional API at cluster.newsmanapp.com and a marketing API at ssl.newsman.app — and under two kinds of account. A platform-level [PLATFORM PROVIDER] account is the default sender for any organisation that has not enabled its own Newsman integration, which makes Newsman a [PLATFORM PROVIDER] sub-processor in the ordinary sense; where a Customer configures its own Newsman account, the same provider is additionally a Customer-provided integration (see the "Customer-Provided Integrations" section below). Both classifications apply, to different sends.

Services:

• Transactional emails: Registration confirmations, event reminders (1h before), "starting now", replay available
• Marketing emails: Future event announcements (only if Customer enables and attendee consents)
• Subscriber list synchronisation: A scheduled job pushes contacts to the Customer's Newsman list in bulk, in batches of up to one hundred thousand subscribers, and adds and removes subscribers from Newsman segments to mirror platform segments
• Delivery and engagement reporting: Newsman returns view, click, bounce, complaint, rejection and unsubscribe events to the platform by webhook

Data Processing:

• Email addresses: Recipients of transactional and marketing emails, and of bulk list imports
• Names: First and last name (for email personalization: "Hi {{firstName}}") and as bulk-import fields
• Segment membership: Per-subscriber membership of the Newsman segments that mirror platform segments
• Engagement data: Open, click, bounce, complaint and unsubscribe events, which Newsman holds and returns to the platform, where they are stored against the contact as suppression flags
• Subscriber status: Including the permanent-suppression status written on erasure
• Opt-in IP address: On server-side re-subscription the platform transmits the placeholder value 0.0.0.0, because no real IP address is available at that point. The authoritative Article 7(1) record of consent is the platform's own consent event log, not the Newsman subscriber record.
• Event metadata: Title, date, time, registration URL (not PII)

Security:

• GDPR-compliant (EU-based provider, Romanian DPA applies)
• TLS encryption for SMTP
• Email delivery logs retained 90 days
• Unsubscribe mechanism (automatic list removal on unsubscribe)

Erasure at the Email Provider: Erasure at the email provider is a suppression, not a deletion. On completing an erasure the platform submits the contact's email address to the email provider with a permanently-rejected status, so that no future message can be delivered to it. By design this keeps the plaintext email address on file at the provider indefinitely.

GAP-DOC-02 · DOCS — KNOWN GAP, REMEDIATION PENDING

This Annex previously described the email provider as receiving recipient email addresses, names and event metadata, and as retaining delivery logs for ninety days. The provider additionally holds bulk-synchronised subscriber lists, per-subscriber segment membership and open, click, bounce, complaint and unsubscribe engagement data, and an erasure request results in the email address being retained indefinitely under a permanent-suppression status rather than deleted. This divergence is recorded on the compliance remediation register and is under review.

DPA: ⚠️ Not yet obtained — ACTION REQUIREDLocation: Romania (EU) SCCs: Not needed (intra-EU transfer)

Breach Notification: [Request SLA from Newsman]

Action Item: Request DPA, sub-processor list (does Newsman use AWS SES?), security certifications.

---

4. Meta Platforms, Inc. (Meta Pixel + Conversions API)

Entity Name: Meta Platforms, Inc. Address: 1 Hacker Way, Menlo Park, CA 94025, USA Parent Company: Meta Platforms, Inc. Website: https://www.facebook.com/business

Services:

• Meta Pixel (client-side): JavaScript tracking script that tracks page views, button clicks and user interactions, and sets advertising cookies once the visitor accepts the advertising category
• Conversions API (server-side): Server-to-server tracking of registration conversions, and of a PageView for every visit to a published funnel landing page
• Custom Audience Exclusion Lists: Hashed email uploads to prevent ad targeting of registered/opted-out/deleted contacts — planned, not yet active
• Active whenever Customer enables the Meta integration in the dashboard. The client-side Pixel loads before, and irrespective of, the attendee's cookie-banner decision, and the server-side Conversions API is not gated on cookie consent at all. Exclusion lists will operate independently under legitimate interest once implemented.

The Meta Pixel and the TikTok Pixel are classified as strictly necessary scripts and are therefore loaded on every page view, before and irrespective of the visitor's cookie-banner decision. Each sends a single page view to Meta and to TikTok respectively at that point, so both platforms receive the visitor's IP address, user agent and page URL before any consent is given. Both are loaded in a consent-withheld state — fbq('consent','revoke') for Meta and ttq.holdConsent() for TikTok — which is intended to prevent the identifying advertising cookies (_fbp, _fbc, _ttp, _ttclid) from being written until the visitor accepts the advertising category, at which point the consent state is flipped to granted. The absence of a cookie is the basis on which these scripts are currently classified as necessary; it is not a determination that the pre-consent load is permitted under Article 5(3) of the ePrivacy Directive, and the classification is under review.

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

This document previously stated that the Meta and TikTok pixels load only where the attendee accepts advertising cookies. Both pixels are in fact classified as necessary and fire a page view before any consent decision, in a configuration intended to be cookie-less until advertising consent is granted. This divergence is recorded on the compliance remediation register; the classification is under review.

Data Processing (Client-Side — Meta Pixel):

• Browser fingerprint: _fbp cookie (90 days, identifies browser across sessions) — written only after the visitor accepts advertising cookies
• Click ID storage: _fbc cookie (90 days, stores fbclid from ad click URL) — written only after the visitor accepts advertising cookies
• Page views: URLs visited, timestamps, referrer — sent on every page view, including before any consent decision
• Button clicks: CTA clicks, form submissions (registration button)
• IP address: The visitor's IP address, received by Meta with every pixel request
• User agent: Browser type, OS, device information

Data Processing (Server-Side — Conversions API, registration conversions):

• Hashed email (SHA-256, lowercase, trimmed before hashing)
• No telephone number. The field is left empty when the event is assembled, whatever number is held on the contact, so none is transmitted on this path
• Hashed first name (SHA-256, lowercase, trimmed)
• Hashed last name (SHA-256, lowercase, trimmed)
• External identifier (the registration ID) — transmitted to Meta unhashed
• Raw client IP address: transmitted by [PLATFORM PROVIDER] to Meta, unhashed
• Raw client user agent: transmitted by [PLATFORM PROVIDER] to Meta, unhashed
• Click ID (fbclid): From URL parameter (already sent by Meta in ad link)
• Cookie values: _fbp, _fbc (if cookies were set via Pixel)
• Event metadata: Registration timestamp, event_id (deduplication), and custom_data carrying the platform's internal webinar, session and funnel identifiers with a zero value and currency code
• Consent gate: none. The only suppression on this path is a GDPR Article 18 processing restriction on the contact.

Data Processing (Server-Side — Conversions API, landing-page 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.

Data Processing (Custom Audience Exclusion Lists) — Planned, not yet active:

• Hashed email (SHA-256) uploaded as negative audience to prevent ad targeting
• Use cases: Contacts who already registered (avoid redundant ads), contacts who revoked marketing consent (honor opt-out), contacts deleted via GDPR erasure (stop all targeting)
• Legal basis: Legitimate interest (Art 6(1)(f)) — serves data subject's interest in not receiving unwanted ads. No consent required.
• Meta matches hashes against their user base for exclusion, then discards non-matches. No new profile is created.
• Status: Will be implemented. Customers will be notified when activated.

NOT Sent to Meta:

• Plaintext email or name (these fields are hashed before transmission). No telephone number is sent at all. The registration identifier is not in this category: Meta receives it unhashed
• Chat messages or behavioral content (event activity is not shared)

The visitor's IP address and user agent are not in this category: both are transmitted to Meta in unhashed form on every server-side event, in addition to being received by Meta from the browser.

Security:

• Meta Business Tools Terms govern processing
• Standard Contractual Clauses (EU Model Clauses) embedded in Meta DPA
• HTTPS API (graph.facebook.com, Conversions API version 21.0)
• Event deduplication via event_id (prevents double-counting)

DPA: Auto-applies when using Meta Business Tools (accepted in Facebook Business Manager) SCCs: Embedded in Meta Data Processing Terms Data Retention (by Meta): 7 days for event matching, then hashed data deleted (per Meta policy)

Breach Notification: Meta notifies within 72 hours (per Meta DPA)

Purpose Limitation: Meta may only use hashed data for ad attribution and audience matching/exclusion (cannot use for Meta's own marketing per Business Tools Terms Section 2.3).

---

5-7. Google Analytics/Ads, TikTok Pixel and Events API, LinkedIn (Status Corrected)

Status:

• Google Analytics: Not implemented by [PLATFORM PROVIDER]. No Analytics integration exists in the product and no Analytics tag is emitted; Analytics reaches visitors only through a Customer's own Google Tag Manager container or a script the Customer pastes into Settings → Integrations → Tracking Scripts
• Google Ads Enhanced Conversions: Future (server-side API, not yet implemented)
• TikTok Pixel: Active (client-side). Injected whenever Customer enables the TikTok integration; loads before, and irrespective of, the attendee's cookie-banner decision
• TikTok Events API: Active since 8 May 2026 (server-side CompleteRegistration on every registration; no advertising-consent gate — see the Data Processing note below)
• LinkedIn Insight Tag: Not implemented. No Insight Tag is emitted by the platform
• LinkedIn Conversions API: Not implemented. No LinkedIn API is called by the platform

Data Processing:

Google Analytics (Customer-Deployed — Client-Side): Where a Customer deploys Analytics through its own tag container or a pasted script, the tag collects:

• User ID cookies: _ga, _ga_*, _gid, _gac_* (2 years retention)
• Page views, session duration, bounce rate, navigation paths
• IP address and the settings that govern its handling, which are determined by the Customer's own tag configuration and not by [PLATFORM PROVIDER]
• User agent, screen resolution, language, timezone
• Privacy Policy: https://policies.google.com/privacy

GAP-DOC-01 · DOCS — KNOWN GAP, REMEDIATION PENDING

This Annex previously stated that Google Analytics is an active [PLATFORM PROVIDER] integration and listed IP anonymisation among the safeguards [PLATFORM PROVIDER] applies to it. No Google Analytics integration exists in the product, no Analytics tag is emitted by the platform, and [PLATFORM PROVIDER] therefore controls neither IP anonymisation nor any other Analytics setting; where Analytics is present it has been deployed by the Customer through its own container or a pasted script. This divergence is recorded on the compliance remediation register and is under review.

TikTok Pixel (Active — Client-Side):

• Browser fingerprint cookie: _ttp (13 months) — written only after the visitor accepts advertising cookies
• Click ID cookie: _ttclid (session) — written only after the visitor accepts advertising cookies
• Page views, button clicks, timestamps — sent on every page view, including before any consent decision
• IP address, user agent
• Privacy Policy: https://www.tiktok.com/legal/privacy-policy

LinkedIn Insight Tag (Not Implemented): No LinkedIn Insight Tag is emitted by the platform, no LinkedIn Conversions API integration exists, and the dashboard integrations screen offers no LinkedIn option. A LinkedIn configuration structure is present in the organisation data model but has no reader. Where a Customer has itself deployed an Insight Tag, the li_fat_id cookie that tag sets is read by the platform's attribution code only after the visitor accepts advertising cookies and is stored as campaign attribution on the registration; it is not transmitted to LinkedIn.

• Privacy Policy: https://www.linkedin.com/legal/privacy-policy

GAP-DOC-01 · DOCS — KNOWN GAP, REMEDIATION PENDING

This Annex previously described the LinkedIn Insight Tag as active and the LinkedIn Conversions API as an operating server-side integration, and listed LinkedIn Corporation as a sub-processor receiving hashed email addresses and click identifiers. Neither integration exists: no LinkedIn tag is emitted, no LinkedIn API is called, and no personal data is transmitted to LinkedIn by [PLATFORM PROVIDER]. Over-declaring a sub-processor that receives nothing misstates this Annex and any Customer record of processing derived from it. This divergence is recorded on the compliance remediation register and is under review.

Server-Side APIs:

• Meta Conversions API: active — see Section 4
• TikTok Events API: active. Sends CompleteRegistration for every registration: SHA-256 hashed email, first name, last name and external identifier, plus the raw client IP address, the raw user agent, the ttclid click identifier and the _ttp cookie value. 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. Server-side PageView is not mirrored to TikTok. Suppressed only for contacts subject to a GDPR Art 18 processing restriction.
• Google Ads Enhanced Conversions: planned, not yet active
• LinkedIn Conversions API: not implemented

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

This Annex previously described the TikTok Events API as planned and not yet active. 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.

Safeguards:

• DPAs and SCCs (Meta pattern) — outstanding for TikTok
• The Meta and TikTok pixels are classified as necessary scripts and load before any consent decision, in a consent-withheld, cookie-less state — see Section 4
• Hashing of directly identifying fields before transmission (server-side)
• Server-side events are suppressed for contacts subject to a GDPR Art 18 processing restriction
• Scripts a Customer adds through its own tag container or the Tracking Scripts field are categorised by the consent bundle and, where categorised as analytics or advertising, are loaded only after the corresponding consent is granted

Action Items:

• [x] TikTok Pixel client-side tracking (active via tracking-scripts API)
• [ ] Finalize Google Ads Enhanced Conversions server-side implementation
• [ ] Request TikTok DPA and SCCs — outstanding and now overdue: the TikTok Events API has been transmitting hashed identifiers, raw IP addresses and raw user agents to TikTok since 8 May 2026 without an executed DPA on file
• [ ] Correct every derived record that lists Google Analytics or LinkedIn as an active integration

---

8. Cloudflare, Inc.

Entity Name: Cloudflare, Inc. Address: ⚠️ Not recorded in [PLATFORM PROVIDER]'s vendor register; to be confirmed against the executed Cloudflare Customer DPA Website: https://www.cloudflare.com

Services:

• Reverse proxy (mandatory, in production): Attendee domains are served through Cloudflare, which terminates TLS and forwards every request to the API. The platform trusts Cloudflare as its edge platform and derives every client IP address it records, stores or forwards to a third party from the CF-Connecting-IP header Cloudflare supplies. This is not conditional on any Customer configuration.
• Turnstile bot protection: Where a published landing page carries a funnel form, the Turnstile widget script is injected into the page head from challenges.cloudflare.com, outside the consent bundle and before any cookie-banner decision. Server-side verification of the resulting token transmits the visitor's IP address to Cloudflare.
• CDN caching and cache purge: Where a Customer configures its own Cloudflare zone, [PLATFORM PROVIDER] calls the Cloudflare API to purge cached landing pages.

Data Processing:

• All proxied request content, including registration form submissions carrying the attendee's plaintext email address, name and telephone number
• Visitor IP addresses and user agents, for every attendee and landing-page request
• Visitor IP address, transmitted to Cloudflare in the Turnstile verification request
• Public landing-page HTML, cached at the edge

Security and Transfer Safeguards:

• Cloudflare Customer DPA
• Standard Contractual Clauses
• ISO 27001, SOC 2 Type II
• TLS in transit
• Customer provides its own Cloudflare Zone ID, API token and Turnstile keys for the cache-purge and Turnstile functions; the proxy relationship is not Customer-configured

Data Location: Global — the Cloudflare edge network routes each request to the nearest point of presence.

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

This Annex previously described Cloudflare as a conditional sub-processor that becomes active only where a Customer enables the CDN integration, and stated that no personal data is cached because landing pages contain no personal data. Cloudflare is in fact in the request path for all attendee traffic in production, terminates TLS for every attendee request including registration submissions that carry plaintext email address, name and telephone number, and additionally receives the visitor's IP address through Turnstile verification and serves the Turnstile widget script before any consent decision. This divergence is recorded on the compliance remediation register and is under review.

---

9. Microsoft Corporation (Microsoft Clarity)

Entity Name (EU contracting): Microsoft Ireland Operations Limited (MIOL) Address (EU): One Microsoft Place, South County Business Park, Leopardstown, Dublin 18, Ireland Parent Company: Microsoft Corporation (One Microsoft Way, Redmond, WA 98052, USA) Service URL: https://clarity.microsoft.com

Services:

• Microsoft Clarity (client-side only): JavaScript tag that records user sessions (mouse movements, clicks, scrolls, navigation), generates heatmaps, and detects behavioral signals (rage clicks, dead clicks, quick-back, excessive scroll)
• No server-side API integration — [PLATFORM PROVIDER] does not send hashed identifiers or conversion events to Microsoft. Clarity operates exclusively in the attendee's browser.
• Only active if Customer enables Microsoft Clarity integration in dashboard AND attendee accepts analytics cookies via cookie banner.

GDPR Classification — Independent Data Controller: Unlike Meta Pixel or Google Analytics integrations (which [PLATFORM PROVIDER] may treat as processors via DPAs), Microsoft states that Clarity operates as an independent data controller (see Microsoft Clarity FAQ). Microsoft determines the means and purposes of its processing of Clarity data. The Customer's relationship with Microsoft for Clarity is governed directly by the Microsoft Products and Services DPA and the Microsoft Privacy Statement — not by [PLATFORM PROVIDER]'s DPA. [PLATFORM PROVIDER] lists Microsoft in this Annex to ensure full transparency, even though Microsoft is technically not a sub-processor in the strict GDPR Art 28 sense.

Data Processing (Client-Side — Clarity Cookies):

Cookie	Type	Purpose	Typical Duration
_clck	First-party	Persists the Clarity User ID (pseudonymous) and preferences for the site	1 year
_clsk	First-party	Connects multiple page views into a single Clarity session recording	1 day
CLID	Third-party	Identifies the first time Clarity saw this user on any site using Clarity	1 year
ANONCHK	Third-party	Indicates whether MUID is transferred to ANID (Clarity does not use ANID; value is always 0)	10 minutes
MR	Third-party	Indicates whether to refresh MUID	7 days
MUID	Third-party	Identifies unique browsers visiting Microsoft sites (used for site analytics, advertising, operational purposes)	~13 months
SM	Third-party	Used to synchronize MUID across Microsoft domains	Session

Data Processing (Session Recording — browser only):

• Interaction events: mouse movements, clicks, scrolls, taps, keystrokes (keys only, not values), page navigation, viewport size, referrer, URL path
• Masked by default: All <input> values are masked in every masking mode (Strict / Balanced / Relaxed) and cannot be unmasked. Text content is masked in Strict mode; masked with heuristic exemptions for non-sensitive text in Balanced mode (default); fully visible in Relaxed mode.
• IP address: Collected by Microsoft (used for geolocation inference and bot detection); not stored or processed by [PLATFORM PROVIDER]
• User-Agent string: Collected by Microsoft for device/browser classification

NOT Sent to Microsoft:

• Plaintext email, name, or phone number (form inputs are always masked before being uploaded)
• Server-side events, conversions, or any data from [PLATFORM PROVIDER]'s backend
• Customer PII from Firestore, RTDB, or PostgreSQL

Security and Transfer Safeguards:

• Microsoft Products and Services DPA governs processing (auto-applies on Clarity sign-up)
• EU customers contract with Microsoft Ireland Operations Limited (MIOL)
• Onward transfer to Microsoft Corporation (USA) between Microsoft affiliates is covered by Standard Contractual Clauses embedded in the intra-Microsoft agreement
• Microsoft is certified under the EU-US Data Privacy Framework
• ISO/IEC 27001, SOC 2 Type II (Microsoft cloud infrastructure)
• HTTPS-only data transmission

Consent Requirements:

• EEA / UK / Switzerland visitors: Since October 31, 2025, Microsoft enforces explicit consent signals for Clarity. Without an affirmative consent signal, Clarity operates in a degraded mode (no full session recording; sessions fragmented across page views).
• [PLATFORM PROVIDER] addresses this by (a) loading the Clarity tag only after the attendee grants analytics consent via the cookie banner, (b) calling clarity("consent", true) immediately inside the Clarity snippet to explicitly confirm consent to Microsoft, and (c) calling clarity("consent", false) before page reload when the attendee revokes analytics consent via the preferences modal — so Clarity drops its state cleanly.

Data Retention (by Microsoft): Per Microsoft Privacy Statement and Clarity data-retention terms — Microsoft retains Clarity data for a limited period (see Microsoft documentation for current retention window).

DPA: Auto-applies via Microsoft Products and Services DPA (Microsoft Customer Agreement). SCCs are embedded for Microsoft affiliate transfers.

Breach Notification: Microsoft notifies per Microsoft DPA (typically 72 hours).

---

10. SendSMS.ro (Transactional SMS)

Vendor Name: SendSMS.ro Service URL: https://www.sendsms.roAPI Endpoint: https://api.sendsms.ro/jsonEstablishment: Romania (EU)

Services:

• Transactional SMS delivery: three webinar lifecycle messages — reminder (default 30 minutes before start), "starting now", and "replay available" — plus SMS steps executed by the automations engine.
• Delivery status callbacks: each message is submitted with a per-message report_url pointing back to the platform, so SendSMS.ro reports delivered / undelivered / failed status.

Data Processing:

• Telephone number: transmitted in plaintext. It is read from the attendee's Firestore PII document at send time; PostgreSQL never holds it.
• Message body: contains the webinar title, the time remaining until start or the replay deadline, and a per-recipient tracked URL. Romanian diacritics are transliterated to ASCII before submission so the message stays within GSM-7 encoding.
• Sender identifier: the Customer's brand, maximum 11 alphanumeric characters.
• Returned to the platform: provider message identifier, delivery status, delivery timestamp, and — where the tracked URL is followed — a click timestamp. These are stored in the PostgreSQL sms_sends table keyed by org_id and email_hash.

Transport: Requests are issued as HTTP GET to https://api.sendsms.ro/json over TLS, with all parameters — including the account username, the account password, the recipient's telephone number and the message text — carried in the query string. Query-string parameters are conventionally recorded in web-server access logs, so these values should be assumed to be present in the provider's logs.

Credentials: Per-organisation. The API key is written to Google Secret Manager under the name org-{orgID}-sendsms-api-key; Firestore stores only the secret reference, the username, the sender identifier and the enabled flag.

Consent and Suppression: An SMS is dispatched only where the contact holds a granted, unrevoked sms_notifications consent and the contact is not subject to a GDPR Art 18 processing restriction. See the Privacy Policy for how that consent is collected.

Data Retention (by SendSMS.ro): ⚠️ Not established. The provider's retention period for message content and delivery logs must be confirmed against the executed service agreement.

Breach Notification: ⚠️ Not established. To be confirmed in the executed DPA.

---

11. Anthropic PBC (Claude API)

Entity Name: Anthropic PBC (Delaware public benefit corporation) Address: 548 Market Street, PMB 90375, San Francisco, CA 94104, USA API Endpoint: https://api.anthropic.comModels called: Claude Haiku 5.5, Claude Sonnet 5.5, Claude Opus 5.5

Engagement Model: Anthropic is engaged by [PLATFORM PROVIDER], not by Customer. The Go API authenticates with a single platform-wide API key held in an environment variable; there are no per-organisation credentials and no per-organisation switch. Anthropic is therefore a [PLATFORM PROVIDER] sub-processor in the ordinary sense, and does not belong in the Customer-Provided Integrations table.

Services:

• Landing-page brief generation and refinement (dashboard page editor).
• Landing-page HTML and marketing copy generation and refinement, including a vision path that inlines staff-selected reference images from the organisation media library.
• Webinar poll question generation.

Data Processing:

• Attendee personal data: approved testimonials are inserted into the generation prompt as "quote" — Name, Company (rating/5). Testimonials are submitted by attendees themselves during or after a live session and approved by staff. This is the sole category of attendee personal data that reaches Anthropic, and it is the reason Anthropic is treated as an Art 28 sub-processor rather than as a software vendor.
• Customer content: organisation name, webinar title, description and type, page brief, style preset, staff-authored custom instructions.
• Images: staff-uploaded reference images are base64-encoded inline in the request. These are Customer marketing assets and may depict identifiable individuals.
• Third-party page content: where a member of staff supplies a reference URL, the platform fetches that page and includes its extracted headings and text in the prompt.
• Never sent: chat message content, registration records, contact email addresses, telephone numbers, poll answers, attendance data or behavioural events. Poll generation in particular receives only the webinar title, description and type, the organisation name and any staff instructions.

Storage of Prompts and Outputs: Every generation is recorded in the PostgreSQL ai_jobs table: system prompt, user prompt, custom instructions, model, full output text, input and output token counts, duration, and the identifier of the member of staff who started the job. Rows are versioned per entity and retained for cost tracking and reproducibility.

Consent: None. AI generation is a staff-initiated action under the Customer's legitimate interest in producing marketing content. Attendees are not asked for, and are not informed of, any consent covering the transmission of their testimonial to an AI provider.

Data Retention (by Anthropic): ⚠️ Not established in [PLATFORM PROVIDER]'s records. Anthropic's published Commercial Terms of Service govern the use and retention of API inputs and outputs; the applicable period must be confirmed against the executed agreement.

International Transfer: USA. ⚠️ The transfer mechanism (Standard Contractual Clauses or an adequacy-based framework) must be confirmed and recorded before this Annex is published.

Breach Notification: ⚠️ Not established. To be confirmed in the executed DPA.

---

Customer-Provided Integrations (NOT [PLATFORM PROVIDER] Sub-Processors)

The following third-party services are engaged directly by Customer (not by [PLATFORM PROVIDER]). [PLATFORM PROVIDER] calls these services using credentials Customer provides via the dashboard. Under GDPR, these providers are sub-processors or processors engaged by Customer, not by [PLATFORM PROVIDER]. Customer holds the DPA with each provider. See DPA Section 3.4 for the governing terms.

Two providers below are dual-classified. NewsmanApp SRL and Cloudflare, Inc. are also [PLATFORM PROVIDER] sub-processors in their own right (sub-processors 3 and 8), because [PLATFORM PROVIDER] engages each of them independently of any Customer configuration. The rows below describe only the Customer-credential leg of those two relationships.

Integration	Third-Party Provider	Customer's Responsibility	What [PLATFORM PROVIDER] Does
Mobile Push Notifications (FCM)	Google Firebase (Customer's own Firebase project, separate from the [PLATFORM PROVIDER] events Firebase project)	Customer has their own Google Cloud account and DPA with Google covering their mobile Firebase project. Customer provides their Firebase service account credentials to [PLATFORM PROVIDER] via Settings → Integrations → Mobile Push.	[PLATFORM PROVIDER] calls the FCM HTTP v1 API on Customer's behalf using Customer's service account. FCM tokens (from device_tokens table) are sent to Customer's Firebase project for delivery. [PLATFORM PROVIDER] does not have a sub-processor relationship with Google for Customer's Firebase project — Customer does.
Email Delivery	NewsmanApp SRL (Customer's own Newsman account, where configured)	Customer has their own contract and DPA with Newsman. Customer provides Newsman API key and list ID to [PLATFORM PROVIDER].	[PLATFORM PROVIDER] calls Newsman API on Customer's behalf to send transactional and marketing emails, synchronises subscriber lists and segment membership, and records the delivery and engagement events Newsman returns. Where a Customer has not enabled its own Newsman integration, sending falls back to [PLATFORM PROVIDER]'s own platform-level Newsman account, and Newsman is then a [PLATFORM PROVIDER] sub-processor — see sub-processor 3.
CDN cache purge and Turnstile	Cloudflare, Inc. (Customer's own Cloudflare account)	Customer has their own Cloudflare account and DPA with Cloudflare. Customer provides Zone ID, API token and Turnstile keys.	[PLATFORM PROVIDER] calls the Cloudflare API to purge cached landing pages on Customer's behalf and to verify Turnstile tokens, which transmits the visitor's IP address to Cloudflare. This is separate from Cloudflare's role as a mandatory reverse proxy for attendee traffic, which is a [PLATFORM PROVIDER] sub-processor relationship — see sub-processor 8.
Ad Platforms	Meta and TikTok (Customer's own ad accounts). Google Ads and LinkedIn are configured for in the data model but no integration is implemented.	Customer has their own terms with each ad platform. Customer provides Pixel IDs and ad account identifiers.	[PLATFORM PROVIDER] injects the Customer's Meta and TikTok pixels into public pages and sends server-side conversion events to Customer's ad accounts using Customer's credentials. No event is sent to Google Ads or LinkedIn.
Transactional SMS	SendSMS.ro (Customer's own SendSMS account)	Customer holds its own contract and DPA with SendSMS.ro. Customer provides the SendSMS username, API key and sender identifier via Settings → Integrations → SendSMS.	[PLATFORM PROVIDER] calls the SendSMS API on Customer's behalf to send webinar reminder, "starting now", replay and automation messages, and records delivery status returned by the provider. The recipient's telephone number is read from Firestore at send time and transmitted in plaintext.

Important: For customer-provided integrations, [PLATFORM PROVIDER]'s obligation is to (a) use Customer's credentials only for the stated integration purpose, (b) store credentials securely in Google Secret Manager, and (c) delete credentials upon service termination. All other GDPR compliance obligations for these third-party services are Customer's responsibility.

Anthropic PBC is not a customer-provided integration. AI generation runs on a single platform-level credential held by [PLATFORM PROVIDER], with no per-organisation credential and no per-organisation switch; Anthropic is listed as sub-processor 11 above.

---

Sub-Processors NOT Used (Common Questions)

To clarify, [PLATFORM PROVIDER] does NOT use the following common sub-processors. Two entries are retained in this table because they are frequently asked about, but they are not exclusions: Cloudflare is a sub-processor (row 8 and Section 8), and Google Tag Manager is a container provided by Google LLC, which is already listed.

Service	Why Not Used
AWS (Amazon Web Services)	We use Google Cloud and Railway instead
Mailchimp / SendGrid	We use Newsman (EU-based email provider)
Stripe / PayPal	No payment processing (SaaS billing handled separately, not in event platform scope)
Segment / Mixpanel	No third-party analytics (we built custom analytics)
Intercom / Zendesk	No live chat support (email support only)
Cloudflare	A sub-processor, not an excluded vendor — see row 8 above. Cloudflare is a mandatory reverse proxy in front of attendee traffic in production and is additionally used for Turnstile bot protection; only the CDN cache-purge function depends on a Customer enabling the integration.
Google Tag Manager (GTM)	Not a separate sub-processor — GTM is a tag management container provided by Google LLC (already listed as sub-processor #1 and #5). GTM is loaded as a "necessary" technology because the container itself does not collect personal data or set cookies. It is one optional delivery path among several: the Meta Pixel, the TikTok Pixel and the Microsoft Clarity tag are injected by the platform directly from the organisation's integration configuration, outside any GTM container. The Google Consent Mode v2 defaults the platform emits (deny-by-default for analytics_storage, ad_storage, ad_user_data and ad_personalization) are emitted only alongside a GTM container and govern only the tags inside it; they have never governed the directly injected pixels. The Meta and TikTok pixels are classified as necessary scripts and fire a page view before any consent decision — see Section 4. No LinkedIn Insight Tag is emitted by any path.
MaxMind (GeoLite2 database)	Not a data processor — no attendee data is sent to MaxMind. MaxMind provides the GeoLite2-City .mmdb database file which is downloaded once at Go API startup (using HTTP Basic authentication with our MaxMind account ID and licence key) and stored locally. All IP-to-location lookups happen in-process with no outbound network calls per request. MaxMind never receives any attendee IP addresses or registration data. Their only contact with us is the initial database file download (which transmits our MaxMind account ID and licence key but no personal data). MaxMind is therefore a software/data vendor, not a sub-processor under GDPR Art. 28.

Cloudflare Note: Cloudflare is a sub-processor (row 8 and Section 8), not a conditional one. It is a mandatory reverse proxy in front of attendee traffic in production and therefore 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. Turnstile bot protection additionally transmits the visitor's IP address to Cloudflare and loads its widget script before any consent decision. Only the CDN cache-purge function depends on a Customer enabling the integration (Settings → Integrations → Cloudflare CDN). Cloudflare DPA available at https://www.cloudflare.com/cloudflare-customer-dpa/.

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

This table previously listed Google Tag Manager as the delivery mechanism for the Google Analytics, Meta, TikTok and LinkedIn tags, and stated that those tags fire only where the attendee grants consent through the cookie banner. The Meta Pixel, the TikTok Pixel and the Microsoft Clarity tag are injected by the platform directly from the organisation's integration configuration and never pass through a container, the Meta and TikTok pixels are classified as necessary and fire before any consent decision, and no LinkedIn Insight Tag is emitted at all. This divergence is recorded on the compliance remediation register and is under review.

---

Notification Process for New Sub-Processors

Step 1: [PLATFORM PROVIDER] Decision to Add Sub-Processor

• Engineering team identifies need (e.g., new email provider, analytics tool)
• CTO reviews vendor's GDPR compliance (DPA, security certifications, location)

Step 2: 30-Day Advance Notice to All Customers

• Email: Sent to registered contact email (stored in orgs/{orgId} Firestore doc)
• Updated List: This Annex III updated and published on the documentation site
• ⚠️ No dashboard announcement surface exists. The dashboard has no notifications screen and no banner mechanism, so notice depends on the email above and on the publication of this Annex.

Email Template:

Subject: Notice of New Sub-Processor — [Vendor Name]

Dear [Customer Name],

[PLATFORM PROVIDER] intends to engage [Vendor Name] as a new sub-processor to provide [service description].

Details:
- Sub-Processor: [Vendor Name], [Location]
- Service: [Brief description]
- Data Processed: [Data categories]
- Safeguards: [DPA, SCCs, certifications]
- Effective Date: [Date, 30 days from today]

You have the right to object to this sub-processor on reasonable data protection grounds.
To object, reply to this email within 30 days.

If we do not receive an objection, the sub-processor will be deemed accepted.

Updated Sub-Processor List: [URL to this Annex]

Questions? Contact [email protected]

Step 3: Customer Objection Handling (if applicable)

• If Customer objects within 30 days, [PLATFORM PROVIDER] shall:
  • Attempt to find alternative sub-processor
  • If not commercially reasonable, offer Customer option to terminate Services (60 days' notice, no penalty)

Step 4: Activation

• If no objections within 30 days, [PLATFORM PROVIDER] proceeds with sub-processor
• DPA signed with sub-processor before processing any data
• Sub-processor added to this list (published version)

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

This Annex states that Customers receive thirty days' advance notice of any new sub-processor and that a DPA is signed with a sub-processor before it processes any data. Four changes reached production without that process being run: Anthropic PBC and SendSMS.ro began processing before either was entered in this Annex; the TikTok server-side Events API transfer began on 8 May 2026; and Cloudflare's role changed materially when it became a mandatory in-path proxy for attendee traffic. No advance notice period ran for any of them, and the DPAs marked as outstanding in the table above remain unexecuted. This divergence is recorded on the compliance remediation register and is under review.

---

Customer Audit Rights

Customers may audit sub-processors' compliance with GDPR through [PLATFORM PROVIDER]:

Direct Audit (Not Permitted): Customers may NOT directly audit sub-processors (e.g., visit Google data centers). This would violate sub-processors' security and confidentiality.

Indirect Audit (Via [PLATFORM PROVIDER]):

1. Customer requests sub-processor audit (Section 11 of DPA)
2. [PLATFORM PROVIDER] provides:
   • Copy of sub-processor's DPA (redacted for commercial terms)
   • Sub-processor's security certifications (SOC 2, ISO 27001)
   • Sub-processor's most recent audit report (if publicly available or shareable)
   • [PLATFORM PROVIDER]'s own assessment of sub-processor compliance (annual vendor review)

Third-Party Audit Reports:

• Google Cloud: SOC 2 Type II report available to GCP customers (request via Google Cloud Console)
• Railway: SOC 2 Type II (request from Railway sales)
• Meta: Public transparency reports available
• TikTok, Anthropic PBC, SendSMS.ro: ⚠️ No audit report or certification has been obtained; see the outstanding actions in the table above

---

Sub-Processor Exit Plan

If a sub-processor is removed or replaced:

Reason for Exit:

• End of service contract
• Sub-processor breach of DPA
• Customer objection (no alternative available, service terminated)
• Regulatory prohibition (e.g., supervisory authority orders data transfer suspension)

Migration Process:

1. Identify replacement (if needed) with equivalent GDPR safeguards
2. Notify customers (30 days in advance if replacement, immediate if emergency)
3. Migrate data to replacement sub-processor (encrypted transfer)
4. Instruct old sub-processor to delete all Customer data (per sub-processor DPA termination clause)
5. Obtain deletion certificate from old sub-processor (written confirmation)
6. Update this Annex III (remove old, add new sub-processor)

Example: If Railway violates DPA, [PLATFORM PROVIDER] would migrate PostgreSQL to alternative EU host (Render, Fly.io, Hetzner) within 60 days.

---

Document Control

Version: 1.0 (DRAFT) Last Updated: [DATE] Next Review: Quarterly (or when adding sub-processor) Owner: CTO, [PLATFORM PROVIDER] Published Location: Documentation site, path /legal/platform/annex-sub-processors

Action Items for Legal Team:

• [ ] Request Railway DPA (https://railway.app/legal or contact support)
• [ ] Request Newsman DPA (contact Newsman support, request sub-processor list)
• [ ] Confirm Google Cloud DPA is auto-applied (check Google Cloud Console → Legal)
• [ ] Confirm Meta Business Tools Terms accepted in Facebook Business Manager
• [ ] Request TikTok DPA and SCCs (integration is live — see Section 5-7)
• [ ] Execute Anthropic Commercial Terms and DPA, and confirm the transfer mechanism for personal data sent to the USA (see Section 11)
• [ ] Execute a DPA with SendSMS.ro and confirm its contracting entity and registered address (see Section 10)
• [ ] Confirm the Cloudflare Customer DPA covers the reverse-proxy and Turnstile roles, not only CDN caching (see Section 8)
• [ ] Issue the DPA Section 5.3 notice retrospectively for Anthropic PBC and SendSMS.ro, the TikTok server-side transfer and the Cloudflare scope change
• [ ] Reconcile the derived lists in the Record of Processing Activities and in Annex I to the Standard Contractual Clauses with the eleven sub-processors listed here
• [ ] Set up automated email notification system for sub-processor changes (integrate with dashboard)

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

---

End of Annex III