Security Posture
SymlaVault is engineered for financial services, healthcare, insurance, and legal — industries where the consequences of a security failure are measured in regulatory action, not just bug reports.
The short version. The full whitepaper (~100 pages, v3.3) details every mechanism, threat model, and failure mode.
No tokens, credentials, or session data in browser storage. Sessions are server-side in PostgreSQL, referenced by a signed HttpOnly cookie. No JWTs in the browser. No API keys in localStorage.
TOTP-based multi-factor authentication required for every account. AES-256-GCM encryption of TOTP secrets at rest. Brute-force protection at the account and IP level. Backup codes are SHA-256 hashed.
PostgreSQL FORCE ROW LEVEL SECURITY enforced on every tenant-scoped table. A query that forgets a tenant filter returns zero rows — not a data leak — enforced at the database engine layer.
Every backend service verifies an HMAC-SHA256 signature on gateway-injected identity headers before processing. Timing-safe comparison. Fail-closed behavior — a misconfigured service refuses all traffic rather than silently bypass verification.
All authentication, document, e-signature, and integration events flow to a retention-locked GCS bucket with append-only writes. No principal has delete permission. Exceeds the RESPA/TILA 7-year statute of limitations.
Each Cloud Run service runs under a dedicated GCP service account with minimal IAM. A compromise of any single service cannot reach Cloud SQL credentials, OAuth tokens, or the audit bucket owned by another.
Every upload — authenticated or magic-link — is scanned by a dedicated service (magic-number verification + ClamAV) before becoming a visible document. Infected or malformed uploads are quarantined to a segregated bucket with 90-day retention.
Electronic signature workflows record explicit consent, capture IP and user-agent per signer, and append a tamper-evident certificate page to every signed PDF. Statutory citations preserved in the document itself.
Infrastructure certifications we inherit from Google Cloud, plus SymlaVault's own audit roadmap.
We'd rather state where we are honestly than claim certifications we don't yet hold. Our technical controls are designed against SOC 2 Trust Service Criteria; the attestation work is a documentation and evidence-collection effort currently underway.
Selected specifics. The whitepaper covers everything in depth.
--ingress internal-and-cloud-load-balancing. Public Cloud Run URLs are rejected.tenants/{id}/docs/{uuid}/.Third parties that may process customer data in the course of providing SymlaVault.
| Subprocessor | Purpose | Location | Trust Center |
|---|---|---|---|
| Google Cloud Platform | Hosting, compute, database, storage, KMS | United States | cloud.google.com/security |
| Brevo | Transactional email (verification, password reset, platform notices) | European Union | brevo.com/security |
| Stripe | Payment processing, subscription billing | United States | stripe.com/privacy |
We'll notify customers of material changes to this list at least 30 days in advance. Request the changelog at security@symlavault.com.
The complete security whitepaper (~100 pages, v3.3) details every control, threat model, failure mode, and audit trail. We'll send a download link to your inbox right away.
For vulnerability disclosure, compliance inquiries, or BAA / DPA requests.
Email: security@symlavault.com
We commit to acknowledging vulnerability reports within 48 hours and maintaining regular contact throughout investigation and remediation. We don't yet run a formal bug bounty program, but good-faith researchers are welcome and credited in the whitepaper's acknowledgments section once disclosure is coordinated.
Please do not publicly disclose vulnerabilities until we have had an opportunity to investigate and address them.