TriarchCRM is built by a security firm, for advisory and security firms. Every customer runs on dedicated, isolated infrastructure, your own cloud project, your own database, your own domain. There is no shared multi-tenant database to misconfigure, because customers are physically separated at the infrastructure layer.
Each customer gets a dedicated, single-tenant deployment: its own Google Cloud / Firebase project, its own CockroachDB database, and its own domain. No shared database. No shared application instance. No commingled tables.
The data model has no tenant-ID columns and no row-level-security filters, because there is nothing to filter. There is no runtime "which-customer-is-this?" check that could be misconfigured to leak data across customers. A boot-time guard binds each instance to its own database, so an instance physically cannot connect to another customer's data.
Isolation lives in the deploy pipeline, not the data model.
Isolation is the foundation. On top of it sits encryption, hardened authentication, least-privilege access, and careful handling of AI over your data.
Sensitive PII fields, such as email addresses and phone numbers, are encrypted at rest using envelope encryption with Google Cloud KMS (AES-256), with a dedicated key per deployment. The underlying storage also benefits from the cloud provider's standard at-rest disk encryption. Data in transit is protected with TLS.
Identity is verified through Firebase Auth, used strictly as an identity provider. Sessions are short-lived JSON Web Tokens signed server-side and stored in httpOnly, Secure cookies, never bearer tokens in browser localStorage. Only your own verified email domain can sign in to your instance. The one exception is Triarch support: when access is required to help you, it is granted only through short-lived, time-boxed credentials that are logged, audited, and visible to you, never a standing back door.
Role-based access control governs what each user can see and do, with granular capabilities layered on roles. An audit log records access and actions so you can see who did what, and when, accountability built into the platform, not bolted on.
TriarchCRM uses a bring-your-own-key model: you supply your own LLM provider key. AI calls over your data require an attested no-training / zero-data-retention configuration, so your data is not used to train third-party models and is not retained by them.
Every deployment runs on Triarch-managed cloud infrastructure (Google Cloud / Firebase and CockroachDB Cloud) and is pinned to a chosen cloud region, so you control where your data lives. Each customer's infrastructure is provisioned and managed separately.
TriarchCRM is built and dogfooded by Triarch Security. Isolation, least privilege, and auditability are treated as first-class, sellable properties, not afterthoughts. We hold ourselves to the standard we ask our own clients to meet.
We welcome responsible disclosure from the security community. If you believe you've found a vulnerability in TriarchCRM, please report it privately so we can investigate and remediate before any details are made public. Please do not access or modify data that isn't yours, and give us a reasonable window to respond before disclosure.
This page describes the security practices engineered into TriarchCRM: isolation, encryption, authentication, access control, and auditability. We do not claim any formal compliance certification on this page. Formal attestations and supporting documentation are available on request and are part of our roadmap. If your procurement process requires a specific framework or questionnaire, contact us and we'll work through it with you.
Book a walkthrough and we'll show you exactly how isolation, encryption, and access control work in a real, dedicated deployment.
Security reports: security@triarchcrm.com