Identity and session controls in production
Application sessions use a signed, HTTP-only cookie. Protected app sessions expire after 15 minutes of inactivity, and accounts lock for 30 minutes after five failed login attempts.
Time-based one-time-password MFA is available to app accounts and required before workspace owners or platform administrators can use privileged capabilities. Recovery codes are stored as hashes, and MFA reset actions are audited.
- 15-minute inactivity timeout on protected app sessions
- Five-attempt login lockout with a 30-minute lock period
- MFA required for workspace owners and platform administrators
- Administrative access also requires an allowlisted account
- Private APIs default to requiring an authenticated session
Workspace authorization and least privilege
Access is tied to a campaign workspace and a specific voter-data authorization record. Ordinary users cannot reach platform administration, and a workspace cannot reach voter data without the authorization attached to that campaign.
Access review happens before onboarding because campaign identity, role, voter-file source, and permitted purpose matter as much as product setup.
- Per-workspace voter-data authorization
- Campaign and role review before workspace activation
- Separate platform-admin allowlist
- No public voter lookup or unauthenticated export path
Encryption, logging, and data minimization
The application is served over HTTPS. Database connections require TLS, and the managed database provider documents AES-256 encryption for stored data. Secrets are held in deployment environment variables rather than committed to source control.
Voter-data access is written to an append-only application log. Error reporting is configured to avoid default PII collection and to scrub identifiers, cookies, headers, and protected-route details. Marketing analytics and replay tooling are not mounted on protected app routes.
- TLS for browser and database connections
- Managed database encryption at rest
- Append-only voter-data access history
- PII scrubbing in application error reports
- Voter-level AI features disabled by default pending subprocessor approval
Sources: Neon security overview · Vercel security and compliance measures
Retention and support expectations
Raw source files and generated exports are not source-controlled assets. Deletion is treated as complete only through the verified offboarding workflow: each in-scope application and provider artifact must be enumerated, removed, and supported by deletion evidence rather than assumed gone because a workspace was closed.
Campaign contacts can request removal of access-request or onboarding information. Any retained record must fit an enumerated operational, contractual, security, or legal retention basis; unresolved provider deletion or evidence work remains open rather than being described as complete. After an authorized export, the campaign remains responsible for downstream storage, sharing, retention, and deletion.
Current limits and security roadmap
VoterFile does not claim its own SOC 2 or ISO certification today, and this page is not a certification or penetration-test report. The hosting and database providers publish their own security and compliance programs, linked below.
Application dependency and vulnerability review is currently local and release-driven rather than continuously certified. Suspicious-access review is operational and manual. Automated anomaly alerts, formal recurring application security review, and clearer customer-facing retention controls remain roadmap work.
Sources: Neon security overview · Vercel security and compliance measures
Need security and access answers before requesting access?
Review the trust pages, then request a human follow-up on campaign fit, access review, and current beta workflow boundaries.
Questions
Is VoterFile a public voter lookup site?
No. The public site explains the product. Private campaign workflows are gated for qualified political use.
Who is responsible for exported voter data?
The campaign or qualified user remains responsible for how exported voter data is used, shared, retained, and secured after export.
How are private routes treated in production?
Private product, dashboard, and operations routes require authenticated access and are kept separate from public product documentation.
Does access review happen before voter data is loaded?
Yes. The private beta is reviewed before onboarding because campaign fit and permitted use matter before any file-handling workflow starts.
Can campaigns request deletion of access or onboarding information?
Yes. Campaign contacts can ask for access-request or onboarding information to be removed through VoterFile contact channels, subject to any operational or legal recordkeeping needs.
Does VoterFile have its own SOC 2 certification?
No. VoterFile does not claim its own SOC 2 or ISO certification today. Its infrastructure providers publish their own assurance programs, but those provider certifications do not certify the VoterFile application itself.
How can someone report a security concern?
Use the public contact page and clearly label the message as a security report. Do not include live voter records, credentials, or exploit data in an initial message.