Trust & security

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.

What it’s built on

Tenacap is built on a mainstream stack:

• Next.js and React (TypeScript end-to-end) for the application.
• 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 system is strongly typed and covered by an automated test suite that runs on every change, including tests against a real database, so the ownership math and the rules behind every transaction are checked continuously.

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 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.

The access check is enforced in code on every route, and the build fails if any endpoint is missing its permission gate. Sign-in is handled by a standard authentication library; passwords are hashed with Argon2id (we store a one-way hash, never the password), and you can sign in with Google.

An AI assistant you connect holds an API token tied to your account and one workspace, and it can never do more than your role allows. It cannot change anything by itself: every write is a proposal that a signed-in person confirms in Tenacap, and the change log records both.

Tenacap staff do not sign in to your workspace, and being an operator grants no access to the company pages. Operators work from an internal console, open only to an allowlist, and every action there writes a hash-chained audit entry. The console shows a health-of-account view built from counts, booleans and dates. The actions it offers:

• Portal invites. Resend or revoke a stakeholder’s pending invite at their request (see Stakeholder portal), logged in your company’s own change log as if you had done it.
• Diagnosing an import. Reset a stuck import so you can retry it. Re-run a failed one “blind”, which shows only succeeded or failed and which fields were present (a count, never a value), and writes nothing. Re-read your uploaded file with a fixed parser and store the new reading on your import, so you need not upload it again; this commits nothing. Check that an imported cap table holds together, for example that each share class has the right type; this reads the company and changes nothing.
• Your original file. An operator can download the file you uploaded, in full, as you sent it: names, share counts, prices, whatever the sheet contains. This is available for every import, with no approval step beyond the allowlist. We built it because two support cases were only solvable by looking at the file itself. The download is logged before the file is served.
• Finishing a first import our bug blocked. When a parser bug made the totals check refuse your first import, and the fixed reading now reconciles, an operator can commit it for you. This only creates a cap table where there was none.
• Asking you to re-import. An operator can email you a request to replace your cap table with a corrected import. Nothing changes unless you approve it from that email.
• Restoring an earlier version. When a re-import replaced your cap table, the previous one was archived as a version. An operator can restore it. The state it replaces is archived first, so a restore can itself be undone, and the restore is written to your company’s own change log.

If you send an export through the beta offer at /beta/upload and anything does not line up, a person on our side reads the import review, fixes our importer, re-reads your file and writes the note at the top of your report. A clean upload is not reviewed by anyone.

One more console action is destructive: at your 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. It requires typing your company’s legal name and a written reason, one account at a time. 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 operations log before the erasure runs.

Operators also create, manage and lock or delete the accounts the console itself needs, such as a new operator’s own sign-in, never a customer’s company data. A locked account is signed out within one request, and any API or MCP token it holds is refused on its next call too, without being revoked; a permanent delete is refused while the account authored anything in a company’s own ledger or signed a document, since that history still matters. An operator’s own AI assistant can reach these same actions, carrying a scope minted only for an allowlisted operator, but it can only propose one. The operator still confirms it from their own browser, the same way every other proposal in Tenacap works.

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 moved or swapped, and a tampered value is rejected.

The cap-table file you upload is encrypted the same way. We keep it so we can re-run your import when we fix a parser bug, and from 22 September 2026 it is encrypted with our own keys before it reaches storage - so if the file store itself were ever exposed, what is in it is unreadable without our keys. That protects the file from everyone except us. We can still read it, because re-running your import is the whole reason we hold it. You can download or delete your file at any time, and closing your account deletes it.

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 in place. If something needs correcting, the fix is a new reversal entry, so the original and its correction both remain in the record. Two operations remove entries: replacing your cap table with a new import, and restoring an earlier version. Both archive the whole outgoing cap table as a version first, in the same step, and write an audit entry, so the removal is recorded and can be undone.

Each entry is cryptographically chained to the one before it with a SHA-256 hash, so the history is tamper-evident: altering or removing a past transaction breaks 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 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. We record a hashed form of the signer’s IP address.

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. The application runs on Vercel. Both providers maintain their own SOC 2 attestations for the infrastructure they operate.

Keeping it secure over time

• 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 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.

Compliance & where we are

Tenacap is built to SOC 2 control standards; a documented internal security review tracks each control to its implementation. We are not yet SOC 2 certified. A SOC 2 audit is on our roadmap, and the controls on this page are in place.

Your data stays yours

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. The Export & open schema guide covers what each file contains. If you 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.