Trust
Security and Data Protection at CalcStack
Every page, embed, and API request CalcStack serves runs over HTTPS, and every customer-owned row in the database sits behind a row-level security policy. This page lists the controls protecting your account and the leads your embedded tools capture, stated plainly so a procurement or security review can verify them.
CalcStack stores customer and lead data in Postgres with row-level security scoping every record to its owner, serves all pages and embeds over HTTPS, processes payments through Stripe so card data never reaches CalcStack servers, and ships GDPR-grade export and erasure through dedicated, test-verified account endpoints.
Last updated: July 2026
Tenant isolation at the database layer
Row-level security is a Postgres access control that attaches an ownership policy directly to each table, so the database itself refuses to return a record to anyone other than the account that owns it. CalcStack applies these policies to customer data: your tool configurations, branding, integrations, and every lead your embeds capture. Because the check runs inside the database on every query, a bug in a page or an unexpected API call cannot widen access beyond your own rows. Privileged operations, such as admin-only endpoints, additionally re-verify the caller's role on the server and fail closed. Paid-feature limits are enforced the same way, in the database rather than only in the interface.
This layered approach came from a real incident: an early admin-role check was written as an inline database subquery, recursed under row-level security, and took down an internal dashboard until it was rewritten as a single dedicated security-definer function. Every privileged check now runs through that one audited path.
Controls in place today
| Layer | Control | Where it is enforced |
|---|---|---|
| Database | Row-level security policies scoping every customer-owned record to the owning account | Postgres (Supabase), applied on every query |
| Application | Strict Content Security Policy with a fresh per-request nonce, so an injected inline script is refused by the browser | Middleware on every page route |
| Transport | HTTPS on every page, embed, and API call | Vercel edge network |
| Payments | Card collection and billing handled entirely by Stripe; card data never reaches CalcStack servers | Stripe-hosted checkout and signed webhooks |
| Privacy | Self-serve GDPR export and erasure, with the export table set test-pinned equal to the deletion table set | Dedicated account endpoints plus an automated parity test |
| Pipeline | Full-history secret scanning, CodeQL static analysis, and a dependency vulnerability gate on every change | Continuous integration, blocking before deploy |
Each control above exists in the CalcStack codebase, database policies, or CI configuration; none is aspirational.
Your leads stay yours
Leads captured through your embedded tools belong to you. They are stored under your account, delivered to the destinations you connect, and never sold, rented, or used to market to your visitors. Because your tools capture your visitors' data, you act as the data controller and CalcStack acts as your processor; that relationship is formalized in the Data Processing Addendum and described in the Privacy Policy.
Export and erasure, verified by tests
You can export the data CalcStack holds for your account and delete the account entirely, both self-serve. The two operations are built as dedicated endpoints, and an automated test pins the export plan's table set equal to the deletion plan's table set. That parity matters in practice: anything the export can show you, the erasure removes, so a deletion request cannot silently leave data behind in a table the export never mentioned. Account deletion removes personal data within 30 days, matching the commitment in the Privacy Policy.
How the code itself is protected
Security review is wired into the delivery pipeline rather than scheduled around it. Every change runs full-history secret scanning (gitleaks) so a committed credential fails the build, CodeQL static analysis for injectable or unsafe code paths, and a dependency audit that blocks known high or critical vulnerabilities. Server endpoints validate every JSON request body against a strict schema before acting on it, and third-party imports in serverless functions are pinned to exact versions so an upstream release cannot slip in silently.
Certifications, honestly
CalcStack does not currently hold SOC 2, ISO 27001, or similar certifications, and no page on this site will imply otherwise. Formal audits are on the roadmap as the business grows into them. Until then, this page and the DPA exist so reviews can rely on named, checkable controls instead of a certificate: database-enforced isolation, a nonce-based Content Security Policy, Stripe-held card data, and tested export and erasure. Questions a review needs answered in writing are welcome through the contact page.
A pre-revenue product cannot buy an audit badge, but it can show its work. Writing this page as a list of checkable controls instead of a compliance logo wall was a deliberate choice: every row in the table above points at something a reviewer could ask us to demonstrate.
Report a vulnerability
If you find a security issue in CalcStack or in an embedded tool, email security@calcstack.net with the affected URL or endpoint, steps to reproduce, and your assessment of the impact. Reports reach the founder directly and confirmed issues take priority over feature work. Please test only against accounts and data you own.
Questions
Frequently Asked Questions
Is CalcStack SOC 2 or ISO 27001 certified?
Not yet. CalcStack is an early-stage bootstrapped product and has not completed a SOC 2 or ISO 27001 audit, and this page will never claim otherwise. Instead it documents the concrete controls in place today, from database row-level security to CI secret scanning, so your review can evaluate the actual posture rather than a badge.
How is my lead data isolated from other CalcStack customers?
Every table holding customer content in the Postgres database carries row-level security policies, so a query made with your account credentials can only return rows your account owns. Isolation is enforced by the database itself on every request, not by application code alone, which means a bug in a page cannot widen access.
Does CalcStack ever see or store payment card numbers?
No. Checkout, subscription changes, and invoicing run entirely on Stripe, and card details are entered on Stripe-hosted payment surfaces. CalcStack servers receive only the subscription status and billing metadata needed to operate your plan, never the card number itself.
How do I report a security vulnerability in CalcStack?
Email security@calcstack.net with the affected page or endpoint, reproduction steps, and the impact you believe it has. Reports go straight to the founder, confirmed issues are prioritized ahead of feature work, and you will be kept informed as the fix ships. Please avoid testing against accounts or data you do not own.
Related pages for your review: