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 subject | Data | Purpose | Retention |
|---|---|---|---|
| Drivers | Name, email, phone, language | Access and communication | Term + 6 months |
| Drivers | Location (consent only) | Live tracking during a trip | 30 days |
| Drivers | Duty time (start, end, how it ended) and odometer readings | Bounding location sharing, hours overview, kilometres per day | 2 years, statutory minimum |
| Drivers | Chat and voice messages | Communication about a trip | 1 year, configurable 30 days – 3 years |
| All data subjects | Access log (who viewed what, when) | Accountability | 1 year, configurable 180 days – 3 years |
| Drivers | Chat and voice messages, transcripts | Communication about a trip | Term + 12 months |
| Drivers | Status changes with timestamps | Progress and waiting-time records | Term + 12 months |
| Planners | Name, email, phone | Access | Term + 6 months |
| Contacts at customers | Name, phone per stop | So the driver can announce arrival | Term + 12 months |
| All | Documents (CMR, proof of delivery, signature) | Proof of delivery | 7 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
| Party | Processing | Location | Transfer basis |
|---|---|---|---|
| Supabase | Database, authentication, document storage | EU (Sweden, Stockholm) | n/a |
| Vercel | Application hosting | EU (Sweden, Stockholm) | n/a |
| Resend | Sending email | EU | n/a |
| DeepL | Translating instructions and messages | EU | n/a |
| Stripe | Payments and billing | Not yet established | Not yet established |
| OpenAI | Transcribing voice messages (switched off today) | United States | Standard Contractual Clauses |