Trust
Trust & Security
OrgLens documents some of your most sensitive infrastructure — the structure of your Salesforce org. We treat that trust as the product. This page summarises how we protect your data across encryption, tenant isolation, backups, and incident response.
Encryption everywhere
TLS 1.2+ for all data in transit and AES-256 at rest for databases and backups.
Tenant isolation
Postgres row-level security (RLS) enforces per-organisation isolation at the database, not just the app.
Encrypted backups
Regular, age-encrypted backups with tested restores and off-site replication.
Incident response
A documented runbook with defined severities, notification timelines, and post-mortems.
1. Encryption
All traffic to OrgLens is served over HTTPS with modern TLS (1.2 or higher) and strong ciphers; HTTP requests are redirected to HTTPS and we send HSTS. Data at rest — including the application database and backups — is encrypted using AES-256. Secrets such as API keys and signing secrets are stored outside the codebase in access-restricted secret files (mode 600) and injected at runtime, never committed to source control.
2. Multi-tenant isolation (row-level security)
OrgLens is multi-tenant, and isolation is enforced in the database itself. Every
tenant-scoped table has PostgreSQL row-level security (RLS) policies that
constrain reads and writes to the current organisation's rows, with FORCE ROW LEVEL
SECURITY so the policy applies even to the application's own role. The application
sets the organisation and user context per request; cross-tenant reads return zero rows
and cross-tenant writes are rejected by the policy's WITH CHECK clause.
This isolation is continuously verified by an automated test suite covering
organisation-to-organisation isolation, IDOR-resistant lookups, cross-tenant write
rejection, and deny-by-default behaviour when no context is set.
3. Access control
The application connects to the database as a non-superuser, least-privilege role so that RLS always applies. Administrative access to production is limited to authorised personnel over a private network, and credentials are rotated when exposure is suspected. Within your workspace, role-based membership controls who can view, review, and deploy documentation.
4. Backups & resilience
We take regular automated backups of the production database. Backups are encrypted with an age public key and stored off-site, following a pull-based architecture so that the production host does not hold the means to read prior backups. Restores are tested end-to-end so that recovery works when it is needed, not just in theory. Container resources are capped per service to protect availability on shared infrastructure.
5. Network & application security
Internal services run on a private Docker network and are not exposed directly to the public internet; an edge reverse proxy terminates TLS and adds security headers (HSTS, a restrictive Permissions-Policy, and content-type protections). The metrics endpoint is blocked at the edge and reachable only inside the internal network. The API is rate-limited to absorb bursts and resist abuse. Inbound webhooks (for example from Stripe and Salesforce) are cryptographically verified — Stripe events are checked against the signing secret and replayed events are rejected idempotently — before any state change is applied.
6. Incident response
We maintain an incident-response runbook with defined severity levels, on-call ownership, and communication steps. On confirming a security incident we contain it, assess scope, and notify affected customers and, where applicable, supervisory authorities within the timelines required by law (for qualifying personal-data breaches, without undue delay and within 72 hours where the GDPR applies). Material service incidents are posted to our status page, and we conduct blameless post-mortems to prevent recurrence.
7. Sub-processors & hosting
OrgLens is hosted on EU infrastructure (Hetzner, Germany). We use a small set of vetted sub-processors — including Stripe for payments, Anthropic for AI generation, AWS SES for email, and Cloudflare for DNS and edge protection — each under data-protection terms. The current list, purposes, and regions are published in our Privacy Policy.
8. Responsible disclosure
We welcome reports from security researchers. If you believe you have found a vulnerability, please email security@orglens.app (see also our security.txt). Please give us a reasonable opportunity to remediate before public disclosure, avoid privacy violations and service disruption, and do not access data beyond what is necessary to demonstrate the issue. We will acknowledge valid reports and keep you informed of remediation.