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 (authorizing new share classes, reversing a ledger entry, recording a priced round, committing or replacing a cap-table import) 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.

Tenacap staff do not have standing access to your cap table: an operator signed in to our internal console cannot browse your workspace or your ledger the way you do. Most of what the console gives them is a health-of-account view assembled from counts, booleans, and dates - never who owns what, at what price, or on what terms - plus a short, deliberately narrow set of support actions. Today that is resending or revoking a stakeholder’s pending portal invite at their request (see Stakeholder portal), resetting a cap-table import that got stuck so you can retry it, and - when we’ve just shipped a fix and need to confirm it works against your file - re-parsing a failed import “blind”: the operator sees only succeeded or failed, plus a table of which fields were present (a count, never a value - e.g. “41 of 41 stakeholders had an email on file”), with no file contents, row content, or free-text error detail ever rendered. One action is broader, and we want to be exact about it rather than soften it: an operator can download the original file you uploaded, in full, as you sent it - names, share counts, prices, whatever the sheet contains. This is available for every import in our console, not only ones that failed or produced wrong data; there is no separate approval step beyond being on the operator allowlist. In practice we built and use it to diagnose an import that produced wrong or missing data - it exists because two real support cases were only solvable by looking at the file itself - but the system does not technically restrict it to that case. None of these actions touch your ledger, and a blind re-run in particular can never create, change, or commit anything - it is a read-only diagnostic that discards the parsed data the moment the request ends. Every one writes an entry to a hash-chained audit log - invite actions to your company’s own log, as if you had done it yourself; import and file-download actions to a tamper-evident operations log, recorded before the file is served - so it is provable after the fact rather than merely permitted in the moment.

One console action is destructive rather than diagnostic: at your explicit request (for example, an email asking us to delete your account), an operator can close your account - the same permanent erasure described in Closing your account & deleting your data, run on your behalf instead of by you. It requires typing your company’s exact legal name and a written reason, one account at a time - there is no bulk-delete capability. Because closing an account erases your company’s own audit log along with everything else, the record of who closed it, when, and why is written to our tamper-evident operations log before the erasure runs, so it survives as the durable proof of what happened even though your own records are gone.

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, 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 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 what each file contains. Your records are a clean handoff to a spreadsheet, your counsel, or another platform whenever you want them. And if you decide to leave, closing your account permanently erases your data - see Closing your account & deleting your data.

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.