Security and trust
A card page carries a named person's phone number and email, so the interesting questions here are about who can see what. Everything below describes behaviour that is built today — and the last section is what is not.
What is in place
Each company's data is separated in the database
Every table scoped to a company is protected by row-level security, so the separation is enforced by Postgres rather than by a filter in application code that a new query could forget. A request for another company's record returns nothing, not an error page.
An employee's visitor data is private from their own admin
Admins see totals per card and per team. Who opened a particular person's card, and when, is visible only to that person — enforced by the absence of an admin rule in the policy, not by a setting. There is no admin-facing export of those rows in any format.
Export everything we hold
A workspace admin can download a complete archive — the company record, the roster, every card, templates, change requests, billing records and the contact details recipients shared. It is machine-readable JSON plus spreadsheet-friendly CSVs. Each export is recorded in the audit log.
Erasure that actually erases
A deletion request removes the record or irreversibly anonymises it — it is never merely hidden. A recipient's record is deleted outright; an employee's name, contact details and photo are overwritten and their sign-in disabled; their card link stops resolving permanently and returns a 410 to search engines.
Recipients can decline tracking
Every public card carries a Privacy control that turns off counting for that device, and a browser sending Global Privacy Control or Do Not Track is never counted without the recipient touching anything. The card page sets no cookies, stores no visitor identifier and loads no third-party script.
Privileged actions are logged by the database
Card edits, roster changes and change-request decisions are written by database triggers rather than by the code that performed them, so a path that forgets to log cannot exist. Platform-team actions — plan overrides, suspensions, and reading cross-company analytics — are logged too.
Secrets stay on the server
The service-role database key and the Stripe secret key are server-side environment variables and are never present in anything a browser downloads. Payment details are handled by Stripe; we never see or store a card number.
Exercising a GDPR or CCPA right
If you are an Introly customer, export and erasure are in your workspace under Data & privacy. If you shared your details on someone's card and want them deleted, contact the company whose card it was — they can action it directly, and they are required to confirm it is you before they do.
We respond to requests within 30 days, inside the one calendar month GDPR Article 12(3) allows and the 45 days CCPA allows. See the privacy policy for what we collect and why.
What we do not have yet
If one of these is a blocker for your review, it is better that you know now. We would rather lose the evaluation than be found out in procurement.
- SAML or Okta single sign-on. Sign-in today is Google Workspace or an emailed magic link.
- A custom domain for your cards. They are served from ours.
- A signed DPA, SOC 2 report or penetration-test summary. Ask us and we will tell you honestly where we are.
- Apple and Google Wallet passes, and CRM or HR-system integrations. On the roadmap, not built.