Security & access control.

Data protection

• Encryption in transit. All traffic is served over HTTPS/TLS; the application and its APIs are not reachable over plaintext.
• Encryption at rest. Voter records and model outputs are stored on encrypted volumes.
• Isolated environments. Development and production run as separate stacks, on separate networks and separate databases, so test activity never touches live voter data.

Access control

Access is role-based and least-privilege. A canvasser sees only the turf and doors assigned to them; personally identifiable information is gated behind explicit read roles, and analytics are separated from PII. No account is granted broad access by default.

• Region-scoped permissions keep users inside the geography they are authorized for.
• Sign-in is on a dedicated authenticated surface at app.voterra.io; the public site collects no credentials.
• Administrative provisioning is explicit — accounts are created and scoped, not self-granted.

Voter contact compliance

Field tools are built to keep contact compliant. Peer-to-peer messaging is one voter per action by design, so routine outreach cannot become a blast by accident. Batch sending exists, but as a separate and deliberately narrower surface: it is restricted to a tighter set of roles than peer-to-peer, and it will not run until a named user attests that the audience has prior express consent. The attestation is stored with the campaign — who confirmed it, and when — so consent is a record rather than a recollection.

Auditability

Changes to the roll and to voter contact are tracked to the household, so activity is attributable rather than anecdotal. Data is handled under strict provenance and access control end to end.

Reporting a concern

If you believe you have found a security issue, please email hello@voterra.io with details. We take reports seriously and will respond promptly.