Trust & security

Short version: your data is encrypted in transit and — for the most sensitive fields — at rest; access is scoped to your workspace and gated by role on every request; every change to your cap table is recorded on a tamper-evident, append-only ledger; and you can export everything you own at any time. The rest of this page explains how.

What it’s built on

Tenacap is a modern web application, built on a mainstream, well-supported stack:

• Next.js and React (TypeScript end-to-end) for the application — the same framework behind a large share of today’s production web apps.
• PostgreSQL, an industry-standard relational database, accessed through a typed data layer (Prisma) that keeps queries scoped and predictable.
• Hosted on Vercel (application) and Neon (managed Postgres) — established cloud providers that carry their own SOC 2 attestations for the infrastructure underneath us.

The whole system is strongly typed and covered by an automated test suite that runs on every change, including tests that exercise the real database — so the math behind your ownership percentages and the rules behind every transaction are checked continuously, not by hand.

Who can see your data

Your company lives inside a workspace, and data never crosses workspace lines. Within a workspace, everyone has a role — for example admin, editor, or a read-only viewer — and every single request is checked against that role before any data is returned or changed. Sensitive actions (creating share classes, issuing or reversing shares, importing or replacing a cap table) are restricted to admins.

This isn’t left to chance: the access check is enforced in code on every route, and an automated rule in our build fails the build if any endpoint is missing its permission gate. Sign-in is handled by a standard authentication library; passwords are hashed with Argon2id (a current best-practice algorithm — we never store a password, only a one-way hash), and you can also sign in with Google.

How your data is encrypted

In transit: every connection is HTTPS/TLS — traffic between your browser and Tenacap, and between Tenacap and its database, is encrypted. The site is served with HSTS, so browsers refuse to connect over anything but a secure channel.

At rest: the database itself is encrypted at rest by our infrastructure provider, and on top of that we apply application-level encryption to the most sensitive personal fields — government tax IDs (SSN/EIN) and bank-account details — using AES-256-GCM. These are encrypted before they’re written and decrypted only when an authorized read needs them. The encryption is bound to the specific field it belongs to, so a tax-ID value can’t be silently moved or swapped, and a tampered value is rejected rather than trusted.

An audit trail you can trust

Your cap table is an append-only ledger. Issuances, transfers, repurchases, cancellations — each is a dated entry that’s never edited or deleted in place. If something needs correcting, the fix is a new reversal entry, so the original and its correction both remain in the record.

Each entry is cryptographically chained to the one before it with a SHA-256 hash, so the history is tamper-evident: you can’t quietly alter or remove a past transaction without breaking the chain. A background job re-verifies the integrity of every company’s ledger nightly. Security-relevant events are recorded the same way, in a hash-chained audit log.

E-signatures that hold up

When a document is signed in Tenacap, we capture the evidence a valid e-signature needs under the U.S. ESIGN Act / UETA: the signer’s explicit consent to sign electronically, a timestamp, and a record of the signing — and we anchor it to a SHA-256 hash of the exact document, so it’s provable that the signed bytes weren’t changed afterward. Signing links use single-use, randomly generated tokens that are stored only as a hash. For privacy, we record a hashed form of the signer’s IP address, never the raw IP.

Where your data lives

Your data is stored in a managed PostgreSQL database (Neon) in the United States, with automated backups and point-in-time recovery handled by the provider — so a mistake or incident can be recovered from, not just detected. The application runs on Vercel. Both providers maintain their own SOC 2 attestations for the infrastructure they operate.

Keeping it secure over time

Security isn’t a one-time checkbox. On an ongoing basis:

• Dependencies are watched and updated automatically (Dependabot), so known vulnerabilities in third-party libraries get patched promptly.
• Secrets are scanned on every change (push protection + secret scanning), so credentials can’t accidentally land in the codebase, and the code is run through automated static security analysis.
• Configuration is locked down — security headers (HSTS, a content-security policy), least-privilege automation, and pinned build tooling.
• Secrets and encryption keys are kept in encrypted configuration, never in the code, and the system fails closed — if a key is missing it refuses to operate rather than quietly running unprotected.

Compliance & where we are

We’ve built Tenacap to SOC 2 control standards from the start — a documented internal security review tracks each control to its implementation. To be straight with you: we are not yet SOC 2 certified. A SOC 2 audit is on our roadmap, and the controls described on this page are already in place. We’d rather tell you exactly where we stand than imply a certification we don’t hold yet.

Your data stays yours

There’s no lock-in. From the cap-table page you can export a CSV, a JSON file in Tenacap’s open, versioned schema, or a full .zip of everything — at any time, without asking us. The Export & open schema guide covers exactly what each file contains. Your records are a clean handoff to a spreadsheet, your counsel, or another platform whenever you want them.

Questions?

Security or data-protection questions, or want our SOC 2 readiness details for your own diligence? Email security@tenacap.com — we’re happy to go deeper than this page.