Skip to main content
InviziPoll
Get Started
Security & Trust

If someone breaches us, they get ciphertext.

Employee survey encryption built for security review - not badge collecting.

Most security pages list badges. We don't have badges yet - we have an architecture designed so a breach yields nothing readable. This page is the threat model, the key custody design, and the data-handling facts, written for the person filling out the vendor assessment.

Read the encryption docsJump to threat ledger
envelope ML-KEM-768signatures ML-DSA-65operator keys none

Breach impact map

Illustrative breach-impact map: plaintext exists only in the respondent browser; infrastructure stores ciphertext; an attacker with full read access obtains opaque bytes.

BLUF: Bottom line up front

No badges. A verifiable design instead.

InviziPoll does not currently hold SOC 2, ISO 27001, or a published third-party pen-test. Rather than imply otherwise, this page gives you the thing certifications summarize: the actual architecture, threat model, and data-handling facts, specific enough to check our claims against the design.

Everything here is written to be pasted into a vendor assessment. If a question isn't answered, and we'll answer it in writing.

What we claim

  • Responses are encrypted client-side; servers persist ciphertext only
  • Decryption keys are generated and held by the customer
  • Respondent identity, IP, and device are never persisted on ballot/respondent flows

What we don't claim

  • Certifications we haven't earned (no SOC 2 or ISO badge yet)
  • "Zero risk" (residual risks are listed below, not hidden)
  • That cryptography fixes bad questionnaire design (it can't)

Threat model

The threat ledger

Each scenario below states plainly what an attacker obtains. Green rows are defeated by architecture; amber rows are residual risks we expect you to evaluate, and that no vendor can honestly claim away.

Full database compromise

Attacker exfiltrates the production responses store.

Attacker yieldciphertext only
Why

Responses are encrypted in the respondent's browser with the workspace public key. The database never receives plaintext to leak.

Backup / snapshot theft

Offsite backups or DB snapshots are stolen.

Attacker yieldciphertext only
Why

Backups are byte-copies of ciphertext at rest. There is no separate plaintext tier to back up.

Malicious insider (root)

An InviziPoll employee with root access reads production data.

Attacker yieldsame as external attacker
Why

Operators hold no decryption keys. Insider access is architecturally equivalent to a breach: opaque bytes.

Legal compulsion

A subpoena or court order demands respondent answers.

Attacker yieldciphertext only
Why

We can only produce what we possess. We cannot decrypt what we are compelled to hand over.

Network interception

TLS is terminated or downgraded in transit.

Attacker yieldML-KEM-wrapped payload
Why

The response is already envelope-encrypted before it enters the TLS tunnel: transport is a second layer, not the only one.

Compromised admin device

Malware on a workspace admin's machine where keys live.

Attacker yieldresidual risk
Why

Blast radius is that workspace's aggregates; individual responses stay k-anonymity-gated. Endpoint hygiene remains your control, not ours.

Identifiable question wording

A poll author asks "What's your desk number?"

Attacker yieldresidual risk
Why

Cryptography cannot fix a question that de-anonymizes by design. Pair the tool with questionnaire review (see our Anonymity page).

Cryptography & key custody

The primitives, named, and who holds the keys

No proprietary crypto, no vague “bank-grade encryption.” Standard, named primitives and a custody model where losing your key means losing decryption, by design.

Primitives

Every response is envelope-encrypted client-side before submission.

Key encapsulation
ML-KEM-768

FIPS 203: post-quantum KEM, hybridized with X25519.

Signatures
ML-DSA-65

FIPS 204: envelope and admin signing without respondent identification.

Payload cipher
AES-256-GCM

Per-response ephemeral key, wrapped by the KEM envelope.

Transport
TLS in transit

Defense in depth: the payload is opaque even to the tunnel.

Full flow →

Key custody

The custody model is the whole point: we never have the ability to decrypt poll responses.

  1. Keypair generated in your browser

    When a workspace is created, the admin's client generates the keypair locally. Private key material never transits our servers.

  2. We store the public key only

    Servers hold what respondents need to encrypt, nothing that can decrypt poll responses.

  3. Decryption happens in your client

    Aggregates are computed in the authorized admin client, after local decryption, above the k-anonymity threshold.

  4. Lost key = lost poll response data. By design.

    Individual poll responses cannot be recovered if decryption keys are lost: a vendor who can read them for you can read them without you. Admin workspace keys may offer optional server-assisted recovery (email-gated escrow); that path never restores individual response plaintext to InviziPoll.

Data handling

Where plaintext exists, class by class

The column your DPA reviewer actually wants: for each data class, where it is ever readable, and for how long we keep it.

Data classWhere plaintext existsRetention
Poll questionsOur servers (required to render ballots). Questions are authored content, not responses.life of workspace
Individual responsesRespondent's browser only, for seconds. Persisted exclusively as ciphertext.ciphertext · until poll deletion
Respondent identity / IPNowhere: never collected on ballot/respondent flows. No cookies, no fingerprinting, IPs not written to logs.n/a (never persisted)
Aggregate resultsAdmin's client, computed locally after decryption, k-anonymity-gated.not stored server-side
Account & billing dataOur servers: admin emails and billing records, like any SaaS. Kept strictly separate from response data.life of account + legal minimum
Marketing analyticsMarketing pages only: first-party, cookieless, aggregate. Ballot pages carry zero telemetry.See Privacy Policy
Coordinated disclosure

Found something? We want the report.

We run a coordinated disclosure process: report privately, we acknowledge, fix, and credit you when it ships. We don't operate a paid bug bounty yet, saying so beats implying one exists.

Reports that demonstrate any path from stored data to a readable individual response are treated as severity-critical, whatever the mechanism.

Report via or the fields in our published /.well-known/security.txt.

/.well-known/security.txt

Contact: mailto:security@invizipoll.comEncryption: /security/pgp.txtPolicy: /security#disclosurePreferred-Languages: en# acknowledge ≤ 3 business days · fix window by severity# no legal action for good-faith research

Go deeper

Check the claims against the design

Speak-up & compliance feedback

Shadow IT risk, discovery surface, and SIEM audit metadata for security-led speak-up programs, on architecture you can verify.

Speak-up solution

Encryption docs

ML-KEM-768 envelope construction, ML-DSA-65 signatures, and the client-side decryption flow, step by step.

Read encryption docs

Anonymity guarantees

Why ciphertext-only storage matters, what operators can and cannot see, and the honest caveats.

Read the anonymity page

Privacy Policy

The ZeroTelemetry posture for respondent flows, plus exactly what marketing analytics do and don't collect.

View Privacy Policy

FAQ

Employee survey encryption - common security questions

Answers for vendor assessments and architecture review. For speak-up and compliance programs, see secure speak-up feedback.

How does InviziPoll encrypt employee surveys?
Each response is encrypted in the respondent's browser before upload. Servers persist ciphertext only. Authorized admins decrypt aggregate analytics in their own clients using keys they control. InviziPoll operators cannot read individual plaintext answers as part of normal service delivery.
What does ciphertext-only storage mean?
Poll response bodies are stored as opaque encrypted blobs. There is no server-side plaintext of answers, and admin surfaces show aggregates above k-anonymity thresholds rather than individual readable submissions.
Is InviziPoll post-quantum ready?
Yes for the payload cryptography path documented on this page: ML-KEM-768 (FIPS 203) for key encapsulation and ML-DSA-65 (FIPS 204) for signatures, hybridized with classical primitives where the architecture requires it.
Can InviziPoll decrypt my team's survey responses?
No for poll response bodies. Customer-held keys decrypt aggregates in authorized admin browsers. Optional admin vault recovery paths never restore respondent plaintext to InviziPoll.
Your AI summarises written answers. Where does that processing happen?
In the admin's browser tab. A small open-source model (Qwen3.5-0.8B, Apache-2.0, about 432 MiB) runs locally on the answers after they are decrypted on that device. No answer, prompt, embedding, token count or summary is sent to InviziPoll or to any AI provider, and the summariser has no network access and no tools. The only added traffic is a one-time, admin-initiated download of the model's public files from Hugging Face at a pinned commit, verified against sha256 hashes shipped in the app before the model is loaded. Summaries are not stored server-side and never appear on shared results links, snapshots or Slack. They are labelled as AI drafts because a model this size can restate one person's wording closely.
Do you have SOC 2 or ISO 27001?
Not yet. Rather than imply certifications we do not hold, /security publishes the architecture, threat model, and data-handling facts a vendor assessment needs so reviewers can verify claims against the design.

Bring your security questionnaire.

We'd rather answer two hundred hard questions in writing than print a badge. Send the assessment. Architecture answers included.

Read the encryption docs