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-north-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 (SQLite on the EC2 host in eu-north-1, Stockholm).
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.

7. Addendum, 27 September 2026: geo.qa photo measuring (United States)

Flow	A visit photo the farmer agreed to, sent to geo.qa's measurer once it reaches our store
Receiving processing	geo.qa, operated by Vortx AI Private Limited (the same legal person as eudr.dev), hosted on Amazon Web Services in `us-east-1`
Data	The photo's pixels. EXIF, XMP and comments (location, capture time, phone model) are removed before it is sent. No name, farm, visit, lot or organisation goes with it
Could it identify a person?	Only if a person is in the frame. The visit forms ask for photos of the fruit, and the farmer's recorded yes is required before any photo is stored. People are mosaicked in-region before a photo is kept or sent, so geo.qa receives the redacted copy (#173)
Chapter V	As in §2, remote processing within one legal person is not a transfer between controller and processor. The hosting provider, Amazon Web Services, Inc., participates in the EU-US Data Privacy Framework (adequacy decision of 10 July 2023)
Measures	TLS in transit; metadata stripped; no identifiers; the consent gate; a signed receipt per reply, checked against a pinned key; one switch (`EUDR_GEOQA_MEASURE`) stops all sending
Residual risk	Low. An image of fruit carries no personal data; a person caught in the frame is the remaining risk, reduced since 28 Sep 2026: redaction now runs before storage, and the copy geo.qa receives is the redacted one
Review	When #173 ships, or if geo.qa moves region or provider. geo.qa has offered an in-region package; moving to it ends this flow

8. Addendum, 28 September 2026: farm coordinates to geo.qa

Flow	A farm's pin or a point inside its field (latitude, longitude), and for the photo check the photo's capture time
Purpose	Pre-screening farms before a trip; checking that a photo could be of its field; distance from the field to water for the spray-buffer rule
Not sent	Farm name, farmer, organisation, price, lot. Pins go under a request-local number
Could it identify a person?	A field's location can point to whoever farms it, for someone who already knows the area. It is the same data emem already receives for satellite reads (§2)
Chapter V	As §2 and §7: one legal person; hosted by Amazon Web Services, Inc. under the EU-US Data Privacy Framework
Measures	TLS; no identifiers; one switch (`EUDR_GEOQA_PRESCREEN`) stops all sending
Residual risk	Low

9. Addendum, 28 September 2026: visit papers to emem

Flow	A photo of a residue lab report or a land record, taken in that place on a visit form, sent to emem's `lab_report_parse` or `land_record_parse` with the language to read it in
Purpose	Reading residue results for the market's limits (Reg (EC) 396/2005) and a buyer's standard; reading the owner and parcel as evidence of the right to use the land (Reg (EU) 2023/1115, Art 9(1)(h))
Not sent	Farm name, farmer, organisation, lot, price. The photo goes without its file name
Could it identify a person?	Yes: a land record names its owner, and a lab report can name the person who sent the sample. This is the first flow to emem that carries a name
Chapter V	As §2: eudr.dev and emem.dev are one legal person, so this is remote processing within it, not a transfer
Measures	TLS; only the two named places on the form are read; emem states its reader keeps nothing; the reply is checked against emem's pinned key and kept with the file, deleted with it; the comparison with farmers and limits is ours; one switch (`EUDR_EMEM_DOCS`) stops all sending
Residual risk	Low to medium: names reach an Indian-hosted responder of the same legal person. The same names are already held by the organisation that photographed the paper
Review	If emem starts keeping documents, moves responder region, or the reader is offered in-region

10. Addendum, 28 September 2026: field pairs to geo.qa and emem

Flow	Pairs from an organisation's gate and visits: crates typed against geo.qa's stack count, the gate's grade against geo.qa's photo measurements, and the day a lot was weighed at the field's emem cell ids. Read by geo.qa and emem, each with its own token
Purpose	Checking and correcting geo.qa's and emem's readings against what people recorded (#189)
Not sent	Names, prices, amounts, farm, lot, receipt or organisation ids. Each pair has an id that means nothing outside the feed
Could it identify a person?	A cell id and a date point to a field and a harvest day, for someone who already knows the area. It is the same kind of location emem already receives (§2); geo.qa receives coordinates already (§8)
Chapter V	As §2, §7 and §8: one legal person
Measures	Off unless the organisation turns it on (`share_ground_truth`); a partner token for each reader, set on the server; no token set, no feed; the reply is signed by eudr.dev
Residual risk	Low

This page last changed on 2026-09-28. It describes the Regulation as it stood then; where a date or a code matters to a decision, check it against the EUR-Lex text it cites.