1. Assessment Overview
Purpose: EUDR compliance (Regulation (EU) 2023/1115)
Assessor: Data Protection Officer
Date of Assessment: March 18, 2026
Last Review: September 17, 2026 (supply-chain map locations; Article 35(11) review)
Correction: September 26, 2026 (the measures and the transfers outside the EEA are described as they are; the risk ratings have not been re-assessed)
Review Cycle: Annual
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 changes to data and of administrators' access to documents
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: Selected personal-data fields (e-mail addresses, company and contact details, notification messages) are encrypted by the platform using Fernet AES symmetric encryption. Plot geolocation and due diligence statement content are not; they are protected at rest only by the storage provider (Appwrite Cloud). Whether Appwrite encrypts the database at rest is still to be confirmed with Appwrite; its storage buckets are set to encrypt files, but Appwrite applies that encryption only to files of up to 20 MB, and the platform accepts documents of up to 25 MB.
- 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, audit logging of changes to data and of administrators' access to documents, 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 selected personal-data fields using Fernet AES, TLS 1.2/1.3 between browsers, the platform and its service providers, Docker container hardening with read-only filesystem and dropped capabilities, no e-mail addresses or names in application logs or error messages (the web-server log keeps client IP addresses).
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: Hosting, database, file storage, identity and e-mail services are in the EU: Appwrite Cloud (EU region), Hetzner (EU), Auth0 (EU Frankfurt; owned by Okta, Inc., United States), Brevo (EU). Personal data leaves the EEA in these cases: (a) when the AI assistant is enabled, the text users type into it is sent to Google LLC (United States); (b) for the risk assessment, plot outlines with a buffer and date ranges, without names or account data, are sent to the World Resources Institute (Global Forest Watch Data API and LandMark, United States); (c) map tiles are requested by users' browsers directly from Esri, Inc. (see below) and the OpenStreetMap Foundation (United Kingdom), and, on the assessment map that only GreenTrust administrators open, from the World Resources Institute (United States); these services receive the viewer's IP address, user agent and the map area viewed. The safeguards for (a) and (b) are still to be confirmed.
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 encryption of selected personal-data fields using Fernet AES (symmetric, key managed via environment variable on the application server)
- Role-based access control enforced on every API endpoint without exception
- Tamper-evident audit log: entries are linked in a keyed hash chain (HMAC-SHA-256) with signed checkpoints, so an entry that is changed, inserted or removed from the middle of the log is detected; security-, GDPR- and evidence-relevant changes are recorded before they are made and refused when the entry cannot be written (entries written before the chain was introduced are not part of it)
- Daily backups of the database and of every storage bucket, encrypted with AES-256-GCM and kept on the application server for 30 days (the key is held on the same server)
- Server-side sessions: logging out, removing a role or deleting an account ends the sessions at once; sessions end after 2 hours of inactivity and 12 hours at most (administrators: 30 minutes and 8 hours)
- Every uploaded file (documents, plot geometry files and signed mandates) is scanned for malware with ClamAV on our own server before it is stored; a file in which the scan finds malware, or that cannot be scanned, is refused
- Rate limiting per IP address on the web server: 10 requests/second general, 5 requests/second authentication, 2 requests/second AI endpoints (no web application firewall)
- Application 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) with the sub-processors (the status of each is stated in the Sub-processor List)
- 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
- Audit-log integrity check every hour: the new entries of the hash chain are verified and a signed checkpoint is written
- Backup completeness check on every daily run: a failed or incomplete backup is logged as an error and recorded in the audit log
- Failed sign-ins are recorded in the Auth0 tenant logs, and Auth0's attack protection blocks repeated failed attempts on an account from one IP address (with password sign-in Auth0 sees the platform server's IP address unless the platform's confidential Auth0 client is configured); the platform raises no alert from them
- No automated security alerting is in place yet, no restore test of the backups is on record yet, and the backups are not yet copied outside the application server
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
Residual Risk Level: LOW
Basis: The technical and organizational measures implemented are sufficient to mitigate identified risks to an acceptable level. The processing is necessary for compliance with Regulation (EU) 2023/1115 and is proportionate to the legitimate aim pursued.
Review of September 17, 2026: Supply-chain map locations assessed (Risks 5 and 6); with the mitigations described, the residual risk remains LOW.
Next Review: March 2027 or upon material change in processing activities.