Security & Privacy
Visitor logs contain identity documents. The platform is built around limiting who can see what, keeping an append-only record of decisions, and giving you a documented path to erase or purge data.
Role-based access
JWT access and refresh tokens, bcrypt password hashing, brute-force lockout, and RBAC middleware on every route. Supervisors approve; operators verify; hosts have a narrow view; auditors are read-only.
Masking and least privilege
Operators and hosts see masked ID numbers such as XXXX-XXXX-4821. Exact-ID search and full identity data require an elevated role. ID images are served only to supervisor and operator roles; hosts receive a 403.
Retention defaults
| Data | Default | Behaviour |
|---|---|---|
| ID images | 30 days | File and reference removed by the purge job |
| Visitor records | 2 years | Idle visitors anonymised after the policy window |
| Audit events | 2 years | Deleted with a RETENTION_PURGED tombstone |
Retention is configurable per deployment and should be confirmed against your own policy before production. The purge endpoint is admin-only and writes an audit event.
Audit and erasure
The audit trail is append-only. There are no edit or delete endpoints, and administrators cannot mutate history. A per-profile erase request deletes documents, images and SMS rows, anonymises PII and retains metadata with a PRIVACY_ERASED audit event that contains no PII.
Deployment security
- TLS is terminated at the site reverse proxy or load balancer on cloud deployments.
- On-prem, the platform runs on an isolated LAN or a TLS-terminated network segment.
- MongoDB has no published host port; the API is not published directly.
- ID images live in an encrypted volume with
0700/0600modes enforced by the API.
Data-subject requests
Use the admin privacy endpoint to erase a profile on request. The operation is logged without retaining the erased identity data. Confirm your retention, access and privacy policy with your legal team before go-live.