Customers trust us with the most sensitive category of information they hold

No, not without explicit authorization. Content is encrypted with AES-256-GCM using a unique 256-bit key per organization, held in AWS KMS (not on vario's servers). No vario engineer has kms:Decrypt permissions by default. Any support access requires your authorization from the admin dashboard, is logged with timestamp, user and IP in an immutable audit log (SHA-256 signed), and the token expires automatically in 4 hours. You can revoke before expiry by writing to infosec@vario.lat.

Your data is protected by independent layers. An attacker who compromises the database obtains unreadable ciphertext — the keys live in AWS KMS with completely separate access controls. Reading plaintext would require simultaneously compromising both the database and the KMS system. In the event of a confirmed incident, we notify your security contact within 24 hours of confirmation and assist with regulatory notification (GDPR/LGPD) within 72 hours.

No. Content is processed within our cloud provider's managed service, which does not share it with the model providers nor use it to train them. It is not an option we switch on: it is how the service works, and it is backed by the data processing agreement with the cloud provider. The first analysis layer, moreover, runs entirely inside our own infrastructure, with no network egress.

We state this precisely, because it is what an evaluator needs to know. Communication content is stored and operated in the platform cloud region, and stays there. The advanced analysis layer runs on a managed service within the same account perimeter, and its routing may process inference outside that region. That international transfer is identified, has a contractual basis with the cloud provider, and includes notice to data subjects. User identity is also delegated to a provider operating in the United States. None of those paths means content is shared with third parties outside the cloud provider.

Isolation is applied in overlapping layers. On every authenticated endpoint the customer is derived from the credential, never from the request. Native Row-Level Security policies in forced mode apply to tables with a customer dimension, with a connection role that has no bypass privilege. Isolation is verified automatically at the startup of every process, wired to alarms. And each customer has a dedicated cryptographic key, making cross-customer decryption cryptographically impossible. With one important precision: a limited set of tables is necessarily queried before customer context exists, during authentication and provisioning, and by definition cannot sit under Row-Level Security. There the protection is the application filter, and it is recorded as an exception with periodic review.