Tano Security
Campaign data is sensitive — voter contacts, donor records, and internal strategy. Here is what Tano Tena actually does to protect it, grounded in what's built, not marketing claims.
A separate physical database per campaign
Every campaign (tenant) runs on its own isolated PostgreSQL database — not shared tables with a "tenant_id" column. Your voter data, finances, and campaign strategy live in a physically different database from every other campaign on the platform.
Tamper-evident audit logging
Every change to tenant data is recorded in a hash-chained audit log — each entry hashes its own data plus the previous entry's hash (SHA-256), so tampering with a past record breaks the chain and is detectable, not just logged and forgotten.
Role-based access control
Access within a campaign is governed by roles and permissions — team members only see and act on what their role grants, whether that's a volunteer coordinator, finance officer, or campaign manager.
Controlled, logged support access
When Tano Tena staff need to access a campaign account to provide support, that access requires a reason code and ticket reference, is time-limited, and is itself audit-logged — support access is never silent or untracked.
Encrypted connections
All traffic to Tano Tena is served over HTTPS/TLS. Campaigns using a custom domain (white-labeling add-on) get their own TLS certificate provisioned automatically, not a shared or self-signed one.
Entitlement-gated add-ons
Paid add-ons like the site builder and white-labeling are gated at the API and route level by your subscription — a lapsed or missing entitlement blocks access server-side, not just in the interface.
Found a security issue?
If you believe you've found a security vulnerability, please contact us directly rather than filing a public report.