Who can access your clients’ EUDR data?

Where the backend runs and what the stack handles

Paris is the confirmed hosting region for our main backend. Our approved architecture uses the following services. Individual controls are verified during implementation and acceptance testing.

Application and processing

FastAPI on AWS ECS Fargate runs the application and background workers.

Records and evidence

Amazon RDS for PostgreSQL with PostGIS holds operational and geospatial records. Amazon S3 stores source files, evidence and exports.

Background jobs

Amazon SQS carries queued work, with dead-letter queues for jobs needing investigation. PostgreSQL retains job state and attempt history.

Credential protection

The design uses AWS KMS envelope encryption and restricted IAM permissions. TRACES credentials are recovered only by authorised execution paths, not exposed through ordinary user or administrator screens.

Delivery, sign-in and monitoring

Cloudflare delivers the static frontend, Clerk handles authentication, and Sentry supports error monitoring alongside AWS CloudWatch and application audit records.

We review supporting services, data locations and access arrangements with you before agreeing the implementation proposal.

Keep each client’s records and permissions separate

Our access model gives each operator a separate workspace. It combines server-side permissions with PostgreSQL row-level security for sensitive records. Supplier access is limited to assigned work, while authorised portfolio staff can work across the clients within their scope.

For EUDR delivery across multiple clients, the review should cover files, search results, exports, submission responses and support access, as well as the pages people see. Hiding a client in a menu is not evidence that its data is protected.

Agree tests that attempt to open or change another client’s records through both the interface and its underlying requests. Also test what happens when a colleague changes role or leaves. The client onboarding checklist helps identify the people who should approve these responsibilities.

Five questions for your security review

Use these questions to agree the details for your deployment, from access permissions to the records you receive at handover.

Hosting and processors

Where will live data, backups and logs be stored? Which providers can process them?

Evidence to request: Named services, locations and responsibilities for the proposed deployment.

Client access

Who can view, change, approve and export each client’s records?

Evidence to request: An access matrix and tests that attempt access across client boundaries.

Integration access

Who administers the connection, and how is access changed or withdrawn?

Evidence to request: Named owners and a documented handover and access-removal procedure.

Retention and exit

What is retained, for how long, and what can the client take away?

Evidence to request: A schedule covering source files, operational records, logs, backups and exports.

Support and incidents

What can support staff see, and who handles a suspected disclosure?

Evidence to request: Support permissions, escalation contacts and agreed response responsibilities.

Include requirements for encryption, backups and restoration in the review. A hosting region alone does not describe where support access, logs or backup copies may be handled. Confirm the complete arrangement before sharing production data.

Separate technical access from permission to file

The person administering an integration and the person approving a client’s filing may be different people. Record both responsibilities. Technical access should not be treated as a substitute for the authority to submit on an operator’s behalf.

For the integration review, identify who owns access administration, how support receives limited access when needed, and how access is removed at handover. Keep acceptance and production arrangements separate. Use fictional or appropriately redacted records for demonstrations and initial troubleshooting.

What happens to a file in our free GeoJSON checker?

The GeoJSON validator and local map preview process your selected file or pasted JSON in browser memory. The tool does not upload that content or persist it in browser storage.

The online basemap is optional. If you enable it, OpenStreetMap receives your IP address and requests for the map areas you view. Your GeoJSON and feature properties are not sent as part of those tile requests. Turning the basemap off stops new tile requests; it cannot undo requests already sent.

This describes the file checker, not a blanket promise that visiting the website makes no network requests. It also does not describe the data handling of a separate production integration.

Agree retention and handover before the first live record

Source documents, submission records, support attachments and backups need separate retention decisions. Document which records the client needs to retain, who holds them and what happens to remaining copies when the engagement ends.

Specify an export that preserves the connection between the client’s internal records and the DDS reference and verification numbers. Agree how access is withdrawn and how deletion is handled, including any backup expiry or retention exception. Avoid promising immediate deletion of every copy unless the agreed system can demonstrate it.

Bring your security questionnaire into the scope

Tell us which systems you use, whether you support several operators, and any requirements for hosting, access, retention or procurement review. We can discuss those requirements alongside the implementation work and acceptance criteria, before a proposal is agreed.

Start with a description of the workflow. Please do not send passwords, access keys, confidential supplier files or verification numbers through the contact form. If a detailed review needs sensitive material, agree an appropriate transfer route first.