The data lands somewhere. The lender wants to know where
The data protection officer at the EU-based lender's project finance team is reviewing the manufacturer's proposed architecture. She asks one question, in writing, to the manufacturer's bid team:
"When the controller transmits its quarterly performance summary to the manufacturer's analytics platform, what is the physical destination of that data — the data centre, the city, the country, the legal entity that operates the data centre, the legal entity that holds the encryption keys, and the legal entity that has root access to the database?"
The manufacturer's response, several days later, is reassuring in tone. The data is encrypted in transit and at rest. It is held in a secure cloud environment operated by a tier-one cloud provider. Access is restricted to authorised personnel. The manufacturer adheres to international data protection standards.
The data protection officer writes back. "I asked six specific questions. None of them was answered. Please provide the six pieces of information requested."
The second response answers four of the six. The data is hosted in the manufacturer's home jurisdiction. The data centre is operated by a national cloud provider with whom the manufacturer has a long-standing relationship. The legal entity that holds the data is the manufacturer's local analytics subsidiary. The encryption keys are managed by the cloud provider through their key management service. The two remaining questions — the city and the legal entity with root access — are deferred to a later response.
The data protection officer reads the response twice. She has, in those four answers, the basis for declining to recommend the bid. The data flow as described does not survive a Schrems II analysis. The cloud provider, operating in the manufacturer's home jurisdiction, is subject to national surveillance and intelligence law that the European Union has not assessed as adequate. The encryption keys are held by an entity within the same jurisdiction, which means they are accessible to that jurisdiction's authorities under domestic law. The cloud provider's home government has lawful access to the data, even encrypted, under conditions that exceed what the GDPR considers necessary and proportionate.
This is the cross-border data flow problem.
The legal framework was set out in the regulatory reference piece earlier in this series . The articles relevant to the conversation are GDPR Articles 44 to 49 (transfers to third countries), the Schrems II judgment of July 2020 (the transfer impact assessment requirement), the updated Standard Contractual Clauses of June 2021 (the mechanism that requires supplementary measures), and the EDPB recommendations on supplementary measures (the guidance on what those measures look like in practice). The architectural conversation that this article concerns is what follows from the legal framework: where the data must actually go, and what the manufacturer's architecture must look like to support it.
What data is actually being transferred
The first move in any cross-border data conversation is to identify what the data actually contains. This is harder than it sounds, because manufacturers tend to bundle data types together under the label "telemetry" and the GDPR analysis requires the bundle to be separated.
A plant generates several distinct categories of data. Operational telemetry from controllers — turbine speed, blade pitch, generator output, inverter status, battery state of charge — is, on its own, not personal data. It describes the equipment, not the people operating it. Condition monitoring data — vibration spectra, oil quality measurements, thermal profiles — falls into the same category. Aggregated performance data, plant-wide energy output, fault rates, mean time between failures — also not personal data.
Other categories are clearly personal data. CCTV footage from cameras in the control room, around the substation, in maintenance areas. Badge swipes and door access logs. Identifiable maintenance records — "Engineer X performed task Y on date Z" is personal data even if the task and the date are uncontroversial. The audit logs from the identity and access management platform are personal data by definition.
Some categories are mixed. A diagnostic data export prepared during a remote support session may include both the operational data being analysed and the screen recording of the engineer performing the analysis. A maintenance work order may include both the technical fault description and the credentials of the engineer who closed it. A condition monitoring report that names the inspector is personal data; the same report anonymised is not.
The exercise the lender's data protection function expects is data classification. Every data flow leaving the plant, or potentially leaving the plant, is identified, categorised, and assessed for personal data content. The result is a data inventory — a list of every data type, its source, its destination, its retention period, and its classification under the GDPR.
For most non-EU manufacturers, this exercise produces surprises. Diagnostic data flowing to the support cloud turns out to include identifiable engineer actions. Condition monitoring data turns out to include some plant operations metadata identifiable to the operations team. Telemetry channels that the engineering team assumed were purely operational turn out to carry contextual metadata that under GDPR analysis constitutes personal data.
The transfer impact assessment in practice
For each personal data flow that crosses the EEA boundary, the controller — the EU-headquartered project sponsor, in the archetype of this series — must conduct a transfer impact assessment under the framework established by Schrems II.
The assessment has a specific shape. Identify the destination country and the recipient legal entity. Assess that country's surveillance and intelligence laws — what access the authorities have to data held by entities in that jurisdiction, under what process, with what oversight. Determine whether the specific recipient is subject to those laws (most are, by virtue of being established in the jurisdiction). Determine whether the supplementary measures available — encryption with keys held only in the EEA, pseudonymisation that prevents re-identification, split processing across multiple jurisdictions — can close the gap identified.
For some destination countries the assessment concludes easily. Adequacy decisions exist for the United Kingdom, Switzerland, Japan, the Republic of Korea, New Zealand, Canada (commercial organisations), Israel, Argentina, Uruguay, the Faroe Islands, Guernsey, the Isle of Man, Jersey, Andorra, and — under the EU–US Data Privacy Framework adopted 10 July 2023 — the United States for recipients on the DPF list with valid certification; transfers to these jurisdictions proceed under Article 45 without further mechanisms. For some other countries the assessment is workable with supplementary measures — adequacy does not exist, but the country's surveillance framework is bounded enough that encryption with EEA-held keys, or pseudonymisation, closes the gap.
For several major industrial manufacturing jurisdictions, the assessment is not workable in any practical configuration. The countries' national security and intelligence laws compel entities established in their jurisdiction to provide access to data they hold, under conditions and with oversight that fall short of what the EU considers necessary and proportionate. No technical supplementary measure short of refusing the transfer entirely satisfies the Schrems II test in these cases, because the entity holding the data is legally compelled to provide access regardless of what the encryption arrangements look like.
The lender's compliance team is not making a political judgement about these countries when they reach this conclusion. They are applying a legal test that the European Court of Justice has set out and that EU data protection authorities have elaborated. The conclusion is a matter of law. The remedy is architectural.
What the asset owner and lender will accept
Three architectural patterns survive the analysis.
EU-only data residency. All telemetry, all analytics, all support tooling, all backup and disaster recovery — terminates in data centres physically located in the European Economic Area, operated by legal entities subject to EU law, with encryption keys held by EEA-resident entities. Data does not leave the EEA at any point in the lifecycle. This pattern is the safest from the lender's perspective and is the one most major non-EU manufacturers have moved to for their European customer base. It typically requires the manufacturer to establish or contract with an EU-based subsidiary, EU-based cloud capacity, and EU-based engineering teams for any function that touches personal data.
In-host-country data residency. Data stays in the country where the plant is physically located — Egypt, in the archetype — under that country's data protection law, with appropriate safeguards. This pattern works when the host country has its own credible data protection framework and the EU lender is comfortable with the local regime as a sufficient floor. It is increasingly common for projects in North Africa, the Gulf states, and Latin America where local data residency requirements often align with the lender's preferences.
Hybrid residency with strict classification. Operational data with no personal data content flows to the manufacturer's home jurisdiction for analytics and product improvement purposes; personal data and identifiable data stays in the EEA or the host country under the patterns above. The hybrid model works only with rigorous data classification at the source, technical controls that prevent personal data from leaking into the operational channel, and continuous monitoring to confirm the separation is maintained. It is more complex than the other two patterns and is typically chosen by manufacturers who have substantial analytics investment in their home jurisdiction that they are not yet ready to relocate.
Patterns that do not survive include any flow where personal data passes through a non-adequacy jurisdiction in transit, any architecture where the cloud provider's home government has compelled-access powers over the encryption keys, and any arrangement where the manufacturer asserts compliance without producing the data flow diagram and the transfer impact assessment that demonstrate it.
The data flow diagram
A specific deliverable that the lender's data protection function will request is a data flow diagram showing every data type, every source, every transit point, every destination, every legal entity involved. The diagram is the artefact that exposes architectural assumptions, and it typically reveals the situations the prose discussion misses.
A typical first-cut diagram, drawn honestly, shows flows the manufacturer's team did not consciously design. Backup flows that mirror primary data to additional jurisdictions for resilience. Analytics flows where data is replicated into a second processing environment and recomputed against a different model. Support workflows where ticket data, screen recordings and engineer logs cross borders as a normal part of the service organisation operating across multiple time zones. Disaster recovery arrangements that activate in a different region than the primary. CDN paths for software downloads that transit through edge locations the architecture team had not formally considered.
Producing this diagram honestly takes work. Many manufacturers find that the diagram they think they have differs significantly from the architecture as built — flows discovered through diagram production that nobody had documented, jurisdictions touched in transit that nobody had counted, legal entities involved that the procurement team had not separately assessed.
The diagram has a second use beyond the lender's review. It is the artefact the manufacturer's own data protection function uses to remediate gaps. Once the flows are visible, the architectural changes required — repointing a backup, relocating an analytics workload, restricting a support tool's data access — become specific and tractable, rather than the abstract task of "ensure GDPR compliance" that is impossible to engineer against.
At proposal stage
A manufacturer's bid that addresses cross-border data flow explicitly — with a data flow diagram, a classification of which data is personal, a residency commitment for personal data, a description of the transfer mechanism for operational data, a documented transfer impact assessment for any non-adequacy destination, and the legal entity structure that delivers the architecture — is a bid that has anticipated the conversation. The lender's data protection function reviews the materials, identifies any remaining concerns, and the conversation proceeds.
A bid that does not address cross-border data flow, or that gestures vaguely at "secure cloud infrastructure" and "compliance with applicable data protection regulations", signals a gap that the lender's compliance team will surface during due diligence. The gap may be closeable through architectural change — repointing telemetry endpoints, establishing EU residency for personal data, building the data classification at source. The gap may be more fundamental, requiring the manufacturer to stand up new infrastructure or new subsidiaries to support the data flows that EU regulation permits. The closer the gap is to the manufacturer's core analytics platform, the more substantial the work to close it.
The deeper observation is that data residency is the area where regulatory specifics most directly constrain architectural choices. The cryptographic baseline, the patch contract, the logging discipline, the identity model — all generalise across global markets, and a manufacturer adopting them sees benefits beyond EU compliance. Data residency is structured by EU regulatory framework in a way that does not generalise as cleanly. Manufacturers serving EU-financed projects typically end up with EU-hosted analytics infrastructure, separate from their home-country infrastructure, with clean architectural separation between the two. The investment is significant. For manufacturers who serve EU-financed projects in any volume, it is also unavoidable.
The next article picks up the topic that the data flow review surfaces alongside data protection: the sanctions and provenance disclosure the lender's compliance team conducts against the bill of materials, the suppliers, and the beneficial ownership of the manufacturer's supply chain.
This article reflects the regulatory landscape at publication. The EU's framework for international data transfers continues to evolve, particularly around adequacy decisions, EU-US data transfer arrangements, and EDPB guidance on supplementary measures. Court of Justice case law continues to develop. Specific transactions should be reviewed by qualified legal counsel rather than against this article. If a citation has rotted or a clause has moved, LinkedIn is the way to flag it.