“The data centre is in Italy” is not enough: the EU supervisor lists why

Your contracts and specifications say “data centre in Italy” or “data resident in the European Union”. Could you say, right now, who can access those systems remotely, from which country, with what privileges, and who holds the encryption keys? If the answer is the data centre’s address, the document we’re covering here says that is not enough. It is Opinion 14/2026 of the European Data Protection Supervisor (EDPS) on the proposed Regulation for the Cloud and AI Development Act — signed in Brussels on 29 July 2026 by Wojciech Rafał Wiewiórowski. The proposal it addresses, COM(2026) 502 final, dates from 3 June 2026.

What is in the proposal

The stated aim, at paragraph 2, is to address “the limited and geographically concentrated availability of computing capacity in the Union and the risks associated with dependence on cloud and AI supplied by non-European providers”.

The proposal — summarised at paragraph 3, verbatim — “establishes Cloud and AI Leadership Initiatives, measures on data centre capacity, a Union cloud computing sovereignty framework based on four Union assurance levels, recognition and assessment procedures for cloud computing services, risk assessments by Member States and Union entities, procurement obligations, the European public sector cloud federation (‘EuroCloud Federation’), Commission-led procurement activities and measures concerning open-source solutions and software reuse.”

The four assurance levels, set out in Article 16 with criteria in Annex II, apply to services provided to Union entities and public-sector bodies. At the lowest level, Article 19 “allows cloud computing service providers to carry out a conformity self-assessment and issue an EU statement of conformity”. The EDPS accepts this only for level 1, and asks that the declaration explicitly state its own scope.

The thirteen factors

Paragraph 24 of the Opinion puts it, verbatim: “The EDPS acknowledges that data localisation in the Union may in some cases be a relevant element for ensuring sovereignty, operational autonomy and limiting exposure to third-country risks. However, data localisation within the Union should not be seen, in itself, as sufficient per se to fully exclude risks of access from third countries. Such risks may also depend on factors such as remote access, support administration, maintenance, monitoring and incident response activities, privileged access management, sub-processing, sub-outsourcing, corporate control, applicable third-country laws, encryption and key management, software dependencies, telemetry, logging, access rights and other technical and organisational measures.”

Data localisation within the Union can be a relevant element for sovereignty and operational autonomy, but on its own it is not enough to rule out third-country access risks. Those risks also depend on other factors. There are thirteen of them, and this is the list a specification should cover:

remote access
support administration
maintenance
monitoring
incident response activities
privileged access management
sub-processing
sub-outsourcing
corporate control
applicable third-country laws
encryption and key management
software dependencies
telemetry, logging and access rights

None of these thirteen points is visible from a site visit: the flooring is the same colour, the racks sit in the same hall. They only show up in contracts, in operating procedures and in system configuration.

Metadata and telemetry are customer data

A detail most hosting contracts do not treat as such, isolated at paragraph 25: “The EDPS notes that several criteria in Annex II require customer data, including metadata and telemetry data, to remain exclusively within the Union — in certain cases ‘in any case’ (criterion (f) for levels 2 to 4), in others unless the public sector body explicitly requires otherwise (criterion (c) for levels 1 to 3).”

The point is not the rule itself, but the premise: metadata and telemetry are customer data, for the purposes of these criteria — not a technical by-product of the provider’s, not a log that “stays in-house” by definition. It is exactly the distinction a standard hosting contract fails to make.

The clauses the supervisor asks for

The conclusions call for Articles 37 to 40 of the proposal to include, verbatim, “appropriate and non-negotiable data protection safeguards, including purpose limitation for telemetry, metadata and service-generated data, full sub-processor transparency, complete transfer mapping, appropriate handling of third-country authority requests, audit rights for each controller and the unimpeded exercise of the EDPS’ powers under Article 58 EUDPR”. As specification lines, that is five:

purpose limitation for telemetry, metadata and service-generated data
full transparency on sub-processors
complete mapping of data transfers
a defined process for third-country authority requests
audit rights for each controller

Clauses written before signature, not negotiated after an incident.

How we check it

When we check a cloud specification or a hosting contract, we don’t start from the data centre’s address: we start from the thirteen factors in paragraph 24 and the five clauses in the conclusions, and check them one by one against what the contract actually says. From the first session comes a dated list of the access points into your systems — who, from where, with what privileges, with what keys — and the list of specification lines that don’t cover it today. It stays yours even if you don’t go further: not a generic opinion, the starting map for writing or correcting the specification.

See the service · Talk to an engineer

What this is not, yet

One point needs saying clearly, once: what we’re covering is a proposed Regulation, tabled by the Commission on 3 June 2026, and an advisory Opinion on that proposal. Neither is law yet: the legislative process can still change the articles, the annexes, even the four assurance levels.

But the list of thirteen factors doesn’t wait for the negotiation’s outcome. It is usable today, in a specification, whatever becomes of the act — because it describes risks that already exist. The Opinion’s Executive Summary says so, verbatim: “Dependence on a limited number of third-country providers, vendor lock-in, access by third-country authorities and operational discontinuity may also have implications for the rights to privacy and the protection of personal data” — with or without the new Regulation.

Two threads, applied

First thread: the thirteen factors and the five clauses become verifiable lines in the specification and acceptance checkpoints, with the record a client can exhibit — not an opinion, a list that gets checked.

Second thread: contracts, configurations, privileged access lists, transfer maps and the room’s as-built stop being scattered files. Together with CSIDIA, the group’s other company, they become a single map: who accesses what, from where, with which keys. An AI runs diagnostics on that map and the crew acts. When a client asks you “who can read my data”, the answer is a list, not a verbal reassurance. Within the client’s own perimeter: on-premise, on autonomous machines with no deep integration into the existing network, or a dedicated cloud with a data centre in Italy — always with shared management.

We’ve written about this before, covering the cloud infrastructure jurisdiction the Data Act requires and the national strategic interest declarations on large data campuses: localisation is the first line in the specification, not the last.

Could you list, right now, without opening a single contract, who accesses your systems remotely, from where, and who holds the encryption keys? If the answer isn’t immediate, talk to an engineer: the site visit is at no cost.