List of sub-processors

Animiyo is a multi-tenant SaaS platform for pet management: a Next.js web application hosted on Google Cloud Run and a native iOS application share the same Firebase backend, in the Google Cloud project petdiary-10327. None of these components runs on machines owned by whoever develops the service, so every piece of data handled by the platform passes through a third party provider. Publishing the list of those providers is the most direct way to let anyone check where their data ends up.

Animiyo has two distinct roles. It is the controller for pet owner accounts, that is for people who sign up and use the application for themselves. It is instead the processor for the data that tenants, veterinary clinics and shops, process about their own clients. This list applies in both cases, with a difference in legal qualification: in the first case the providers are processors appointed by Animiyo, in the second they are sub-processors authorised under Article 28 paragraphs 2 and 4 of Regulation (EU) 2016/679.

Two kinds of readers use this page. The data subject, meaning the person whose data is processed, uses it to check that the notice at /privacy tells the truth and to exercise the rights described at /diritti-privacy. The tenant controller uses it to meet the information obligation set out in the agreement at /dpa, to update its own record of processing activities and to decide whether to accept a provider or object to it. Publication therefore satisfies both the transparency obligation towards data subjects and the information obligation towards tenant controllers.

The tables below are the substance of this document: the paragraphs only exist to explain them. If a row changes, the update date at the top of the page changes too and an entry appears in the change log at the end.

A provider is activated only after passing a fixed set of checks, always applied in the same order. This is not a discretionary assessment: they are minimum requirements, and a provider that fails them does not enter the platform, however convenient or cheap the service may be.

• Sufficient guarantees under Article 28 paragraph 1: a signed data processing agreement, documented security measures, transparency about where data is held.
• An absolute ban on clauses allowing the provider to process data for its own purposes, including training artificial intelligence models, without separate and revocable consent.
• Breach notification within twenty four hours, acceptable up to forty eight.
• An obligation to delete data within thirty days of the end of the relationship, with written confirmation that deletion took place.
• Publication by the provider of its own list of further sub-processors.
• Minimisation: for the same function we choose the provider that receives the smallest amount of data needed.

One term alone is not negotiable. No provider may process user data for its own purposes, and in particular to train artificial intelligence models, without separate, informed and revocable consent. On every other point a less favourable clause can be balanced by technical or organisational measures; on this one it cannot, because data that has entered a model can no longer be retrieved or deleted in any verifiable way. If a provider introduces such a clause into its terms, the service is replaced through the procedure described further down.

This is the main table of the document. For each provider it states the service, the categories of data received, where processing takes place and the legal role. The role reads processor because the provider handles data on behalf of Animiyo and under its instructions; towards tenant controllers the same provider is an authorised sub-processor.

The Google group appears eight times rather than once. This is not pointless repetition: each row is a separate service, with its own configuration, its own location and its own category of data. Firebase Authentication knows the email address but not the contents of the health record; Cloud Storage for Firebase holds photographs but knows nothing about appointments; Google Analytics 4 sees only the public site and never the signed in area. Listing the services separately makes it possible to understand which data would be involved in an incident affecting only one of them, and to replace one without touching the others.

The wording global infrastructure marks the services that do not allow a processing region to be chosen: the provider delivers them from a distributed network and data may be handled in more than one location. This applies to push notifications, to fraud prevention checks and to public site measurement, that is to services handling technical identifiers rather than account content. For these cases the transfer basis is the same as described in the section on data location.

Stripe Payments Europe Limited appears in the list even though it receives no data. The integration exists in the code but the gateway is switched off by a configuration flag, so no payment information leaves the platform. The row stays in the table for transparency: the day the flag is switched on it will not be a hidden novelty, and activation will in any case follow the notice period set for sub-processor changes.

Some features of the platform read information from public databases: a medicine data sheet, the nutritional value of a food, a breed description, an exchange rate, a map tile. These are calls that only read data, they start from the user's browser and they carry neither the account identifier nor any diary content. They do, however, transmit the browser IP address and the technical details of the request, which is why they must be declared.

These services are not processors, because they do not process data on behalf of Animiyo and receive no instructions from Animiyo on how to use the information they obtain. In relation to the connection data they collect they are independent controllers: they determine purposes and means themselves, apply their own notices and answer directly for their own choices. The difference is not a formality. A processor handles data only as it has been told to and deletes it when asked; an independent controller answers in its own right, and requests concerning that connection data must be addressed to it.

The main resources of the platform sit in the us-central1 region, in the United States. This means that account data, uploaded content and system logs are processed outside the European Economic Area, and that the transfer must rest on a valid legal basis as well as on adequate technical measures.

The safeguards accompanying the transfer to the United States are the following.

• Google Ireland Limited as contracting counterparty, under the Google Cloud Data Processing Terms.
• Standard contractual clauses adopted by the European Commission with implementing decision 2021/914.
• Certification of Google LLC under the EU United States Data Privacy Framework.
• Encryption of data in transit with TLS and at rest with AES at 256 bits.
• A transfer impact assessment documented by the owner.
• Google's policy on handling requests from public authorities.

Migrating the resources to a European region, in the europe-west area, is under consideration. It is not a settled decision, because it means rebuilding part of the infrastructure and accepting a window of service unavailability. If it happens, it will be announced on this page with the same notice period set for adding or replacing a sub-processor, so that tenant controllers can update their own documentation before the change takes effect.

Towards tenant controllers, the use of the listed providers rests on a general authorisation under Article 28 paragraph 4 of Regulation (EU) 2016/679. A general authorisation is not a blank cheque: whoever grants it keeps the right to know in advance what changes and to object. The procedure below describes how that right is exercised in practice.

1. 1

   Publication of the notice

   At least thirty days before adding or replacing a sub-processor, the change is published on this page, stating the provider, the service, the data involved and the planned activation date.

2. 2

   Message to the tenant

   At the same time as publication, the notice is sent to the email address the tenant has entered in its profile. Keeping that address up to date and monitored is the tenant's responsibility.

3. 3

   Reasoned objection

   The tenant may object within fifteen days of the notice, stating the grounds for the objection. Objections are sent from the /contatti page and must be reasoned, that is they must explain which risk or which constraint makes the proposed provider unacceptable.

4. 4

   Search for an alternative measure

   Before the activation date we assess whether the objection can be resolved by alternative measures: a different configuration, a different region, a reduction of the data transmitted or a different provider for that function.

5. 5

   Termination without penalty

   If the objection cannot be resolved, the tenant controller may terminate without penalty the part of the service affected by the change, in the manner set out in the agreement published at /dpa.

There is a single exception to the thirty day notice. If a provider must be replaced on security grounds, for example after a serious vulnerability or the sudden discontinuation of a service, the replacement may take place with shortened notice. In that case the message to tenants is immediate and the right to object remains intact, but it is exercised after the change rather than before. Waiting thirty days in the face of an ongoing risk would harm exactly the people the procedure is meant to protect.

This list covers the providers chosen by Animiyo to run the platform. It does not cover the providers chosen by the tenant. When a veterinary clinic or a shop connects its own tools, exports data from the platform or passes it to its own providers, those providers do not appear here and remain the tenant's responsibility: the tenant must appoint them as processors and inform its own data subjects.

The distinction matters above all for people who have left their data with a clinic or a shop. If a request concerns a provider the tenant has chosen on its own, it must be addressed to the tenant, because the tenant is the controller of that processing and only the tenant knows which tools it has connected. This page still remains the starting point for understanding which providers are common to everyone and which are not.

A list of sub-processors says a great deal through what it leaves out. The categories of provider below are absent from the platform, and their absence is a design choice, not a temporary situation waiting for budget.

• No advertising network, no data broker, no commercial profiling provider.
• No artificial intelligence model provider receiving user data.
• No third party customer support service with access to the data.
• No marketing email system fed with the user base.
• No sale or transfer of data to third parties.

Each of these entries corresponds to a provider that does not appear in the main table and will not appear without the notice described above. If one of these categories ever became necessary, the addition would follow the same notice and objection procedure set for other providers, and for purposes requiring consent that consent would be collected separately and revocably.

Every change to this list is published on this same page, which is the authoritative source. Tenant controllers are additionally notified at the email address entered in their profile, because for them the notice has contractual effects and not merely informative ones.

The simplest way to tell whether something has changed is to check the update date at the top of the page and compare it with the change log at the end. For questions about the list, to request the contractual documentation relating to a provider or to raise an objection, use the /contatti page, which is the single channel for all communications about this document.

Later revisions are added to this table and are tracked in the version control history of the code, which preserves the exact text of every version together with the date of the change. Anyone who needs to reconstruct which list was in force at a given moment can ask through the /contatti page.