Data Processing Agreement (DPA)

Last updated: 4 October 2026 · Version: 1.1

This is a translation. The Dutch version at trajenda.com/verwerkersovereenkomst is the binding text for Dutch customers.

Between the customer ("controller") and Trajenda v.o.f., Gasthuisstraat 27, 5931 NT Tegelen, Netherlands, Chamber of Commerce (KvK) 42185785, branch number 000066918065, VAT ID NL870091487B01 ("processor"). This agreement forms part of the terms of service and prevails over them on matters of personal data.

1. Subject matter

The processor processes personal data solely on the controller's instructions, for the purpose of trip planning and communication between planners and drivers.

2. Instructions

The processor processes only on documented instruction. Use of the software constitutes such instruction. If the processor believes an instruction breaches the GDPR, it will say so immediately.

3. Confidentiality

Persons with access to the data are bound by confidentiality. Access to customer data by the processor's staff occurs only as far as necessary for operation or support.

4. Security

See Annex B. In summary: separation between customers at database level (row level security), TLS in transit, private document storage reachable only through short-lived signed links, and an automated test suite that on every change actively attempts to break the separation between customers.

5. Sub-processors

The controller gives general authorisation for the sub-processors in Annex C. For a new sub-processor the processor gives at least 30 days notice. The controller may object within that period; failing agreement, the controller may terminate at no cost for the remaining term.

6. Transfers outside the EEA

One sub-processor (OpenAI, for transcribing voice messages) would process in the United States if used, under the European Commission's Standard Contractual Clauses. That feature is switched off today: voice messages work, but are not automatically transcribed, so nothing goes to the United States. If the controller wants that permanently excluded, the feature can be moved to an EU alternative; this is a setting, not a rebuild.

All other processing takes place within the EU.

7. Data subject rights

The processor assists the controller with requests for access, rectification, erasure and portability. Drivers can withdraw location consent themselves, directly in the app, with no intervention required.

If the processor receives a request directly from a data subject, it refers the person to the controller and informs the controller within 3 working days.

8. Personal data breaches

The processor reports a personal data breach without undue delay and within 24 hours of discovery, stating the nature of the breach, the categories of data involved, the likely consequences and the measures taken.

9. Retention and deletion

See Annex A. On termination the processor deletes the data within 30 days of the account closing, except where a legal retention obligation applies (documents: 7 years). Thirty days because that is the same period during which the controller can still log in to export after cancelling (see the terms of service); deletion follows directly after that export window closes, rather than adding another period on top.

10. Audit

On request the processor provides the information needed to demonstrate compliance. An on-site audit is possible, at most once a year, with 30 days notice and at the controller's expense, unless the audit reveals a failing.


Annex A - Processing, data and retention

Category of data subjectDataPurposeRetention
DriversName, email, phone, languageAccess and communicationTerm + 6 months
DriversLocation (consent only)Live tracking during a trip30 days
DriversDuty time (start, end, how it ended) and odometer readingsBounding location sharing, hours overview, kilometres per day2 years, statutory minimum
DriversChat and voice messagesCommunication about a trip1 year, configurable 30 days – 3 years
All data subjectsAccess log (who viewed what, when)Accountability1 year, configurable 180 days – 3 years
DriversChat and voice messages, transcriptsCommunication about a tripTerm + 12 months
DriversStatus changes with timestampsProgress and waiting-time recordsTerm + 12 months
PlannersName, email, phoneAccessTerm + 6 months
Contacts at customersName, phone per stopSo the driver can announce arrivalTerm + 12 months
AllDocuments (CMR, proof of delivery, signature)Proof of delivery7 years (legal obligation)

Special categories: none. Trajenda processes no health data, biometrics or comparable categories. A signature on a proof of delivery is not biometric data under the GDPR, because no characteristics are derived from it for identification.

Location is deliberately limited: only during a running trip, only with consent, and trip status is never inferred from location.


Annex B - Technical and organisational measures

Separation between customers. Every table holding customer data is protected by row level security in the database itself, not only in the application. A bug in application code therefore cannot show another company's data.

Tested, not assumed. An automated test suite stands up a second company on every change and actively tries to reach the first company's data from it: reading, writing, deleting, downloading files and escalating privileges. This suite has found and stopped real vulnerabilities during development.

Access rights. Two signed-in roles at the transport company itself: planner and driver; within planners, some can also see the management screens (money and staff). A driver sees only trips assigned to them. A user cannot change their own role or company; this is enforced at column level.

There are also two separate, restricted portals that do not give the user a role at the transport company: a customer portal (the shipper sees their own shipments, documents and invoices) and a charter portal (a subcontracted carrier sees the trips assigned to them and submits their consignment note). Both sit outside the transport company's role model: such a user gets no access to other customers, other charters, or the transport company's own data.

Documents. Stored in private storage, reachable only through signed links with a short validity.

Transport. TLS for all traffic.

Authentication. Password for planners, email link for drivers. Sessions are validated server-side.

Public tracking links. Per trip, off by default, revocable with immediate effect. A tracking link returns a predetermined, limited set of fields - not a copy of the trip - so fields added later do not automatically become public. The driver's location is expressly not among them.

Known limitations, stated honestly:

  • Every period in Annex A has been enforced automatically since 16 August 2026: each night the database removes what is older than the configured period. The customer sets those periods themselves, within the stated limits.
  • Deletion of the ENTIRE file on termination happens on request, not automatically. That is deliberate: an administrative error in subscription status must not cause data loss on its own.
  • Documents belonging to a deleted trip remain in storage. They are unreachable by anyone, but are not yet automatically cleaned up.
  • There is an audit log (audit_log) that records, per company, who created, changed or deleted which row, and when; it does not cover every setting in the application, only the data itself.

Annex C - Sub-processors

PartyProcessingLocationTransfer basis
SupabaseDatabase, authentication, document storageEU (Sweden, Stockholm)n/a
VercelApplication hostingEU (Sweden, Stockholm)n/a
ResendSending emailEUn/a
DeepLTranslating instructions and messagesEUn/a
StripePayments and billingNot yet establishedNot yet established
OpenAITranscribing voice messages (switched off today)United StatesStandard Contractual Clauses