How Veni keeps building data secure

Veni holds sensitive information; resident contact details, access codes, ID-check records, call notes. Here's what the platform does to protect it, in plain terms.

Encryption at rest

Sensitive fields are encrypted in the database with AES-256-GCM, an industry-standard authenticated cipher. That covers resident and front desk email and phone numbers, entry and package notes, call notes, announcements, and the names attached to captured IDs. Encryption keys are versioned and rotatable, so a key can be retired without re-encrypting existing data.

When staff search by email or phone, Veni matches against a blind index (a one-way fingerprint) rather than a readable copy, so search works without storing the value in the clear.

Encryption in transit

All traffic between apps and Veni's servers runs over HTTPS/TLS. Web apps send HSTS so browsers refuse to connect over plain HTTP, and the native apps reject any non-secure API endpoint. Incoming webhooks are signature-verified, and secrets are compared in constant time.

Least-privilege, audited access

Access to data is gated by role and scoped to the buildings a person manages. Veni does not store ID photos at all. When the front desk checks a visitor's ID, the barcode is verified on the device, and the only details kept are the visitor's name (encrypted) and the result of the check. Management views of these ID-check records are logged to the audit trail.

Opening the most sensitive records is fail-closed: viewing a signed vendor-compliance form or key-release document, or revealing the identity behind a de-identified activity record, is denied outright if the audit entry can't be written. For those records, there's no look without a record of the look.

For a deeper look at roles and what each person can see, read *Access roles and permissions* and *Controlling what staff and the front desk can see*.