Data Protection Impact Assessment (DPIA)

[PLATFORM PROVIDER] — Event Platform Processing ActivitiesGDPR Article 35Last Updated: [DATE]

1. Introduction and Scope

1.1 Purpose

This Data Protection Impact Assessment (DPIA) evaluates the privacy risks associated with [PLATFORM PROVIDER]'s event platform processing activities and documents the measures taken to mitigate those risks, as required by GDPR Article 35.

1.2 Why a DPIA Is Required

GDPR Article 35(1) requires a DPIA when processing is "likely to result in a high risk to the rights and freedoms of natural persons." A DPIA is specifically required (per Article 35(3) and EDPB Guidelines 09/2022) for:

Systematic monitoring — behavioral tracking of attendees (chat, polls, offers, attendance patterns)
Large-scale processing — processing attendee data across multiple customer organizations at scale
Profiling — lead scoring and engagement scoring based on attendee behavior

[PLATFORM PROVIDER]'s processing meets all three criteria.

1.3 Scope of This DPIA

This DPIA covers processing performed by [PLATFORM PROVIDER] as Data Processor on behalf of Customer organizations (Data Controllers). It assesses risks from [PLATFORM PROVIDER]'s perspective as the platform provider.

Two of the processing operations assessed below are not, in their current implementation, determined by the Customer. AI-assisted content generation runs on a single platform-wide credential held by [PLATFORM PROVIDER], with the vendor, the models and the retention of prompts and outputs chosen by [PLATFORM PROVIDER] and no per-organisation switch. The server-side ad conversion transfers are executed by [PLATFORM PROVIDER]'s code on the legitimate-interest assessment set out in Section 3.3 of this document rather than in the Customer's own assessment. Both are treated as in scope below. The controller/processor characterisation of those two operations, and the records and notices that follow from it, are under review.

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

This DPIA, in common with the wider legal corpus, models [PLATFORM PROVIDER] exclusively as a processor acting on Customer instructions. For AI-assisted content generation and for server-side ad conversion measurement, [PLATFORM PROVIDER] in fact determines the vendor, the purpose and the legal basis, and the Customer has no means of instructing, objecting to or disabling either. No Article 30(1) record and no Article 13/14 notice exists for [PLATFORM PROVIDER] in a controller capacity for that processing. This divergence is recorded on the compliance remediation register; the classification is under review.

In scope:

Attendee registration data collection
Behavioral tracking (chat, polls, offers, attendance)
Automated moderation of attendee chat messages (banned-word masking and shadow removal)
Push notification delivery (transactional and marketing)
Email marketing delivery
Transactional segment broadcasts sent outside the marketing-consent gate
SMS notification delivery
Lead qualification and engagement scoring
Ad platform conversion tracking (server-side and client-side)
Landing-page visitor measurement (funnel page views and the server-side Meta PageView)
Video streaming to attendees through a third-party embedded player
AI-assisted content generation
GDPR data subject rights automation
Mobile app authentication and device token storage

Out of scope:

Customer-specific use of the platform (each customer should conduct their own controller-level DPIA where required)
Per-organisation credentialed integrations, to the extent the Customer configures and contracts for them directly: the Customer's own NewsmanApp SRL account, per-org Firebase, the Customer's own SendSMS.ro account and the Customer's own ad-platform accounts

Cloudflare, Inc. is not out of scope. It is a mandatory reverse proxy in front of attendee traffic in production: it terminates TLS for and sees every attendee request, including registration submissions carrying plaintext email address, name and telephone number, and for that traffic the platform takes the client IP address it records or forwards from a Cloudflare-supplied header, which its IP-extraction helper checks before any other proxy header. Cloudflare Turnstile is additionally injected into published landing pages outside the consent bundle, and server-side verification transmits the visitor's IP address to Cloudflare. A platform-level NewsmanApp SRL account also exists alongside the per-organisation accounts. Anthropic PBC is engaged on a single platform-wide credential and is not a customer-provided integration at all. The server-side conversion transfers are performed by [PLATFORM PROVIDER]'s own code and cannot be disclaimed as customer-provided integrations.

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

Earlier versions of this DPIA placed Cloudflare, Newsman and the ad platforms wholly out of scope as customer-provided integrations for which the Customer was responsible. Cloudflare is now a mandatory in-path proxy for attendee domains, a platform-level Newsman account exists in addition to the per-organisation ones, and the server-side ad transfers are performed by [PLATFORM PROVIDER]'s code under the assessment in Section 3.3. This divergence is recorded on the compliance remediation register and is under review.

2. Description of Processing

2.1 Nature of Processing

Dimension	Description
Collection method	Web registration forms, mobile app onboarding, real-time behavioral events during events, server-side conversion events at registration
Storage	Firestore (contact PII, configuration), PostgreSQL (marketing and behavioural analytics, keyed by email hash save for the exceptions recorded in Section 3.4), Firebase Realtime Database (live session real-time data), Firebase Cloud Storage (organisation media library, branding assets, page templates and landing-page files), and an in-process cache of plaintext contact details held by the API
Use	Event delivery, lead qualification, email/push/SMS messaging, transactional segment broadcasts, ad conversion tracking, landing-page visitor measurement, automated chat moderation, AI-assisted content generation, analytics
Access	The Customer organisation's staff users, in the four roles the platform defines — `admin`, `moderator`, `marketer` and `staff`; [PLATFORM PROVIDER]'s platform infrastructure (automated); no [PLATFORM PROVIDER] staff access to attendee PII in normal operations
Disclosure	[PLATFORM PROVIDER] engages eleven sub-processors, listed in Annex III (annex-sub-processors.md). Those receiving attendee personal data in normal operation are Google LLC, Railway Corp., NewsmanApp SRL, Cloudflare, Inc., Meta Platforms, Inc., TikTok Pte. Ltd., Microsoft Corporation, SendSMS.ro and Anthropic PBC. "Hashed data only" is not accurate: Meta and TikTok receive the visitor's raw IP address and raw user agent alongside SHA-256 hashes of email address, telephone number and name. The attendee watch page additionally embeds video from a third-party player, from the attendee's browser and outside the consent bundle
Retention	Varies by data type — see ROPA and Data Retention Policy (data-retention-policy.md). Live-session data in the Realtime Database, the audit log and the data-subject request register are subject to no automated deletion; see Section 4.2 R10 and R11
Deletion	GDPR deletion pipeline (incomplete — see Section 4.2 R8); sub-processor cascade deletion

2.2 Purpose of Processing

See ROPA (ropa.md) for full purpose register. Key purposes:

Event access and delivery (contract performance)
Behavioral tracking for lead qualification (consent)
Email marketing (consent) — email_marketing gates exactly one thing: whether the contact is synchronised into the marketing email provider's list and segments. Every other email path — registration confirmation, reminders, "starting now", replay, automation email, resend and segment broadcast — runs on the transactional gate alone
Push notification delivery — transactional only (consent). Every push send requires a granted, unrevoked push_notifications consent record, checked at send time; marketing push is not implemented
SMS communications (consent — a granted, unrevoked sms_notifications consent record). WhatsApp messaging is not implemented: whatsapp_notifications and whatsapp_marketing are accepted and displayed as consent purposes but gate no send path
Ad conversion tracking — server-side (legitimate interest, Art 6(1)(f); see Section 3.3) and client-side pixels (see Section 3.1)
Security, fraud prevention, abuse detection (legitimate interest)
Automated moderation of attendee chat messages (legitimate interest, determined by the Customer)
Transactional segment broadcasts to segment members, sent irrespective of marketing consent (see Section 3.1)
Landing-page visitor measurement, applying to every visitor rather than only to registrants (see Sections 3.3 and 3.4)
AI-assisted generation of landing pages, marketing copy and poll questions (see Section 1.3 and Section 4.2 R15)

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

Earlier versions of this DPIA recorded transactional push as resting on legitimate interest and marketing push as an implemented purpose, listed WhatsApp as a live communications channel, and recorded ad conversion tracking as gated by the advertising category of the cookie banner. Transactional push in fact requires a granted push_notifications consent, marketing push and WhatsApp messaging have no send path, and no advertising-consent gate exists on either the server-side conversion events or the client-side pixels. This divergence is recorded on the compliance remediation register and is under review.

2.3 Data Subjects

Event attendees (B2C individuals who register for customer-hosted events)
The Customer organisation's own staff users, whose account data, IP address and user agent are processed and retained in the audit log
Typically not vulnerable populations. A minimum age of 16 is stated in the Customer's Terms of Service and self-declared by acceptance of those terms; it is not technically enforced. No age, date of birth or age-confirmation field is collected on any registration path, so a person under 16 can register undetected. Where that occurs, the consent-based purposes above may not be validly grounded for that registrant (Art 8).

2.4 Data Categories

See DPA Section 2.6 (Types of Personal Data) and the ROPA Processing Activity records for the full data inventory. Key categories:

Category	Sensitivity	Examples
Registration data	Low-medium	Email, name, phone
Behavioral data	Medium	Chat messages, poll votes, offer clicks
Technical data	Low	Device type, country, FCM token (pseudonymous)
Attribution data	Medium	Ad click IDs, UTM parameters
Consent records	Low	Consent timestamps and purposes
Push delivery data	Low	FCM message ID, send status (linked to email_hash)
Visitor identifiers	Medium	A persistent SHA-256 hash of the visitor's IP address and user agent, recorded for every non-bot visitor to every funnel landing page
Device and environment data	Low-medium	Device type, operating system, browser, timezone, country, city, landing URL and referrer URL, recorded per contact on funnel entry
Purchase and order data	Medium	Order identifier, order total, currency and payment status, received by webhook from the Customer's e-commerce store and linked to an identified contact
Third-party webhook payloads	Medium	The full raw body of third-party form and webhook submissions, retained as funnel-entry metadata
Moderation data	Medium	The original full text of a chat message removed by automated moderation, the author's actor data and the removal reason
Suppression labels	Low	A derived per-contact email suppression reason produced by the email-provider synchronisation, for example a bounce or spam-complaint label
SMS delivery records	Low-medium	Email hash, webinar and session, template type, tracking code, provider message identifier, delivery status, delivery and click timestamps
AI prompt and output data	Medium	System and user prompts, staff instructions, model outputs and token counts — including approved attendee testimonials (display name, quote, company, rating) embedded in the prompt — together with staff-uploaded reference images
Staff audit data	Low-medium	Acting staff user identifier, IP address and user agent, recorded on every audited write
Cloud Storage objects	Medium	Organisation media library, branding assets, page templates, offer and webinar imagery and landing-page files, which may depict identifiable individuals

No special categories of data (GDPR Article 9) are intentionally collected. Free-text fields that attendees control — chat messages, testimonials, feedback responses and third-party webhook payloads — may nevertheless contain special-category data volunteered by the data subject; no screening for special-category content is performed on those fields.

3. Necessity and Proportionality

3.1 Legal Bases

All processing purposes have identified legal bases (see the ROPA Processing Activity records). Key assessments:

Processing	Legal Basis	Proportionate?
Registration collection	Contract performance (Art 6(1)(b))	Yes — minimum data for service delivery
Behavioral tracking	Consent (Art 6(1)(a))	Qualified — the consent captured is bundled, partly inferred and organisation-wide; see the note on consent mechanics below this table
Transactional email	Legitimate interest (Art 6(1)(f))	Yes — necessary for service; balancing test below
Transactional push and SMS	Consent (Art 6(1)(a))	Yes — a granted, unrevoked `push_notifications` or `sms_notifications` record is required at send time
Marketing email	Consent (Art 6(1)(a))	Qualified — explicit opt-in gates the marketing-provider synchronisation only; marketing push and SMS marketing gate nothing, because neither send path exists
Ad conversion tracking — client-side (pixels)	⚠️ Not established	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.
Ad conversion tracking — server-side (CAPI)	Legitimate interest (Art 6(1)(f))	Qualified — hashed identifiers are transmitted together with the raw IP address and raw user agent; balancing test below
Landing-page visitor measurement	Legitimate interest (Art 6(1)(f))	Qualified — applies to every visitor, including persons with no prior relationship who never register; balancing test in Section 3.3
Lead scoring	Consent (Art 6(1)(a))	Yes — gated behind behavioral_tracking consent
Transactional segment broadcast	⚠️ Determined by the Customer; not established in [PLATFORM PROVIDER]'s records	No — the send is not gated on marketing consent; see the note on staff-operated bypass lanes below this table
Automated chat moderation	Legitimate interest (Art 6(1)(f)), determined by the Customer	Qualified — the data subject is not notified; see Section 4.2 R14
AI-assisted content generation	Legitimate interest (Art 6(1)(f))	Qualified — approved attendee testimonials are transmitted to a provider in the USA without notice or a consent gate; see Section 4.2 R15
Security/fraud prevention	Legitimate interest (Art 6(1)(f))	Yes — essential; minimal data used

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.

Note on consent mechanics. The consent recorded by the platform is not granular in the sense the earlier table implied.

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.

Consents are organisation-scoped rather than event-scoped: a single grant covers every subsequent event within that organisation for as long as it is not revoked. There are exactly ten valid consent purposes — data_processing, tos_acceptance, email_marketing, push_notifications, push_marketing, behavioral_tracking, whatsapp_notifications, whatsapp_marketing, sms_notifications and sms_marketing — of which whatsapp_notifications, whatsapp_marketing, push_marketing and sms_marketing are accepted and displayed but gate nothing, and data_processing and tos_acceptance cannot be withdrawn through the preferences page. The consent policy version in force is "1.0". The cookie banner's outcome is a separate vocabulary and is stored only in a first-party cookie on the visitor's device (rx_cookie_consent, 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.

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

This DPIA previously recorded behavioural-tracking consent as opt-in, granular and revocable, and treated that characterisation as the proportionality justification for the processing. The consent actually captured is bundled with the terms of service, inferred from the entry of a telephone number, organisation-wide rather than event-scoped, manufactured by the bulk importer for contacts who never used the platform, and recorded only as a grant, so a refusal and an absence of any decision are indistinguishable in the ledger. This divergence is recorded on the compliance remediation register; the classification is under review.

Note on staff-operated bypass lanes. Three shipped features allow the Customer's staff to reach contacts who hold no marketing consent. First, the transactional segment broadcast sends a staff-composed subject, body and call to action to every member of a segment, filtered only on the Article 18 processing restriction and on the email-suppression flag, with no marketing-consent predicate. Second, a lacks_consent segment condition builds a segment of exactly those contacts who hold no active grant for a given purpose. Third, the segment export returns plaintext email addresses and names with no marketing-consent gate, and an optional parameter additionally returns contacts that have bounced, complained of spam or globally opted out; contacts who have unsubscribed are always present in the default export, because unsubscribing revokes marketing consent without setting the suppression flag.

All three are authorised by the marketing permission group, which the non-administrator marketer role holds. 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. Each of the three actions is written to the audit log, but none is prevented by the platform. Whether a given broadcast is a service message or direct marketing, and therefore whether Article 13 of the ePrivacy Directive and article 12 of Legea 506/2004 are engaged, is determined by the Customer as controller on each send.

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

This DPIA previously recorded marketing communications as resting throughout on explicit opt-in consent. The platform provides staff with three lanes that reach contacts holding no marketing consent — a segment broadcast that is filtered only on processing restriction and email suppression, a segment condition that selects precisely the contacts lacking a grant, and a plaintext contact export with no consent gate — and none is blocked by the platform. This divergence is recorded on the compliance remediation register and is under review.

3.2 Legitimate Interest Balancing Test (Transactional Communications)

Interest pursued: Delivering the event service the Data Subject registered for (reminders, "starting now", replay availability).

Necessity: Without transactional communications, attendees may miss events they signed up for; service delivery would be materially impaired.

Balancing: Data Subjects reasonably expect to receive reminders and updates for services they registered for. Processing is limited to what is necessary (no behavioral profiling, no third-party sharing). Data Subjects can opt out of transactional push via OS settings at any time.

Scope of this test: This balancing test covers transactional email only. Transactional push notifications and transactional SMS messages are not sent on legitimate interest: each requires a granted, unrevoked push_notifications or sms_notifications consent record, verified against the consent ledger at send time. Transactional SMS messages additionally involve a transfer to SendSMS.ro; see Section 4.2 R17.

Conclusion: Legitimate interest basis is justified for transactional email.

3.3 Legitimate Interest Balancing Test (Server-Side Ad Conversion Tracking)

Interest pursued: Measuring ad campaign effectiveness by sending registration events to ad platforms server-to-server, so the organization can optimize marketing spend and reduce wasted ad budget. Two server-side integrations exist: the Meta Conversions API and the TikTok Events API, the latter active since 8 May 2026. There is no Google Ads and no LinkedIn server-side integration: both exist only as inert configuration structures, and Google Ads Enhanced Conversions and the LinkedIn Conversions API are not implemented.

Necessity: Without server-side conversion data, ad platforms cannot attribute registrations to specific campaigns, leading to degraded ad targeting, higher cost-per-lead, and inability to measure return on ad spend. Client-side tracking alone is unreliable due to ad blockers and browser restrictions (ITP, ETP). Server-side conversion tracking is the industry-standard solution recommended by all major ad platforms.

Balancing:

Data minimization — partial: SHA-256 hashes of the email address, first name and last name are sent to both platforms, and TikTok additionally receives a hashed external identifier derived from the registration; Meta receives that same identifier unhashed. 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 raw client IP address and the raw user agent are transmitted alongside those hashes to both platforms; Meta additionally receives the registration event identifier unhashed and the _fbp and _fbc cookie values where present, and TikTok additionally receives the raw ttclid click identifier and the raw _ttp cookie value. The statement that raw personal data is never transmitted is therefore not accurate: an IP address is personal data, and it is sent unhashed.
Browser access — the page-view path does read the device: the registration event is a server-to-server call that neither writes nor reads cookies on the Data Subject's device. That is not true of the page-view path assessed separately below, where an inline script on every rendered landing page reads the _fbp and _fbc cookies from the browser before the values are forwarded to Meta. Reading information already stored on a subscriber's terminal equipment falls within Article 5(3) of the ePrivacy Directive irrespective of where the onward transfer originates, so no general ePrivacy carve-out can be claimed for this processing as a whole.
Limited purpose: Data is used solely for conversion attribution and campaign optimization, not for building independent user profiles.
Retention by platforms: Ad platforms retain hashed data for 7–28 days for matching, then delete.
Reasonable expectation: A person who clicks an ad and registers for an event reasonably expects the advertiser to measure whether the ad led to the registration. This argument is available for the registration event only; it does not carry the page-view transfer assessed below.
GDPR processing restriction honored: 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.
No consent gate: There is no advertising-consent gate on the server-side path. The only condition, apart from the Article 18 restriction, is that the Customer has enabled the integration.
Opt-out available: Data Subjects can object to this processing under Art 21 via the DSAR process.

Conclusion: Legitimate interest is capable of supporting the registration-event transfer, subject to the qualification that the transfer is not limited to pseudonymised data: the Data Subject's IP address and user agent are transmitted in the clear. The claim in earlier versions of this DPIA that the processing "uses only pseudonymized data" is withdrawn.

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

This DPIA previously recorded that only hashed email and name are transmitted to the ad platforms, that raw personal data is never sent, and that server-side conversion tracking sits outside the scope of the ePrivacy Directive because it neither places nor reads cookies. Raw IP addresses and raw user agents are transmitted to Meta and TikTok on every event, TikTok additionally receives a raw click identifier and a raw cookie value, and the landing-page beacon reads the _fbp and _fbc cookies from the visitor's browser before forwarding them. It also named a Google Ads and a LinkedIn server-side integration, neither of which exists. This divergence is recorded on the compliance remediation register and is under review.

Separate assessment — the all-visitor landing-page transfer. The test above was written for a person who clicked an advertisement and completed a registration. It does not carry the page-view transfer, which must be assessed on its own terms.

Interest pursued: Measuring landing-page reach so the organisation can attribute campaign traffic and optimise spend, including where the browser pixel is blocked.

Nature of the processing: Every rendered funnel landing page carries an inline script that generates a per-request event identifier, reads the _fbp and _fbc cookies from the visitor's browser, reads any fbclid from the query string, and requests a one-pixel image from the platform. The platform records the view against a persistent visitor identifier derived from the IP address and user agent, and — where the Customer has enabled the Meta integration — sends a Meta Conversions API PageView carrying the visitor's raw IP address, raw user agent, page URL, the click identifier and the cookie values. Where the cookie is absent, which is the position for a visitor who has not accepted advertising cookies, a click-derived value is synthesised in its place. The only condition on the transfer is that the Customer has enabled the Meta integration; there is no consent check on this path. Server-side page views are not mirrored to TikTok.

Categories of data: Raw IP address, raw user agent, page URL, referrer, click identifier and advertising cookie values, together with a persistent hash of the IP address and user agent retained by the platform.

Data subjects: Every human visitor to a funnel landing page, including persons who have no relationship with the Customer, who never register, and who arrived from a source other than an advertisement.

Balancing: The reasonable-expectation argument that supports the registration event is not available here. A person who merely loads a page has not initiated any relationship with the advertiser and has no basis to expect that the visit, their IP address and their user agent will be transmitted to a third-country advertising platform. The processing is not necessary for the delivery of any service to that person. The Article 18 restriction and the Article 21 objection route both operate on an identified contact record and therefore give the unidentified visitor no practical remedy. Nothing in the interface discloses the transfer at the moment it occurs.

Conclusion: ⚠️ Not established. The legitimate-interest basis relied on for the registration event does not, on this assessment, extend to the all-visitor page-view transfer, and the reading of the _fbp and _fbc cookies engages Article 5(3) of the ePrivacy Directive independently of the Article 6 analysis. The position must be determined by the controller.

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

This DPIA previously assessed server-side ad conversion tracking as a single activity performed on registrants who had clicked an advertisement. A server-side page-view transfer additionally fires for every human visitor to a funnel landing page, with no registration, no prior relationship and no consent check, carrying the visitor's raw IP address and user agent to Meta. No balancing test had been recorded for it and its lawfulness is not established. This divergence is recorded on the compliance remediation register and is under review.

3.4 Data Minimization

Measure	Implementation
IP address — not minimised	A geo-lookup at registration derives and stores only the country and city, as previously described. Beyond that path, a persistent SHA-256 hash of the visitor's IP address and user agent is written to the funnel page-view table for every non-bot visitor to every funnel landing page, with no consent gate; that table is not among the data types the retention job recognises, so those records are retained indefinitely. The audit log stores the acting staff user's raw IP address and user agent on every audited write and is likewise not reached by the retention job. Raw IP addresses are transmitted to Meta and TikTok on every conversion and page-view event. 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.
User-Agent — not minimised	The user agent forms part of the persistent visitor identifier described above, is stored raw and indefinitely in the audit log, and is transmitted raw to Meta and TikTok.
FCM tokens pseudonymized	Keyed by email_hash, not plaintext email
Behavioral data consent-gated — narrower than described	Granular behavioural event rows are not written to the analytics database without `behavioral_tracking` consent, and that gate is applied by each behavioural Cloud Function. It reaches no further. 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. The live-session write and the attendance synchronisation rest on contract performance. The service ingest endpoint does not independently re-verify the gate; it trusts the calling function to have applied it.
Ad conversion data hashed — in part	SHA-256 hashes of email address and name are sent to Meta and TikTok, and no telephone number is sent at all; the raw IP address and raw user agent are sent alongside them, Meta additionally receives the registration identifier unhashed, and TikTok additionally receives the raw click identifier and the raw `_ttp` cookie value
Push delivery linked to email_hash	push_sends table uses email_hash, not email
PostgreSQL keyed by email hash — subject to the exceptions noted	See the note on pseudonymisation below this table
Consent evidence held at the email provider is not authoritative	On server-side re-subscription the platform transmits a placeholder opt-in IP address (`0.0.0.0`) to the email provider, because no real IP address is available in a server-side synchronisation. The provider's subscriber record therefore asserts an origin that is not the data subject's. The authoritative Article 7(1) record of consent is the platform's own consent-event ledger, not the provider's subscriber record, and it is the ledger that must be produced as evidence of an opt-in.

Note on 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.

A further limitation applies to the hash itself. The email hash is an unsalted SHA-256 of the lowercased, trimmed email address, so anyone who knows a target's email address can compute the identifier under which that person's records are held.

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

This DPIA previously recorded that IP addresses are not stored, that user agents are stored only where marketing attribution requires it, and that the PostgreSQL database holds no plaintext contact details. A persistent identifier derived from the IP address and user agent is in fact stored indefinitely for every landing-page visitor, raw IP addresses and user agents are stored indefinitely in the audit log and transmitted to Meta and TikTok, and the automations engine writes plaintext email addresses and telephone numbers into PostgreSQL. This divergence is recorded on the compliance remediation register and is under review.

4. Risk Identification

4.1 Risk Register

#	Risk	Likelihood	Severity	Inherent Risk
R1	Unauthorized access to attendee PII (data breach)	Low	High	Medium
R2	Cross-org data leak (tenant checks absent outside PostgreSQL)	High	Critical	High
R3	Excessive profiling beyond disclosed purposes	Low	High	Medium
R4	Behavioral tracking without valid consent	Low	Medium	Low-Medium
R5	Ad platform receives identifiable data (raw IP address and user agent transmitted alongside the hashes; CJEU hash adequacy)	High	High	High
R6	Mobile app token theft (Keychain/EncryptedSharedPreferences compromise)	Very Low	Medium	Low
R7	Push notification consent not honored (revocation not applied at send time)	Low	Medium	Low-Medium
R8	GDPR deletion pipeline failure (documented incomplete erasure)	High	High	High
R9	Sub-processor breach (nine recipients of attendee data; agreements outstanding with four)	Low	High	Medium
R10	Behavioral data retention beyond customer relationship	High	Medium	Medium-High
R11	Indefinite retention of live-session content (chat text, attendee display names, presence, votes), readable by any authenticated user	High	High	High
R12	Third-party loading on landing pages and the attendee watch page before, or irrespective of, the consent decision, with the consent controls removed from the watch page	High	Medium	Medium-High
R13	Staff-operated bypass of the marketing-consent gate and bulk export of plaintext contact details	Medium	High	High
R14	Automated moderation of attendee chat content without notification to the data subject	Medium	Medium	Medium
R15	Transfer of attendee testimonials to an AI provider in the USA without notice, consent gate or erasure reach	Medium	Medium	Medium
R16	Attendees shown a fabricated participant count	Medium	Medium	Medium
R17	Personal data and credentials recorded in provider request logs and application logs on the SMS path	High	Medium	Medium-High
R18	Weaknesses in the attendee and mobile sign-in path (four-digit one-time code, standing store-review demo credential)	Medium	High	High

4.2 Risk Detail

R1 — Unauthorized access to PII: Attackers targeting Firestore or PostgreSQL to extract attendee email addresses and names.

Mitigations: Firebase security rules, PostgreSQL Row Level Security, API authentication (Firebase JWT), Railway private networking, encryption at rest.
Qualification: the Firebase security rules are a partial control only. As recorded under R2, the Firestore rule governing contact PII documents admits any authenticated principal, registration documents are readable without authentication, the Realtime Database rules authorise on the role claim alone, and the Cloud Storage rules grant unconditional public read on every organisation path. The extraction this risk contemplates does not, for those stores, require an attacker to defeat a control.

R2 — Cross-org data leak: One customer's data being visible to another. Tenant isolation is enforced in PostgreSQL. It is not enforced in the Realtime Database, in the Firestore rules governing contact PII and registration documents, or in Cloud Storage.

Mitigation in place — 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.
Residual limits of the PostgreSQL control. 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, but 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 — there is accordingly no application-level Row Level Security bypass in use. The dedicated database role is provisioned outside the migration set, so the control cannot be reproduced or verified from the repository alone.
Control absent — 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. Session identifiers are served by an unauthenticated public endpoint.
Control absent — Firestore contact PII and registration documents. 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 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.
Control absent — 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.
Correction to a previously stated mitigation. It is not the case that all API routes require the AuthRequired() middleware. Two route groups carry it; the public registration, tracking, share and configuration routes are unauthenticated by design.

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

This DPIA previously described cross-organisation isolation as resting on four layers — an organisation column on every table, Row Level Security, authentication middleware on all API routes, and separated database users — and assessed the residual risk as very low. Three of those four are not present in the form described: the Realtime Database rules contain no organisation identifier, the Firestore rules expose contact PII to any authenticated principal and registration documents to unauthenticated callers, the Cloud Storage rules grant unconditional public read on every organisation path, and authentication middleware is applied to two route groups rather than to all routes. Organisation-level isolation in PostgreSQL, described above, is unaffected. This divergence is recorded on the compliance remediation register and is under review.

R3 — Excessive profiling: Behavioral data used for purposes beyond what was disclosed (e.g., sold to third parties, used for automated decisions without disclosure).

Mitigations: Processing purpose is documented in ROPA and Privacy Policy; no [PLATFORM PROVIDER] cross-customer profiling is performed; behavioural data in PostgreSQL is accessible only to the Customer organisation that collected it, by operation of Row Level Security.
Qualification: the access limitation holds for PostgreSQL only. As recorded under R2, live-session behavioural content in the Realtime Database carries no organisation check, so it is readable by staff-role tokens of other organisations. That is a confidentiality exposure rather than profiling, but it defeats the containment on which this mitigation was previously stated without qualification.

R4 — Behavioral tracking without valid consent: Cloud Functions record behavioral events for attendees who did not grant behavioral_tracking consent.

Mitigations: a behavioural-consent check is applied in each of the behavioural event Cloud Functions; consent is stored in Firestore and read at event time; consent records are auditable.
Scope of the mitigation: the check suppresses only the granular behavioural event rows written to the analytics database. Live-session content and the attendance synchronisation are unaffected — see Section 3.4 — and the service ingest endpoint does not independently re-verify the gate. The validity of the consent itself is qualified by the note on consent mechanics in Section 3.1.

R5 — Ad platform receives identifiable data: Data sent to Meta and TikTok allows re-identification of the Data Subject. Google Ads and LinkedIn receive no server-side data, because neither integration is implemented.

Mitigations: the directly identifying fields that are sent — email address, first name and last name — are SHA-256 hashed before transmission, and hashing is one-way; no telephone number is sent at all. The registration identifier is hashed for TikTok but transmitted to Meta unhashed. Server-side events are suppressed for contacts subject to a GDPR Article 18 processing restriction.
Limits of the mitigation: there is no advertising-consent gate on either the server-side events or the client-side pixels, and the raw IP address and raw user agent are transmitted unhashed alongside the hashes, so the transfer is not confined to pseudonymised data.
Google Consent Mode v2: the deny-by-default consent signal is implemented correctly, but it applies only to the Google Tag Manager container and only where the Customer has configured one. Where no container is configured there is no consent signal to deny by default. The Meta Pixel, the TikTok Pixel and Microsoft Clarity are injected directly by the consent bundle from the organisation's integration settings, entirely outside Google Tag Manager and outside Consent Mode. Google Fonts on AI-generated landing pages do not load from Google in the visitor's browser: the generation prompts instruct the model to emit the stylesheet link, and the public application rewrites it to the page's own domain and fetches the fonts server-side, so visitors' IP addresses and user agents do not reach Google. The platform's own Next.js applications self-host their fonts.

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

This DPIA previously recorded that server-side conversion data is sent only where cookie consent for the advertising category has been granted, that no plaintext personal data is transmitted, and that Google Tag Manager with Consent Mode v2 ensures no Google service fires without explicit consent. No advertising-consent gate exists on any conversion path, raw IP addresses and user agents are transmitted, and Consent Mode governs only the Google Tag Manager container where one is configured. This divergence is recorded on the compliance remediation register and is under review.

R6 — Mobile app token theft: Attacker extracts Firebase Auth JWT from compromised device.

Mitigations: JWT stored in iOS Keychain / Android EncryptedSharedPreferences (OS-protected); 1-hour expiry limits the window; magic-link authentication avoids password storage entirely; rate limiting is applied to the authentication endpoints.
Correction to the rate-limit figures: rate limiting is applied per IP address, or per authenticated user where one is present — never per email address. The configured limits are: send-link 10 requests per minute with a burst of 3; verify-link 10 per minute, burst 5; verify-code 10 per minute, burst 5; refresh 30 per minute, burst 5. The limiter holds its counters in process memory, so limits apply per API instance rather than across the deployment, and the client address it keys on is taken from a proxy-supplied header.
Second authentication factor not previously assessed: a four-digit numeric one-time code sent by email is available as a fallback to the magic link. The code has ten thousand possible values, is valid for ten minutes, and is invalidated after three failed attempts. Being per-account, the attempt limit is the effective control; the per-IP rate limits above are not.
See R18 for the standing store-review demo credential on the same sign-in path.

R7 — Push consent not honored: A push notification reaching a Data Subject after that person has withdrawn the relevant consent.

Mitigation in place: consent is checked server-side before every send. Each push dispatch requires a granted, unrevoked push_notifications consent record, read from the consent ledger at send time, so a withdrawal takes effect on the next send without any dependence on device-side synchronisation. Marketing push is not implemented, so the marketing-after-revocation scenario the previous version described cannot arise.
Corrections to previously stated mitigations: the silent synchronisation push is not triggered by consent revocation. It is sent on two occasions only — when an erasure request is processed and when a processing restriction is applied. Nor is an FCM token deleted on consent revocation: device tokens are removed by the erasure pipeline, by the attendee's own request from the mobile application, and by the cleanup of tokens the messaging service reports as invalid.

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

This DPIA previously recorded that a silent push is sent to the mobile application whenever consent is revoked and that the device token is deleted on explicit revocation. Neither mechanism is wired to consent revocation: the silent synchronisation fires only on erasure and on a processing restriction, and tokens are deleted only by erasure, by the attendee's own request or by invalid-token cleanup. The send-time consent check, which is the control that actually prevents the risk, was described as one mitigation among three. This divergence is recorded on the compliance remediation register and is under review.

R8 — GDPR deletion pipeline failure: Personal data surviving an erasure request. This was previously framed as the possibility of a bug leaving orphaned records; the incompleteness set out below is systematic rather than accidental, and occurs on every erasure to which it applies.

Mitigations: cascade deletes on the contacts table; explicit deletes for email_sends, push_sends, device_tokens and funnel_entries by organisation and email hash; deletion steps logged; the pipeline is executable by the Customer from the dashboard.
The description "deletion pipeline tested" is withdrawn. Automated test coverage in the API consists of five unit-test files covering email-tracking handlers, email utilities, tracked-link redirects and page-utility helpers. No automated test covers the erasure pipeline, authentication, authorisation, Row Level Security or tenant isolation, and no test simulates a cross-organisation query.
Known incompleteness of the pipeline, each item verified against the current implementation:
- 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.
- Per-actor deduplication markers and per-actor message counts in the Realtime Database are not among the nodes the per-actor cleanup removes.
- Only one actor identifier is retained per registration, so where an attendee joined from more than one device or rejoined under a new actor identifier, the chat messages, display name and votes associated with the earlier identifiers survive the erasure.
- Where a contact changes their email address through the preferences page, the erasure request is created against the previous email hash after that hash has already been updated, so the pipeline finds no matching contact, records the request as completed and deletes nothing.
- Erasure does not reach Cloud Storage: no object in the bucket is deleted by the pipeline.
- 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.
- The audit log and the data-subject request register are not among the data types the retention job recognises, and nothing else in the platform deletes from them, so both grow without limit. The audit log records the acting user's IP address and user agent, and entries created by the data-subject rights workflow record the subject's email hash in their metadata, so an erased subject's email hash remains in the audit log after erasure. The application database role holds only select and insert privileges on the audit log, which makes it append-only for the application but also means it cannot be purged through the application's connection.
- The in-process cache of plaintext contact details described in Section 3.4 is invalidated only within the API instance that performs the deletion.

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

This DPIA previously described the erasure pipeline as tested and as complete apart from the possibility of a bug leaving orphaned records. The pipeline has no automated test coverage, and six categories of personal data are known to survive an Article 17 erasure: SMS delivery records, segment-broadcast recipient records, certain per-actor live-session data, live-session data held under a second actor identifier, Cloud Storage objects, and the audit-log entries that record the subject's own email hash. An erasure requested after an email-address change deletes nothing at all. This divergence is recorded on the compliance remediation register and is under review.

R9 — Sub-processor breach: A sub-processor suffers a data breach affecting [PLATFORM PROVIDER] customer data. The exposure is wider than the two vendors previously named: attendee personal data is held or received by Google LLC, Railway Corp., NewsmanApp SRL, Cloudflare, Inc., Meta Platforms, Inc., TikTok Pte. Ltd., Microsoft Corporation, SendSMS.ro and Anthropic PBC.

Mitigations: Google LLC and Railway Corp. maintain mature security programmes (SOC 2, ISO 27001), and the Google Cloud Data Processing and Security Terms carry a breach-notification obligation; [PLATFORM PROVIDER] maintains a breach response plan (data-breach-response-plan.md).
Limits of the mitigation: a data processing agreement is not on file for every sub-processor. Agreements and, where applicable, transfer mechanisms remain to be executed with Railway Corp., TikTok Pte. Ltd., SendSMS.ro and Anthropic PBC. The TikTok Events API has been transmitting hashed contact identifiers together with raw IP addresses and raw user agents since 8 May 2026 without an executed agreement on file. See Annex III (annex-sub-processors.md) for the current status of each.

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

This DPIA previously identified sub-processor breach exposure as limited to Google and Railway and recorded that data processing agreements with breach-notification obligations are in place. Nine sub-processors receive attendee personal data, and agreements remain to be executed with Railway Corp., TikTok Pte. Ltd., SendSMS.ro and Anthropic PBC. This divergence is recorded on the compliance remediation register and is under review.

R10 — Data retained beyond relationship: Attendee data not deleted after the retention period has elapsed, or after the customer terminates their [PLATFORM PROVIDER] subscription.

Mitigations: a data retention policy is documented; customer-initiated deletion is available from the dashboard; data deletion on organisation termination is governed by DPA Section 10 (Deletion and Return of Personal Data).
The claim that scheduled jobs enforce retention periods is withdrawn in its unqualified form. 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. In consequence, no age-based deletion is presently taking place for any organisation.
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.
The sixty-day rolling retention of mobile push tokens described in earlier versions does not exist as an enforced period. Sixty days is a default value shown on the retention settings screen, on a screen that cannot save.
Data types outside the job's reach altogether: the funnel page-view table, the audit log, the data-subject request register, live-session data in the Realtime Database (see R11) and Cloud Storage objects. No time-to-live policy is configured on any Firestore collection; registration documents and contact PII documents are removed only by an erasure request or by the manual deletion of the parent webinar or session.

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

This DPIA previously recorded that [PLATFORM PROVIDER] scheduled jobs enforce retention periods and that mobile push tokens are subject to an enforced sixty-day rolling retention. No default retention policy is seeded, the settings screen submits data types the API rejects so that no policy can be saved at all, and the sixty-day figure is an unsaved default value. No age-based deletion is presently taking place. This divergence is recorded on the compliance remediation register and is under review.

R11 — Indefinite retention of live-session content: Chat message text, attendee display names, presence and attendance records, poll votes, reactions, offer clicks and feedback responses accumulating in the Realtime Database without limit, while remaining broadly readable.

Position today: 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.
Compounding factor: as recorded under R2, the chat stream and the actor directory — which holds attendee display names — are readable by any authenticated user, and every other live node is readable by any staff-role token from any organisation. The two exposures combine: an indefinitely retained record of what each named attendee said, readable well beyond the organisation that collected it.
Assessment: this is a storage-limitation question under Article 5(1)(e). No retention period has been determined for this category, and none is enforced.
Mitigations: none automated. Manual deletion of the session or of the webinar is the only method.

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

Earlier versions of this DPIA and of the retention policy stated that live-session data is removed by a scheduled cleanup function shortly after a session ends. No such 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.

R12 — Third-party loading before, or irrespective of, the consent decision: Third-party scripts, assets and embeds transmitting the visitor's IP address, user agent and page context before the visitor has made a cookie choice, or on pages where no choice can be made.

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. The consent bundle loads the whole necessary group immediately on initialisation, before it reads the stored consent cookie and before the banner is rendered, and does not re-check that group when the visitor chooses "Doar necesare" (Only necessary).
Embedded video: 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.
Consent controls removed on the watch page: on the live watch page the cookie banner and the floating cookie-settings button are suppressed, on the basis that attendees have already been presented with the consent choices at registration. A visitor who opens a watch page directly is therefore not shown a cookie prompt on that page and cannot change or withdraw cookie preferences from it; the scripts classified as strictly necessary, including the Meta and TikTok pixels, still load. Article 7(3) requires that withdrawing consent be as easy as giving it, and attendees spend the greater part of their time on this page.
Withdrawal does not remove cookies already set. Withdrawing consent stops further use of the advertising and analytics services but does not delete cookies that were already placed on the device. When consent is withdrawn the platform opts Microsoft Clarity out, returns the Meta and TikTok pixels to their consent-withheld state and reloads the page; cookies such as _fbp, _fbc, _ttp, _ga and _clck remain in the browser until they expire naturally or the visitor deletes them.
Mitigations: Microsoft Clarity is correctly categorised as analytics, loads only after analytics consent and is skipped entirely in the attendee application. The pixels are held in a cookie-less state until advertising consent is granted. Google Fonts on generated landing pages are served from the page's own domain and fetched server-side, so they no longer reach Google from the visitor's browser.

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

This DPIA previously carried no risk covering third-party loading ahead of the consent decision, and recorded that advertising scripts load only after consent. Advertising pixels and an embedded third-party video player both load before or irrespective of the visitor's choice, and the cookie banner and settings control are removed from the attendee watch page altogether. This divergence is recorded on the compliance remediation register; the classification is under review.

R13 — Staff-operated bypass of the marketing-consent gate: The Customer's staff using in-product features to reach contacts who hold no marketing consent, or exporting plaintext contact details out of the platform's suppression and retention controls.

Nature of the exposure: as set out in the note on staff-operated bypass lanes in Section 3.1, the transactional segment broadcast is not gated on marketing consent, a lacks_consent segment condition selects precisely those contacts holding no grant, and the segment export returns plaintext email addresses and names with no consent gate and optionally includes bounced, complained and globally opted-out contacts. Unsubscribed contacts are always present in the default export.
Mitigations: a GDPR Article 18 processing restriction excludes a contact from all three; the email-suppression flag excludes bounced and complained contacts from the broadcast; every action is written to the audit log with the acting user, IP address and user agent. All three are available to the non-administrator marketer role.
Assessment: whether a given send is a service message or direct marketing is determined by the Customer as controller on each send. Where it is direct marketing, Article 13 of the ePrivacy Directive and article 12 of Legea 506/2004 apply and the platform provides no technical control that would prevent the send. Exported contact details, once outside the platform, are beyond the reach of subsequent withdrawals, suppressions, erasures and retention policies.

R14 — Automated moderation of attendee chat content: Attendee messages being automatically assessed, altered or removed without the attendee's knowledge.

Nature of the processing: a Cloud Function screens every chat message against a per-session banned-word list. Plain matches are masked in place in the message the attendee has already sent. Where an obfuscated spelling remains after masking, the message is removed from the stream and the original full text, together with the author's actor data and a removal reason, is written to a staff-readable removed-message node. The attendee is not notified in either case, and the message continues to appear to have been sent. A maintenance script applies the same logic retrospectively to messages already sent.
Retention: removed messages are retained in the removed-message node indefinitely, on the same footing as the rest of the live-session data assessed under R11.
Mitigations: the word list is not client-readable; the processing is confined to text the attendee published into a session; no automated decision producing legal or similarly significant effects is taken.
Assessment: the absence of notification is the material point under Articles 12 to 14, together with the retrospective application to messages sent before the feature existed. The Customer's terms of service should disclose that messages may be altered or removed automatically.

R15 — Transfer of attendee testimonials to an AI provider: Attendee testimonials being transmitted to Anthropic PBC in the USA as part of an AI generation prompt.

Nature of the processing: approved testimonials — the attendee's display name, their free-text quote, their company and their rating — are inserted into the generation prompt used for landing-page copy and HTML. This is the sole category of attendee personal data that reaches Anthropic. Organisation name, webinar details, staff instructions, staff-uploaded reference images and text scraped from staff-supplied reference URLs are also transmitted. Chat message content, registration records, contact email addresses, telephone numbers, poll answers and behavioural events are not transmitted.
Transfer: USA. ⚠️ The transfer mechanism must be confirmed and recorded; see R9 and Annex III.
Mitigations: server-side only — no attendee device contacts Anthropic and no cookies are set. Testimonials are volunteered by the attendee and approved by staff before publication.
Limits: there is no consent gate and no notice to the testimonial's author covering AI processing. The stored generation records — system prompt, user prompt, staff instructions, model, full output and token counts, together with the initiating staff user identifier — 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 that contact has been erased. Anthropic is engaged on a single platform-wide credential, so the Customer cannot disable the processing; see Section 1.3.

R16 — Fabricated participant count shown to attendees: Attendees being shown a participant figure that does not correspond to the number of people present.

Nature of the processing: where the Customer enables the feature, the displayed attendee count is computed as a configured base plus the real present count multiplied by a configured factor, with a small random variation applied each minute so that the figure drifts as organic traffic would. The attendee interface renders that figure beside a live indicator. The Realtime Database rules expose only the displayed figure to attendees; the true count and the presence list are staff-only, so an attendee cannot see the real number. The staff panel shows the true count alongside the displayed one.
Assessment: this does not concern the security of personal data but the fairness of the processing under Article 5(1)(a), which requires that personal data be processed fairly and transparently in relation to the data subject. Where a fabricated audience figure is used to induce registration or purchase it may additionally engage Directive 2005/29/EC on unfair commercial practices, including Annex I thereto, and Legea 363/2007.
⚠️ Determination required: whether [PLATFORM PROVIDER] permits Customers to enable this feature, and on what conditions, is not settled in [PLATFORM PROVIDER]'s records. Any constraint adopted should be reflected in the acceptable-use provisions of the SaaS Terms of Service and in the Customer Compliance Guide.

R17 — Personal data and credentials in provider and application logs on the SMS path: The recipient's telephone number, the message body and the account credentials being recorded in logs outside [PLATFORM PROVIDER]'s control.

Nature of the exposure: messages are submitted to SendSMS.ro as an HTTP GET request 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. The message body contains the webinar title, the time remaining and a per-recipient tracked URL. On delivery the message is processed by the recipient's mobile network operator. The telephone number is additionally written to the application log on a send failure.
Mitigations: per-organisation credentials are held in Google Secret Manager and only the secret reference is stored in Firestore; transport is TLS; an SMS is sent only where the contact holds a granted, unrevoked sms_notifications consent and is not subject to an Article 18 processing restriction.
⚠️ 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.

R18 — Weaknesses in the attendee and mobile sign-in path: An unauthorised person obtaining an attendee session, and so access to that attendee's registration, preferences and contact details.

Four-digit one-time code: the email fallback to the magic link issues a four-digit numeric code with ten thousand possible values, valid for ten minutes and invalidated after three failed attempts. The per-account attempt limit is the effective control; the rate limits recorded under R6 are keyed on the client address, not on the account.
Store-review demo credential: one configured email address can be signed in with a fixed code that does not expire, bypassing the stored-code validation entirely, including the per-account lockout. The comparison is exact on the full address and constant-time, so it can unlock only that one account, and each use is written to the application log at warning level. It is intended to be present in the production environment. It is a standing credential with no expiry and no rotation schedule, its use produces no audit-log entry, and the address is written to the application log in plaintext.
Assessment: the demo credential is a deliberate, narrowly-scoped exception rather than a defect, but it is a permanent authentication bypass for a real account in the production environment and belongs on the risk record as such. Its custody and rotation are not documented.

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

This DPIA previously assessed the mobile authentication path solely as a question of token theft from a compromised device, and recorded rate limiting as applying three requests per minute per email address. Rate limiting is applied per client address and never per email address; a four-digit one-time code is available as a fallback to the magic link; and a standing store-review demo credential permits one configured account to sign in with a fixed, non-expiring code in the production environment. This divergence is recorded on the compliance remediation register and is under review.

5. Mitigation Measures

5.1 Technical Measures

Measure	Risk(s) Addressed
PostgreSQL Row Level Security (RLS) with `app.current_org_id`, on 33 of 34 tables, enforced through a dedicated non-superuser role, with a production boot guard that refuses to start on the privileged connection	R1, R2
No application-level Row Level Security bypass is in use: the administrative-context helpers in the database layer are unreferenced and no policy consults the session variable they set	R2
Firebase Security Rules (Firestore) restricting organisation configuration, staff records, page records, private webinars, consent records and the registration PII subcollection to members of the owning organisation, and denying all client access to verification codes and magic links. They do not restrict contact PII documents or registration documents — see Section 4.2 R2	R1, R2
⚠️ Realtime Database and Cloud Storage rules contain no organisation check and are not a tenant-isolation control — see Section 4.2 R2	—
Firebase JWT authentication on the dashboard and attendee API route groups. Public registration, tracking, share and configuration routes are unauthenticated by design	R1
Encryption at rest (Railway encrypted volumes, Firestore encryption)	R1, R6, R9
Encryption in transit (TLS 1.2+ on all connections)	R1, R9
Behavioural-consent check in the behavioural event Cloud Functions, suppressing the granular event rows written to the analytics database only	R4
SHA-256 hashing of directly identifying fields before ad platform transmission; raw IP address and user agent are transmitted alongside them	R5
Article 18 processing restriction enforced as a hard stop across consent, messaging, exports, broadcasts and server-side conversion events	R5, R13
JWT stored in Keychain / EncryptedSharedPreferences	R6
1-hour JWT expiry with automatic refresh	R6
Rate limiting on the attendee authentication endpoints, keyed per client address or per authenticated user — never per email address: send-link 10/min burst 3; verify-link 10/min burst 5; verify-code 10/min burst 5; refresh 30/min burst 5. Counters are held in process memory, so limits apply per API instance	R6, R18
Four-digit email one-time code invalidated after 3 failed attempts and after 10 minutes	R18
Silent synchronisation push on erasure and on processing restriction (not on consent revocation)	R7
Send-time consent check against the consent ledger before every push and SMS dispatch	R7
GDPR deletion pipeline with cascade and explicit queries, with the documented gaps recorded in Section 4.2 R8	R8
⚠️ No enforced retention period exists for mobile push tokens, or for any other data type, because no retention policy can currently be saved — see Section 4.2 R10	—
Google Consent Mode v2 deny-by-default, applying to the Google Tag Manager container where the Customer has configured one. It does not govern the Meta Pixel, the TikTok Pixel or Microsoft Clarity	R5, R12
Microsoft Clarity categorised as analytics, loaded only after analytics consent and skipped entirely in the attendee application	R12
Per-organisation SMS credentials held in Google Secret Manager, with only the secret reference stored in Firestore	R17
Append-only audit log: the application database role holds only select and insert privileges	R1, R3, R13

5.2 Organizational Measures

Measure	Risk(s) Addressed
ROPA maintained; annual review is the intended cadence, and the interval recorded in Section 8 was not observed	R3, R10
Sub-processor data processing terms in place with Google LLC. ⚠️ Agreements and, where applicable, transfer mechanisms remain to be executed with Railway Corp., TikTok Pte. Ltd., SendSMS.ro and Anthropic PBC	R9
Data Processing Agreement with each customer	R3, R8
Audit logging on dashboard write operations, recording the acting user, role, IP address and user agent	R1, R3, R13
Separate DB users (RLS-enforced application role vs superuser scheduler role) to limit blast radius. ⚠️ The application role is provisioned outside the migration set, so the control is not reproducible from the repository alone	R2
Breach response plan documented	R9
DSAR procedure for handling deletion requests	R8
Staff access to PII limited to operational necessity. ⚠️ Four staff roles exist (`admin`, `moderator`, `marketer`, `staff`), and every destructive action other than the audit-log listing is available to a non-administrator role — see the note on staff-operated bypass lanes in Section 3.1	R1, R3, R13
Compliance remediation register recording each divergence marked KNOWN GAP in this document	All

6. Residual Risk Assessment

#	Risk	Residual Risk	Acceptable?
R1	Unauthorized access to PII	Low-Medium	Qualified — see Section 4.2 R1 and R2
R2	Cross-org data leak	High	No — remediation pending
R3	Excessive profiling	Low	Yes
R4	Behavioral tracking without consent	Low-Medium	Qualified — see Section 4.2 R4 and the note on consent mechanics in Section 3.1
R5	Ad platform receives identifiable data	Medium-High	No — remediation pending
R6	Mobile token theft	Low	Yes
R7	Push consent not honored	Low	Yes
R8	Deletion pipeline failure	Medium-High	No — remediation pending
R9	Sub-processor breach	Medium	No — remediation pending
R10	Over-retention	High	No — remediation pending
R11	Indefinite retention of live-session content	High	No — remediation pending
R12	Third-party loading before or irrespective of consent	Medium-High	No — remediation pending
R13	Staff bypass of the marketing-consent gate	High	No — remediation pending
R14	Automated moderation without notification	Medium	Qualified — see Section 4.2 R14
R15	Testimonial transfer to an AI provider	Medium	No — remediation pending
R16	Fabricated participant count	Medium	⚠️ Determination required — see Section 4.2 R16
R17	Personal data and credentials in provider logs	Medium-High	No — remediation pending
R18	Attendee and mobile sign-in weaknesses	Medium-High	No — remediation pending

Overall residual risk: High. The previous assessment recorded every risk as residually low and acceptable. That conclusion rested on mitigations which, on the review recorded in this revision, are not implemented in the form described: tenant isolation outside PostgreSQL, enforcement of retention periods, completeness of the erasure pipeline, and a consent gate on advertising pixels. Where a control is absent rather than imperfect, the inherent risk stands and cannot be reduced by documenting it. The risks marked "No — remediation pending" above are recorded on the compliance remediation register and are not accepted in their present state.

GAP-GOV-06 · PROCESS — KNOWN GAP, REMEDIATION PENDING

This DPIA previously concluded that all identified risks were mitigated to an acceptable level and that the overall residual risk was low. That table has been recalculated against the platform as implemented, eight further risks have been added, and eleven risks are now recorded as not accepted. This divergence is recorded on the compliance remediation register and is under review.

7. Consultation

7.1 Internal Consultation

Role	Input
CTO / Engineering Lead	Technical measures, architecture review
Legal / DPO	Legal basis assessment, proportionality, necessity
Security Lead	Risk identification, technical controls

7.2 Supervisory Authority Consultation

Required? ⚠️ Not determined. The previous answer — that no prior consultation with the supervisory authority (Romanian ANSPDCP) is required — rested on the residual-risk table as it stood before this revision, in which every risk was recorded as low and acceptable. That table has been corrected in Section 6: several of the controls on which it relied are absent rather than imperfect, eight further risks have been added, and the overall residual risk is now assessed as high.

GDPR Article 36(1) requires prior consultation where a data protection impact assessment indicates that the processing would result in a high risk in the absence of measures taken by the controller to mitigate it. The question must therefore be re-evaluated by the controller against the corrected table — either once the risks marked "No — remediation pending" in Section 6 have been addressed, or, where they cannot be addressed, on the table as it stands. The reasoning supporting whichever conclusion is reached is to be recorded in this section rather than the conclusion alone.

If future processing changes materially increase risk (e.g., automated decision-making with legal effects, processing of special category data), this DPIA will be updated and prior consultation will be reassessed.

GAP-GOV-06 · PROCESS — KNOWN GAP, REMEDIATION PENDING

This DPIA previously concluded that no prior consultation with the supervisory authority was required, on the basis that residual risk was low after mitigation. The residual-risk table supporting that conclusion has been corrected in Section 6 and now records an overall residual risk of high, so the Article 36(1) question is reopened and no conclusion is presently recorded. This divergence is recorded on the compliance remediation register and is under review.

8. Review Cycle

This DPIA must be reviewed:

Annually as a routine review
When processing changes significantly — new features, new sub-processors, new high-risk activities, new data categories
After a security incident that reveals a gap in the risk assessment
When supervisory authority guidance changes in a way that affects the risk analysis

Review record. This DPIA was revised on 4 September 2026 against the platform as then implemented. The assessment had not been revised since 27 March 2026, notwithstanding that several of the trigger conditions above were met in the intervening period. The changes that should have triggered a revision include: the activation of the server-side TikTok Events API; the reclassification of the Meta and TikTok pixels as necessary scripts loading ahead of the consent decision; the introduction of a server-side page-view transfer covering every landing-page visitor; the addition of transactional segment broadcasts and of a segment condition selecting contacts lacking consent; the ingestion of purchase and order data from customer e-commerce webhooks; automated moderation of attendee chat; the simulated participant count; AI-assisted content generation with Anthropic PBC as a new sub-processor; SMS delivery with SendSMS.ro as a new sub-processor; and the introduction of a standing store-review demo credential in the production environment.

No process presently requires a revision of this assessment when a sub-processor, a tracking recipient, a new data category or a new high-risk processing activity is introduced. Establishing one is a precondition for this document remaining an accurate Article 35 record.

9. Sign-Off

Role	Name	Date	Signature
Data Protection Officer (or appointed counsel)	[DPO Name]	[DATE]	_____________
CTO	[CTO Name]	[DATE]	_____________
CEO / Legal Representative	[CEO Name]	[DATE]	_____________

Document Version: 1.0 (DRAFT) Prepared by: [Legal Team / Engineering] Review Status: ⚠️ REQUIRES LEGAL REVIEW — Must be reviewed and signed by a qualified DPO or GDPR counsel before production deployment.

Last Updated: [DATE] Next Review: [DATE + 1 year] or upon significant processing change

Data Protection Impact Assessment (DPIA) ​

1. Introduction and Scope ​

1.1 Purpose ​

1.2 Why a DPIA Is Required ​

1.3 Scope of This DPIA ​

2. Description of Processing ​

2.1 Nature of Processing ​

2.2 Purpose of Processing ​

2.3 Data Subjects ​

2.4 Data Categories ​

3. Necessity and Proportionality ​

3.1 Legal Bases ​

3.2 Legitimate Interest Balancing Test (Transactional Communications) ​

3.3 Legitimate Interest Balancing Test (Server-Side Ad Conversion Tracking) ​

3.4 Data Minimization ​

4. Risk Identification ​

4.1 Risk Register ​

4.2 Risk Detail ​

5. Mitigation Measures ​

5.1 Technical Measures ​

5.2 Organizational Measures ​

6. Residual Risk Assessment ​

7. Consultation ​

7.1 Internal Consultation ​

7.2 Supervisory Authority Consultation ​

8. Review Cycle ​

9. Sign-Off ​