How we take your data

Trust in a software product starts with being clear about how it handles your data. We would rather tell you exactly where we stand, including the parts that are still in progress, than make a broad claim we cannot back up. This post lays out our data practices plainly, section by section.

A note on honesty before anything else. Tamats does not yet hold a SOC 2 attestation or an ISO 27001 certification. In their place we maintain a detailed security questionnaire that answers each control question directly, marking each item as done, partial, or not yet done. Everything below is grounded in that self assessment and in our internal audits, not in aspiration.

Your data is isolated by design

The most important promise a multi-tenant product can make is that one customer's data can never reach another. We enforce that promise at the layer where it is hardest to get wrong.

Isolation in the database, not just the app

Every piece of customer data in Tamats is scoped to your organization. That boundary is enforced in the database itself using Postgres Row-Level Security, and it is forced on every tenant table, which means even a table owner cannot bypass it. The rule that decides what belongs to your organization is defined in one place and reused everywhere, so there is a single definition of tenancy rather than a scattering of separate checks that can quietly drift apart over time.

Defense in depth

Application-level role and organization checks sit on top of that database floor as a second, independent layer. If application code ever missed a check, the database itself would still refuse to return another organization's rows. Two independent layers have to agree before any data moves, which means a single mistake in one layer is not enough to cause an exposure.

Verified, not assumed

Isolation is only worth as much as your willingness to test it. We have inspected every policy, grant, function, and trigger in the live database during internal audits, and no cross-tenant break has been found in any traced path. A fully automated isolation test suite in continuous integration is on our roadmap, and we name it as not yet complete rather than implying it already exists.

We keep the sensitive surface small

The safest data is the data you never hold. We designed the product to minimize what we store and what we touch.

Authentication

Sign-in is delegated to Google through our authentication provider. We do not run a password database, which means there is no password store to leak, phish, or crack. Multi-factor authentication is inherited from your own Google account, so the strength of your login is the strength you already trust.

Payments

Payment card data never touches our systems. Billing runs through a merchant-of-record, and we store only what we need in order to know whether a subscription is active, such as its status and billing period. Card numbers are handled entirely by the payment provider, and our exposure to cardholder data is effectively zero.

Telemetry and personal data

We minimize personal data in our operational telemetry. The goal is to understand how the product performs without quietly accumulating a shadow copy of who did what. We collect what we need to run and improve the service, and we try not to collect more.

Access is least privilege

Not everyone on a team should be able to do everything, and the product enforces that rather than trusting convention.

Roles that mean something

Roles are stored on the server, never in a place a browser can tamper with. A read-only role is genuinely read-only, enforced in the database rather than merely hidden in the interface. Membership changes go through hardened, audited paths rather than direct writes to a table.

Watching for drift

A daily automated check compares our live security policies against a known-good baseline and flags any unauthorized change. If a policy were altered out of band, whether by mistake or otherwise, the system would notice and raise it rather than let it pass silently.

Deletion and your rights

Holding data responsibly includes being able to let go of it.

Tamats supports account and data deletion, so your data does not have to live with us forever once you are done. A public privacy policy and a formal data subject request process, including export, are in progress, and we mark them as in progress rather than claiming they are finished. If you have a specific deletion or export need today, we will handle it directly.

Built on audited infrastructure

We do not run the entire stack ourselves, and the vendors we build on are held to real, external standards.

Our core subprocessors, including our database and hosting providers, hold SOC 2 Type II attestations, and several also hold ISO 27001. We maintain a register of these subprocessors and what each one processes on our behalf, so the chain of who touches your data is not a mystery.

To date we have had no known data breach, and no cross-tenant data exposure has been found in any of our internal audits, including inspection of the live database.

Where we are honest about the gaps

Being transparent means naming what is not finished, not just listing what is.

Some of the governance artifacts a mature security program carries, such as fully adopted and signed written policies, scheduled formal access reviews, and an external penetration test, are on our roadmap rather than complete today. The technical controls are the strong half of our posture. The formal program around them is the half we are still building, and we track that openly rather than papering over it.

Questions

If you would like to review our security questionnaire in full, or you have a specific question about how your data is handled, write to us at team@tamats.org. We would far rather have that conversation directly than leave you to guess at the answer.