Home/Legal/Data Processing Agreement

Processing on your instructions.

The Data Processing Agreement (Art. 28 GDPR) between your company and Frachta for the data you control on the platform — partners, orders, invoices and bank statements — including our subprocessor list.

Jump to section
  1. 01 · Scope of this agreement
  2. 02 · Roles of the parties
  3. 03 · Subject matter, nature & duration
  4. 04 · Categories of data & data subjects
  5. 05 · Instructions & confidentiality
  6. 06 · Security measures (Art. 32)
  7. 07 · Subprocessors
  8. 08 · Assistance to the controller
  9. 09 · Personal data breaches
  10. 10 · International transfers
  11. 11 · Return & deletion of data
  12. 12 · Audits & information
  13. 13 · Term & liability
  14. 14 · How to execute this DPA
  15. 15 · Contact
Last updated · 10 November 2026Version 1.13Applies to · frachta.lv

01Scope of this agreement

This Data Processing Agreement (“DPA”) governs the processing of personal data that your company (“Customer”) controls and entrusts to Frachta by using the platform. It supplements the Terms & Conditions and applies whenever the Customer stores personal data of its own contacts, partners, drivers or counterparties on Frachta.

02Roles of the parties

For this data the Customer is the controller and SIA "HEIDA LTD" (“Frachta”) is the processor, processing personal data only on the Customer's behalf. For data Frachta collects for its own purposes — accounts, security logs, billing, support communications, platform analytics — Frachta is the controller, as described in the Privacy Policy.

Telematics providers. The Customer holds the contract with its telematics provider and chooses to connect it; the provider is the Customer's own processor, not one Frachta engages. What Frachta does is receive that data on the Customer's instruction and process it as the Customer's processor for this specific data. The Customer should therefore satisfy itself that its agreement with the provider, and any notice it gives its drivers, covers the transfer into Frachta. Frachta does not read telematics data for its own purposes and does not make it available to other Customers.

03Subject matter, nature & duration

The subject matter is the provision of the Frachta platform: freight exchange, transport management, fleet and driver management, document generation, invoicing and payment reconciliation. The nature of processing is storage, structuring, display, calculation (for example of drivers' pay, per diem and road tolls), transmission between authorised users, transmission by e-mail to the recipients the Customer names — transport orders, invoices, payment reminders and order updates — and deletion. Processing lasts for the duration of the Customer's account, plus the deletion period in section 11.

04Categories of data & data subjects

  • Data subjects — the Customer's employees and drivers; drivers' children, by date of birth or expected date of birth only, on a leave application; contact persons of the Customer's partners, shippers and carriers; payers appearing on bank statements.
  • Data categories — names, business contact details, roles; order and shipment details; invoice data; bank-statement lines (counterparty name, IBAN, amount, date, reference); drivers' pay records (base pay, the Customer's standard rates and any rates set for an individual driver, shifts (days on the road), driving hours and distance, kilometres driven at night and nights of work, days and kilometres on public holidays, bonuses and deductions with their reasons, the employer taxes the Customer may enter for its own cost reports, and the gross pay, the amounts withheld from it, the employer's contributions and the net pay as the Customer's accountant calculated them and the Customer uploads them), which the driver also sees in the driver app and on the payslip — except the employer taxes entered for cost reports, which are never shown to the driver.
  • Driver identity and licences — name, date of birth, nationality, country of residency, contact details, driving-licence categories and their validity dates, for drivers the Customer connects to the driver app.
  • Work events with location — arrivals, loading and unloading, waiting for documents, departures and problems at a stop, arrivals at and departures from saved places, seals (each with the cargo unit it is on and that unit's registration plate), the answer at a loading stop that no seal is required, proofs of delivery, damage and defect reports, each with the position of the phone at that moment where the driver allows it (balanced accuracy, about 100 metres, or the approximate position where the driver allows only that; captured only at the event, never continuously or in the background; where the phone gives no position within about 4 seconds, the last one it already has, if no more than 2 minutes old, which can be more exact than 100 metres); for each arrival, loading or unloading, waiting for documents, departure, arrival at or departure from a saved place, seal, no-seal answer, proof of delivery and problem photo, whether the truck was at the stop: the truck's latest position from the Customer's connected telematics account, if taken no more than 15 minutes before the event — or, where none is usable, the phone's position — compared with the stop's location, kept as the outcome, which position was used, the distance and the time of that position, not the truck's position itself. A defect report opens a repair order in the Customer's maintenance records, and a driver's answer that the vehicle cannot be driven takes it out of the Customer's planning until the Customer releases it. Older delivery records may also hold the signature of the person who received the goods, with the same position and comparison. Where the Customer switches on order updates for an order, the time the run carrying it started and the times the driver recorded arriving at and leaving its stops are included in the e-mails to the client's recipients, without the driver's name or any position.
  • Photographs taken in the driver app, which may incidentally show people who are neither the Customer's staff nor Frachta's users.
  • People named on delivery documents — a proof of delivery is a photograph of the signed delivery documents and shows the names and signatures on them; older delivery records also hold the name and role of the person who signed for the consignment on the driver's phone, and any remarks made at handover. Where the Customer switches on order updates for an order, its proof of delivery — the Customer's own file, or else up to three of the driver's photographs — is attached to the e-mail that tells the client's recipients the order was delivered.
  • Telematics data about named drivers — where the Customer connects a telematics account: driver names, tachograph card numbers, driving, work, availability and rest periods, and vehicle position history. That history includes each trip's start and end time and place and its distance, and each change in the fuel tank with its time and place, each with the driver the provider identified; the vehicle's border crossings; and its daily odometer and fuel-counter readings. When the account is connected, up to 13 months of this history are copied. From it the platform works out which driver was in which country on each day — for a trip the provider tied to no driver, by assuming that the driver who last drove that vehicle kept it until somebody else drove it or four days passed — for the Customer's per diem and posting and cabotage reports. Where the Customer pays extra for night work or public holidays, the times and distances of a vehicle's trips during a driver's run are used to work out that pay. Where the Customer pays per hour, the driving hours of those trips are used to work out the hourly pay; the Customer can correct them. The fuel report lists each fall of 5 litres or more in a vehicle's tank with the driver the provider identified at that moment.
  • Absence, leave and drivers' documents — absence type (leave, holiday or sickness), dates, approval status, and a note on leave or holiday (a sickness absence takes none); the applications drivers make in the app (annual, unpaid, maternity, paternity and child-care leave; resignation with its grounds, reason and last working day) and explanations; the drawn signature on those signed in the app; for a resignation, the file signed with a qualified electronic signature — eParaksts where the Customer is registered in Latvia, another EU qualified electronic signature elsewhere — which contains the signer's certificate, often with a personal identification code, and the name taken from it. On a document in Latvian, Lithuanian or German, the driver's position is written in the feminine form if the driver's gender is female.
  • Special categories (Art. 9). Data concerning health reaches the platform in three ways: a sickness absence, limited to the fact and the dates of that type of absence, with no note; a driver's problem report marked “Injury or illness”, with whatever the driver writes; and a maternity leave application, which shows that the driver is pregnant and holds the leave period and the expected date of birth. The platform asks for no diagnosis or medical certificate in any of them: for maternity leave it asks only for the dates the doctor's certificate gives. The notification and e-mail that tell the Customer's users about a maternity leave application call it only a leave application. An annual-leave application may also state that it follows maternity leave. The Customer is the controller and is responsible for the Art. 9(2) condition it relies on. Customers should assess whether this, together with the location and working-time records above, requires a data-protection impact assessment under Art. 35.
  • Chat between the Customer's dispatch and its drivers — the messages exchanged in the driver app, and a driver's report about a message from dispatch, with its reason.

05Instructions & confidentiality

Frachta processes this data only on the Customer's documented instructions — using the platform's features is the instruction — unless EU or Latvian law requires otherwise, in which case Frachta informs the Customer before processing (unless the law prohibits it). All personnel authorised to process the data are bound by confidentiality obligations.

Reported chat messages. A driver can report a message that the Customer's dispatch sent in the driver app's chat. The users who hold the owner role in the Customer's account are then told by e-mail, without the message text, and Frachta's authorised support staff read the reported message, the name of the dispatcher who sent it and the driver's note in order to deal with the report; every such reading is logged. By this DPA, the Customer instructs Frachta to review reported platform content — messages, photos and other reported material — where reasonably necessary to investigate a specific report of misuse, abuse or a breach of platform policies, and to take appropriate action; reading a reported chat message, the sending dispatcher's name and the reporting driver's note, as described above, is one instance of this. The driver's note is the driver's own data, which Frachta holds as controller: it is not shown to the Customer and is erased when the driver deletes their account.

Support for drivers. Frachta's authorised support staff can open a driver's app account to support the driver. Of the Customer's data they see only the Customer's link to that driver, with its status and dates, and counts of the driver's work — runs started and finished, stop events, photos uploaded, documents signed, applications submitted and chat messages sent, over the last 30 days and in all, and the days the driver was active — added up over every carrier the driver is or was linked to, the Customer included, and never split by carrier; never the records themselves or the text of a message. Staff can also sign the driver out and block the driver's account, which stops the driver signing in; the Customer's link to the driver and its records are not touched. Every opening of an account and every action is recorded in the audit log, with the staff member and, for an action, the reason. The Customer instructs Frachta to process its data in this way.

Order updates to the Customer's clients. Where the Customer switches on order updates for an order, Frachta e-mails the addresses the Customer enters for it — at most five, which the platform may suggest from the client's card and its contacts — as the order reaches each stage: confirmed, on the way to loading, loading, in transit, unloading, delivered or cancelled; stages reached moments apart go out as one e-mail. An e-mail covers that order only: its stops, with their planned times and the times the driver recorded arriving and leaving, the time the run carrying the order started, the cargo, and the truck's and trailer's plates; the e-mail on delivery attaches the proof of delivery — the Customer's own file, or else up to three of the driver's photographs. It never contains the price, the driver's name or any other order. Each recipient receives their own copy, so no recipient sees another's address. The e-mail is sent through the Customer's own outgoing mail server where one is set up, otherwise from Frachta's mail service in the Customer's name, marked “via Frachta”, with the user who created the order as the reply-to address. Each e-mail links to a page where its recipients can stop the updates for that order; the Customer is then told, and the updates start again only if the Customer switches them on again. A record of each e-mail — to whom, which stage, when, and whether it was sent — is kept with the order. The Customer instructs Frachta to process its data in this way, and enters only the addresses of people who expect these updates.

06Security measures (Art. 32)

Frachta implements appropriate technical and organisational measures, including:

  • Encryption in transit (TLS) for all connections; hashed credentials and single-use, hashed sign-in and verification tokens.
  • Tenant isolation enforced at the database layer (row-level security) in addition to application checks.
  • Least-privilege access — the application runs under a restricted database role; administrative access is limited and logged.
  • Uploaded files stored under randomised names with type and size restrictions; audit logging of security-relevant actions, chained so that any change to, or removal of, an entry can be detected.
  • EU-based hosting, separation of environments, and encrypted off-site backups — encrypted on our own servers before they are transferred, so the storage provider holds only ciphertext.

07Subprocessors

The Customer authorises the following subprocessors; the list excludes providers that act as independent controllers for the relevant data (for example Montonio for payment data, as described below). Frachta will announce changes to this list in advance (in-app or by email), giving the Customer the opportunity to object on reasonable grounds:

  • Hetzner Online GmbH (Germany; servers in Helsinki, Finland, in the data centre of Hetzner Finland Oy) — runs the servers and database for the platform, the domain name service, and Frachta's own map and route server, which draws the maps and plans truck routes from OpenStreetMap data; the points of a route and a truck's dimensions stay on these servers and reach no third party.
  • E-mail — Frachta's own mail server, on the Hetzner servers above, delivers verification, notification and document e-mails, and the e-mails the Customer sends through the platform to its own contacts — transport orders, invoices, payment reminders and order updates — when they are sent from Frachta's mail service, marked “via Frachta”, with no other e-mail provider in between. Where the Customer sets up its own outgoing mail server in the platform, those e-mails are sent through that server instead; its provider is engaged by the Customer itself, not by Frachta.
  • PostHog (EU cloud) — product analytics: which features are used, linked to internal user and company numbers — never to names, email addresses or content. Page-view analytics in the browser run only for users who consent to analytics cookies. In the driver app it counts screens and work actions only for drivers who agree, linked to the driver's internal account number.
  • Sentry (Functional Software, Inc.; EU data region — Germany) — error and performance monitoring, to keep the platform stable: the error, the address where it occurred and the browser or device type. Sign-in data, request contents and IP addresses are removed before a report leaves our servers; a report from a user's browser goes to Sentry directly and, like any web request, shows Sentry that user's IP address. For a small sample of page loads and requests it also receives how long they took, treated in the same way. From the driver app it receives crash and performance reports linked to the driver's internal account number only, from which request contents, e-mail addresses and sign-in data are removed on the phone. Separately, a native component of its library, built into the app, records for each use only whether it ended in a crash; before sign-in that record carries a random installation identifier rather than an account number and is not linked to the driver. With the driver's consent, it also receives anonymous diagnostic reports from the driver app — counts, memory sizes, screen names, the app version and the phone's model and system, with no account number, IP address or location — in a project of their own, apart from crash reports.
  • When Sentry's generative-AI features (Seer) are enabled, some of the data above may be processed using AI models provided, depending on the specific feature, by Sentry's own subprocessors, including Anthropic PBC and OpenAI in the United States. Sentry represents that this data is not used to train models without permission.
  • Anthropic (United States) — the model behind the platform's optional AI features, engaged only for the feature the Customer actually uses. It receives what that feature sends it and nothing else: in a Company Check, the company details entered, the findings from public sources and — where the checked company is on the platform — its verification status, number of completed deals and ratings, and it may run up to four web searches about the company; an uploaded repair invoice, together with the work order's repair lines, to read the invoice lines off it; in the route planner, the trucks' plates and the planning rules typed for them, the dispatcher's instruction and the loads as country to country with their weights — no addresses; and news or instruction text, to draft and translate it. It is not used to make decisions about a data subject, and its output is advisory. Its use for support tickets and security reviews is Frachta's own processing, described in the Privacy Policy.
  • Montonio Finance, UAB (Lithuania) — payments for everything bought on the platform; with each order it receives what was bought, the Customer's name, VAT number and address, and the name and e-mail address of the user paying (the Customer's public e-mail address where there is none). It acts as an independent controller for payment data, not a subprocessor.
  • SMS delivery provider (Esteria, EU) — delivers verification and notification SMS, and is instructed with each one to keep neither its text nor the number it was sent to.
  • Backblaze (B2 Cloud Storage, EU Central — Amsterdam) — stores our off-site backups. The data is encrypted before it leaves our servers, so Backblaze cannot read it.
  • Expo (650 Industries, Inc., United States) — delivers push notifications to the driver app, passing each one to Apple's push service (APNs) or Google's Firebase Cloud Messaging. For each notification it receives the phone's push token, a short general text in the driver's language — never the text of a chat message; an invitation names the inviting company — and a link to the screen it opens.

08Assistance to the controller

Taking into account the nature of processing, Frachta assists the Customer with appropriate technical and organisational measures in fulfilling data-subject requests (Art. 12–23), and in meeting the Customer's obligations under Art. 32–36 (security, breach notification, impact assessments), insofar as the information is available to Frachta.

For PostHog, whose retention period we cannot shorten in their settings, we carry out individual data-subject deletion requests (Art. 17) ourselves, using the PostHog API.

09Personal data breaches

Frachta notifies the Customer without undue delay after becoming aware of a personal data breach affecting the Customer's data, providing the information reasonably required for the Customer's own notification duties under Art. 33–34 GDPR.

10International transfers

Processing takes place in the EU, except by Anthropic (United States; basis — Standard Contractual Clauses, not an adequacy decision), which is used only for the optional AI features, and by Expo (United States), which delivers push notifications to the driver app. Any transfer outside the EEA occurs only with an adequacy decision — including the one for the EU-U.S. Data Privacy Framework — or Standard Contractual Clauses in place, and is reflected in the subprocessor list above. The transfer to Expo relies on the certification of 650 Industries, Inc. under that Framework.

11Return & deletion of data

The Customer's controlled data is kept for as long as the account exists, including the data of a module the Customer has cancelled. When the Customer's owner deletes the account, Frachta deletes or anonymises that data 48 hours after the owner confirms the deletion — until then the deletion can be cancelled — unless EU or Latvian law requires longer storage (for example accounting records) or a legal hold applies. Before closing the account the Customer can export its data using the platform's export features.

Encrypted backups are taken several times a day and rotate on a rolling schedule of up to six months. Data deleted from the live platform is gone from it immediately; the last backup copy disappears as that schedule rotates. Backups are restored only for disaster recovery, never to revive individual deleted records.

Telematics history that Frachta copies from the Customer's telematics account — trips, border crossings, daily odometer and fuel-counter readings and fuel-tank changes, including up to 13 months from before the connection — is kept while the Customer's account exists and is deleted with it; tank-level and temperature readings are deleted two years after they were taken.

12Audits & information

Frachta makes available the information necessary to demonstrate compliance with Art. 28 GDPR and allows for audits — normally satisfied by documentation and third-party attestations; on-site audits require reasonable notice, business-hours access and confidentiality undertakings, at the Customer's cost.

13Term & liability

This DPA applies as long as Frachta processes personal data for the Customer. Liability follows the limitations in the Terms & Conditions, to the extent permitted by Art. 82 GDPR.

14How to execute this DPA

This DPA is incorporated into the Terms and applies automatically to every Customer. Enterprise customers who need a countersigned copy, a bespoke security annex or an audit conversation: email privacy@frachta.lv and we will arrange it.

This DPA is published in English and in translation. If a translation differs from the English text, the English text prevails.

15Contact

Questions about this DPA? Write to privacy@frachta.lv. The processor is SIA "HEIDA LTD", registration No. 40203741048, VAT No. LV40203741048, Spāres iela 3A, Rīga, LV-1002, Latvia. Related documents: Privacy Policy, Terms & Conditions, Cookie Policy and GDPR.