How EntryWick protects your people

Tenant isolation

Every record belongs to exactly one organization, and the scope is applied by the framework to every query — not by each screen remembering to filter. The handful of places that must look across organizations (the platform's own operations) are named in code with the reason, and every feature ships with a test that tries to read another organization's data and must fail. Public identifiers are random, not sequential.

Accounts and access

• Passwords of at least 12 characters, checked against known breach corpora at sign-up and change.
• Rate-limited sign-in, password reset and registration.
• Two-factor authentication with an authenticator app for every user; required to erase a person or delete an organization. Requiring it for Owners and Admins is a decision we expect to make before early access.
• Single sign-on (Microsoft, Google) on the Scale plan; a paused SSO connection completes no sign-in.
• Roles are built from permissions and can be scoped to a group, so a lead sees only their subtree.
• API keys are per organization, scoped, rate-limited, and shown once.

Data handling

• Secrets — provider credentials, webhook secrets, DKIM private keys — are stored encrypted and never written to logs.
• All traffic is TLS; custom domains receive certificates automatically.
• Money is stored in integer cents, times in UTC, and rendered in the event's time zone.
• Tenant-authored content (emails, pages) renders through a sandboxed template engine, and tenant HTML is sanitized.
• Every write to a domain record goes through a service that writes an audit row naming the actor and the source (admin, API, import, job, scanner, webhook, CLI).

Integrity of the gate

Tickets are issued once and never modified; a fix is a void and a reissue in one transaction, and a voided code names its replacement. Check-ins are append-only — a correction is a new row — and a duplicate is caught by a database constraint, not by application logic. These two rules are what make offline scanning safe and attendance numbers defensible afterwards.

Availability and recovery

• Nightly database backups with a copy off the server; restores are drilled on a schedule in CI.
• A public status page reports, measured at load time, whether registration, the API, the scanner, the database, the queue, certificates and backups are healthy.
• The scanner keeps every scan on the phone until the server confirms it, so an outage on our side cannot lose a check-in.
• Self-hosted installs: the license never stops check-in, even when it lapses.

Privacy by design

• Per-person export and erasure from the admin, with a documented list of what erasure keeps and why.
• Organization-wide export of every table and file as one zip, with no ticket to support.
• Retention by plan, then archive.
• No advertising or analytics trackers on public event pages or this website.

Testing and review

Every change runs a suite of unit, feature and cross-organization negative tests, static analysis and formatting checks before it can merge. We are working through the OWASP ASVS 4.0.3 Level 2 checklist item by item; items are marked met only when a test asserts them, and the remaining items — a third-party penetration test and verification on a running system — are owed before early access opens.

Responsible disclosure

If you believe you have found a vulnerability, email hello@entrywick.com with Security in the subject. Please include steps to reproduce and do not access data that is not yours. We acknowledge within two business days, keep you informed until it is fixed, and credit you if you wish. We do not pursue good-faith researchers who follow these guidelines.

Security questionnaires

Pilot organizations and Enterprise prospects can request a completed security questionnaire, this page as a PDF, and a signed data processing agreement: hello@entrywick.com.