Orvoq is where your team and your AI work side by side — which means the platform holds your conversations, your documents, and your decisions. This page explains how we protect that data: how tenants are isolated, how data is encrypted, how access is controlled, and how we watch for and respond to problems.
Orvoq serves both companies (B2B organizations) and individuals (B2C) from one shared platform. Every customer's data lives in a separate logical boundary called an organization — enforced by four independent layers, so no single mistake in one layer can expose one customer's data to another.
Every request is authenticated and its organization is resolved and validated against your actual membership records — never taken on trust from a client-supplied value alone.
Access to any resource requires an explicit, database-checked permission grant. Missing configuration fails closed, not open.
Every database read and write is automatically scoped to your organization at the data-access layer, so a query simply cannot reach across tenants by default.
A second, independent guard sits directly in front of the database and blocks any query that isn't properly scoped — a backstop that catches what the layers above might miss.
We run an automated cross-tenant isolation test suite that proves, continuously, that one customer's data cannot be read, listed, or modified by another — including adversarial tests that try to bypass scoping through query composition tricks.
All traffic to and from Orvoq is encrypted with TLS 1.2 or higher. Connections between our services and our data stores are also encrypted.
Customer data is encrypted at rest. Sensitive fields — API keys, OAuth tokens, SSO client secrets — receive an additional layer of AES-256-GCM encryption under AWS KMS-managed keys.
Sensitive field encryption cryptographically binds each value to the owning organization — a ciphertext can't be decrypted if it's ever moved into the wrong tenant's context.
Encryption covers fields before they reach the database driver, using MongoDB CSFLE with a per-organization data key — sensitive fields can be cryptographically erased on request by destroying that key.
Encryption keys are managed through AWS KMS. Enterprise customers can optionally bring their own customer-managed key for an added layer of control.
No unencrypted customer data at rest, in transit, or in our backups — encryption is the default, not an opt-in.
Platform secrets — database credentials, provider API keys, and integration client secrets — are managed through AWS Secrets Manager rather than static configuration, with scheduled rotation. Secrets are never written to disk or persisted outside the secrets store.
Rotated every 30 days automatically, with zero-downtime rollover.
Rotated every 90 days, or on-demand if a compromise is suspected.
Orvoq runs on AWS. Our infrastructure security posture includes:
Security isn't a review gate at the end — it's built into every stage between a commit and a deployment, with automated tooling that blocks a merge or a release rather than relying on someone remembering to check.
Every code change is checked by automated tests, linting, and type checking before it can be merged. No direct commits to production branches — every change goes through a pull request.
Every commit and pull request is scanned for accidentally committed credentials — API keys, tokens, private keys, connection strings — using pattern-based and entropy-based detection. A match blocks the commit locally and fails the CI pipeline as a backstop.
Semgrep runs on every pull request, checking for OWASP Top 10 patterns — injection, XSS, insecure deserialization, unsafe cryptography, hardcoded secrets — plus custom rules specific to Orvoq's own multi-tenancy patterns, including a rule that flags any database query missing tenant-scoping before it can reach review.
Every first- and third-party dependency is scanned against the National Vulnerability Database (NVD) for known CVEs on every build, not just on a schedule — so a newly disclosed vulnerability in an existing dependency is caught on the next commit, not weeks later.
Every container image is scanned before deployment for OS package vulnerabilities and misconfigurations. Base images are kept minimal (distroless where practical) and rebuilt on a regular patch schedule, not just when application code changes.
Automated active scans run against a staging environment, simulating real attack patterns against the running application — catching runtime issues static analysis can't see, like authentication flow weaknesses, session-handling bugs, and live API behavior under adversarial input.
CI/CD deploys with no long-lived credentials, automatic rollback on failed health checks, and no direct production access outside the pipeline — nobody, including engineering leadership, deploys by hand.
Continuous, ML-driven threat detection watching for anomalous API calls, compromised credentials, cryptomining activity, and unusual data access patterns — running independently of anything the application code does.
Aggregates findings from GuardDuty, Config, Inspector, and other AWS security services into one place, mapped against the CIS AWS Foundations Benchmark, so drift and misconfiguration are visible in one dashboard rather than scattered across services.
Every stage above enforces tenant-isolation guarantees specifically — including a CI check that blocks any new data collection from shipping without a corresponding isolation test alongside it.
Organizations can configure a preferred data residency region. We document data flows and retention for each category of data we store, and do not retain data longer than necessary for the purpose it was collected for or as required by law.
Orvoq is built against the control frameworks that matter to enterprise buyers, mapping technical controls to recognized frameworks and maintaining evidence — tests, metrics, and configuration checks — for each control on an ongoing basis.
| Framework | Status | Notes |
|---|---|---|
| SOC 2 Type II | Not yet certified | No audit is currently underway. Our technical controls — tenant isolation, encryption, access management, audit logging, and the secure development pipeline — are built to align with SOC 2 Trust Services Criteria, and formal certification is a planned milestone as we scale. |
| ISO 27001 | Not certified | Not currently pursuing certification. Controls are mapped against ISO 27001 Annex A as a reference framework for our own program. |
| GDPR / CCPA | Practices in place | Configurable data residency, documented data flows, and retention limits support these obligations — this describes our technical controls, not a legal compliance determination, which depends on your own use of the product too. |
No SOC 2 or ISO 27001 report exists yet to share. What we can share today: a detailed security questionnaire response and documentation of the controls described on this page — reach out to our security team.
Email security@orvoq.com with details, and we'll acknowledge your report and work with you on a fix and timeline.
Please don't share the issue publicly until we've had a chance to address it.
Read the full Responsible Disclosure Policy →For security questionnaires, penetration test summaries, subprocessor lists, or DPAs, contact our security team or your Orvoq account team.
security@orvoq.comContact sales