Privacy Policy

1. Scope

This policy explains data processing in DART DDD, including its website, user workspace and mobile applications connected to its API. It covers account holders, drivers whose records are uploaded, and organisation representatives.

The service stores and analyses digital tachograph and driver card files, maintains a journal and sends notifications. Uploading a DDD file for analysis transfers it to the server. These records do not remain exclusively on your phone or computer.

This policy is a notice about processing. Reading or using it does not replace separate consent where consent is required, or authorise unrelated new purposes.

2. User and service operator responsibilities

Users are responsible for lawfully obtaining and uploading files and other information, having the necessary authority and legal grounds to process and transfer third-party data, and meeting applicable notice and consent requirements where required by law. Users must not upload information they are not entitled to process.

Users are responsible for the accuracy of information they enter, safeguarding sign-in credentials, granting access to other people and lawful use of exported files and reports. Before making employment, transport, financial or other significant decisions, users must verify analysis against source records and applicable requirements; the service does not replace professional or legal review.

To the extent permitted by applicable law, the operator is not responsible for consequences of unlawful user actions, inaccurate or incomplete user-supplied information or independent user decisions based on reports, unless those consequences result from the operator breaching its own duties. This policy does not transfer responsibility for the operator’s own violations to users, remove mandatory data security duties, or restrict data subject rights or liability that cannot lawfully be excluded.

The service operator determines processing needed to maintain accounts, protect the service and communicate with users. An organisation uploading its drivers’ records determines the purposes and legal grounds for that processing; the service processes those records on its instructions under the applicable agreement.

Access to files and reports depends on organisation membership, roles and permissions. Authorised colleagues may see driver records within their access rights. Uploading a file does not make it public.

Organisations must inform affected drivers and upload only data they are entitled to process. For an individual account, the functions selected by its user determine the scope of processing.

3. Data we process

The records involved depend on the profile, file contents and functions used.

• Account details: name, email, an optional phone number, language, time zone, organisation membership and permissions. Passwords are hashed. Enabling two-factor authentication creates additional authentication records.
• Organisation profile: the name and contact information supplied by authorised members.
• DDD and analysis: driver name, card number, licence information, document validity dates, date of birth where present, vehicles, mileage, driving, work and rest periods, events, faults and integrity results. A file may include GNSS coordinates recorded by the tachograph.
• Journal: shifts, journeys, mileage, fuel purchases, expenses, amounts and notes entered by the user. Avoid unnecessary personal details in free-text fields.
• Technical records: request timing and outcomes, errors, IP address and User-Agent during network access, and security events. The application audit uses pseudonymous IP and User-Agent values; infrastructure logs are considered separately.
• Notifications and requests: push registration token, platform, supplied device name, notification contents and status, and information submitted in support or privacy requests.

4. Purposes and legal grounds

If a user chooses Google sign-in and the feature is enabled, Google supplies an ID token containing an account identifier, email, its verification status and an available name. The service verifies the signature and intended audience and stores an HMAC of the identifier for later sign-ins, not the Google token itself. A third-party email may need separate verification. Google sign-in does not transmit DDD files to Google. In the web interface, the Google component loads after user action; Google may process technical sign-in information under its own privacy policy.

We use these records to register and authenticate users, provide workspace access, receive and analyse DDD files, prepare reports, synchronise the journal, deliver service messages, provide support and prevent misuse.

The legal ground depends on the purpose and applicable law: performing a user contract, complying with legal duties, a legally permitted interest in security, or separate consent for an optional feature. An organisation’s grounds and duties for employee records are assessed separately.

We do not sell personal data or use DDD contents for advertising profiles. Analysis assists users in reviewing tachograph records; it is not itself an employer or government decision about a person’s rights.

5. Mobile applications and permissions

When a mobile client uses the account, submitted information, DDD files selected for upload and journal operations are sent to the server for the requested function. Coordinates in DDD originate from tachograph records; their presence is not permission to track the phone’s location.

Optional push uses Firebase Cloud Messaging; delivery to Apple devices may involve APNs. Delivery providers process the necessary identifiers and message payload. Notification permission can be changed in device settings. Depending on those settings, messages may be visible on a lock screen.

Uninstalling an app does not delete the account, DDD or journal on the server. Use the privacy request process below for server data. Copies independently saved or shared with others remain under the control of their recipients.

6. Cookies and browser storage

The browser stores information needed for sign-in, language preferences and the interface. Authentication tokens and settings may use local storage. The installed web app may cache its interface and journal records for offline operation.

You can remove this information using browser or site-data settings. On shared devices, sign out and clear stored site data after use. Clearing local storage does not remove server records.

This policy page can be read without signing in and loads no advertising, analytics or push scripts.

In the web interface, clicking “Got it” in the privacy notice saves its version and dismissal time in browser storage. This acknowledgment lasts 180 days and is not consent to advertising, analytics or arbitrary processing purposes. Clearing site data makes the notice appear again.

7. Access and recipients

Recipients include authorised members of the relevant organisation and personnel who need access to support or protect the service. Infrastructure and service email providers may also be involved. When push is enabled, Google/Firebase and, for applicable devices, Apple process notification delivery.

Exporting or sharing a report makes it available to the recipient selected by the user. Information may be disclosed to authorities on a valid legal ground and within the required scope. App stores process use of their stores under their own privacy terms.

Using Firebase for push does not by itself send source DDD files to Firebase: the service sends a token and notification payload. That payload can still relate to the account or the user’s work events.

8. Processing locations and international transfers

Infrastructure, email and push providers may process information in other countries. Transfers require assessment and safeguards under applicable law; publishing this policy does not replace those measures.

Localisation and international transfer requirements depend on the user’s and organisation’s countries. You can request information about applicable providers and transfer safeguards through the operator’s contact.

9. Retention and deletion

DDD follows the retention policy assigned to the organisation; the policy and its basis are saved with each uploaded file. Service settings do not establish a universal statutory retention period for every country.

A mandatory transport-record retention period or active legal hold may prevent deletion of a particular file. When a request is reviewed, the reason and applicable period must be explained. Requesting account deletion does not override an organisation’s lawful record-keeping duties.

Backups follow a separate lifecycle. Removal from the primary system does not instantly remove every backup, delivery-provider record or copy previously supplied to a recipient. These locations are considered when handling the request.

10. Rights and requests

Depending on applicable law, you may request information, access and a copy of your data, correction, erasure, restriction or portability, object to processing and withdraw consent previously given. Withdrawal concerns the relevant processing and does not invalidate lawful processing before withdrawal.

Contact the operator with your account email and the nature of your request. For records uploaded by an employer, you may also contact your organisation. Do not email your password, MFA code or a full DDD file. We will request only the information necessary to verify identity and arrange an appropriate channel.

The subject-request workspace available to authorised personnel supports request handling. Its existence does not mean every user already has a self-service account deletion button. Erasure checks retention and legal hold; remaining necessary records may be anonymised or retained to the extent legally required.

Response deadlines follow applicable law. If a request is lawfully limited, we explain the reason and available review process. You may also complain to the competent data protection authority.

11. Security

Protection includes access controls, organisation isolation, password hashing, encryption of protected records and access logging. Public service traffic must use HTTPS. This is not end-to-end encryption that prevents the operator from processing an uploaded DDD.

Users must protect their sign-in credentials and grant colleague access carefully. Contact the operator if you suspect an account compromise. Protective measures reduce risks but cannot eliminate every technical failure or unauthorised act.

12. Children and policy changes

The service supports professional tachograph work and is not intended for children. Contact the operator if you believe a child’s data has been provided without a proper ground so it can be reviewed.

The current edition is available at this address with a version and effective date. Material new purposes or changes requiring further notice or consent must be communicated before the relevant processing begins.