Trust Security at Lumen BI Security at Lumen BI
Last updated: July 2026.
This page summarizes the security controls that are actually implemented in Lumen BI today. It is maintained by the Lumen BI team and is not a third-party certification or a legal commitment. For a current Data Processing Agreement or vendor security questionnaire, contact support@lumenbi.app.
Encryption
All traffic between your browser and Lumen BI is encrypted in transit using TLS 1.2 or higher. Customer data at rest in our managed Postgres database, file storage, and backups is encrypted using AES-256 by the underlying cloud provider.
Tenant isolation
Every row of customer data is scoped to a workspace and protected by database-level row-level security (RLS) policies. Server functions verify the calling user's session and only ever execute queries under that user's identity, except for narrowly scoped administrative tasks performed by our team under audit.
Authentication & access control
Authentication is handled by our identity provider with email/password (HIBP-checked passwords), Google OAuth, and magic-link sign-in. Access inside a workspace is governed by per-workspace roles (owner, admin, editor, viewer). Sensitive operations are rate-limited and logged.
Secrets & credentials
Data source credentials (database passwords, API keys) are encrypted at the application layer with a separate envelope key before being stored. Secrets are never returned to the client and are decrypted only inside server-side handlers when needed to execute a query.
Customer-Managed Encryption Keys (CMEK / BYOK)
Status: Enterprise roadmap — available on request. Customer-Managed Encryption Keys are not enabled by default on Lumen BI today. All workspaces currently use platform-managed AES-256 keys (see Encryption above).
For enterprise customers in regulated industries (banking, healthcare, government) that require BYOK, we can scope a Phase 1 deployment in which per-workspace data-encryption keys used to seal data-source credentials and uploaded file blobs are wrapped by a KMS key that lives in the customer's own AWS account. The customer retains the ability to rotate or revoke the key; revocation makes the wrapped data unreadable to Lumen BI.
This is a contracted engagement, not a self-serve toggle. It requires a signed Enterprise agreement, an AWS account with a dedicated KMS key, an IAM trust policy for Lumen BI's service role, and an agreed key-revocation runbook. Azure Key Vault, Google Cloud KMS, and HashiCorp Vault Transit are on the longer-term roadmap. To discuss scope, contact support@lumenbi.app.
Monitoring & audit
We capture application errors and performance traces in our monitoring provider, and record an immutable audit trail of significant actions (sign-ins, role changes, billing events, data exports, deletions). Admins can review activity from the in-product audit log.
Backups & business continuity
The managed database is continuously backed up with point-in-time recovery within the retention window provided by our infrastructure partner. We periodically validate restore procedures.
Sub-processors
Lumen BI uses a small set of sub-processors to operate the platform. They are listed on our Subprocessors page. We notify customers of material changes at least 30 days in advance.
Incident response
If we become aware of a security incident affecting your data, we will investigate, mitigate, and notify affected customers without undue delay and in line with applicable data protection law. Incident reports are sent to the email on file for workspace owners and admins.
Responsible disclosure
Report suspected vulnerabilities to support@lumenbi.app. We will acknowledge within two business days, work with you on a remediation timeline, and credit you where you wish to be credited. Please do not publicly disclose issues before we have had a reasonable opportunity to fix them.
What customers are responsible for
Security is a shared responsibility. You are responsible for choosing strong passwords, enabling MFA where supported, managing workspace roles, scoping connector credentials to least privilege, classifying which data is appropriate to upload, and reviewing AI outputs before acting on them.