Sub-processors

Why this page exists

When you use Ever Traduora to process personal data, we act as your processor and you are the controller. Article 28 GDPR says we may not bring in another processor without your authorisation, and that you must be told in advance when we intend to add or replace one so that you have a real chance to object.

This page is that disclosure. It names every provider we engage to process personal data for the hosted Service, says what each one does, where it does it, and what categories of data reach it. Our Data Processing Addendum refers to this page, and your general authorisation to the providers listed here is given through it.

It is also written for people who are not our customers — someone whose employer uses the Service, or whose data ends up here for some other reason — because "who else can see this" is a fair question and the answer should not be available only to the person paying the invoice.

What counts as a sub-processor

A sub-processor is a third party we engage that processes personal data on our behalf and on our instructions, under a written contract meeting Article 28 GDPR. A provider that keeps the servers running, delivers your email, catches our errors or answers your support chat is a sub-processor.

Three things are not sub-processors, and lumping them in would make this page less accurate rather than more complete:

• A provider that never touches personal data. A design tool or an accounting package we use internally is not in the path of your data.
• A company that decides its own purposes. A payment processor acting on its own regulated obligations — fraud prevention, anti-money-laundering, card-scheme rules — is a controller in its own right for that part, not our processor. Those recipients are described in the Privacy Policy instead.
• Something we run ourselves. Our databases, object storage, secrets manager and container platform are ours. There is no third party to disclose. The infrastructure section below explains what we operate and what genuinely sits in front of it.

What this page covers

The hosted Service we operate at traduora.co, for Ever Traduora specifically. Other products in our range have their own list on their own domain, and the providers differ between them — do not read this one as covering a product it does not name.

It does not cover a deployment you run yourself. If you install our open-source software on your own infrastructure, you choose your own providers with your own credentials and contracts. The third tier below exists to make that distinction visible rather than to blur it.

This page is versioned and dated. The version in force, and the date it took effect, are at the end.

How to read this list

The three tables that follow mean genuinely different things, and reading them as one flat list will give you the wrong answer.

Here is why the split exists. Our products are open-source at their core and built to be connected to other things, so more than 160 distinct third-party providers appear somewhere in our source code across our whole range of products. The overwhelming majority of them are never engaged by us for anything. Some are optional integrations that do nothing until somebody switches them on. Many are reachable only in a deployment that somebody else runs, with their own account and their own credentials.

Publishing all of them as "our sub-processors" would be inaccurate, and inaccurate in the worst direction: it would tell you your data reaches companies it never touches, while burying the handful that it actually does. A list that is technically exhaustive and practically misleading is not a disclosure. So there are three tiers.

Tier 1 — always engaged

If you use the hosted Service, these providers are in the path. There is no setting that removes them, because they are part of how the Service is delivered to everyone.

This is the real Article 28 sub-processor list. It is the tier to use when you are completing a data protection impact assessment, mapping your transfers, or deciding whether you can use the Service at all. It is short, and it is short because we run our own infrastructure rather than renting someone else's.

Tier 2 — engaged only if you turn something on

A provider in this tier is engaged only when a specific feature, connector or integration is enabled. Enable nothing and it is never involved, and no data of yours ever reaches it.

Who does the enabling depends on the feature:

• You or your workspace administrator, by switching on a feature or connecting an account in the product's settings — a payment provider, an analytics tool, a chat widget, a calendar or repository connector.
• An individual user, by making a personal choice — signing in with a social account, for example, or connecting their own third-party tool.

The table names the feature or setting that activates each provider, so you can check your own configuration against it rather than take our word for the current state. If you want to know precisely which of these are live for your workspace today, ask us at [email protected] and we will tell you.

Enabling one of these is a decision to send your data somewhere else, and it is yours to make. The provider's own terms and privacy notice then apply to what it does, alongside our contract with it.

Tier 3 — self-hosted deployments only

Several of our products are published as open source and can be run on your own infrastructure. When you do that, you choose the database, the object storage, the email relay, the AI provider and everything else, using your own accounts and your own credentials.

The providers in this tier are listed only so that you can see what the software can be pointed at. They are not our sub-processors, and they never become ours by appearing here.

In a deployment you run: we process nothing, we have no access to it, we are not your processor for it, and nothing on this page or in our Data Processing Addendum describes it. You choose those providers, you contract with them, you hold the credentials, and the obligations to your own users are yours alone. The open-source section of our Terms of Service sets out the same split.

If you run a deployment yourself and need to publish a sub-processor list of your own, this tier is a useful starting inventory. It is not your list — only you know which of these you actually configured.

What the columns mean

• Sub-processor — the contracting legal entity, not the brand on the website. Where a provider has a separate European establishment that contracts with us, that is the one named.
• Purpose — what it does for the Service, specifically enough to be checked. Not "business operations".
• Location — where the processing takes place, or the provider's place of establishment where processing is distributed. Where a provider contracts through a European establishment but processes elsewhere, this column says both, because the two are different facts and only naming the first would flatter us.
• Transfer mechanism — for a provider outside the European Economic Area, the Chapter V instrument we actually rely on for that specific provider: an adequacy decision, the Standard Contractual Clauses, or nothing yet. Where it reads "To be confirmed", we have not yet evidenced an instrument for that provider, and we would rather say so here than print one we cannot produce. That is a live piece of work, not a formula. Providers established inside the EEA need no mechanism and say so. For the third tier the transfer is not ours at all — you choose the provider and hold the contract. The general rules behind this column are in the international transfers section of our Privacy Policy, and we will give you a copy of the safeguards for a named provider on request.
• Personal data — the categories that reach that provider. Categories, not a promise about volume: a provider that receives email addresses receives them for the people who trigger the feature, not for everyone.

Why this list is deliberately longer than it needs to be

We list providers we may engage, not only the ones engaged today. Where we have configured a provider, kept one available behind a feature flag, used one recently, or expect to use one for a purpose already described here, it appears in the tables below — even if no data has reached it this month, and even where we currently run the equivalent ourselves.

We do this on purpose, and you should read the tables with it in mind:

• A provider appearing here is not proof that your data has reached it. It means the provider is within the scope of what we have told you we may do, at the tier shown. The tier is the part that tells you when it is engaged.
• Where we self-host something today — our analytics, our job runner, our databases, our object storage — we say so, and we also name the hosted service we would move to, so that a later change is covered by a disclosure you have already seen rather than by a fresh surprise.
• The alternative is worse. A list that names only today's exact set has to be re-issued, and re-consented, every time an engineer changes a setting. A list drawn slightly wide stays true through ordinary operational change, which is what makes it dependable.

What we will not do is use this as cover. Breadth here does not license a purpose we have not described, a category of data we have not listed, or a transfer without a mechanism. If we start sending a new kind of personal data, or sending it for a new reason, that is a change to this page and to the notice period below — not something the width of a table quietly absorbs.

If you need to know precisely which providers are live for your workspace today, rather than which ones may be, ask us at [email protected] and we will tell you.

What is deliberately not in the tables

• Infrastructure we operate ourselves. Our databases, object storage, cache, secrets manager and container platform are not sub-processors, because there is no third party involved. The next section describes what we run and what really does sit in front of it.
• Recipients that are not processors — payment providers acting under their own regulatory obligations, professional advisers, public authorities, and an acquirer in a corporate transaction. Those are covered in the Privacy Policy.
• Sites you choose to visit by following a link out of the Service. Once you are on someone else's site, their notice applies.

Annex: Ever Traduora

Tier 1 — always engaged

Tier 2 — engaged only when a feature, integration or consent brings them in

Tier 3 — self-hosted deployments only

If you run Ever Traduora on your own infrastructure, you choose these providers and hold the credentials. We are not a processor for anything in a deployment you run: we do not receive that data, we cannot reach it, and we have no relationship with the providers you configure.

There is no hosted service, so this list is short

Ever Traduora is open source and self-hosted. We do not run a cloud version of it, which means we hold none of your translation data and engage no sub-processor for it. Tier 1 above covers only the traduora.co website and its documentation.

If you run Ever Traduora, every provider it talks to is one you configured, under your own account. That is the whole of tier 3, and none of it involves us.

Hosting and infrastructure

The tables above are short for a reason, and the reason is worth stating plainly: we run our own infrastructure. The Service is not a tenancy in a public cloud account. It runs on physical servers we own, in facilities we control, inside the European Union, on a virtualisation and container platform we operate ourselves.

The database, the object storage that holds your files, the cache and queue layers, the secrets manager and the deployment system are all components we run. None of them is a third party, so none of them appears as a sub-processor — there is nobody else to disclose. What we do with them is described on our Security page.

Where processing actually happens

• Your data at rest, and the applications that process it, sit on our own hardware in the European Union. That is the primary location for accounts, content, files and the databases behind them.
• Requests reach us through a global content delivery and security network. Traffic is terminated at the edge location nearest to whoever is making the request, which can be anywhere in the world, before being carried to our infrastructure in Europe. That provider is in the always-engaged tier above, and the transfer mechanism for it is described in our Privacy Policy.
• Off-site backup copies are held with an external object storage provider, encrypted by us before they leave our network. That provider holds ciphertext and no key, and cannot read what it stores.
• Our source code, build pipeline and container images are hosted with a third-party provider. That is how the Service is built and deployed rather than where your data lives day to day, but it is a genuine third party and it is disclosed as one.

Where a product does something different

A small number of products use a third-party managed database, managed storage or hosted platform for a specific function instead of our own infrastructure. Where that is the case for Ever Traduora, the provider appears in the always-engaged tier above and the product annex says which data goes there.

We are explicit about this because "self-hosted" is exactly the sort of claim that gets made once and then stops being true for one product in the range. If your data for a given feature sits with someone else, the table says so.

The regions you should design around

If you are completing a transfer mapping or a data protection impact assessment, the honest summary is: primary processing in the European Union on infrastructure we operate; edge termination worldwide; a small number of named providers established outside the European Economic Area, each with its own transfer mechanism. Every one of those providers is in the tables above, and the mechanism for each is in the international transfers section of the Privacy Policy.

If you need a copy of the safeguards for a named provider — the Standard Contractual Clauses and which modules apply — write to [email protected] and we will send them.

When this list changes

The notice period

We give at least 30 days' notice before a new or replacement sub-processor starts processing personal data for the hosted Service. The 30 days run from the date the notice is published or sent, whichever comes first, and they exist so that your objection right is a real one rather than a formality you learn about afterwards.

How you find out

• This page changes first. It carries the date it took effect and a dated record of what changed, so the page itself is the notice.
• By email, if you ask for it. Write to [email protected] and we will add your address to the notification list. We then email you before each change, at the same time the page is updated. We recommend a role address rather than an individual's — a notice sent to someone who has left your organisation has been sent and not received.
• In the product, for changes that affect a feature you are using, through a notice to workspace administrators.

What the notice tells you

The provider's legal name, what it will do, where it is established, the categories of personal data it will receive, the transfer mechanism if it is outside the European Economic Area, the date it takes effect, and whether it is a new provider or replaces one already on the list. If it replaces one, we say which.

Urgent replacements

Sometimes we have to move faster than 30 days — a provider suffers a security incident, terminates its service, loses the legal basis it relied on, or fails in a way that makes staying with it worse than leaving.

Where that happens we may engage the replacement sooner, and we will notify you as quickly as we can with the reason we could not wait. Your right to object is not affected: it simply runs from the notice instead of before the change. We do not use this route as a convenience, and a notice sent under it says plainly why the normal period was not followed.

Changes that do not need notice

Removing a provider does not need a notice period — it reduces the number of people handling your data. A provider changing its own name, or the group entity that contracts with us changing without a change in where or how the processing happens, is recorded here as an administrative update rather than announced as a new engagement. A provider moving its processing to a different country is not administrative, and gets the full notice.

The record

We keep the change history for this page so that you can reconstruct who was engaged during a given period. That matters if you are updating your own records of processing, refreshing an impact assessment, or answering a question about a period in the past. Ask [email protected] if you need the state of the list as it stood on a particular date.

Objecting to a sub-processor

Who can object

The customer — the organisation or person who contracts with us and acts as controller for the data in the workspace. If you are an individual whose data we hold, this is not your route: your rights are in the Privacy Policy, and if your data sits in an employer's workspace, your employer is the controller and the request goes to them.

How to object

Write to [email protected] within 30 days of the notice, and tell us:

• which provider you are objecting to;
• your reasons, on data protection grounds — a transfer you cannot justify, a conflict with a commitment you have given your own users, a regulator's position that applies to you, a documented security concern;
• which of your workspaces or environments the objection covers.

The reasons matter. This is a right to object on data protection grounds, not a veto over our choice of suppliers, and an objection with no stated ground gives us nothing to work with. Tell us what the problem is and we can usually solve it.

What we do next

We acknowledge your objection within five business days and respond substantively within 30 days. In between we look for a way to make the objection unnecessary:

• A different provider for your workspace, where one exists that does the job.
• A different configuration — narrowing what is sent, changing a region, or turning off the feature that needs the provider at all, if you can live without it.
• Excluding your workspace from the provider, where that is technically possible.
• Additional safeguards or contractual terms where your concern is about a specific risk rather than the provider as a whole.

Where it is technically possible to hold off, we will not start using the provider you have objected to for your data while the objection is open. Where it is not possible — because the provider is part of how the Service is delivered to everyone — we will tell you that plainly and quickly, rather than letting the clock run out on you.

If we cannot resolve it

If we cannot offer you a solution you can accept, you may terminate the affected subscription by written notice, without penalty, and we will refund the fees you have prepaid for the period after termination. That is the remedy: neither of us owes the other damages for a good-faith disagreement about a supplier.

Give us notice within 30 days of our final response, and we will keep your data available for export for the usual 30-day window described in the Terms of Service so that leaving does not cost you the data.

If you are on a free tier there is nothing to refund, and the same route is simply to stop using the Service and export your data.

Objecting to a provider already on the list

You do not have to wait for a change. You can raise a concern about a provider already listed at any time, using the same address and the same process, without the 30-day deadline. The realistic outcome differs by tier: a tier 2 provider can usually be switched off for you; a tier 1 provider generally cannot, because it is part of how the Service works — and if the answer is going to be no, you will get it as a straight no with the reason.

How to reach us about this list

• Questions about a provider, a request for the safeguards behind a transfer, or a request to join the change notification list — [email protected].
• An objection to a sub-processor — [email protected], as set out above.
• The Data Processing Addendum, a due diligence request, or a security questionnaire — [email protected].

We are Ever Technologies LTD, registered in Bulgaria under company number 204599535, with its registered office at Mladost 2, bl. 211, ent. A, Sofia 1799, Bulgaria. We are the controller for our own processing and your processor for the data in your workspace. By post, write to the registered office and mark the letter for the attention of the privacy team. We correspond in English.

You may also complain to a data protection supervisory authority. Ours is the Commission for Personal Data Protection (Комисия за защита на личните данни), the CPDP, at https://www.cpdp.bg/. You may instead complain to the authority for the country where you live or work.

This document is version 1.0.2 of the sub-processor list for traduora.co, in force from 2026-08-02. It lists the providers engaged as at that date. Earlier versions, with the dates they applied, are at https://traduora.co/subprocessors.