Grid data residency in 2026: guidance for EU operators

A vendor may say your grid data stays in the EU cloud without naming a region. Or your review may reveal that metering data falls under GDPR in ways the vendor documentation never explains. Distribution operators need to understand where the line sits between operational and personal data, and what safeguards apply in either case.

When grid metering data becomes personal data under GDPR

GDPR defines personal data as any information relating to an identified or identifiable natural person. High resolution interval metering data from residential feeders or smart meters can reveal occupancy patterns, appliance usage, and daily routines of the individuals behind the meter. Academic literature on privacy risks of smart meter data documents this concern, as do national DPA guidance documents including Portuguese CNPD materials.

The issue is less direct when grid data is aggregated at feeder level rather than individual meter level. A feeder aggregate showing 150 MW of load at 14:00 does not directly identify any individual. Still, other information could be combined with that aggregate to infer details about the consumer base. GDPR de identification is not "theoretically perfect"; the data only needs to be "not reasonably linkable to an identifiable person", and "reasonably" has no universal threshold.

At eZap, our position is that feeder level aggregate data without individual consumer identifiers is operational data, not personal data. We still apply appropriate access controls and data retention limits, regardless of that classification.

Understanding the controller and processor roles

When a distribution operator uses an external software tool for grid data, the operator is generally the data controller because it determines the purpose and means. The vendor is the data processor because it processes data on behalf of the operator. That allocation carries specific responsibilities.

As data controller, the operator must ensure that the processor offers sufficient guarantees for technical and organisational security measures under GDPR Article 28. A Data Processing Agreement, or DPA, must be in place before the processor handles the data. A vendor processing EU grid operational data for an EU distribution operator without a DPA is not GDPR-compliant, whatever classification it assigns to the data.

The DPA should identify the subject-matter and duration, nature and purpose, type of data, categories of data subjects if relevant, and the obligations and rights of the controller. For grid operational data, it should state that processing is restricted to load forecasting and dispatch scheduling. It should exclude secondary analysis, model training for other customers, and commercial use.

eZap includes a DPA with all pilot and production contracts and makes it available for review before data transfer begins. Customer data is never used to train models serving other customers.

Data residency expectations for EU utilities

The EU has no universal data residency law that currently bans processing grid operational data outside the EU. However, national sector guidance and emerging requirements vary. Operators covered by the NIS2 Directive, which came into force October 2024 across EU member states, also face security and incident reporting duties that may influence where sensitive operational data is processed.

For Portuguese distribution operators, CNPD and ERSE have not imposed a blanket ban on processing grid data outside Portugal. Even so, GDPR Chapter V restrictions on transfers to non-adequate countries, NIS2 security duties, and common sector contract terms make EU processing the expected baseline for a new vendor engagement.

eZap conducts all data processing in EU data centers. No grid operational data is transferred to infrastructure outside the EU. This reflects our contractual requirements with infrastructure providers and can be verified through infrastructure documentation requested by customers.

Questions for a grid software vendor in 2026

A third party grid software review should cover a short list of concrete questions. These are the same points that have arisen in our vendor discussions with distribution operators.

Where is data processed and stored? Expect a named EU region, not just "EU cloud." If the vendor cannot name the AWS or Azure region, treat that as a red flag.

Is your grid data used to train models serving other customers? The answer should be an unambiguous no. Sharing model signals, aggregate patterns, or forecasts that reflect your network across customers would require explicit consent and a clear data governance framework.

Does the vendor provide a GDPR-compliant DPA? It should be available for review, rather than hidden behind a terms of service checkbox. If the vendor legal team cannot produce a draft DPA within a week of request, that says something about its wider GDPR posture.

What is the retention period and deletion policy? Ask how long metering data remains after the contract ends, and how deletion or return is handled. A serious vendor should answer these questions clearly.