Data Processing Agreement (DPA)

Between:[ORGANIZATION NAME] ("Customer" or "Data Controller") [Customer Address] [Customer Country]

And:[PLATFORM PROVIDER] ("Processor" or "[PLATFORM PROVIDER]") [[PLATFORM PROVIDER] Address] [[PLATFORM PROVIDER] Country] [Company Registration Number]

Effective Date: [DATE]

---

Recitals

WHEREAS:

A. The Customer has subscribed to [PLATFORM PROVIDER]'s event platform services ("Services") to host events, collect attendee registrations, and perform lead qualification and marketing analytics.

B. In providing the Services, [PLATFORM PROVIDER] processes personal data on behalf of the Customer.

C. The Parties wish to comply with Regulation (EU) 2016/679 (General Data Protection Regulation, "GDPR") and establish the terms governing such personal data processing.

D. This Data Processing Agreement ("DPA") supplements and forms an integral part of the main service agreement between the Parties (the "Service Agreement").

NOW, THEREFORE, the Parties agree as follows:

---

1. Definitions and Interpretation

1.1 Definitions

Unless otherwise defined herein, capitalized terms have the meanings set forth in the GDPR:

• "Affiliate" means any entity that directly or indirectly controls, is controlled by, or is under common control with a party
• "Applicable Data Protection Laws" means all laws and regulations applicable to the processing of Personal Data, including GDPR, ePrivacy Directive (2002/58/EC), and national implementing legislation
• "Customer Data" means all data submitted by Customer or Customer's end users (attendees) to the Services
• "Data Subject" means an identified or identifiable natural person whose Personal Data is processed under this DPA (primarily event attendees)
• "Personal Data" means any information relating to an identified or identifiable natural person contained in Customer Data
• "Processing" has the meaning given in GDPR Art 4(2)
• "Security Incident" means any accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to Personal Data
• "Standard Contractual Clauses" (SCCs) means the European Commission's Standard Contractual Clauses for the transfer of personal data to third countries (2021 version), as may be amended or replaced
• "Sub-processor" means any third party engaged by Processor to process Personal Data

1.2 Interpretation

• References to "Articles" refer to GDPR articles unless otherwise stated
• Headings are for convenience only and do not affect interpretation
• "Including" means "including without limitation"

---

2. Scope and Roles

2.1 Relationship of the Parties

• Customer acts as Data Controller (or, in some cases, Data Processor if Customer is itself providing services to third parties)
• [PLATFORM PROVIDER] acts as Data Processor on behalf of Customer

2.2 Scope of Processing

[PLATFORM PROVIDER] shall process Personal Data only:

• To provide the Services as described in the Service Agreement
• In accordance with Customer's documented instructions
• As necessary to comply with applicable legal obligations

Services include:

• Event hosting and attendee management
• Real-time features (chat, polls, offers, Q&A)
• Automated moderation of attendee chat messages against a per-session banned-word list, including in-place masking of matched terms and, where an obfuscated spelling still matches after masking, removal of the message to a staff-visible removed-message store that retains the full original text, the author's actor record and the reason for removal
• Behavioral analytics and lead qualification
• Email delivery (registration confirmations, reminders, marketing)
• Staff-initiated segment broadcasts: a one-off email composed in the dashboard and sent to the members of a saved segment
• SMS delivery of webinar reminder, "starting now" and replay messages and of automation SMS steps
• Mobile push notification delivery (transactional and marketing, via Firebase Cloud Messaging)
• Funnel and landing-page hosting, including server-side unique-visitor measurement, tracked share and redirect links, and inbound order and form webhooks
• AI-assisted generation of landing-page briefs, landing-page HTML, marketing copy and webinar poll questions
• Server-side ad conversion tracking (Meta and TikTok only). Google Ads Enhanced Conversions and the LinkedIn Conversions API are represented in the integration configuration data model but are not implemented: no server-side sender exists for either, and no event is transmitted to Google Ads or to LinkedIn from the Services
• GDPR compliance tools (data export, deletion pipelines)

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

This Section previously described server-side ad conversion tracking to Meta, Google, TikTok and LinkedIn, and did not describe several processing operations the Services perform. Server-side conversion tracking exists for Meta and TikTok only, and the Services additionally perform automated chat moderation, SMS delivery, funnel and landing-page hosting with server-side visitor measurement, AI-assisted content generation and staff-initiated segment broadcasts, none of which was previously listed. This divergence is recorded on the compliance remediation register and is under review.

2.3 Subject Matter and Duration

• Subject matter: Provision of event platform services
• Duration: For the term of the Service Agreement and until final deletion of Personal Data upon termination

2.4 Nature and Purpose of Processing

• Nature: Collection, storage, organization, structuring, retrieval, consultation, use, disclosure, erasure
• Purpose: Enable Customer to host events, capture leads, qualify attendees based on engagement, send marketing communications, and measure ad campaign effectiveness

2.5 Categories of Data Subjects

• Event attendees (B2C end users who register for Customer's events)
• Visitors to Customer's funnel and landing pages who do not register. Every non-bot visitor is recorded against a persistent pseudonymous identifier derived from the visitor's IP address and user agent, without a consent gate, and — where Customer has enabled the Meta integration — a server-side Meta Conversions API PageView carrying the visitor's raw IP address and user agent is transmitted for that visit
• Customers of Customer's e-commerce store, where Customer has configured an order webhook. Order data is matched to an existing contact by the hash of the customer's email address; an order for an address that does not already correspond to a contact is discarded without a record being created, so this population consists of registrants who are also customers of Customer's store
• Customer's staff users (employees, contractors with dashboard access)

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

This Section previously identified only event attendees and Customer's staff users as categories of Data Subject. The Services also process personal data about visitors who never register — a persistent pseudonymous identifier derived from their IP address and user agent, and a server-side ad-platform PageView carrying their unhashed IP address and user agent — and about the store customers whose order data Customer's e-commerce platform transmits by webhook. Section 3.3(a) allocates the lawful-basis determination for these populations to Customer without previously disclosing that they exist. This divergence is recorded on the compliance remediation register and is under review.

2.6 Types of Personal Data

Category	Data Elements
Registration Data	Email address, full name, phone number (optional, collected post-registration via lobby or preferences page)
Behavioral Data	Chat messages, poll votes, offer clicks, attendance timestamps, session duration, reactions, Q&A questions
Technical Data	IP address and user agent — stored verbatim in the audit_log table for every audited staff action and in the scheduler_job_runs table for job executions; used transiently for geo-enrichment on the registration and funnel paths, where the derived country and city (not the address itself) are stored on the funnel entry; and transmitted unhashed to Meta and to TikTok where Customer has enabled those integrations. Browser type, device information (derived from user agent, stored as device_type/os/browser). 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. Firebase Auth UID (stored on mobile app contact doc for UID→contact lookup; linked to contact email), FCM push token (pseudonymous device identifier stored in device_tokens table, keyed by (org_id, email_hash, fcm_token), platform: android/ios, no automated deletion; deleted on FCM UNREGISTERED response, GDPR erasure, or explicit consent revocation)
Funnel Visitor Data	Persistent pseudonymous visitor identifier derived from the visitor's IP address and user agent, recorded once per visitor per funnel step per day in funnel_page_views. The identifier is stable over time — the same visitor produces the same value on every visit — and is therefore a persistent pseudonymous identifier. Collected for every non-bot visitor to a funnel or landing page, without a consent gate.
Attribution Data	UTM parameters (source, medium, campaign, content, term), advertising click IDs (fbclid, gclid, ttclid, li_fat_id), landing page URL, referrer URL, referral share data (share channel, source, click count, registration count), and — recorded on the funnel entry against the identified contact — country code, city, device type, operating system, browser and browser time zone
Purchase and Order Data	Where Customer configures an e-commerce order webhook: the customer's email address (used to match an existing contact), order identifier, total amount, currency and payment status, stored as funnel entry metadata. Sourced from Customer's store rather than collected from the Data Subject.
Inbound Webhook Payloads	For generic and form-provider webhooks, the entire raw request body is stored verbatim as funnel entry metadata and may contain arbitrary form answers determined by Customer's form configuration
Staff Data	Email, name, role (admin, moderator, marketer or staff), Firebase Auth UID, and — for every audited staff action — the acting user's IP address, user agent and request identifier recorded in the audit_log table
Consent Records	Consent granted/revoked dates and the consent purpose. There are exactly ten valid purposes: data_processing (required), tos_acceptance (required), email_marketing, push_notifications, push_marketing, behavioral_tracking, whatsapp_notifications, whatsapp_marketing, sms_notifications, sms_marketing. A request naming any other purpose is rejected. whatsapp_notifications, whatsapp_marketing, push_marketing and sms_marketing are accepted and displayed but gate no send path. The consent method recorded is one of web_form, app_onboarding, app_registration, app_preferences, preferences_page, unsubscribe, email_unsubscribe, import or newsman_sync_reconcile. Consent policy version in force: "1.0". The cookie-banner decision is not part of this record — see the note below.
AI Generation Records	For each AI generation: the system prompt, the user prompt, custom instructions, the model identifier, the full model output, input and output token counts, duration, and the identifier of the member of staff who started the job, retained in the ai_jobs table. Prompts embed approved attendee testimonials — the attendee's display name, free-text quote, company and rating — and, on the vision path, staff-uploaded reference images from the organisation media library, which are Customer marketing assets and may depict identifiable individuals.
SMS Delivery Data	Recipient telephone number in plaintext and the full message body, transmitted to the messaging provider at send time and read from Firestore rather than stored in the analytics database. Delivery records in the sms_sends table: email hash, webinar and session identifiers, template type, tracking code, provider message identifier, delivery status, error text, tracked URL, and delivery and click timestamps.
Moderated Content	The full original text of a chat message removed by automated moderation, together with the author's actor record, the removal timestamp and the removal reason, retained in the session's removed-message store and readable by holders of the admin, moderator, marketer and staff roles
Segment Broadcast Data	Broadcast content (subject, title, body, call-to-action label and URL, and the identifier of the member of staff who composed it) and a per-recipient send ledger in segment_broadcast_sends keyed by email hash, segment identifier, campaign key and send timestamp
Push Delivery Data	Push notification send records (push_sends table): template type, FCM message ID, send status, open timestamp (client-reported), event/session context. Linked to email_hash (pseudonymous).

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

The Technical Data row previously stated that the IP address is processed transiently for geo-enrichment and is not stored, and that the user agent is stored only where marketing attribution is present. Both values are in fact stored verbatim in the audit_log and scheduler_job_runs tables, a persistent pseudonymous identifier derived from the IP address and user agent is stored for every landing-page visitor, and both values are transmitted unhashed to Meta and to TikTok where those integrations are enabled. This divergence is recorded on the compliance remediation register and is under review.

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

The Technical Data row previously stated that FCM push tokens are subject to a 60-day rolling retention. No such retention operates. Retention periods are configured per organisation and no default policy is seeded, the retention enforcement job acts only on policies that exist, and the retention settings screen currently submits eight data types while the API accepts five and validates the whole submission before writing any of it, so no retention policy can be configured through the product and no push token is deleted by age. This divergence is recorded on the compliance remediation register and is under review.

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

The Consent Records row previously presented the cookie-banner decision as part of the consent record and named checkbox and cookie_banner as consent methods. Neither method value is ever written, and the cookie banner's outcome is stored only in a first-party cookie on the visitor's device (rx_cookie_consent, a JSON value recording the necessary, analytics and advertising choices, a timestamp and a version, retained for twelve months). It is never written to the consent ledger, so the platform holds no server-side record of who accepted or rejected cookies, and cannot evidence a cookie-consent decision after the fact. This divergence is recorded on the compliance remediation register and is under review.

Consent recorded under the import method. Contacts loaded through the bulk importer are written with granted consents for data processing and acceptance of the terms, recorded with the current policy version and a method of "import", and with marketing consent where the imported row carries that flag. These grants are inherited from the source of the import rather than collected from the Data Subject by the Services, and Customer is responsible for holding the underlying evidence.

Special Categories of Data (Art 9): None intentionally collected. If Data Subjects voluntarily disclose sensitive data (health, religion, etc.) in chat messages, moderation and removal are performed both by Customer and, in part, automatically by the Services: every chat message is checked against the per-session banned-word list, matched terms are masked in place, and a message whose obfuscated spelling still matches after masking is removed from the live stream and retained in full, with its author's actor record, in the staff-visible removed-message store. The attendee is not notified of the masking or the removal. Automated moderation operates on a word list, not on special-category detection, and Customer remains responsible for reviewing and removing sensitive content it does not catch.

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

This Section previously stated that Customer is responsible for the moderation and removal of sensitive data disclosed in chat messages, without disclosing that the Services perform automated moderation. Attendee messages are altered or removed automatically without notice to the attendee, and the full original text of a removed message is retained together with the author's actor record. This divergence is recorded on the compliance remediation register and is under review.

---

3. Customer's Instructions and Obligations

3.1 Processing Instructions

[PLATFORM PROVIDER] shall process Personal Data only on documented instructions from Customer, which include:

a) The Service Agreement and this DPA b) Use of the Services via the [PLATFORM PROVIDER] dashboard, APIs, and configuration settings c) Email instructions from Customer's authorized personnel (sent to [email protected]) d) Settings configured in the dashboard (integrations, consent requirements). Retention periods are configured per organisation and no default policy is seeded, but the retention settings screen submits eight data types while the API accepts five and validates the whole submission before writing any of it, so no retention policy can currently be saved and Customer cannot in fact issue a retention instruction through this channel

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

This Section previously listed retention policies among the settings through which Customer issues documented instructions. No retention policy can be saved through the product: every submission from the retention settings screen is rejected before any of it is written, no default policy is seeded, and the retention enforcement job acts only on policies that exist, so an organisation that has configured none has no data deleted by age. Where an enabled policy would delete more than ten thousand rows in a single run, the job records a warning and deletes nothing. This divergence is recorded on the compliance remediation register and is under review.

3.2 Instruction Compliance

If [PLATFORM PROVIDER] believes an instruction violates Applicable Data Protection Laws:

• [PLATFORM PROVIDER] shall immediately inform Customer
• [PLATFORM PROVIDER] is entitled to suspend execution of the instruction until Customer confirms or amends it

3.3 Customer's Responsibilities

Customer represents, warrants, and undertakes that:

a) Legal Basis: Customer has established a lawful basis (consent, contract, legitimate interest) for all processing it instructs [PLATFORM PROVIDER] to perform

b) Consent Collection: Customer is responsible for obtaining valid consent from Data Subjects for:

• Behavioral tracking (chat analytics, lead scoring). 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
• Marketing communications. email_marketing gates exactly one thing: whether the contact is synchronised into the marketing email provider's list and segments. Every other email path — registration confirmation, reminders, "starting now", replay, automation email, resend and segment broadcast — runs on the transactional gate alone (not suppressed, not restricted)
• Ad conversion tracking. Customer's responsibility under this clause is qualified: the Services do not implement a consent gate on this processing and Customer therefore cannot enforce a consent decision through them. The server-side Meta Conversions API and TikTok Events API events are transmitted for every registration where Customer has enabled the corresponding integration, and the server-side Meta PageView for every landing-page visit, irrespective of the Data Subject's cookie-banner choice. The registration form collects an advertising-consent field, but that field is stored on the registration and attribution records only and is never read as a condition of any transmission. The sole enforced suppression is a GDPR Art 18 processing restriction

c) Privacy Notices: Customer has provided Data Subjects with transparent privacy notices (GDPR Art 13/14) disclosing [PLATFORM PROVIDER] as a processor

d) Data Subject Rights: Customer is responsible for responding to Data Subject rights requests ([PLATFORM PROVIDER] will assist per Section 7)

e) Data Minimization: Customer shall only collect Personal Data that is adequate, relevant, and limited to what is necessary

f) Accuracy: Customer shall ensure Personal Data is accurate and up-to-date

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

Clause (b) previously made Customer solely responsible for obtaining consent to ad conversion tracking and behavioural tracking. The Services implement no consent gate on server-side ad conversion tracking, and the client-side pixels are classified as necessary scripts, so neither the presence nor the absence of an attendee's consent changes what is transmitted to Meta or to TikTok; behavioural-tracking consent likewise suppresses only the analytics event rows and not the live-session record. The identity of the controller for the ad-measurement processing, and the legal basis on which it is performed, are unresolved and are being determined. This divergence is recorded on the compliance remediation register and is under review.

3.4 Customer-Provided Third-Party Credentials (Integrations)

The Services allow Customer to connect third-party services by providing API credentials via the dashboard (Settings → Integrations). This includes:

• Email delivery: Newsman API key (Customer's own NewsmanApp SRL account). Where Customer has not configured its own account, sends fall through to a platform-level NewsmanApp SRL account operated by [PLATFORM PROVIDER]; in that case NewsmanApp SRL is a [PLATFORM PROVIDER] sub-processor and the carve-out in clause (a) below does not apply
• Transactional SMS: SendSMS.ro username, API key and sender identifier (Customer's own SendSMS.ro account), configured under Settings → Integrations → SendSMS. The API key is held in Google Secret Manager under a per-organisation secret name; Firestore stores only the secret reference, the username, the sender identifier and the enabled flag
• Mobile push notifications: Mobile Firebase service account JSON (Customer's own Firebase project, separate from the [PLATFORM PROVIDER] events Firebase project)
• CDN cache purge: Cloudflare Zone ID + API Token (Customer's own Cloudflare, Inc. account). This credential covers cache purge only and must not be confused with [PLATFORM PROVIDER]'s own use of Cloudflare, described below
• Ad platforms: Meta Pixel ID, TikTok Pixel ID, etc. (Customer's own ad accounts)

Cloudflare is also a [PLATFORM PROVIDER] sub-processor, independently of the Customer credential above. Cloudflare, Inc. 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 that carry a funnel form, outside the consent bundle, and server-side verification transmits the visitor's IP address to Cloudflare. That processing is engaged by [PLATFORM PROVIDER], not by Customer, and clauses (a) to (e) below do not apply to it.

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

This Section previously listed Cloudflare only as an optional Customer-provided CDN integration and described Newsman solely as Customer's own account. Cloudflare is in fact a mandatory reverse proxy through which all attendee traffic passes in production, and additionally serves Turnstile from published landing pages outside the consent bundle; and email may be delivered through a platform-level Newsman account where Customer has configured none, in which case the "not a sub-processor of [PLATFORM PROVIDER]" carve-out in clause (a) does not hold. The SendSMS.ro integration was absent from this list altogether. This divergence is recorded on the compliance remediation register and is under review.

When Customer provides credentials for these integrations:

a) Customer is the party with the third-party relationship. The third-party provider (e.g., Google Firebase for mobile push, NewsmanApp SRL where Customer has configured its own account, SendSMS.ro, Cloudflare for cache purge) is engaged by Customer, not by [PLATFORM PROVIDER]. Customer holds the DPA with that third party. The third party is not a sub-processor of [PLATFORM PROVIDER] for these integrations — it is a sub-processor (or processor) engaged directly by Customer. This carve-out does not extend to the platform-level Newsman account, to [PLATFORM PROVIDER]'s use of Cloudflare as a reverse proxy and Turnstile provider, or to any other service [PLATFORM PROVIDER] engages on its own credentials, all of which are [PLATFORM PROVIDER] sub-processors listed in Annex III.

b) [PLATFORM PROVIDER] acts as Customer's agent when calling these third-party APIs using Customer's credentials. [PLATFORM PROVIDER] processes data through these services solely on Customer's documented instructions (the integration configuration Customer sets in the dashboard).

c) Customer is responsible for GDPR compliance of their own third-party accounts, including: having a valid DPA with the provider, ensuring the provider's GDPR safeguards are adequate, and maintaining their own sub-processor records for these providers.

d) [PLATFORM PROVIDER] stores Customer's credentials securely in Google Secret Manager (encrypted at rest, access-controlled). Credentials are used only to perform the integration Customer has configured and are deleted upon Customer's request or service termination.

e) [PLATFORM PROVIDER] is not liable for data processing carried out by Customer-provided third-party services beyond its role as the calling agent using Customer's credentials.

Practical implication for Mobile Push (Firebase FCM): Customer's mobile Firebase project is Customer's own Google Cloud/Firebase project. Customer has their own Google Cloud DPA with Google for that project. [PLATFORM PROVIDER] calls the FCM HTTP v1 API on Customer's behalf using the service account Customer provides. If Customer does not have an active Google Cloud DPA covering their Firebase project, that is Customer's compliance obligation to resolve.

3.5 Customer-Added Tracking Scripts

The Services allow Customer to add third-party tracking scripts (e.g., Pinterest Tag, Snapchat Pixel, Klaviyo) via dashboard settings (Settings → Integrations → Tracking Scripts). When Customer adds such scripts:

a) Customer is solely responsible for ensuring compliance with Applicable Data Protection Laws, including obtaining valid consent from Data Subjects for any data collection by those scripts b) Customer acknowledges that such scripts may introduce additional data processors not listed in Annex III (Sub-Processors), and Customer must maintain its own sub-processor records for these scripts c) [PLATFORM PROVIDER] categorizes Customer-added scripts automatically, by matching the content of the snippet against a fixed set of patterns, into one of three groups — necessary, analytics or advertising. "Advertising" is the fallback where no pattern matches; it is not the default the classifier applies first. A Google Tag Manager container, a Meta snippet that calls fbq('consent','revoke') before initialisation, and a TikTok snippet that calls ttq.holdConsent() before loading are all classified necessary. The consent bundle loads the whole necessary group immediately on initialisation, before it reads the stored consent cookie and before it renders the banner, and it does not re-check that group when the visitor chooses "Doar necesare" (Only necessary). A Customer-added script that falls into the necessary group therefore executes on every page view, before and irrespective of the attendee's consent decision. Only scripts classified analytics or advertising are withheld pending the corresponding consent d) [PLATFORM PROVIDER] is not liable for data processing carried out by Customer-added tracking scripts, as these constitute Customer's own processing instructions

[PLATFORM PROVIDER]'s own Meta and TikTok pixel snippets are classified the same way. 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.

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.

Google Fonts. The page-generation prompts instruct the model to include a Google Fonts <link> whenever the chosen typography calls for one, and the design-brief path instructs it in every case. When a published page is served, the public application rewrites those links to the page's own domain (/fonts/…) and fetches the stylesheets and font files from Google server-side, so the visitor's browser never 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.

3.6 Instructions Outside Scope

If Customer requests processing outside the scope of the Service Agreement (e.g., custom data processing, expedited GDPR requests requiring manual intervention), the Parties may agree to additional fees and terms.

---

4. Security Measures

4.1 Technical and Organizational Measures

[PLATFORM PROVIDER] implements appropriate technical and organizational measures to ensure a level of security appropriate to the risk, including:

Technical Measures:

• Encryption in transit (TLS 1.2+)
• Encryption at rest (database backups, file storage)
• Pseudonymization (email hashing with SHA-256 in the analytics database). 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
• Row Level Security (RLS) on all org-scoped PostgreSQL tables (org_id isolation). 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. Row Level Security is enabled but not forced, so a table owner or superuser connection is not subject to the policies; and 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 — on which Row Level Security provides no backstop and isolation rests on the unguessability of the token
• Firestore security rules. These rules restrict organisation configuration, staff user records, page records, private webinars, contact-level consent records and the registration PII subcollection to authenticated members of the owning organisation, and they deny all client access to the top-level collections that hold verification codes and magic links. They do not restrict two categories of personal data: the contact PII document, which 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); and registration documents, which are readable without authentication, exposing the registration status, the email hash, the registration timestamp and the registration metadata
• Realtime Database security rules. Access to live-session data is authorised by the role claim in the caller's authentication token alone. The 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. 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
• Cloud Storage security rules. The 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. A final catch-all rule grants read and write access to every remaining object in the bucket to any authenticated user
• Access controls (role-based permissions). 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
• In-process cache of contact PII. 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
• Multi-factor authentication (MFA) for [PLATFORM PROVIDER]'s own accounts on third-party hosting and console providers. ⚠️ This is an internal administrative practice and is not a control of the Services: the Services provide no multi-factor authentication for dashboard users, who sign in with an email address and password or with Google OAuth. See Annex II and the Record of Processing Activities

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

This Section previously represented org-scoped Firestore security rules and a two-role access model of administrator against read-only staff. Neither representation held: the contact PII document is readable by any authenticated Firebase user of any organisation who knows the organisation identifier and the unsalted email hash, registration documents are readable without authentication, the Realtime Database rules contain no organisation identifier at all, the Cloud Storage rules grant unconditional public read across every organisation-scoped path, and the platform defines four roles in which the non-administrator marketer and moderator roles can perform every destructive action except listing the audit log. Organisation-level isolation in PostgreSQL, described above, is unaffected. This divergence is recorded on the compliance remediation register and is under review.

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

This Section previously represented pseudonymisation by SHA-256 email hashing without qualification. The automations engine persists the recipient's plaintext email address and telephone number in the PostgreSQL step-execution record, and the API holds an in-process cache of plaintext contact details with no expiry that is invalidated only within the writing process, so a rectification or an erasure applied on one instance does not propagate to another until that instance restarts. This divergence is recorded on the compliance remediation register and is under review.

Organizational Measures:

• Confidentiality agreements for all personnel with access to Personal Data
• GDPR and security awareness training (covering, among other things, phishing and password hygiene) for engineering, support and management staff. ⚠️ Not yet delivered: no training programme has been run and no attendance or completion record exists; staff GDPR training remains an open item on the internal compliance register
• Background checks for personnel (to the extent legally permitted)
• Documented information security policy
• Annual security audits and penetration testing (commenced [DATE]). ⚠️ Not yet performed: no third-party security audit and no penetration test is evidenced in [PLATFORM PROVIDER]'s records; Annex II records the first independent penetration test as planned and no external certification audit as having been carried out
• Vendor management procedures (GDPR compliance checks for sub-processors)

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

This Section previously asserted a delivered GDPR training programme and security awareness training covering phishing and password hygiene. No training has been delivered and no attendance or completion record exists, so no training evidence can be produced under the audit right in Section 11.1. This divergence is recorded on the compliance remediation register and is under review.

Detailed Security Documentation: See Annex II: Technical and Organizational Security Measures

4.2 Security Updates

[PLATFORM PROVIDER] shall:

• Regularly review and update security measures to adapt to evolving risks
• Apply security patches to infrastructure and dependencies within 30 days of release (critical vulnerabilities within 7 days)
• Notify Customer of material changes to security measures that may adversely affect protection of Personal Data

4.3 Confidentiality of Processing

[PLATFORM PROVIDER] ensures that persons authorized to process Personal Data:

• Are bound by confidentiality obligations (contractual or statutory)
• Are instructed on their data protection responsibilities. As recorded in Section 4.1, no formal training programme has been delivered and no completion records exist
• Access Personal Data only on a need-to-know basis

---

5. Sub-Processors

5.1 General Authorization

Customer grants [PLATFORM PROVIDER] general authorization to engage sub-processors, subject to the conditions in this Section 5.

Current Sub-Processors: [PLATFORM PROVIDER] engages eleven sub-processors, listed in Annex III. See Annex III: List of Sub-Processors.

Two of those eleven were engaged in production before being disclosed in Annex III and before the notice required by Section 5.3 was given:

• Anthropic PBC (USA), the model provider behind AI-assisted content generation. Anthropic is engaged by [PLATFORM PROVIDER] under a single platform-wide API key; there are no per-organisation credentials and no per-organisation switch, so it is a [PLATFORM PROVIDER] sub-processor and not a Customer-provided integration. Generation prompts embed approved attendee testimonials — the author's display name, free-text quote, company and rating — which are personal data of a Data Subject processed on Customer's behalf.
• SendSMS.ro (Romania), the transactional SMS provider. SendSMS.ro is called on Customer's own credentials and therefore also appears in the Customer-Provided Integrations described in Section 3.4; it is listed in Annex III because [PLATFORM PROVIDER] transmits the recipient's plaintext telephone number and the full message body to it in the course of providing the Services.

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

Annex III previously listed nine sub-processors and did not include the model provider behind AI-assisted content generation or the transactional messaging provider. Both have been processing personal data in production — approved attendee testimonials in the first case, and recipients' plaintext telephone numbers and message bodies in the second — without appearing in the Annex and without the thirty days' advance notice and objection period required by Section 5.3, and neither has an executed sub-processor agreement on file. This divergence is recorded on the compliance remediation register and is under review.

5.2 Sub-Processor Obligations

[PLATFORM PROVIDER] shall:

• Impose on each sub-processor data protection obligations equivalent to those in this DPA
• Ensure sub-processors implement appropriate security measures (Art 32)
• Obtain contractual commitments from sub-processors regarding data deletion, security incident notification, and audit rights
• Remain fully liable to Customer for the performance of sub-processors' obligations

5.3 Changes to Sub-Processors

Notification: [PLATFORM PROVIDER] shall notify Customer of any intended addition or replacement of sub-processors at least 30 days in advance via:

• Email to Customer's registered contact
• Updated Annex III published on the documentation site at the path /legal/platform/annex-sub-processors

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

This Section previously named a dashboard page at Settings → Integrations → Sub-Processors as a notification channel. The dashboard has no sub-processor screen and no announcement surface, so notice is given only by email and by publication of the updated Annex III; Section 5.1 additionally records two sub-processors engaged in production before any notice was given. This divergence is recorded on the compliance remediation register and is under review.

Objection: Customer may object to a new sub-processor on reasonable data protection grounds within 30 days of notification.

If Customer Objects:

• [PLATFORM PROVIDER] shall use reasonable efforts to make available a change to the Services that avoids the objected sub-processor
• If not commercially reasonable, either Party may terminate the affected Services upon 60 days' written notice

No Objection = Consent: If Customer does not object within 30 days, the new sub-processor is deemed accepted.

---

6. International Data Transfers

6.1 Transfer Mechanism

Where Personal Data is transferred outside the European Economic Area (EEA), [PLATFORM PROVIDER] ensures transfers comply with GDPR Chapter V by:

a) Adequacy Decision: Relying on European Commission adequacy decisions (e.g., EU-US Data Privacy Framework for Google Cloud, Meta) b) Standard Contractual Clauses (SCCs): Executing SCCs (2021 version) with sub-processors in non-adequate countries (see Annex IV) c) Binding Corporate Rules (BCRs): If applicable to sub-processors (currently N/A)

6.2 Transfer Impact Assessment (TIA)

[PLATFORM PROVIDER] has conducted a Transfer Impact Assessment pursuant to the "Schrems II" decision (CJEU C-311/18) for all transfers to the United States and other non-EEA countries. Findings:

• Google LLC — Cloud / Firebase ([PLATFORM PROVIDER]'s project): EU-US DPF certified + SCCs in place + EU data residency options (europe-west3 region) → Low risk
• FCM push delivery (Customer's Firebase project): FCM sends push tokens and notification payloads through Google's global FCM infrastructure (USA-based). This transfer is governed by Customer's own Google Cloud DPA and EU-US DPF (Google certified). Customer is responsible for assessing this transfer risk as part of their own GDPR compliance. → Customer's responsibility (see DPA Section 3.4)
• Meta Platforms, Inc. (Conversions API): SCCs in place + limited data categories (no special categories). Data minimisation is partial, not complete: the directly identifying fields that are sent (email address, first name, last name) are transmitted as SHA-256 hashes, but the registration identifier is transmitted to Meta unhashed as the external_id matching key, and the visitor's raw IP address and raw user agent are transmitted unhashed on both the registration event and the landing-page PageView, for every visitor where Customer has enabled the integration and irrespective of any consent decision. 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 → Residual risk not fully mitigated by hashing; assessment under review
• TikTok Pte. Ltd. (Events API): USA / Singapore. Active since 8 May 2026. CompleteRegistration is transmitted for every registration, carrying SHA-256 hashed email address, first name, last name and external identifier, together with the raw client IP address, the raw user agent, the raw ttclid click identifier and the raw _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. There is no advertising-consent gate; the only suppression is a GDPR Art 18 processing restriction. ⚠️ No DPA or Standard Contractual Clauses are on file → Assessment outstanding; transfer operating without a recorded mechanism
• Anthropic PBC (Claude API): USA. Generation prompts, staff-authored instructions, staff-uploaded reference images inlined as base64, and approved attendee testimonials (author's display name, quote, company and rating) are transmitted server-side to api.anthropic.com. No attendee device contacts Anthropic and no cookies are set. ⚠️ The transfer mechanism (Standard Contractual Clauses or an adequacy-based framework) and Anthropic's retention period for API inputs and outputs must be confirmed against the executed agreement → Assessment outstanding
• Cloudflare, Inc.: United States establishment; mandatory reverse proxy terminating TLS for all attendee traffic in production, and Turnstile verification, which transmits the visitor's IP address to Cloudflare. ⚠️ The applicable transfer mechanism has not been assessed or recorded → Assessment outstanding
• Google Ads Enhanced Conversions: Not implemented. No server-side sender exists and no event is transmitted to Google Ads from the Services, so there is no transfer to assess. Previously assessed in this Section jointly with Meta
• Railway Corp.: EU region hosting → recorded here as no transfer. ⚠️ Annex IV treats the same relationship as a transfer to a third country, on the basis that Railway Corporation is established in the United States and administrative access from the United States to data hosted in the EU region cannot be excluded, and records that Railway's Data Processing Terms have been requested and not obtained. This divergence is recorded on the compliance remediation register; the classification is under review

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

This Assessment previously covered four transfers and characterised the Meta transfer as minimised to hashed personal data. Two live transfers to third countries were unassessed — the TikTok Events API, active since 8 May 2026, and the Anthropic Claude API — a third, Cloudflare, is unrecorded, one assessed entry (Google Ads) corresponds to no implemented transfer, and the Meta transfer carries the visitor's unhashed IP address and user agent alongside the hashed identifiers. This divergence is recorded on the compliance remediation register and is under review.

Annual Review: [PLATFORM PROVIDER] commits to reviewing TIA annually and suspending transfers if risks become unacceptable.

6.3 Customer Transfers

If Customer instructs [PLATFORM PROVIDER] to transfer data (e.g., by configuring ad platform integrations), Customer warrants it has:

• Assessed the legality of such transfers under GDPR Chapter V
• Obtained necessary consents or established alternative legal grounds
• Informed Data Subjects of the transfer

---

7. Assistance with Data Subject Rights

7.1 Obligation to Assist

[PLATFORM PROVIDER] shall assist Customer in fulfilling Customer's obligations to respond to Data Subject rights requests under GDPR Articles 15-22, taking into account the nature of processing.

7.2 Types of Requests

Right	Description	[PLATFORM PROVIDER] Assistance
Access (Art 15)	Data Subject requests copy of their data	Provide data export by processing an access or portability request from the dashboard (POST /v1/gdpr/requests/:id/process); there is no separate export endpoint. JSON format containing: contact record, registrations, behavioural events, consents, consent events, segment memberships, email send records, push delivery records (push_sends), device tokens (device_tokens), Firestore contact PII, Firestore consents, Firestore registrations, lead scores and live-session data. Not included: funnel entries and funnel page views, and therefore every element of the Attribution Data and Funnel Visitor Data categories listed in Section 2.6; SMS delivery records; segment broadcast records; automation enrolments and step execution records; and AI generation records. Each must be collected by hand and added to the response. Timeframe: Within 5 business days of Customer request.
Rectification (Art 16)	Data Subject requests correction of inaccurate data	Enable Customer to update contact PII via dashboard. The correction is written to the Firestore contact PII document. PostgreSQL holds no plaintext name, email address or telephone number to correct, save for the automation step-execution records described in Section 4.1, which are not updated. The attendee display name held in the live-session database is not updated and retains its previous value. Propagation to other API instances is subject to the in-process PII cache described in Section 4.1. Rectification cannot be logged as a request type in the GDPR request register, which accepts only deletion, access, portability, objection and restriction. Timeframe: On save, subject to cache refresh on other API instances.
Erasure (Art 17)	Data Subject requests deletion	Deletion pipeline run by a member of staff from the dashboard (Process button on the GDPR request). There is no timer, queue or scheduled job; execution depends on staff action. Deletes from Postgres: email_sends, push_sends, device_tokens and funnel_entries by explicit query matched on org_id with email_hash or contact_id, and the contacts row together with everything that cascades from it; from Firestore: the contact PII and consent documents; from the live database: the actor's attendance, presence, actor record, poll votes, reactions, offer clicks, feedback responses, presence sessions, identity cache, banned and muted flags, and message items in the live and removed streams. Does not delete: sms_sends and segment_broadcast_sends, both keyed by email hash with no foreign key to the contact record; the per-actor deduplication markers and per-actor message counts in the live database; AI generation records (ai_jobs), which are keyed to an entity and a staff user rather than to a contact, so a testimonial quote and its author's name persist in the stored prompt; and live-session data belonging to any actor identifier other than the single identifier stored on each registration, so a re-joining or multi-device attendee retains their display name, chat messages and poll votes. consent_events is retained in pseudonymised form as evidence of consent under Art 7(1). On completion the contact's email address is submitted to the email provider with a permanently-rejected status: erasure at the email provider is a suppression, not a deletion, and by design keeps the plaintext email address on file at the provider indefinitely. Timeframe: 24 hours is an operational target contingent on staff action, not automated behaviour; confirmation provided.
Restriction (Art 18)	Data Subject requests temporary processing suspension	Flag contact as processing_restricted in database. 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. Timeframe: Within 2 business days.
Portability (Art 20)	Data Subject requests machine-readable export	Same as Access (Art 15) — the same JSON export, subject to the same omissions. Timeframe: Within 5 business days.
Objection (Art 21)	Data Subject objects to processing	For marketing emails: immediate unsubscribe. For marketing push: revoke push_marketing consent + suppress from marketing push sends. For behavioral tracking: revoke consent — future events are no longer persisted to the analytics database, but already-recorded events are deleted only through an Art 17 erasure request. Revocation does not stop live-session capture: chat messages, poll votes, reactions, offer clicks and feedback continue to be written to the live database and remain visible to staff, and attendance continues to be recorded against the registration. Timeframe: Immediate for the change of consent state.

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

The Access and Portability rows previously cited an export endpoint that does not exist and described the export as containing all Personal Data. The export is produced only as part of processing an access or portability request, and it omits funnel entries — and with them every element of the Attribution Data and Funnel Visitor Data categories recorded in Section 2.6 — as well as SMS delivery records and segment broadcast records, so those categories are processed but are not reachable through Art 15 or Art 20. This divergence is recorded on the compliance remediation register and is under review.

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

The Erasure row previously described an automated deletion pipeline executing within 24 hours and removing personal data from Postgres, Firestore and the live database in full. Execution is triggered only by a member of staff and several categories survive: the SMS delivery log and the segment broadcast recipient log, the AI generation records containing attendee testimonials, the per-actor markers and message counts in the live database, and all live-session data belonging to any actor identifier beyond the single one recorded on each registration. Erasure at the email provider is a suppression that keeps the plaintext email address on file indefinitely. This divergence is recorded on the compliance remediation register and is under review.

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

The Rectification row previously stated that corrections propagate to all databases immediately, and the Objection row that behavioural events are deleted on withdrawal of consent. Corrections are written to Firestore only and do not reach the attendee display name held in the live database or the in-process caches of other API instances; withdrawal of behavioural-tracking consent changes the consent state and stops further analytics events but deletes nothing already recorded. Separately, where an attendee changes their email address the platform raises a deletion request against the former email hash, which finds no contact under that hash and is recorded as completed without deleting anything, so the request register can contain completions that performed no deletion. This divergence is recorded on the compliance remediation register and is under review.

7.3 Request Workflow

1. Data Subject → Customer: Data Subject submits request to Customer's privacy contact
2. Customer → [PLATFORM PROVIDER]: Customer creates GDPR request in the [PLATFORM PROVIDER] dashboard, in the top-level GDPR section (GDPR → New Request). The form's only subject field is the SHA-256 hash of the Data Subject's email address, so the address must be hashed before the request can be filed
3. [PLATFORM PROVIDER] → Customer: [PLATFORM PROVIDER] processes request and provides export/confirmation via dashboard
4. Customer → Data Subject: Customer delivers response to Data Subject

Direct Requests to [PLATFORM PROVIDER]: If a Data Subject contacts [PLATFORM PROVIDER] directly, [PLATFORM PROVIDER] shall forward the request to Customer within 2 business days and will not respond without Customer authorization.

7.4 Fees

[PLATFORM PROVIDER] provides standard GDPR assistance (export, deletion, rectification via dashboard) at no additional charge as part of the Services.

Custom Requests: Expedited processing (<24h), manual data compilation, or requests requiring significant engineering effort may incur reasonable fees (quoted in advance).

---

8. Assistance with Other GDPR Obligations

8.1 Data Protection Impact Assessments (Art 35)

Upon Customer's request, [PLATFORM PROVIDER] shall provide:

• Description of processing activities
• Categories of Personal Data processed
• Technical and organizational security measures (Annex II)
• Sub-processor information (Annex III)
• Data retention periods
• Assistance in assessing risks and mitigations

Customer Responsibility: Customer is responsible for conducting and documenting the DPIA. [PLATFORM PROVIDER] provides information only.

8.2 Consultation with Supervisory Authorities (Art 36)

If Customer is required to consult a supervisory authority (following a high-risk DPIA), [PLATFORM PROVIDER] shall:

• Provide necessary documentation and evidence of compliance
• Cooperate with Customer's legal counsel
• Implement any changes required by the authority (subject to feasibility and agreement on costs)

8.3 Records of Processing Activities (Art 30)

[PLATFORM PROVIDER] maintains its own Record of Processing Activities (ROPA) as a Processor and makes it available to supervisory authorities upon request.

Template ROPA for Customer: ⚠️ No template ROPA for Customer (as Controller) is currently available for download in the dashboard; no such feature exists in the product. Until one is published, [PLATFORM PROVIDER] supplies the information listed in Section 8.1 on request, from which Customer can compile its own Art 30(1) record.

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

This Section previously directed Customer to download a template Record of Processing Activities from the dashboard. No such download exists in the product and no template has been published. This divergence is recorded on the compliance remediation register and is under review.

---

9. Security Incidents and Personal Data Breaches

9.1 Incident Notification

In the event of a Security Incident, [PLATFORM PROVIDER] shall:

Step 1: Internal Detection and Containment (0-2 hours from awareness)

• Detect incident. Detection is manual and reactive: it depends on a member of staff observing application logs or the system-health endpoint, or on a report from Customer, a Data Subject or a third party. The platform emits structured application logs to standard output, which the hosting provider retains and makes searchable, and exposes an administrator-only system-health endpoint reporting request counters and database read counters; those counters are held in process memory and reset on every restart or deployment. There is no error-tracking service, no on-call paging integration and no automated alerting
• Assemble incident response team
• Contain the breach (isolate affected systems, revoke credentials)

The 0-2 hour containment window runs from the moment [PLATFORM PROVIDER] becomes aware of the incident, as does the Art 33 clock in Section 9.3. Two limits on forensic reconstruction should be noted: the HTTP access log records the request method, path, status, latency, client IP address and request identifier but neither the organisation nor the acting user; and the IP address recorded in the audit log is taken from a caller-supplied forwarding header in preference to the connection's own address, without trusted-proxy validation, so it can be set by the caller.

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

This Section previously offered three routes to incident detection — monitoring, alerts or a staff report. Only the last exists: there is no error-tracking service, no alerting infrastructure and no on-call paging route, so an incident is detected only when a person observes it or someone reports it. This divergence is recorded on the compliance remediation register and is under review.

Step 2: Customer Notification (within 24 hours of becoming aware)

• Notify Customer by email. There is no registered security-contact field on the organisation record and no setting through which Customer can nominate one, so notification is addressed to the email addresses of Customer's administrator users
• Provide initial assessment:
  • Nature of the incident (unauthorized access, data loss, ransomware, etc.)
  • Estimated number of affected Data Subjects
  • Categories of Personal Data involved
  • Likely consequences
  • Measures taken or proposed to address the incident

Step 3: Ongoing Updates

• Provide updates every 48 hours until resolved
• Final incident report within 14 days

9.2 Information to be Provided

[PLATFORM PROVIDER] shall provide (to the extent known):

• Date and time of the incident
• Date and time [PLATFORM PROVIDER] became aware
• Root cause (technical vulnerability, human error, malicious attack)
• Affected systems and databases
• Data exfiltrated or compromised (if any)
• Remediation steps completed
• Recommendations for Customer (e.g., notify Data Subjects, reset credentials)

9.3 Customer's Notification Obligations

Customer is responsible for:

• Assessing whether the incident requires notification to supervisory authority (within 72h of becoming aware, Art 33)
• Assessing whether Data Subjects must be notified (if high risk, Art 34)
• Making the final decision on notifications ([PLATFORM PROVIDER] provides information, Customer decides)

[PLATFORM PROVIDER] shall cooperate with Customer in preparing notifications.

9.4 Documentation

[PLATFORM PROVIDER] shall document all Security Incidents (even if not notifiable) in compliance with Art 33(5), including:

• Facts of the breach
• Effects and consequences
• Remedial action taken

Records retained for: 3 years

9.5 No Limitation of Liability

This Section 9 does not limit [PLATFORM PROVIDER]'s liability for Security Incidents under Section 13 (Liability).

---

10. Deletion and Return of Personal Data

10.1 Upon Termination of Services

Within 30 days of termination or expiration of the Service Agreement, [PLATFORM PROVIDER] shall (at Customer's choice):

Option A: Deletion

• Permanently delete all Personal Data from production systems (databases, file storage)
• Delete from backups within 90 days (backups are immutable, deletion occurs as backups age out)
• Provide written certification of deletion

Option B: Return

• Export all Personal Data in machine-readable format (JSON)
• Provide Customer with secure download link (expires in 14 days)
• Delete all Personal Data after Customer confirms successful download

Default (if Customer does not elect): Deletion (Option A)

How both options are performed. Neither option is automated. The Services provide no organisation-level export and no organisation-level purge: the export functions available are per contact, per contact list and per segment, and there is no operation that deletes an organisation's data across the four stores. Executing either option is therefore a manual operational procedure carried out by [PLATFORM PROVIDER]'s engineering personnel across PostgreSQL, Firestore, the Realtime Database and Cloud Storage. Live-session data in the Realtime Database is removed only by deleting each session or its parent webinar; moving a session to replay or archived status does not prune it.

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

This Section presents deletion and return on termination as options [PLATFORM PROVIDER] executes within thirty days, and Section 10.3 commits an authorised officer to certifying completion. No tenant-level export or purge mechanism exists, and no written checklist governs the manual procedure that would have to substitute for it, so completion cannot presently be evidenced to the standard the certification implies. This divergence is recorded on the compliance remediation register and is under review.

10.2 Legal Retention Exception

[PLATFORM PROVIDER] may retain Personal Data to the extent required by applicable law (e.g., tax records, audit trails) or as necessary to defend against legal claims.

Retained Data:

• Shall be isolated from production systems
• Subject to continued confidentiality and security obligations
• Deleted once legal retention period expires

10.3 Certification

Upon request, [PLATFORM PROVIDER] shall provide a certificate signed by an authorized officer confirming deletion or return.

---

11. Audit Rights

11.1 Customer's Audit Rights

Customer (or its authorized auditor) may conduct audits to verify [PLATFORM PROVIDER]'s compliance with this DPA, subject to:

Frequency: Once per year (more frequently if required by supervisory authority or following a Security Incident)

Notice: At least 30 days' advance written notice

Scope: Inspection of:

• Technical and organizational security measures
• Confidentiality undertakings given by personnel with access to Personal Data (anonymized). ⚠️ Staff training records are not available for inspection: no training programme has been delivered and no completion records exist — see Section 4.1
• Sub-processor agreements (redacted for commercial confidentiality). ⚠️ Four of the eleven sub-processors listed in Annex III have no executed agreement on file — Railway Corp., TikTok Pte. Ltd., SendSMS.ro and Anthropic PBC — See Annex IV for the transfer-instrument status of each
• Security Incident logs
• Access logs for Customer's Personal Data. These consist of the audit log of staff actions and the HTTP access log; the latter does not record the organisation or the acting user, as noted in Section 9.1

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

This Section previously offered staff training records as evidence producible on thirty days' notice under Customer's contractual audit right. No such records exist, so a Customer exercising the audit right would find that part of the agreed audit scope cannot be satisfied. This divergence is recorded on the compliance remediation register and is under review.

Timing: During business hours, with minimal disruption to [PLATFORM PROVIDER] operations

Confidentiality: Auditor must sign [PLATFORM PROVIDER]'s confidentiality agreement

Costs: Customer bears all costs of audit (travel, auditor fees). If audit reveals material non-compliance, [PLATFORM PROVIDER] shall reimburse reasonable costs.

11.2 Industry Certifications (Alternative to Audit)

[PLATFORM PROVIDER] may satisfy audit requirements by:

• Obtaining ISO 27001 or SOC 2 Type II certification
• Providing Customer with annual audit reports from independent third-party auditors

Current Status: ISO 27001 certification targeted for [Q3 2026]. Until then, Customer may exercise full audit rights.

11.3 Supervisory Authority Audits

[PLATFORM PROVIDER] shall cooperate with supervisory authorities and allow inspections as required by law. [PLATFORM PROVIDER] shall notify Customer within 48 hours of any supervisory authority inspection related to Customer's Personal Data.

---

12. Term and Termination

12.1 Term

This DPA takes effect on the Effective Date and continues for the duration of the Service Agreement.

12.2 Survival

The following provisions survive termination:

• Section 4 (Security Measures) — until data deleted
• Section 9 (Security Incidents) — for incidents occurring pre-termination
• Section 10 (Deletion and Return) — until completed
• Section 13 (Liability) — as per limitation periods
• Section 14 (Confidentiality) — indefinitely

---

13. Liability and Indemnification

13.1 Processor Liability (Art 82)

[PLATFORM PROVIDER] is liable for damages caused by processing only if:

• [PLATFORM PROVIDER] has not complied with GDPR obligations specifically directed to processors (Art 28), OR
• [PLATFORM PROVIDER] has acted outside or contrary to lawful instructions from Customer

No Liability if: [PLATFORM PROVIDER] proves it is not in any way responsible for the event giving rise to damage.

13.2 Limitation of Liability

Cap: [PLATFORM PROVIDER]'s total liability for all claims arising out of or related to this DPA shall not exceed:

• Direct Damages: 100% of fees paid by Customer in the 12 months preceding the claim
• Indirect Damages: €0 (excluded entirely — no liability for consequential, incidental, or punitive damages)

Exceptions (No Cap):

• Gross negligence or willful misconduct
• Fraudulent misrepresentation
• Security Incidents caused by [PLATFORM PROVIDER]'s failure to implement agreed security measures
• Violations of Data Subject rights caused by [PLATFORM PROVIDER]'s unauthorized processing
• Liability that cannot be limited under applicable law

13.3 Customer Indemnification of [PLATFORM PROVIDER]

Customer shall indemnify and hold harmless [PLATFORM PROVIDER] from claims, fines, or damages arising from:

• Customer's violation of Applicable Data Protection Laws (e.g., failure to obtain consent)
• Customer's instructions that violate GDPR
• Claims by Data Subjects against [PLATFORM PROVIDER] where Customer is ultimately responsible (e.g., invalid consent)

Process: [PLATFORM PROVIDER] shall promptly notify Customer, allow Customer to control defense, and cooperate reasonably.

13.4 Allocation of Fines

If a supervisory authority imposes a fine jointly on Customer and [PLATFORM PROVIDER] (Art 83):

• Each Party bears responsibility proportional to its fault
• If fault cannot be allocated, Parties agree to negotiate in good faith
• If no agreement within 30 days, matter referred to mediation (see Section 16.3)

---

14. Confidentiality

14.1 Confidential Information

Each Party shall keep confidential all information received from the other Party in connection with this DPA ("Confidential Information"), including:

• Personal Data
• Business terms and pricing
• Security measures and vulnerabilities
• Trade secrets and proprietary methodologies

14.2 Exceptions

Confidential Information does not include information that:

• Is publicly available (not through breach of this DPA)
• Was known to receiving Party prior to disclosure
• Is independently developed without use of Confidential Information
• Is required to be disclosed by law (with prior notice to disclosing Party)

14.3 Use Restriction

Confidential Information may be used only for purposes of this DPA and the Service Agreement.

---

15. Amendments and Modifications

15.1 Changes to this DPA

This DPA may be amended only by written agreement signed by both Parties.

15.2 Changes to Annexes

[PLATFORM PROVIDER] may update Annexes (Sub-Processor List, Security Measures) without Customer signature if:

• Changes are required by law
• Changes do not materially reduce protection of Personal Data
• Customer is notified 30 days in advance (for sub-processors, per Section 5.3)

Material Changes: Require Customer consent via signed amendment.

15.3 Changes to Applicable Laws

If Applicable Data Protection Laws are amended or interpreted by courts/authorities in a manner that affects this DPA, Parties shall negotiate in good faith to amend this DPA to ensure continued compliance.

---

16. General Provisions

16.1 Governing Law

This DPA is governed by the laws of [Country], without regard to conflict of law principles.

16.2 Jurisdiction

Exclusive jurisdiction: Courts of [City, Country]

Exception: Data Subjects may bring claims in their country of residence per GDPR Art 79.

16.3 Dispute Resolution

Step 1: Good Faith Negotiation (30 days) Parties shall attempt to resolve disputes through senior management escalation.

Step 2: Mediation (60 days) If unresolved, Parties agree to mediate before an independent mediator (costs split equally).

Step 3: Litigation If mediation fails, either Party may commence litigation.

16.4 Entire Agreement

This DPA, together with the Service Agreement and Annexes, constitutes the entire agreement regarding Personal Data processing.

Order of Precedence: DPA > Service Agreement (for data protection matters)

16.5 Severability

If any provision is found unenforceable, it shall be reformed to the minimum extent necessary to make it enforceable. Remaining provisions remain in full effect.

16.6 Waiver

No waiver of any provision is effective unless in writing. Waiver of one breach does not waive subsequent breaches.

16.7 Language

This DPA is executed in English. Translations may be provided for convenience, but English version governs.

---

17. Signatures

CUSTOMER (Data Controller):

Signature: ______________________ Name: ______________________ Title: ______________________ Date: ______________________

[PLATFORM PROVIDER] (Data Processor):

Signature: ______________________ Name: ______________________ Title: ______________________ Date: ______________________

---

ANNEXES

• Annex I: Details of Processing (incorporated in Section 2)
• Annex II: Technical and Organizational Security Measures (see separate document: annex-security-measures.md)
• Annex III: List of Sub-Processors (see separate document: annex-sub-processors.md)
• Annex IV: Standard Contractual Clauses (see separate document: annex-sccs.md)

---

Document Version: 1.0 (DRAFT) Prepared by: [Legal Team] Review Status: ⚠️ REQUIRES LEGAL REVIEW — This is a draft for lawyer consultation