Everything in the first list is built and covered by tests. Everything in the second is a limit that applies today. Both are stated with the same prominence, because a security page that lists only strengths tells you nothing.
Each of these exists in the application and is exercised by automated tests, several of which work by attempting the attack and asserting that it fails.
Access is granted by role — Organization Owner, Benefits Administrator, Payroll Administrator, Finance Controller, Authorized Approver, Platform Operator — and each endpoint checks the specific permission it requires rather than only that a user is signed in.
Every request is scoped to one organization at the router, before a handler runs. Isolation is covered by tests that attempt to reach another tenant’s records on each endpoint and assert that the attempt fails.
Uploaded files are recorded with a content hash. Each finding references the rule that produced it and the source rows it rests on, so any figure can be traced back to the exact file and row it came from.
Consequential actions are written to an append-only audit record identifying the actor, the action, the affected records, and the time.
No financial claim advances on its own. A recovery package must be approved by a user holding the Authorized Approver role, and Tallyvant does not transmit disputes to carriers.
Traffic is served over HTTPS. The application requires a TLS-verified database connection, with a startup check that fails rather than falling back to an unverified one. Sessions use signed, HTTP-only cookies, and sensitive values are redacted from logs.
Authentication, upload, and reconciliation endpoints are rate limited, with tests that exceed each limit and assert that the request is refused.
Database backup and restore are implemented and verified by performing an actual restore, rather than by asserting that a backup file was produced.
These are facts about the product's current maturity. They are listed here rather than left for you to discover during diligence.
Separate from the product, and deliberately boring.
The marketing site is a separate deployment with its own build and its own project. It has no database connection, no application credentials, and no route that can reach employee records. A compromise of this site would not reach the product.
The demo-request form collects a name, a company, a work email, an approximate employee count, and an optional message. There is no analytics script, no advertising pixel, no session recording, and no third-party tag of any kind on this site.
A Content Security Policy, HSTS, frame denial, MIME-sniffing protection, a strict referrer policy, and a restrictive permissions policy are configured in the application rather than only in hosting settings, so a preview deployment carries the same headers as production.
Submissions are size-capped, strictly validated on the server, rate limited per client, and screened by a honeypot field and a timing floor. A submission is only ever reported as received after a configured destination has accepted it.
If you are evaluating Tallyvant and need detail this page does not cover, ask directly. An unanswered question will be answered as unanswered.
A demo runs through one period of your carrier billing, payroll deductions, and enrollment records, and shows you the findings with their evidence. Tallyvant is pre-production and is being prepared for early pilots.