Security

Data & Security

How Nabad handles session and participant data — written for the questions procurement teams ask.

Last updated: 7 September 2026

Nabad runs live, multilingual polling in rooms where the audience does not share a language. Participants join with a 6-digit code and no account. This page describes where their data lives, who processes it, how long we keep it, and how to have it removed. For security or data-protection questions, or to complete a security questionnaire, email info@nabad.live.

1. Where session data is stored

Application data — accounts, sessions, questions, and participant responses — is stored in a managed PostgreSQL database (Neon). Live vote tallies during a session are held in a managed Redis cache (Upstash). The application runs on DigitalOcean. Our current data region is the United States (AWS US-East). Customers with a regional data-residency requirement can contact us to discuss options.

2. What we collect from participants

Participants do not create accounts. For each participant we process:

A random device identifier generated in the browser, used only to prevent double-voting within a session. It is not linked to any real-world identity.
Their answers — a vote, a word, a short text response, a ranking, or a position on a map.
An optional display name. Name collection is a per-session setting that hosts can turn off; it is on by default, so unless the host turns it off, responses carry the name the participant typed and the host can see it. With it off, responses carry no name.

We do not ask participants for an email, phone number, or login, and we use no advertising cookies anywhere. No analytics or tracking script runs on the pages a participant sees — the join page, the voting page and the presenter screen carry none. Our public marketing pages use Cloudflare Web Analytics, which counts visits without cookies. Browser local storage is used only to remember a participant’s chosen reading language and which questions they have already answered.

3. Retention

Data	Retention
Session results & participant responses	Kept until the host deletes them. Closing a room does not delete it, so a host can reopen the results sheet later, on any plan. We do not run an automatic deletion schedule today; if your organisation needs a fixed retention period, contact us and we will agree one in writing.
Account data	Kept while the account is active; deleted within 30 days of account deletion, except where retention is legally required.
Live vote cache (Redis)	Cleared when the session ends.

4. Subprocessors

We share data with these providers only to deliver the service. We do not sell data.

Provider	Purpose	Data
Neon	Primary database	Accounts, sessions, responses
Upstash	Live vote cache (Redis)	Transient vote tallies
Google (Gemini API)	AI room insights and recap (Pro sessions); translation of answers when a host requests it (any plan)	Participant open-text, Q&A and word-cloud answers (see section 5)
Stripe	Payments	Host billing details — card data never touches our servers
Google (Analytics)	Marketing-site analytics	Page views on our public pages. Not loaded on the join page, the voting page or the presenter screen.
Resend	Transactional email	Host email address
Sentry	Error monitoring	Stack traces and request context from server errors, which can include a session identifier
DigitalOcean	Application hosting	Application traffic

5. AI processing

Participant text reaches Google’s Gemini API in exactly two situations, and no others:

AI room insights and recap — Pro sessions only. In a session owned by a Pro account, answers to word-cloud, open-text and Q&A questions are sent while the session is running, to read sentiment and group similar answers into themes, and once more when the session ends, to write the recap emailed to the host. Sessions owned by Free accounts are not sent for this. Accounts created before 1 September 2026 keep the AI they signed up with, so their sessions are still sent.
Translation — any plan, and only on request. When a host asks to translate participant answers on the presenter screen, the answers being translated are sent for that translation. Nothing is sent unless the host asks.

Text is sent for that processing only. It is not used to build a profile of any participant, and display names are not sent. Institutional customers can request our current data-processing and retention terms for this provider.

6. Security controls

All traffic is encrypted in transit over HTTPS (TLS).
Passwords are stored only as bcrypt hashes; we never see the plaintext.
Session identifiers are unguessable, and every read of a session’s results is authorised against the owning account, server-side, on every request.
Participant text is escaped wherever it is displayed, and response length is capped on the server.
The 6-digit join endpoint is rate-limited to prevent code guessing, and voting is rate-limited per participant.
Access to production systems is restricted to the core team.

7. GDPR position

For host account data, Nabad is the data controller. For participant responses, the host running the session is the controller and Nabad is the processor acting on their behalf. Our lawful basis is the legitimate interest of the host in running their session and the performance of our contract with the host. A data processing agreement is available to institutional customers on request.

8. How to request deletion

A host can delete any session — and all of its responses — from their dashboard at any time, and can delete their entire account from their profile. For any other deletion request, including a participant asking to remove a response, email info@nabad.live. We action verified deletion requests within 30 days.

9. Breach notification

If we become aware of a personal-data breach affecting your data, we will notify affected customers without undue delay and, where required, within 72 hours of becoming aware — describing what happened, what data was involved, and the steps we are taking.