Trust Center
Security and operations of OdySecure, the security platform by Cybervize, in one place. This page collects what is publicly substantiated today. We discuss detailed documentation in a first conversation.
Hosting and data residency
- Hosting of the platform and processing of your data within it exclusively in data centers in Germany, with OVHcloud. OVHcloud is a European provider without a US parent company and, under current law, is not subject to the US CLOUD Act.
- One exception, and you choose it: in the BYOK operating mode you connect your own model provider, and the content sent to it leaves this scope. In the default mode (Sovereign) the language model runs in Germany, with no hand-off to external model providers.
- OVHcloud is the platform's only hosting subprocessor.
- Product development and security engineering in Germany.
Tenant isolation and access
- Strict tenant isolation between clients, including multi-tenant consulting operation.
- Role model with RBAC in four layers; four-eyes rules for critical actions.
- Audit-proof log of actions; access keys expire at the term set for them. Without a set term they do not expire.
- What sits behind the log: it is designed as an append-only log at the database level. Triggers reject UPDATE and DELETE on log entries, regardless of which application writes. Two exceptions are by design and named: anonymising the foreign keys to NULL when a user is deleted, and a transaction-local maintenance switch used exclusively by the documented paths for retention periods, GDPR redaction and tenant teardown. The switch applies only within that one transaction and ends with it; the triggers stay active throughout. The promise also has a limit above the database: in some places writing the log entry is best-effort. If it fails, the error is recorded in the technical log and the action still goes through. In the administration interface the log is read-only, including for accounts with the highest application privileges. This layer holds against any writing application, but not against interventions made with database administration rights. How we separate those rights is something we set out in the initial call.
AI governance
- Three operating modes for AI processing: Sovereign Mode (self-operated language model in Germany, no data passed to external model providers), BYOK (customer-owned API keys) and Managed Mode with defined data residency.
- The OdySecure Navigator answers only from data covered by read permissions, cites source and metric, and logs the questions audit-proof.
- AI agents are in a design-partner programme, not yet generally available: suggesting is the default, acting requires four-eyes approval, hard locks, a kill switch, and automatic entry in the platform's own AI system inventory.
Operations and assurance
- External penetration test of the platform by secuvera GmbH. Summary available on request.
- Multiple backups per day; recovery time objective (RTO) and recovery point objective (RPO) of 24 hours each. The recovery time is evidenced by a restore test; the recovery point follows from the backup interval, which sits well below it. We go through the test record in the initial call.
- Availability and support commitments are contractually defined. We state the specifics in the proposal.
- JSON data export that marks its own limits, and scheduled data deletion after contract end.
- Our own ISMS runs on OdySecure; certification to ISO 27001 is in preparation.
Reporting vulnerabilities
- Responsible disclosure process with encrypted reporting and a safe harbor commitment.
Privacy and contracts
- Privacy policy in accordance with GDPR.
- A standard data processing agreement under Art. 28 GDPR is available.
- We discuss technical and organizational measures in a first conversation.
Questions about the security architecture?
We are happy to walk you through the platform, the operating model and the documentation.
Book a first conversation