Independent AI agent for EU Deforestation Regulation compliance, not affiliated with the EU. Scope & disclaimer →

Transfer impact assessment (TIA) — emem.dev satellite-signal lookups

Status: adopted 2026-06-04 · review cadence: 12 months or on any change to the data flow, the corporate structure, or Indian law relevant to the assessment.

This document records the controller-facing analysis for the only non-EEA data flow in the eudr.dev pipeline: satellite-signal lookups against emem.dev. It exists because the EDPB's position is that Art. 49 GDPR derogations must remain occasional, while this flow is systematic (one lookup per compile) — so the legal basis deserves a written assessment rather than a one-line citation.

1. The flow


Exporting processing	eudr.dev engine, AWS `eu-central-1` (EU)
Receiving processing	emem.dev Earth-memory service, operated from India
Legal persons involved	One: Vortx AI Private Limited operates both eudr.dev and emem.dev
Data categories	Plot geometry (GeoJSON), HS code, country of production, quantity
Identity data	None. Operator and supplier identity are stripped before any emem call (`operator: None` is enforced in `crates/eudr-pipeline/src/runner.rs`; the privacy notice, DPA and sub-processor register all state this and the code is the control)
Frequency	Every compile (systematic, not occasional)

2. Is this a Chapter V "transfer" at all?

Under EDPB Guidelines 05/2021 a Chapter V transfer requires a disclosure by one controller/processor to another controller/ processor. eudr.dev and emem.dev are operated by the same legal person, so the movement of data between the EU compute location and the Indian processing location is intra-entity remote processing, not a transfer to a third party — Standard Contractual Clauses (Decision (EU) 2021/914) are structurally unavailable for it, because an entity cannot contract with itself.

That does not lower the bar: Art. 5(1)(f), Art. 24 and Art. 32 GDPR fully apply to the processing wherever it happens, and the remainder of this assessment treats the flow with the same rigour a third-country transfer would receive.

For any future third-party sub-processor outside an Art. 45 adequacy decision, SCCs Module 3 will be executed before the transfer — that commitment stays in the DPA §7.

3. Could the data identify a person?

Plot geometry can be personal data when the plot maps to an identifiable smallholder. Mitigations:

No name, address, EORI, email, or any direct identifier ever leaves the engine toward emem — re-identification requires combining the geometry with an external land register the receiving service does not hold.
The engine emits a DPIA observability event for any polygon over the 5 ha smallholder-protective threshold forwarded to emem (routes.rs polygon proxy), so the controller's records can show the sub-5-ha slice over time.
Lookups are content-addressed facts about land, returned signed; emem does not build profiles of operators (it never learns who they are).

4. Receiving-jurisdiction considerations (India)

India's DPDP Act 2023 applies to digital personal data processed in India; the categories above sit at the very edge of "personal".
Government-access regimes (s. 69 IT Act 2000 and successors) target communications and identified subscribers. The realistic intelligence value of pseudonymous plot polygons + HS codes is low, and the engine holds the identity linkage only in the EU.
Worst-case access to the emem-side data yields satellite-derived facts about land parcels — information that is substantially available from public Earth-observation sources already.

5. Supplementary measures in place

Identity stripping at source (code-enforced, audited 2026-05/06).
TLS 1.2+ on every call; no bulk export interface on emem.
Content-addressed, signed responses (tamper-evident both ways).
Data minimisation: four fields, no free text from the operator.
EU-side retention of all identity and account data (eu-central-1 SQLite + Litestream).
This TIA, reviewed annually, referenced from the DPA and the privacy notice.

6. Conclusion

The flow is lawful as intra-entity processing protected by Art. 32 measures and the supplementary measures above; the previous reliance on Art. 49(1)(d) as a transfer derogation is retired as unnecessary for this flow (it remains cited for completeness where a supervisory authority takes a broader view of "transfer"). The residual risk to data subjects is assessed as low, dominated by the re-identification scenario in §3, which the identity-stripping control addresses at source.

This assessment is operational tooling, not legal advice; the controller (operator) remains responsible for their own Art. 35 assessment where their use is high-risk.