Data Protection Impact Assessment (DPIA)

1. Assessment Overview

This Data Protection Impact Assessment is conducted pursuant to Article 35 of the General Data Protection Regulation (GDPR) to evaluate the necessity, proportionality, and risks of personal data processing carried out by the GreenTrust EUDR platform.

2. Description of Processing

The GreenTrust EUDR platform processes personal data of EU operators and global suppliers to enable compliance with the EU Deforestation Regulation (EUDR). Personal data processed includes operator and supplier details, geolocation of plots of land, and supply chain data required for due diligence statements.

Data is collected from two categories of data subjects:

• EU Operators: Importers and traders who must file due diligence statements
• Global Suppliers: Producers and exporters who provide evidence of compliance

Processing activities include:

• User registration and authentication
• Due diligence form submission
• Supporting document upload (PDF, images, geospatial files)
• Risk assessment of plots and suppliers
• Due Diligence Statement (DDS) generation and export
• Derivation of approximate (city-, region- or country-level) business locations of suppliers and operator headquarters from the city, region and country in their profiles, computed on platform servers with an offline copy of the GeoNames dataset, for display on operator and admin supply-chain maps
• Audit logging of all platform actions

3. Necessity and Proportionality

The processing of personal data through this platform is necessary and proportionate for the following reasons:

• Legal basis: Legitimate interest under GDPR Article 6(1)(f), arising from the compliance obligation established by EUDR Article 4.
• Data minimization: Data collected is limited strictly to what Annex II of Regulation 2023/1115 requires for due diligence statements.
• Geolocation requirement: Collection of plot geolocation data is mandatory under EUDR (polygons for plots exceeding 4 hectares, single coordinates for smaller plots).
• Encryption at rest: All personally identifiable information is encrypted using Fernet AES symmetric encryption.
• Access controls: Role-based access control (RBAC) enforces strict separation between operator, supplier, and administrator roles.
• Supply-chain map locations: Supplier positions rely on legitimate interest under GDPR Article 6(1)(f). Interest: linked operators need an accurate geographic overview of their supply chain for their due diligence, and the platform provides it. Necessity: positions are derived only from the city, region and country already held in the profile, never from street addresses, and are no more precise than city level; a country-level point alone would misplace suppliers. Balancing: positions are visible only to operators linked to the supplier, who already see these profile fields, and to administrators; no profile data is sent to external geocoding services to derive them; data subjects can see, correct and object to their position. The further use of profile location data is compatible with the purpose for which it was collected (Article 6(4)): the supply-chain context is the same, no special categories of data are involved, the consequences are limited, and the safeguards in Risks 5 and 6 apply. Operators' own headquarters positions rely on contract performance (Article 6(1)(b)).

4. Risks to Data Subjects

Risk 1: Unauthorized Access to Supply Chain Data

Likelihood: Low · Impact: High

Supply chain data could be commercially sensitive. Unauthorized access could result in competitive harm to operators or suppliers.

Mitigations: Role-based access control (RBAC) on every API endpoint, JWT authentication via Auth0, comprehensive audit logging of all data access, rate limiting on authentication endpoints.

Risk 2: PII Exposure in Data Breach

Likelihood: Low · Impact: High

A breach could expose personal data including names, email addresses, company details, and geographic coordinates.

Mitigations: Field-level encryption of PII using Fernet AES, TLS 1.2/1.3 for all data in transit, Docker container hardening with read-only filesystem and dropped capabilities, no PII in logs or error messages.

Risk 3: Excessive Data Retention

Likelihood: Medium · Impact: Medium

Data retained beyond the legally required period increases exposure risk and may violate GDPR storage limitation principles.

Mitigations: Automated data retention enforcement aligned with EUDR Article 12(4) requirements (5-year retention), GDPR data subject rights processing for erasure requests, clearly defined retention periods per data category.

Risk 4: Cross-Border Data Transfer

Likelihood: Low · Impact: Medium

Transfer of personal data outside the EEA could expose data subjects to jurisdictions with inadequate protection.

Mitigations: All services hosted within the EU: Appwrite Cloud (EU region), Hetzner (Nuremberg, Germany), Auth0 (EU Frankfurt). Platform systems make no data transfers outside the EEA; the only exception is the satellite imagery that users' browsers request directly from Esri (see below). Data Processing Agreements in place with all sub-processors.

Map imagery (reviewed September 17, 2026): Satellite imagery on the platform's maps is loaded by users' browsers directly from Esri's ArcGIS Online service (Esri, Inc., United States); these requests go from the user's browser, not from platform systems. Esri receives the user's IP address, user agent, the platform's address as referrer and the requested tile coordinates, which reveal the map area being viewed; no account data, pins or names are sent. This is disclosed in the Privacy Policy (Sections 6 and 10). Esri states that it is certified under the EU–U.S. Data Privacy Framework, for which the European Commission has adopted an adequacy decision (GDPR Article 45). The approximate business locations (Risks 5 and 6) are derived and stored within the EU and are not sent to any external service.

Risk 5: Inaccurate or Falsely Precise Business Locations

Likelihood: Medium · Impact: Medium

City and region are free text, and many village and town names repeat within a region or country (for example, over a hundred places named Sukamaju in West Java). A position derived from them can be wrong, or can look more precise than it is. Region- and country-level fallbacks use a representative point (a country-level pin sits at the capital city), which could be misread as the supplier's actual location. An operator could draw wrong conclusions about a supplier in its due-diligence review, contrary to the accuracy principle (GDPR Article 5(1)(d)).

Mitigations: Stored precision levels (city, region, country): city level is granted only for an exact or known-variant name match that is either unambiguous (the name is unique within the confirmed region, or within the country, across all GeoNames populated places) or the best-ranked candidate and a significant place (national capital, seat of a first- or second-level administrative division, or population of at least 15,000) inside a recognised region; where no region was given or the one given was not recognised, a name that is not unique in the country additionally has to be a national capital, a first-level administrative seat or a town of at least 100,000 inhabitants, and a typed region that contradicts the match requires both significance and a name unique in the country. Matches via alternate or historical names count only for significant places, and are refused when other populated places carry that name as their own. Fuzzy (near-spelling) matches require region confirmation, must meet the same test, and are refused when the name as typed is itself a populated place of that region. Region names are matched only where the match is unambiguous. Otherwise the position is downgraded to region or country level. Map popups state the precision of every pin (e.g. "Approximate location · region level"). The resulting place name and precision are shown back to the supplier or operator on their profile page. Correction path (Article 16): editing city, region or country triggers recalculation, and a stored position whose inputs no longer match is not used (the map falls back to country level until it is recalculated). Restriction flag: on request, a data subject's position is held at country level only. Derived positions are display-only: they are never written back into profile fields, never used as plot geolocation, and never used in risk scoring or due diligence statements. The reference dataset is versioned and refreshed every 6–12 months, after which positions are recalculated.

Risk 6: Location Inference and Visibility to Operators

Likelihood: Low · Impact: Medium

Some suppliers are natural persons (sole traders, smallholders) whose business location is also their home or farm. Combined with a name, a town-level pin shows the approximate area where they live or work, and it can be linked across the operators that supplier works with.

Mitigations: Positions are derived only from city, region and country, never from street addresses, and are no more precise than a city or town reference point. Supplier positions are shown only to operators with an active link to that supplier, who already have access to the supplier's city, region and country, and to platform administrators; each operator sees only its own linked suppliers. Supplier map pins do not include the street address, and never fall back to the supplier's email address as a name. Positions are computed offline on platform servers, so no profile address or location data is sent to external geocoding services to derive them. Positions are stored in a separate collection, kept out of the profile data used to prefill due diligence statements, included in the Article 15 data export, and deleted in both erasure paths (GDPR erasure request and admin account deletion). Data subjects can object (Article 21) by contacting privacy@greentrust.eu, after which their position is held at country level only. Application logs record only counts, precision levels and record identifiers, never place names or addresses. The feature is controlled by a configuration switch and can be disabled at once.

5. Measures to Address Risks

Technical Measures

• Field-level PII encryption using Fernet AES (symmetric, key managed via environment variable)
• Role-based access control enforced on every API endpoint without exception
• Audit log integrity verification using SHA-256 hashing
• Rate limiting: 10 requests/second general, 5 requests/second authentication, 2 requests/second AI endpoints
• Docker container hardening: non-root execution (UID 1001), read-only root filesystem, all capabilities dropped
• TLS 1.2/1.3 only with HSTS, CSP, and X-Frame-Options headers
• JWT validation with RS256 asymmetric signing via Auth0
• Supply-chain map locations derived offline from city, region and country (no external geocoding service), stored with a precision level, which map popups state

Organizational Measures

• Annual DPIA review and update
• Employee and administrator training on data protection obligations
• Data Processing Agreements (DPAs) executed with all sub-processors
• Documented breach notification procedure (GDPR Articles 33-34)
• Handling of objections to supply-chain map locations (GDPR Article 21) via privacy@greentrust.eu, applied with an administrator-side country-level restriction flag
• Designated Data Protection Officer reachable at dpo@greentrust.eu

Monitoring Measures

• Automated audit log integrity checks
• Backup verification and restore testing
• Failed authentication attempt monitoring
• Security event alerting and review

6. Consultation

Based on this assessment, the residual risk to data subjects after implementation of the measures described above is considered acceptable. The processing does not present a high residual risk that would require prior consultation with the supervisory authority under GDPR Article 36.

No supervisory authority consultation is required at this time. This determination will be re-evaluated during the annual review or if processing activities change materially.

7. Conclusion

← Back to Privacy Policy