RestartiX Webinars

English

Română

English

Română

Appearance

SaaS Terms of Service ​

Between [PLATFORM PROVIDER] ("[PLATFORM PROVIDER]", "we", "us") and [CUSTOMER ORGANIZATION] ("Customer", "you")Effective Date: [DATE]

Note: This document governs the B2B relationship between [PLATFORM PROVIDER] and Customer organizations. It is separate from the Attendee Terms of Service (terms-of-service.md), which governs the relationship between Customer and their event attendees.

1. Acceptance of Terms ​

By subscribing to, accessing, or using the [PLATFORM PROVIDER] event platform ("Services"), you agree to be bound by these Terms of Service ("Terms") and the Data Processing Agreement ("DPA") incorporated by reference.

If you are entering into these Terms on behalf of an organization, you represent and warrant that you have authority to bind that organization.

If you do not agree, do not use the Services.

2. Definitions ​

  • "Services" — the [PLATFORM PROVIDER] event platform, including the public website, acquisition funnels and landing pages, the attendee app, the dashboard, mobile app infrastructure, APIs, Cloud Functions, the marketing automation and segment broadcast engines, inbound e-commerce and form webhooks, tracked-link and referral measurement, automated chat moderation, and the AI generation features described in Section 6.4
  • "Customer Data" — all data submitted to the Services by Customer or Customer's attendees
  • "Attendees" — end users (individuals) who register for and attend Customer's events
  • "Subscription" — Customer's paid or trial access plan for the Services
  • "Documentation" — [PLATFORM PROVIDER]'s technical product documentation at [[PLATFORM PROVIDER DOCS URL]]. The legal corpus published under legal/ — the DPA and its Annexes, the Records of Processing Activities, the Data Protection Impact Assessment, the Data Retention Policy, the Data Breach Response Plan, the DSAR Procedure and the Customer Compliance Guide — is not Documentation for the purposes of the conformance warranty in Section 10.1. Those documents bind the parties, where at all, through the DPA and its Schedules
  • "DPA" — the Data Processing Agreement between the parties (dpa.md)

3. Services ​

3.1 Scope ​

[PLATFORM PROVIDER] provides a multi-tenant event platform enabling Customers to:

  • Host live, evergreen, and replay events
  • Collect attendee registrations and consent records
  • Track attendee behavioral engagement (with consent)
  • Send email, push, and SMS communications to attendees
  • Perform lead qualification and marketing analytics
  • Integrate with advertising platforms for conversion tracking
  • Manage GDPR data subject rights requests via dashboard
  • Build and operate multi-step acquisition funnels and public landing pages, including tracked share and redirect links, referral attribution and unique-visitor measurement on funnel pages
  • Receive inbound order and form webhooks from Customer's e-commerce or form platform (MerchantPro, WooCommerce, Tally or a generic sender) and ingest the personal data those payloads carry
  • Run marketing automations and one-off segment broadcasts against contact segments
  • Generate landing-page briefs, landing-page HTML, marketing copy and webinar poll questions through an AI sub-processor engaged by [PLATFORM PROVIDER] (Section 6.4)
  • Screen attendee chat messages automatically against a Customer-configured banned-word list, which masks matching text in place and removes obfuscated matches from the live chat stream (Section 6.2)
  • Display a simulated attendee count to attendees in place of the true concurrent-viewer figure, where Customer enables that feature (Section 4.1)

WhatsApp is not an available delivery channel. The platform records whatsapp_notifications and whatsapp_marketing consent purposes, displays them on the attendee preferences page and exposes a WhatsApp toggle in the integration settings, but no WhatsApp message can be sent: the messaging engine implements email and SMS steps only, and WhatsApp appears in the product solely as client-side share links. The push_marketing and sms_marketing consent purposes likewise gate nothing.

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

This Section previously listed WhatsApp among the communication channels the Services provide, and the [PLATFORM PROVIDER] legal corpus presents WhatsApp consent as an enforced control. No WhatsApp send path exists in the Services, so the whatsapp_notifications and whatsapp_marketing consents are collected, displayed and stored but gate nothing. This divergence is recorded on the compliance remediation register and is under review.

3.2 Per-Org Domains ​

Each Customer receives three subdomains:

  • webinars.{domain} — public event landing pages
  • live.{domain} — attendee registration and viewing app
  • dashboard.{domain} — administration dashboard

Domain configuration is Customer's responsibility. [PLATFORM PROVIDER] provides DNS instructions.

3.3 Service Availability ​

[PLATFORM PROVIDER] targets 99.5% monthly uptime for the core attendee app and API, excluding scheduled maintenance. Scheduled maintenance will be announced at least 48 hours in advance via dashboard notification or email.

Uptime is measured as availability of the attendee registration and event viewing features. Dashboard and non-critical features are excluded from SLA calculations.

Uptime SLA remedies (if applicable to Customer's plan):

  • < 99.5%: 10% service credit for the affected month
  • < 99.0%: 25% service credit for the affected month
  • < 98.0%: 50% service credit for the affected month

Service credits are the sole remedy for downtime. Credits are applied to next invoice upon written request within 30 days of incident.

3.4 Service Changes ​

[PLATFORM PROVIDER] reserves the right to:

  • Add, modify, or remove features with reasonable notice (material changes: 30 days notice)
  • Update infrastructure, sub-processors, or security measures (per DPA Sections 4.2 and 5.3)
  • Deprecate APIs with 60 days notice

4. Customer Obligations ​

4.1 Acceptable Use ​

Customer agrees NOT to use the Services to:

  • Process data of individuals under 16 years of age without verifiable parental consent
  • Send spam, unsolicited marketing, or communications without valid GDPR consent
  • Collect special categories of data (health, religion, political opinions, etc.) without appropriate safeguards
  • Host events promoting illegal activities, hate speech, or content that violates applicable laws
  • Attempt to access other customers' data or circumvent the platform's multi-tenant isolation
  • Reverse-engineer, decompile, or attempt to extract the platform's source code
  • Use the platform to train AI models without explicit written consent from [PLATFORM PROVIDER]
  • Exceed usage limits specified in Customer's subscription plan
  • Misrepresent audience metrics to attendees, including by presenting a simulated concurrent-viewer figure as if it were a true measurement

Audience-count simulation. Where Customer enables audience-count simulation on a session, the figure shown to attendees in the live chat header is computed as a configured base plus the true concurrent-viewer count multiplied by a configured factor, with a random variation applied each minute so that the figure drifts as organic traffic would. Attendees are shown that figure alone, presented as an "online" count beside a live indicator, with no indication that it is simulated; the true count is visible only to Customer's staff. Customer represents and warrants that any use of this feature complies with Directive 2005/29/EC on unfair commercial practices, including Annex I thereto, and, in Romania, with Legea nr. 363/2007, and that Customer will not use it, or any other engagement metric the Services expose, to deceive attendees.

4.2 GDPR Controller Obligations ​

Customer is the Data Controller for their attendees' personal data. Customer is solely responsible for:

  • Publishing a compliant Privacy Policy and Cookie Policy to attendees
  • Ensuring a valid legal basis for each processing activity
  • Collecting valid consent where required
  • Responding to data subject rights requests ([PLATFORM PROVIDER] provides assistance per DPA)
  • Maintaining their own Records of Processing Activities (ROPA)
  • Notifying their supervisory authority in the event of a breach affecting their attendees
  • Managing the third-party relationships Customer itself configures: NewsmanApp SRL (transactional and marketing email delivery), Customer's own Firebase project where mobile push is used, the advertising platforms Customer enables, SendSMS.ro (transactional SMS) an onward recipient of the recipient's telephone number and the full message body), and any e-commerce or form platform Customer connects to an inbound webhook

Cloudflare, Inc. and Anthropic PBC are not Customer-managed. Cloudflare is a mandatory reverse proxy in front of attendee traffic in production: it terminates TLS for and sees every attendee request, including registration submissions carrying plaintext email address, name and telephone number, and for that traffic the platform takes the client IP address it records or forwards from a Cloudflare-supplied header, which its IP-extraction helper checks before any other proxy header. Anthropic PBC is engaged by [PLATFORM PROVIDER] under a single platform-wide API key, is not a Customer-provided integration and cannot be switched off per organisation. Both are [PLATFORM PROVIDER] sub-processors and are listed as such in Annex III (annex-sub-processors.md).

Sends and disclosures that operate outside the marketing-consent gate. Customer acknowledges that the Services expose supported functions that transmit to, or disclose, contacts without reference to marketing consent, and that Customer alone determines the lawfulness of each such use. These are: segment broadcasts, which read raw segment membership and exclude only contacts subject to a GDPR Article 18 processing restriction and contacts flagged as bounced, complained or opted out; segment conditions that select contacts precisely because they lack a given consent; segment contact export, which returns plaintext email addresses and names irrespective of marketing consent and, on request, includes flagged contacts; and the bulk contact importer, which writes granted data_processing and tos_acceptance consents — and email_marketing where the imported row carries that flag — recorded with the current policy version and a method of "import". 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). Customer's use of these functions constitutes Customer's documented instructions under DPA Section 3, and Customer is responsible for compliance with Article 13 of Directive 2002/58/EC and, in Romania, with Legea nr. 506/2004.

Processing that runs irrespective of the attendee's cookie decision. So that Customer can publish an accurate Privacy Policy and Cookie Policy, [PLATFORM PROVIDER] discloses that the following processing is performed on the legal basis Customer determines as controller and is not exposed as a per-attendee control:

  • 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.
  • 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.
  • Server-side conversion events are mirrored to the advertising platforms Customer has enabled on every registration, with no advertising-consent gate. The TikTok Events API is active and has been since 8 May 2026. It sends CompleteRegistration for every registration: SHA-256 hashed email, first name, last name and external identifier, plus the raw client IP address, the raw user agent, the ttclid click identifier and the _ttp cookie value. No telephone number is transmitted on this path: the field is left empty when the event is assembled, whatever number is held on the contact. Server-side PageView is not mirrored to TikTok. It is suppressed only for contacts subject to a GDPR Art 18 processing restriction. The Meta Conversions API registration mirror operates on the same footing.
  • A pseudonymous visitor identifier — an SHA-256 hash of the visitor's IP address and user agent — is recorded once per visitor per funnel step per day. The hash is stable over time — the same visitor produces the same value on every visit — and is therefore a persistent pseudonymous identifier. There is no consent gate on this measurement.
  • Where a visitor follows a tracked redirect, the platform forwards the campaign parameters and the advertising click identifiers — utm_source, utm_medium, utm_campaign, utm_content, utm_term, fbclid, gclid, ttclid, li_fat_id, referral source — onto the destination URL, which is frequently a third-party site.
  • 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. The Next.js applications self-host their fonts.
  • 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.
  • The cookie banner's outcome is stored only in a first-party cookie on the visitor's device (rx_cookie_consent, a JSON value recording the necessary, analytics and advertising choices, a timestamp and a version, retained for twelve months). It is never written to the consent ledger, so the platform holds no server-side record of who accepted or rejected cookies, and cannot evidence a cookie-consent decision after the fact.

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

This Section previously made Customer solely responsible for establishing a valid legal basis for each processing activity and for collecting valid consent, and Section 4.1 prohibits Customer from sending communications without valid GDPR consent. The Services in fact expose supported functions that transmit to, and disclose, contacts without reference to marketing consent, and perform the tracking described above irrespective of the attendee's cookie decision and without a per-organisation control to disable it, so Customer cannot discharge that responsibility in full through the product as delivered. This divergence is recorded on the compliance remediation register and is under review.

See the Customer Compliance Guide (customer-compliance-guide.md) for detailed guidance.

4.3 Credential Security ​

Customer is responsible for:

  • Securing all dashboard credentials. Dashboard sign-in is by email address and password through Firebase Authentication; the Services provide no multi-factor authentication, so credential strength and credential custody are the only controls available to Customer
  • Keeping Firebase service account credentials confidential (if using mobile push)
  • Revoking access for staff who leave the organization
  • Reporting any suspected unauthorized access to [PLATFORM PROVIDER SECURITY EMAIL] immediately

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

This Section previously recommended that Customer enable multi-factor authentication on dashboard accounts. No multi-factor authentication capability exists anywhere in the Services, so the recommendation was not actionable by Customer and no second factor protects a dashboard account. This divergence is recorded on the compliance remediation register and is under review.

Staff roles. The platform defines four staff roles — admin, moderator, marketer and staff — mapped to three permission groups (marketing, live, settings). staff holds no permission group and is effectively read-only; marketer holds the marketing group; moderator holds the live group; admin holds all three. A role is chosen explicitly when the account is created; there is no read-only default. Administrator privileges are required for exactly one endpoint, the audit-log listing. Every other destructive action — deleting webinars, sessions, funnels, segments, pages, offers, polls, uploads and testimonials — is authorised by the marketing or live permission group, which the non-administrator marketer and moderator roles satisfy. Customer should assign roles on that basis rather than on the assumption that only administrators can delete data.

4.4 Accurate Information ​

Customer must provide accurate billing information, organizational details, and technical configurations. [PLATFORM PROVIDER] is not responsible for service failures caused by Customer's incorrect configuration.

5. Subscription and Payment ​

5.1 Plans and Pricing ​

Subscription plans, pricing, and included feature sets are defined at [[PLATFORM PROVIDER PRICING URL]] and in Customer's order form. Plans may include limits on:

  • Monthly active attendees
  • Number of events per month
  • Storage (recording/replay files)
  • API call volume
  • Team members (staff seats)

5.2 Billing ​

  • Subscriptions are billed in advance (monthly or annually)
  • Payment is due within 14 days of invoice date
  • Late payment may result in service suspension after 7 days written notice
  • All fees are exclusive of VAT/taxes; Customer is responsible for applicable taxes

5.3 Plan Changes ​

  • Upgrades: Effective immediately; prorated billing
  • Downgrades: Effective at next billing cycle
  • Overages: Usage exceeding plan limits will be billed at the overage rate specified in the plan, or may result in service throttling

5.4 Refunds ​

  • Annual plans: 30-day money-back guarantee from initial purchase only
  • Monthly plans: No refunds for partial months
  • Downtime credits: Per Section 3.3 above — sole remedy for service unavailability

5.5 Subscription Termination by Customer ​

Customer may cancel their subscription at any time by emailing [PLATFORM PROVIDER BILLING EMAIL]. There is no self-service cancellation route: the dashboard exposes no subscription or billing screen. Cancellation takes effect at the end of the current billing period. No refund for the remaining period.

Upon cancellation, Customer has 30 days to request an export of Customer Data and to elect deletion or return under DPA Section 10. Neither the export nor the deletion is a self-service operation; both are performed as described in Section 13.4.

6. Intellectual Property ​

6.1 [PLATFORM PROVIDER] IP ​

The [PLATFORM PROVIDER] platform, including all software, algorithms, designs, documentation, and trademarks, is the exclusive property of [PLATFORM PROVIDER]. Customer receives a limited, non-exclusive, non-transferable, revocable license to use the Services during the Subscription period.

Customer may NOT:

  • Copy, reproduce, or create derivative works of the platform
  • Sublicense the platform to third parties
  • Remove any proprietary notices or branding

6.2 Customer IP and Data ​

Customer retains all rights to Customer Data. Customer grants [PLATFORM PROVIDER] a limited license to process Customer Data solely to provide the Services.

Automated content moderation. Customer authorises [PLATFORM PROVIDER] to screen attendee-generated chat content against the banned-word list Customer configures for a session, and to alter, remove and retain that content accordingly. Where a message matches the list, the matching text is replaced in place with a fixed-length mask. Where an obfuscated spelling still matches after masking, the whole message is removed from the live chat stream and the complete original message, together with the identity of its author and the reason for removal, is written to a separate removed-message stream readable by Customer's staff. The attendee is not notified in either case. The same screening may be applied retroactively to messages already stored. Removed messages are retained for staff review; removal from the live stream does not delete them.

[PLATFORM PROVIDER] does NOT:

  • Share Customer Data with other customers
  • Use Customer Data to train AI models
  • Use Customer Data for [PLATFORM PROVIDER]'s own advertising

[PLATFORM PROVIDER] does, on Customer's instruction and as an inherent part of the Services:

  • Transmit Customer Data to the advertising platforms Customer enables, including server-side conversion events sent without an advertising-consent gate (Section 4.2)
  • Transmit Customer content and approved attendee testimonials to Anthropic PBC when a member of Customer's staff initiates an AI generation (Section 6.4)
  • Transmit attendee telephone numbers and message bodies in plaintext to SendSMS.ro, when an SMS message is sent

Retention of Customer Data after subscription termination is governed by DPA Section 10 and by Section 13.4 of these Terms.

6.3 Feedback ​

If Customer provides feedback, suggestions, or feature requests, Customer grants [PLATFORM PROVIDER] a royalty-free, perpetual license to use such feedback to improve the Services. [PLATFORM PROVIDER] is not obligated to implement any feedback.

6.4 AI-Generated Output ​

The Services include AI generation features: landing-page briefs, landing-page HTML and marketing copy in the page editor, and webinar poll questions. These are executed server-side by Anthropic PBC (Claude API) under a single platform-wide API key held by [PLATFORM PROVIDER]. Anthropic PBC is a [PLATFORM PROVIDER] sub-processor, not a Customer-provided integration, and cannot be disabled per organisation.

Inputs. A generation request carries the organisation name, the webinar title, description and type, the page brief and style preset, staff-authored custom instructions, staff-uploaded reference images from Customer's media library inlined as base64, text extracted from any third-party reference URL a member of staff supplies, and approved attendee testimonials — the attendee's display name, free-text quote, company and rating. Chat message content, registration records, contact email addresses, telephone numbers, poll answers, attendance data and behavioural events are not sent. Poll generation in particular receives only the webinar title, description and type, the organisation name and any staff instructions. Every request's system prompt, user prompt, custom instructions, model identifier, full model output and token counts are retained in [PLATFORM PROVIDER]'s analytics database together with the identifier of the member of staff who started the job.

Ownership. As between the parties, [PLATFORM PROVIDER] assigns to Customer all right, title and interest it may have in output generated for Customer through these features, and such output is Customer Data. [PLATFORM PROVIDER] makes no representation that any such output is original, or that it is capable of protection by copyright or any other intellectual property right in any jurisdiction. Identical or substantially similar output may be generated for other customers.

No warranty. AI-generated output is provided "AS IS". [PLATFORM PROVIDER] does not warrant that it is accurate, complete, fit for any purpose, free from bias or error, or free from infringement of any third party's intellectual property, publicity or other rights, and does not warrant that it complies with advertising, consumer protection or sector-specific law. Customer is solely responsible for reviewing, verifying and approving AI-generated output before publication or distribution.

Indemnity carve-out. The indemnity in Section 12.2 does not extend to any claim arising out of AI-generated output, output derived from material Customer or its staff supplied as generation input, or Customer's publication or use of such output. Claims of that kind fall within Customer's indemnity in Section 12.1.

Attendee testimonials. Attendees are not asked for, and are not informed of, any consent covering the transmission of their testimonial to an AI provider, and AI generation is treated as a staff-initiated action under Customer's legitimate interest in producing marketing content. AI generation records are keyed to an entity and to a staff user rather than to a contact, 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. Customer determines the lawful basis for this processing as controller.

7. Confidentiality ​

7.1 Definition ​

"Confidential Information" means non-public information disclosed by either party that is designated as confidential or that reasonably should be understood to be confidential (including Customer Data, pricing, technical architecture, business plans).

7.2 Obligations ​

Each party agrees to:

  • Keep the other party's Confidential Information strictly confidential
  • Use Confidential Information only for the purpose of performing under these Terms
  • Disclose Confidential Information only to employees/contractors with a need to know, under equivalent confidentiality obligations

7.3 Exceptions ​

Confidentiality obligations do not apply to information that:

  • Is or becomes publicly available through no fault of the receiving party
  • Was already known to the receiving party before disclosure
  • Is independently developed without use of Confidential Information
  • Is required to be disclosed by law or court order (with prompt notice to disclosing party where permitted)

8. Data Protection ​

The parties' data protection obligations are governed exclusively by the Data Processing Agreement (DPA) attached as Schedule A. In the event of conflict between these Terms and the DPA on data protection matters, the DPA prevails.

Key DPA obligations (summary):

  • [PLATFORM PROVIDER] processes Customer Data only on Customer's documented instructions
  • [PLATFORM PROVIDER] implements appropriate technical and organizational security measures
  • [PLATFORM PROVIDER] notifies Customer within 24 hours of becoming aware of a personal data breach, per DPA Section 9.1. The 72-hour period in Article 33 GDPR is a separate obligation: it is the deadline for Customer, as controller, to notify its supervisory authority
  • [PLATFORM PROVIDER] deletes or returns Customer Data upon termination, per DPA Section 10. Section 13.4 of these Terms records how that is performed and which categories no automated process removes

9. Security ​

[PLATFORM PROVIDER] implements security measures as documented in Annex II (Security Measures, annex-security-measures.md). Key measures include:

  • Encryption at rest and in transit
  • Row Level Security in PostgreSQL — organisation-level data isolation in the relational database only, as described below
  • Firebase Authentication with JWT expiry
  • Access logging and an append-only audit trail of staff actions

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

Its residual limits are as follows:

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

The three Firebase stores do not enforce organisation-level isolation:

Realtime Database (live-session data). 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.

Cloud Storage (uploaded media and generated pages). 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.

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

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

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

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

This Section previously offered "Row Level Security (org-level data isolation)" as the measure that isolates one Customer's data from another's, and Section 4.1 prohibits Customer from circumventing "the platform's multi-tenant isolation". Row Level Security operates in PostgreSQL only; the Realtime Database, Cloud Storage and Firestore rules contain no organisation check, so the isolation the Section described is not platform-wide. This divergence is recorded on the compliance remediation register and is under review.

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

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

Monitoring and alerting. The platform emits structured application logs to standard output, which the hosting provider retains and makes searchable, and exposes an administrator-only system-health endpoint reporting request counters and database read counters. Those counters are held in process memory and reset on every restart or deployment. There is no error-tracking service, no on-call paging integration and no automated alerting: incident detection depends on a person observing logs, the health endpoint or a customer report.

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

This Section previously listed "regular security reviews" among the key security measures, and Annex II describes automated dependency scanning, static analysis, an enforced continuous integration pipeline and automated alerting. No continuous integration configuration exists in the repository, no automated security scanning is performed and no alerting integration exists; the checks described are run manually at the developer's discretion. This divergence is recorded on the compliance remediation register and is under review.

Customer is responsible for securing their own systems, credentials, and integrations.

10. Warranties and Disclaimers ​

10.1 [PLATFORM PROVIDER] Warranties ​

[PLATFORM PROVIDER] warrants that:

  • The Services will substantially conform to the technical product Documentation, as defined in Section 2, during the Subscription period. This warranty does not extend to the legal corpus published under legal/, which Section 2 excludes from the definition of Documentation
  • [PLATFORM PROVIDER] has the right to provide the Services to Customer
  • [PLATFORM PROVIDER] will process Customer Data in compliance with the DPA and applicable data protection laws

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

This Section previously warranted that the Services would substantially conform to the Documentation, which Section 2 defined to include the whole legal corpus published under legal/. Several of those documents contain statements the behaviour of the Services does not support, including automated retention and deletion, automated dependency and security scanning, automated alerting, and organisation-scoped isolation in the Firebase stores; each such statement is now marked in the document in which it appears. Section 2 has accordingly been narrowed so that the conformance warranty covers the technical product documentation only. This divergence is recorded on the compliance remediation register and is under review.

10.2 Disclaimer ​

EXCEPT AS EXPRESSLY STATED IN SECTION 10.1, THE SERVICES ARE PROVIDED "AS IS" WITHOUT WARRANTIES OF ANY KIND, INCLUDING IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT.

[PLATFORM PROVIDER] does not warrant that:

  • The Services will be uninterrupted or error-free
  • All bugs will be corrected within a particular timeframe
  • The Services are suitable for any specific regulatory environment or industry
  • AI-generated output is accurate, complete, original, non-infringing, or suitable for publication or distribution without human review (Section 6.4)

11. Limitation of Liability ​

11.1 Cap on Liability ​

[PLATFORM PROVIDER]'S TOTAL LIABILITY ARISING OUT OF OR RELATED TO THESE TERMS SHALL NOT EXCEED THE FEES PAID BY CUSTOMER IN THE 12 MONTHS PRECEDING THE CLAIM.

11.2 Exclusion of Consequential Damages ​

NEITHER PARTY SHALL BE LIABLE FOR INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES, INCLUDING LOST PROFITS, LOST DATA, OR BUSINESS INTERRUPTION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

11.3 Exceptions (No Cap) ​

The limitations above do NOT apply to:

  • Gross negligence or willful misconduct
  • Fraud or fraudulent misrepresentation
  • [PLATFORM PROVIDER]'s liability under the DPA for personal data breaches caused by [PLATFORM PROVIDER]'s failure to implement agreed security measures
  • Liability that cannot be limited under applicable law (including GDPR Article 82)
  • Customer's indemnification obligations

12. Indemnification ​

12.1 Customer Indemnification ​

Customer agrees to indemnify, defend, and hold harmless [PLATFORM PROVIDER] and its officers, directors, and employees from any claims, losses, damages, or expenses (including legal fees) arising from:

  • Customer's violation of these Terms or the DPA
  • Customer's failure to comply with GDPR as Data Controller
  • Customer's attendees' claims arising from Customer's use of the platform
  • Customer's violation of third-party rights
  • Content Customer uploads or distributes via the platform (event content, chat messages)
  • Customer's use of the audience-count simulation feature, or of any other engagement metric the Services expose, in a manner that misrepresents audience size to attendees
  • Customer's use of segment broadcasts, segment contact export, consent-status segmentation or the bulk contact importer, and any communication sent outside the marketing-consent gate (Section 4.2)
  • Customer's publication or distribution of AI-generated output (Section 6.4)

12.2 [PLATFORM PROVIDER] Indemnification ​

[PLATFORM PROVIDER] agrees to indemnify Customer from third-party claims alleging that the Services, as provided and used in accordance with these Terms, infringe a third party's intellectual property rights.

This indemnity does not extend to Customer Data, to Customer content, to material supplied by Customer or its staff, or to AI-generated output and any claim within the scope of the carve-out in Section 6.4.

13. Term and Termination ​

13.1 Term ​

These Terms are effective from the Effective Date and continue for the Subscription period, automatically renewing unless cancelled per Section 5.5.

13.2 Termination for Cause ​

Either party may terminate these Terms immediately on written notice if:

  • The other party materially breaches these Terms and fails to cure the breach within 14 days of written notice
  • The other party becomes insolvent, files for bankruptcy, or ceases business operations
  • The other party violates the DPA in a way that cannot be remedied

13.3 Termination for Convenience ​

Customer may terminate per Section 5.5 (subscription cancellation). [PLATFORM PROVIDER] may terminate for convenience with 60 days written notice, with pro-rata refund of prepaid fees for the remaining period.

13.4 Effect of Termination ​

Upon termination:

  • Customer's access to the Services is suspended
  • Customer has 30 days to request an export of Customer Data and to elect deletion or return under DPA Section 10
  • [PLATFORM PROVIDER] deletes or returns Customer Data in accordance with DPA Section 10
  • Sections 6 (IP), 7 (Confidentiality), 8 (Data Protection), 11 (Liability), 12 (Indemnification), and 14 (Governing Law) survive termination

How export and deletion are performed. 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 an export or a deletion on termination is therefore a manual operational procedure carried out by [PLATFORM PROVIDER]'s engineering personnel across PostgreSQL, Firestore, the Realtime Database and Cloud Storage, and not a product feature.

Categories that no automated process removes, and that persist after termination until they are removed by hand, include:

  • Live-session data in the Realtime Database. Live-session data in the Realtime Database is retained indefinitely. There is no scheduled cleanup function: the Cloud Functions codebase exports ten functions, of which nine are database triggers and one is a minutely presence reconciler, and none deletes session data. Moving a session to replay or archived status does not prune it either — the lifecycle job writes a statistics snapshot to Firestore and performs no deletion in the Realtime Database. The only operations that remove a live-session node are the manual deletion of a session and the manual deletion of the parent webinar. Chat message text, attendee display names, presence and attendance records, poll votes, reactions, offer clicks and feedback responses therefore persist for the lifetime of the webinar record.
  • The audit log and the data-subject request register. 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. 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 SMS delivery log and the segment-broadcast recipient log. 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.
  • AI generation records. The stored prompt for each generation retains any approved attendee testimonial it contained, including the testimonial author's display name. Those records are keyed to an entity and to a staff user rather than to a contact (Section 6.4).
  • The email provider's suppression list. Erasure at the email provider is a suppression, not a deletion. On completing an erasure the platform submits the contact's email address to the email provider with a permanently-rejected status, so that no future message can be delivered to it. By design this keeps the plaintext email address on file at the provider indefinitely.

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

These Terms previously stated that Customer has thirty days to export Customer Data and that [PLATFORM PROVIDER] then permanently deletes all Customer Data. No tenant offboarding mechanism exists: there is no organisation-level export, no organisation-level purge, and the categories listed above are reached by no automated deletion path, so neither the export nor the deletion previously described can be executed or evidenced as a product operation. This divergence is recorded on the compliance remediation register and is under review.

14. Governing Law and Disputes ​

14.1 Governing Law ​

These Terms are governed by Romanian law and applicable EU law (including GDPR), without regard to conflict-of-law principles.

14.2 Dispute Resolution ​

The parties agree to first attempt informal resolution. Either party may initiate informal resolution by written notice; the parties will negotiate in good faith for 30 days.

If informal resolution fails:

  • EU/EEA Customers: Exclusive jurisdiction in the courts of [City, Romania]
  • Non-EEA Customers: Disputes may be submitted to ICC arbitration (Paris), unless otherwise agreed in writing

14.3 EU Consumer Rights ​

These Terms do not waive any mandatory consumer protection rights that apply under EU law.

15. General ​

15.1 Entire Agreement ​

These Terms, together with the DPA, Order Form, and any addenda, constitute the entire agreement between the parties regarding the Services. They supersede all prior agreements and representations.

15.2 Order of Precedence ​

In case of conflict: DPA > these Terms > Order Form > Documentation.

15.3 Amendments ​

[PLATFORM PROVIDER] may update these Terms with 30 days notice for material changes. Continued use after the notice period constitutes acceptance. Customers may reject material changes by terminating their Subscription before the changes take effect (pro-rata refund provided).

15.4 Assignment ​

Customer may not assign these Terms without [PLATFORM PROVIDER]'s written consent. [PLATFORM PROVIDER] may assign to an affiliate or successor in a merger/acquisition, with 30 days notice to Customer.

15.5 Force Majeure ​

Neither party is liable for delays or failures caused by events beyond reasonable control (natural disasters, internet outages, cyberattacks, government actions, sub-processor failures). The affected party must notify the other within 5 business days and resume performance as soon as reasonably possible.

15.6 Severability ​

If any provision is found unenforceable, the remaining provisions remain in full effect. The unenforceable provision will be modified minimally to make it enforceable.

15.7 No Waiver ​

Failure to enforce any right or provision does not constitute a waiver.

15.8 Notices ​

Legal notices must be in writing and delivered by email to:

  • [PLATFORM PROVIDER]: [PLATFORM PROVIDER LEGAL EMAIL]
  • Customer: Email address on Customer's account (or as specified in Order Form)

16. Contact ​

[PLATFORM PROVIDER] [Address, City, Country] [Company Registration Number] VAT: [VAT Number]

Email: [PLATFORM PROVIDER LEGAL EMAIL] Support: [PLATFORM PROVIDER SUPPORT EMAIL] Security: [PLATFORM PROVIDER SECURITY EMAIL] Billing: [PLATFORM PROVIDER BILLING EMAIL]

Schedule A — Data Processing Agreement ​

The Data Processing Agreement (dpa.md) is incorporated into these Terms by reference and forms Schedule A.

Document Version: 1.0 (DRAFT) Prepared by: [Legal Team] Review Status: ⚠️ REQUIRES LEGAL REVIEW — Must be reviewed by qualified legal counsel before use with customers.

Last Updated: [DATE]