OrgPoll Security

Last reviewed: 2026-05-16

OrgPoll is a polling and voting platform for small organizations — churches, clubs, nonprofit boards, HOAs that want a working internal election without paper. This page describes what we do, what we don't claim, and how we treat your data.

Encryption in transit

All traffic between your browser and OrgPoll runs over HTTPS. The API is hosted on Azure App Service, which enforces TLS on every request. The SPA is served via Azure Static Web Apps over HTTPS. We do not accept plain-HTTP requests in production.

Encryption at rest

OrgPoll runs on Azure SQL Database with Transparent Data Encryption (TDE) enabled by default. Database backups inherit the same encryption. The exact key-management posture depends on the Azure SQL service tier we run on — currently a service-managed-key configuration on a Basic/Standard tier.

Ballot anonymity

OrgPoll does not store a link between a member and the option they selected on a vote.

We do store that you voted on a poll — so we can prevent double-voting and so admins can see turnout. We do not store what you voted for in a way tied to your identity.

Concretely: the VoteReceipts table records (PollId, UserId, VotedAt) with a unique constraint on (PollId, UserId). The Votes table records (PollId, OptionId, VotedAt) — and that is all. There is no UserId column on Votes, no foreign key from Votes back to VoteReceipts, and no other column anywhere in the schema that ties the two tables together. An admin with full SQL access cannot reconstruct "who voted for what" because the link does not exist.

This is a structural guarantee, not a cryptographic one. We don't issue verifiable cryptographic receipts (see "What we don't claim" below). The guarantee is that the database schema does not store the link.

Re-introducing this link in the future — for any feature — requires a documented architecture decision. It is not something we'll add quietly.

Audit log

Every meaningful action in OrgPoll is recorded in an admin-visible audit log. Admins for an organization can view it at /audit inside the app. Per-poll history is also shown on each poll's detail page.

Today we record these actions:

Poll lifecycle: poll created, poll published, poll closed, poll deleted, poll structure updated. Member lifecycle: member invited, invite accepted, member role changed, member removed. Voting: a vote was cast.

That is ten distinct actions (Created, Published, Closed, Deleted, StructureUpdated, MemberInvited, InviteAccepted, MemberRoleChanged, MemberRemoved, VoteCast) attached to three entity types (Poll, Member, VoteReceipt). For each event we record the timestamp, who did it (Clerk user ID + email from the verified JWT), the action, and the entity it touched.

For vote-cast events, we record that the vote happened — but the details payload is empty, on purpose, to preserve the anonymity guarantee above. The audit log knows you voted; it does not know what you picked.

The audit log is append-only. We do not currently provide an API to delete or modify audit events, and we do not currently expire old events. If you delete an organization, its audit events are deleted with it (foreign-key cascade).

The audit log is scoped to your organization. You cannot see another organization's events, and another organization cannot see yours. Only members with the Admin or SuperAdmin role can read it — the endpoint returns 403 to everyone else.

We started recording the actor's email address in May 2026. Events recorded before that date show "—" in the Actor column.

What we don't claim

OrgPoll is built for voluntary internal elections in small organizations. It is not a substitute for the following, and we don't claim to be:

  • SOC 2: we have not completed a SOC 2 Type I or Type II audit.
  • ISO 27001 or BSI: we have not been certified under either framework.
  • Cryptographic verifiability: we do not issue Helios-style cryptographic receipts. If you need every voter to be able to mathematically verify their vote was counted, OrgPoll is not the right tool.
  • Statutory HOA elections: state laws in some jurisdictions require paper ballots, supervised polling, or certified election services. We are not certified for those purposes.
  • NLRB-supervised union elections: these have specific procedural requirements we don't meet.
  • Government, civic, or municipal elections: different threat model entirely. Look at Helios, POLYAS, or a certified civic vendor.
  • High-coercion voting environments: hostile-takeover proxy fights, whistleblower votes — anywhere a voter needs strong protection from a determined adversary, including their own org leadership. We are not built for that.
  • Native mobile apps: OrgPoll is a web app.
  • SMS, phone, or IVR voting: we do not currently accept votes over text or phone.

If any of these are hard requirements for you, OrgPoll is the wrong tool. We'd rather you know now.

Data residency and sub-processors

OrgPoll runs on:

  • Microsoft Azure — data hosting (Azure App Service + Azure SQL Database + Azure Static Web Apps). Currently US-East region. If we migrate, we will publish the new region on this page.
  • Clerk — identity provider. Clerk manages user accounts, sessions, and JWTs. Clerk's security posture is documented at clerk.com/security.

We do not use any other sub-processor for processing customer poll or vote data today. If we add one, we will list it here.

Billing runs through Clerk's billing module on a flat-rate annual plan. Card data is handled by Clerk's payment processor; OrgPoll never sees or stores it.

Found something wrong on this page? Open an issue or email security@orgpoll.app — we'd rather hear it.

← back to marketing summaryStart your org free →