Skip to main content
InviziPoll
Sign inStart free trial
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-65unlocked keys we hold none

Breach impact map

Illustrative breach-impact map: an answer is readable only in the respondent's browser and in your team's browsers; our infrastructure stores ciphertext and keeps a respondent's IP only as a one-day keyed hash; 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 and device are never stored on ballot flows. IPs are kept only as a one-day keyed hash, not the address

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 key that can open a response. 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

An attacker on an admin's machine can see what that admin can open: the workspace's results and written comments, as they're released. Answers still held back aren't sent to any browser until they're released, and our servers still hold nothing readable. 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. Your key backup is locked in your browser before it reaches us, with your password, your recovery key or a passkey. Nothing we store can open it. Your recovery key never reaches us at all.

  2. We store public keys and locked backups

    Servers hold what respondents need to encrypt, plus key backups locked in your browser. Nothing we store can decrypt a poll response.

  3. Decryption happens in your client

    Responses are decrypted in the authorized admin's browser, and only once the poll's minimum group has answered. Admins see totals and charts, and written comments word for word, in a shuffled list with no name, time or order attached. Where the poll allows it, anyone who'd rather not be read can send just the topics they pick instead.

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

    If you lose your keys along with your password and your recovery key, and no one else on your team holds the workspace key, individual poll responses cannot be recovered: a vendor who can read them for you can read them without you. Confirming your email only releases your locked key backup to you; it never opens it. An owner can restore a colleague's access only after confirming a code with them directly; we can't do it for them.

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 responsesThe respondent's browser, and your team's browsers once results are released. Stored only as ciphertext.ciphertext · until poll deletion
Speak-up reportsThe reporter's browser and your authorized admins' browsers. Stored only as ciphertext. Speak-up inboxes work differently: once the first reports are in, each new report appears on its own, so authorized admins read and reply to it individually. It still carries no name, account or IP address, and replies reach the reporter only through a return code that never reaches us.ciphertext · until poll deletion
Respondent identity / IPIdentity: nowhere, never stored on ballot flows, no fingerprinting. Respondent IP: never stored. Rate limiting keeps a one-day keyed hash, not the address.identity n/a · IP hash key rotates daily
ResultsYour team's browsers, computed after decryption. Results you choose to share, such as a public results page or a snapshot, are stored as an encrypted, signed summary that the people you share the link with can open.only what you share · until it expires or you remove it
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 results in their own browsers using keys they control. Admins see totals and charts, and written comments word for word, in a shuffled list with no name, time or order attached. Where the poll allows it, anyone who'd rather not be read can send just the topics they pick instead. 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. Nothing shows to admins until the poll's minimum group has answered; after that, admins see totals and charts, and written comments word for word, in a shuffled list with no name, time or order attached. Where the poll allows it, anyone who'd rather not be read can send just the topics they pick instead.
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 results only 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.
Where is our data stored?
In the United States, on AWS (us-east-1). We don't offer regional hosting yet. Answers are encrypted on the respondent's device before they reach us, so the answers we hold are unreadable to us wherever they're stored.
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