Data processing agreement

4. Subprocessors

We use a limited set of subprocessors to deliver the Service, covering infrastructure and hosting, transactional email delivery, and AI providers for specific capabilities. Each is engaged under a written contract with data protection obligations no less protective than these.

A current subprocessor list is available on request. We notify customers of intended changes to that list so they have an opportunity to object on reasonable data protection grounds.

5. Security measures

• Tenant isolation: each customer runs in a separate Site with its own database, and requests resolve to a single Site before business logic runs.
• Access control: the platform's permission system governs record, row, and field access, and applies identically to the UI, the API, and Trivena AI.
• Encryption in transit: all traffic to Sites is served over HTTPS with automatically renewed certificates and HSTS enabled.
• Operational access: administrative access to infrastructure is restricted to the personnel who operate Trivena Cloud, over authenticated channels.
• Backups: automated on a schedule, with restoration performed by Trivena.
• Monitoring: continuous monitoring of the control plane, workers, proxies, and database hosts, published at status.trivena.tech.
• Patching: platform, application, and infrastructure updates applied as part of running the Service.
• Environment separation: test and staging Sites are separate tenants, so evaluating a change does not touch production data.

Our security page describes these measures in more depth.

6. Trivena AI

AI capabilities operate within a single Site and in the context of the requesting user's permissions. Customer data is used to answer that customer's requests, and not to train models shared across customers. Where an external AI provider processes a request, it does so as a subprocessor under contract. An enterprise option for customers to use their own AI provider or keys is planned.

7. International transfers

Trivena is operated from the Netherlands and we prefer subprocessors within the European Economic Area. Where a transfer outside the EEA is necessary, we rely on an appropriate transfer mechanism such as the European Commission's standard contractual clauses, together with any additional measures required.

8. Data subject requests

Requests from data subjects should be directed to the customer as controller. Where a request reaches us directly, we forward it rather than acting on it, and we assist the customer in responding, including by making the relevant records available or exportable from their Site.

9. Breach notification

If we become aware of a personal data breach affecting customer data, we notify the customer's administrative contact without undue delay, with the information available at that point: what happened, which data is affected as far as we know, what we are doing about it, and what we recommend the customer does. Updates follow as the investigation progresses.

10. Audit and information

On reasonable request we provide the information a customer needs to assess our compliance with this DPA, including descriptions of our architecture, security measures, and subprocessors. Enterprise agreements can include further audit arrangements.

11. Return and deletion

Customer data remains exportable over the REST API and in standard formats throughout the term. After termination we make it available for export for a defined period, then delete it from active systems and, on the expiry of the backup cycle, from backups, unless law requires longer retention.

12. Getting a signed DPA

This page is a summary so you can evaluate our terms before asking for paperwork. For a signed DPA covering your specific processing, including standard contractual clauses where relevant, contact us and tell us which entity is contracting.