Security, privacy and compliance
Security for the analytics you ship to customers
Embedding analytics puts a vendor inside your customers’ security reviews, not just your own. Databrain holds metadata only, and every query runs live against your warehouse, so your customers’ rows never leave your infrastructure.
- SOC 2 Type 2
- ISO 27001
- GDPR
- HIPAA
- CCPA
- Cloud or self-hosted
- Covered service
- Databrain embedded analytics platform, API and embed SDK
- Deployment
- Databrain cloud on AWS, or self-hosted on your infrastructure
- Tenancy models
- Table, schema or database tenancy, all supported
- Evidence
- SOC 2 Type 2 report and policy set, under NDA via the Trust Centre
Where your data actually goes
Yours
Your warehouse
Snowflake, BigQuery, Redshift, Postgres, or whatever you already run. Connected read-only where the warehouse supports it.
Ours
Databrain
Validates the signed tenant scope against the guest token, builds the SQL, and passes the result straight through to the browser.
Your customer’s
End-user browser
The dashboard renders inside your product, under your brand, holding a guest token that carries the tenant scope and nothing else.
What we store
- Schemas, dashboard configuration and semantic layer definitions
- Databrain app accounts: names and email addresses
- Your warehouse credentials, encrypted at rest
- Operational logs of API, authentication and admin events
What we never store
- Your customers’ rows, in any form
- An extract, replica or nightly sync of your warehouse
- A persistent cached result set of tenant data
- Anything mined, sold, or used to train a model
Multi-tenant analytics, enforced at the query layer rather than the chart layer
How a guest token scopes a session
When your backend mints a guest token, the tenant identifier (clientId), the Data App, and the workspace and datamart underneath it are signed into it. Once signed, nothing the browser does can widen that scope. Not a filter, not a URL parameter, not a direct API call.
Every request is validated against that signed scope before any SQL is built. A mismatched clientId does not produce a wrong-data query. It does not produce a query at all. Guest tokens are minted server-side only and carry a configurable TTL; your API and App tokens never reach the browser.
- Your backend mints a guest tokenclientId, Data App, workspace and datamart are signed in. Server-side only.
- The browser makes a requestNo filter, URL parameter or direct API call can widen the signed scope.
- Scope is validated before any SQL is builtEvery request, every path that can return a row.
Three multi-tenant analytics architecture models, one guarantee
Your architecture decides how the scope is applied, not whether it holds. All three are supported, so adopting Databrain is not a migration.
For custom SQL metrics, the {{global_client}} variable resolves to the same value the tenant scope uses. They cannot disagree. Scope validation applies to every path that can return a row:
- Chart renders
- Filter lookups
- Drill-downs
- Scheduled reports
- PDF, CSV and XLS exports
- The API
- AI chat
- Table tenancyThe tenant column filter is applied to every tenanted table the query touches. Joins compose as expected; the filter follows the table.
- Schema tenancyThe query targets the tenant’s own schema. There is no shared-schema query path.
- Database tenancyThe query routes to the tenant’s own database. Cross-tenant queries are not reachable from this layer.
Single tenant vs multi tenant, and why the question is usually asked backwards
Teams arrive expecting a security answer and it is mostly an economics and operations answer. Single tenancy gives each customer their own database or schema, which is easy to explain to an auditor and makes cost, migrations and schema drift your ongoing problem. Multi tenancy shares the path and pushes the burden onto whether the tenant scope holds on every query.
Both are correct. The multi-tenant one fails differently if the scope check is wrong, so the check has to sit somewhere you cannot bypass. That is why we validate before the query exists rather than filtering after it runs.
Embedded session and browser controls
Domain allowlisting
Embeds render only on origins you have explicitly approved, managed per Data App. An embed lifted onto an origin you did not approve does not render, closing the framing and origin-spoofing risk unique to iframe and SDK embedded products.
Short-lived guest tokens
Stateless, signed, configurable TTL, minted server-side only. No long-lived credential in the browser to leak.
Credential separation
API and App tokens stay server-side. Only the guest token reaches the browser, and it carries scope rather than privilege.
Rotation without downtime
Rotating an API token does not invalidate live guest tokens. Your end users keep working until their own TTL expires.
Web hardening
HTTPS enforced, CSP and HSTS headers, parameterised queries, input validation, output encoding, rate limiting and DDoS protection.
What you control, and what we control
You control
The trust boundary into Databrain
- Minting guest tokens server-side and mapping each end user to the correct
clientId - The allowlist of origins your embeds may render on
- The warehouse credentials you connect and the read-only grants on them
- Roles, dashboard permissions and row-level rules for your own users
- Token TTL, and revoking access when a customer offboards
- Whether AI features are enabled, per tenant
Databrain controls
Everything downstream of the signed token
- Validating company, workspace, Data App, dashboard and client scope before SQL is built
- Encryption in transit and at rest, and key handling
- Platform authentication, RBAC and access logging
- Vulnerability management, patching and independent testing
- Availability, backups and recovery of the platform
- Notifying you within 72 hours of a confirmed incident affecting your data
AI security
AI answers stay inside your permission boundaries.
- No training on your data
- Nothing from your warehouse or your customers’ sessions trains a model. Model providers are disclosed on request as part of our sub-processor list.
- Bounded by existing permissions
- AI queries run through the same signed tenant scope and row-level rules as every other query. It cannot answer with data a user is not allowed to see.
- Per-tenant AI controls
- Enable, configure or fully opt out of AI per tenant, so a customer whose contract prohibits AI processing can be excluded without excluding everyone.
Encryption standards and practices
AES-256 at rest
All data at rest in our secure private cloud is AES-256 encrypted, with stringent access controls. Warehouse credentials and API keys carry an additional layer of application-level encryption and are decryptable only by the components that need them. Keys are held outside source control, access-restricted, logged and rotated.
SSL/TLS in transit
TLS 1.2 or higher on all public network communication, HTTPS enforced for web traffic, and SSL mode on database connections where the warehouse supports it. All communication within Databrain is encrypted in transit.
Robust security measures
Product security
- DevSecOps practices integrated into the development lifecycle
- Secure design reviews, with SAST and DAST in CI/CD
- Strong multi-tenancy controls, enforced before SQL is built
- Dependency and CVE monitoring, OWASP Top 10 practices
Cloud security
- AWS infrastructure in highly resilient, certified data centres with redundancy
- 24/7/365 managed physical security and access controls
- Multi-availability-zone deployment for high availability
- Segmentation via VPCs, security groups and network ACLs
Operational security
- Continuous security logging and monitoring, with alerts on failed logins and unusual access
- Strict production access control with regular log reviews
- Vulnerability management and patching to defined SLAs
- Regular security reviews and independent penetration tests
Privacy and data protection
- Transparent data management policies aligned with regulations
- No selling or mining of customer data for advertising
- Granular access controls including row-level security
- Data residency options for regional requirements
Access, identity and audit
- RBAC with Admin, Editor and Viewer defaults, plus permissions you configure
- SSO via OIDC and SAML, including Google, Microsoft and custom IdPs through Keycloak
- MFA supported for users and required for our own production access
- Least privilege on our side, reviewed quarterly and fully logged
Business continuity and disaster recovery
- High-availability architecture across multiple availability zones
- Daily off-site backups, encrypted, with point-in-time recovery
- Annual disaster recovery tests and automated failover
- Incident notification within 72 hours of confirmation
| Patch cadence | Deployed within |
|---|---|
| Critical | 24 to 72 hours |
| High | 1 week |
| Medium | 30 days |
| Low | Next scheduled maintenance window |
| Deployment model | Where it runs |
|---|---|
| Cloud | Databrain-hosted on AWS. The default for most customers. |
| Self-hosted | Your infrastructure, on the Enterprise plan, when a customer contract requires it. Enterprise pricing → |
| Both | Every tenancy and query-layer guarantee above holds identically. Report a vulnerability to security@usedatabrain.com |
SLAs and trust
- 99.5%
- Uptime SLA on Enterprise plans
- 24/7
- Monitoring and support, 365 days a year
One resilience note specific to this architecture: because your rows stay in your warehouse, a Databrain outage affects dashboard availability rather than data integrity. There is no Databrain-side data set to lose.
Certifications and independent assurance
What we hold, and what each one actually covers
SOC 2 Type 2 is an attestation report, not a certification: an independent auditor tests whether controls operated over a 12-month period. It is the authoritative attachment for most questionnaire items. Request it and we will send it under NDA.
- SOC 2 Type 2Audited by a third party for Security, Availability and Confidentiality.Request under NDA →
Report available - CertifiedISO 27001Certified compliant, implementing all Annex A controls.Certificate on request →
- GDPRGDPR-compliant, with APIs that help you meet your own obligations.Request the DPA →
Compliant - HIPAAWith the option of a signed Business Associate Agreement (BAA).Request a BAA →
- CCPASupports your California Consumer Privacy Act obligations.Learn more →
- CompliantIndependent VAPTVulnerability assessment and penetration testing by qualified external assessors.Request scope and date →
NIST Cybersecurity Framework used as the internal control framework (self-assessed, not a certification)
Common questions from security reviewers
Does Databrain store our data?
Databrain does not copy or replicate your warehouse. Queries run live against your database with read-only credentials, and Databrain stores metadata such as schemas, dashboard and metric definitions, encrypted connection settings and user accounts. If you turn on result caching, query results are kept for 24 hours by default in Databrain’s managed Redis; if residency matters, point the cache at your own Redis or ElastiCache, or self-host Databrain on the Enterprise plan.
Is Databrain SOC 2 compliant?
Yes. Databrain holds a SOC 2 Type 2 report covering the Security, Availability and Confidentiality criteria, audited annually by an independent third party, and the report is shared under NDA. Databrain is also GDPR compliant and completes independent vulnerability assessment and penetration testing (VAPT). ISO 27001 certification is in progress. Current status for each framework is published on the trust portal at trust.usedatabrain.com.
Is single tenancy more secure than multi-tenancy?
Not inherently. Single tenancy separates customers physically, which is easier to explain to an auditor but adds cost, migrations and schema drift for every tenant. Multi-tenancy can be just as safe when tenant scope is enforced before a query is built and cannot be widened by the client. Databrain supports shared tables filtered by a tenant column and schema-per-tenant or database-per-tenant routing, with the tenant fixed by a server-created guest token. Builder metrics get the tenant filter injected into their SQL; custom SQL metrics must reference the tenant variable.
Who at Databrain can access our data?
Access at Databrain is limited to engineering, operations and support staff on a need-to-know basis, controlled by role-based access, protected by multi-factor authentication, logged and reviewed quarterly. Customer data is processed only to provide the service, and Databrain does not claim rights to use it for its own purposes. If you want Databrain running entirely inside your own infrastructure, the Enterprise plan includes self-hosting.
Can Databrain be self-hosted?
Yes. Databrain can be self-hosted on the Enterprise plan, running inside your own cloud or data center on Kubernetes or Docker, with the same embedding flow pointed at your own API URL. Databrain Cloud, the default, runs on AWS, and Enterprise cloud customers can connect over VPC peering or a bastion host. HIPAA-regulated teams can self-host on the Enterprise plan; talk to us about a BAA.
How does Databrain encrypt data?
Databrain encrypts all public network traffic with TLS 1.2 or higher and uses SSL for database connections where the database supports it. Data source credentials, SSH tunnel settings and connection details are encrypted at rest with AES-256, and API keys are encrypted and hashed for comparison. Backups run daily to geographically separate AWS S3 storage with server-side encryption, and user passwords are hashed with bcrypt.
Send this page to your security reviewer
If something on their questionnaire is not answered above, ask us and we will answer it in writing rather than on a call.