Data retention and metadata boundary

Heads up: Retention (days after close) is separate from the 3+ responses rule for viewing aggregates (see Viewing results). The platform also avoids per-response admin metadata by design.

Retention (admin-configured)

When creating a poll, the Data retention after poll closes setting offers 7, 14, 30, 60, or 90 days. Responses are permanently deleted after this period.

This is a product-level purge window for encrypted responses after the poll ends - separate from the unlock threshold (3 responses) which governs when aggregates become visible.

What outlives the purge, and what does not

A few artifacts are deliberately kept past a poll's response purge, and all of them are aggregate-only ciphertext:

Series trend snapshots. When a wave in a recurring pulse series unlocks, the admin's browser archives its counts and distributions, encrypted to that wave's poll key, so the trend line survives the purge without extending any respondent's data lifetime.
Shared slices. A share-a-slice link stores an encrypted aggregate snapshot whose key exists only in the link. It expires on the schedule you chose (7, 30, or 90 days), can be revoked earlier, and is deleted with the poll.
Published actions. You said, we did commitments are admin-authored plaintext, like a poll title, and stay with the poll.

Deleted with the poll, and never kept past it: responses, reply mailboxes and threads, and every snapshot above.

What the platform avoids storing

InviziPoll does not store row-level response timelines, IP-derived rankings, or per-ballot audit trails in the admin analytics surface. Operational logs may record admin actions (for example who changed a setting) without turning the respondent data store into a per-person feed.

Tenant purge

Irreversible tenant purge workflows destroy stored data without decrypting content - consistent with zero-knowledge operations.