Built to protect the data that matters most.
Attendance, payroll, and biometric data deserve more than an afterthought. Here's exactly how we protect it.
Encryption everywhere
TLS 1.2+ in transit, AES-256 at rest. Face-verification data stays scoped to your organization and never crosses tenant boundaries.
Google-only authentication
Every session is backed by Google OAuth with short-lived, httpOnly, secure session cookies.
Organization isolation
Every API request is scoped to a single organization at the data-access layer — not just the UI — so cross-tenant leakage isn't possible by construction.
Audit logs
Every sensitive action (payroll run, role change, data export) is logged with actor, timestamp, and IP on Business plans.
Rate limiting & abuse protection
All /api/v1 endpoints are rate-limited per organization and per IP, with automatic backoff on repeated failures.
Responsible disclosure
Found a vulnerability? Email security@attenzo.com — we credit and respond to every valid report within 48 hours.
How we actually handle face verification data.
Not a vague privacy promise — the real data flow, since face check-in is a genuine differentiator and deserves scrutiny, not marketing language.
Face matching itself runs on-device, in the browser: a camera frame is converted locally into a 128-number embedding that is matched against your enrolled template. We also capture a photo — at enrollment and at each face check-in — and store it so your administrators can review attendance and confirm a live person, not a held-up photo, checked in. All of it is encrypted at rest and scoped to your organization; it is never shared across tenants.
Enrollment and check-in run a guided liveness challenge: you're asked to slowly turn your head, and the server independently re-verifies the head-movement series rather than trusting the client. A flat photo can't produce a real left-and-right head turn, which is a stronger, less annoying signal than repeated blinking. We're explicit about its limits — it's a genuine technique against the common case, not a claim of defeating a sophisticated video replay.
Every face check-in also requires a device an administrator has explicitly approved, independent of the face match — so a colleague's face on their own already-unlocked device still fails. Both checks must pass, and the stored photo gives an administrator a final human review.
Only an administrator can remove a face enrollment (a member can't clear their own to dodge verification); doing so deletes the stored embedding and enrollment photo and forces the member to re-enroll.
Have a security question?
Report a vulnerability or ask about our practices — security@attenzo.com.