Data Processing Agreement (DPA)

Addendum to the Terms of Service   |   Last Updated: Oct 22, 2026

Plain-English Summary (Not Part of the Legal Terms)

This box is just here to help you understand the document below — it has no legal effect and does not change the actual terms.

When a Driver’s data passes through FuelaFleet (names, routes, logbook entries, receipts), GDPR treats your business as the “Controller” — you decide why that data is collected and what it’s used for — and treats FuelaFleet as the “Processor” — we just handle the data on your instructions, to provide the Service. Whenever a Processor handles personal data on behalf of a Controller, GDPR requires that relationship to be written down in a contract. That is what this document is.

In short, it covers: what FuelaFleet can and can’t do with your data; which other companies (called “sub-processors” — here, Zoner, Stripe, make.com, iDoklad, Google Gemini AI, Brevo, Telegram, Hotjar by Contentsquare, and Meta) also touch the data, and why; what happens if there’s a data breach; how you can check up on us; and what happens to your data when you leave. You, as the Controller, remain responsible for having a lawful reason to collect your Drivers’ data in the first place (e.g., telling them what is tracked and why) — this DPA only covers FuelaFleet’s side of that relationship.

Preamble

This Data Processing Agreement (“DPA”) is entered into between Mgr. Ján Kubiš, operator of the FuelaFleet application (“Processor,” “Provider,” “we,” “us”), and the business entity that has registered for a FuelaFleet account (“Controller,” “Customer,” “you”). This DPA forms part of, and is incorporated by reference into, the Terms of Use between the parties (the “Main Agreement”), and applies automatically whenever Controller uses the FuelaFleet application (the “Service”) to process personal data of Drivers or other individuals. This DPA reflects the parties’ respective obligations under Articles 28 and 29 of Regulation (EU) 2016/679 (“GDPR”).

Where Controller requires a separately countersigned copy of this DPA for its own vendor-compliance records, it may request one using the contact details in Section 16.

1. Definitions

1.1 “GDPR” means Regulation (EU) 2016/679 (General Data Protection Regulation), as amended or replaced from time to time.

1.2 “Controller,” “Processor,” “Data Subject,” “Personal Data,” “Processing,” “Personal Data Breach,” and “Supervisory Authority” have the meanings given to them in Article 4 GDPR.

1.3 “Sub-processor” means any processor engaged by Processor to assist in processing Customer Personal Data on behalf of Controller, as listed in Annex III.

1.4 “Customer Personal Data” means personal data processed by Processor on behalf of Controller through the Service, as described in Annex I.

1.5 “Main Agreement” means the FuelaFleet Terms of Service in effect between the parties.

2. Roles of the Parties

The parties acknowledge that, with respect to Customer Personal Data, Controller is the Data Controller and Processor is the Data Processor, as those terms are defined in the GDPR. Annex I describes the subject matter, duration, nature, and purpose of the processing, the categories of Data Subjects, and the categories of Customer Personal Data.

3. Controller’s Instructions

Processor shall process Customer Personal Data only on the documented instructions of Controller, including with regard to international transfers, unless required to do otherwise by EU or Member State law; in that case, Processor shall inform Controller of that legal requirement before processing, unless the law prohibits Processor from doing so.

The Main Agreement, this DPA, and Controller’s use of the standard features and configuration options of the Service constitute Controller’s complete documented instructions to Processor as of the date of this DPA. Any additional or alternative instructions require the parties’ written agreement and may be subject to additional fees if they require material changes to the Service.

Processor shall promptly inform Controller if, in Processor’s reasonable opinion, an instruction infringes the GDPR or other applicable data protection law.

4. Confidentiality

Processor shall ensure that any person it authorizes to process Customer Personal Data is subject to a binding obligation of confidentiality, whether contractual or statutory, and processes such data only as necessary for the purposes of the Main Agreement.

5. Security of Processing

Processor shall implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk, as described in Annex II, taking into account the state of the art, the costs of implementation, and the nature, scope, context, and purposes of processing, consistent with Article 32 GDPR.

Processor may update the measures described in Annex II from time to time to reflect technical progress, provided that any such update does not materially decrease the overall level of protection.

6. Sub-processors

Controller grants Processor general written authorization to engage the Sub-processors listed in Annex III to assist in providing the Service.

Processor shall impose data protection obligations on each Sub-processor that are substantially equivalent to those set out in this DPA, and remains fully liable to Controller for the performance of each Sub-processor’s obligations.

Processor shall give Controller at least 14 days’ prior notice (by email or in-app notice) of any intended addition or replacement of a Sub-processor, giving Controller a reasonable opportunity to object on reasonable data-protection grounds. If the parties cannot resolve such an objection, Controller’s sole remedy is to terminate the Main Agreement with respect to the affected part of the Service.

7. International Data Transfers

Where Processor or a Sub-processor transfers Customer Personal Data outside the European Economic Area (“EEA”), Processor shall ensure the transfer is subject to appropriate safeguards under Chapter V GDPR, such as: (a) an applicable European Commission adequacy decision; (b) the Standard Contractual Clauses adopted under European Commission Implementing Decision (EU) 2021/914; or (c) a Sub-processor’s self-certification under the EU-U.S. Data Privacy Framework or a successor mechanism, where applicable.

As of the date of this DPA, the Sub-processor most likely to process Customer Personal Data outside the EEA is Google (Google Gemini AI, used for receipt OCR). Processor relies on the transfer safeguards incorporated into Google’s own customer and data-processing terms, as updated by Google from time to time. Controller may request a copy of the relevant transfer documentation for this and any other Sub-processor.

8. Assistance with Data Subject Rights

Taking into account the nature of the processing, Processor shall provide reasonable assistance to Controller, through appropriate technical and organizational measures, to help Controller fulfil its obligation to respond to Data Subject requests (e.g., access, rectification, erasure, restriction, portability, or objection) under Chapter III GDPR.

If Processor receives a request directly from a Data Subject (for example, a Driver) concerning Customer Personal Data, Processor shall not respond to it substantively, beyond acknowledging receipt, and shall promptly forward the request to Controller, who remains responsible for responding to it.

9. Assistance with Compliance, Security, and Impact Assessments

Processor shall provide Controller with information reasonably requested about its processing activities and security measures, to the extent necessary for Controller to comply with its own obligations under Articles 32 to 36 GDPR, including carrying out data protection impact assessments and any required prior consultation with a Supervisory Authority.

10. Personal Data Breach Notification

Processor shall notify Controller without undue delay, and in any event within 48 hours, after becoming aware of a Personal Data Breach affecting Customer Personal Data.

The notification shall describe, to the extent then known: the nature of the breach; the categories and approximate number of Data Subjects and records concerned; the likely consequences; and the measures taken or proposed to address the breach and mitigate its effects. Processor shall provide further information as it becomes available, without undue delay.

Processor’s notification of, or response to, a Personal Data Breach shall not be construed as an admission of fault or liability by Processor.

11. Audits and Inspections

Processor shall make available to Controller all information reasonably necessary to demonstrate compliance with this DPA, and shall allow for and contribute to audits, including inspections, conducted by Controller or an independent auditor mandated by Controller, subject to: (a) at least 30 days’ prior written notice; (b) audits taking place no more than once per 12-month period, unless required by a Supervisory Authority or following a Personal Data Breach; (c) audits being conducted during normal business hours in a manner that minimizes disruption to Processor’s operations, and subject to confidentiality; and (d) Controller bearing its own costs, and any reasonable costs incurred by Processor in supporting an on-site audit.

In place of an on-site audit, Processor may satisfy this obligation by providing a written description of its security measures, completing a reasonable security questionnaire, or providing a relevant third-party audit or certification report, where one is available.

12. Return and Deletion of Customer Personal Data

Following termination or expiry of the Main Agreement, Processor shall, at Controller’s choice, make Customer Personal Data available for export and thereafter delete it, in accordance with the data export and retention provisions of the Terms of Service.

Unless applicable law requires Processor to retain copies, Processor shall delete all remaining Customer Personal Data, including from routine backups, within a commercially reasonable period following the retention period described in the Terms of Service, in line with its standard deletion and backup-rotation schedules.

13. Liability

Each party’s liability arising out of or in connection with this DPA is subject to the limitations and exclusions of liability set out in the Limitation of Liability section of the Terms of Service, which apply equally to this DPA as if set out in full, except where applicable law prohibits such a limitation.

14. Term and Termination

This DPA takes effect on the date Controller first uses the Service to process Customer Personal Data, and remains in effect for as long as Processor processes Customer Personal Data on Controller’s behalf under the Main Agreement. Termination of the Main Agreement automatically terminates this DPA, without prejudice to any obligation that by its nature survives termination (for example, post-termination deletion and confidentiality).

15. Order of Precedence and Governing Law

In the event of a conflict between this DPA and the Terms of Service, this DPA prevails with respect to the processing of personal data; the Terms of Service prevail on all other matters. This DPA is governed by the laws of the Slovak Republic, consistent with the Governing Law and Jurisdiction section of the Terms of Service.

16. Contact

Questions about this DPA, requests for a countersigned copy, or Sub-processor transfer documentation, can be sent to Questions about DPA

Annex I — Details of Processing

• Subject matter: Processor’s provision of the FuelaFleet fleet-management SaaS to Controller.
• Duration: For the term of the Main Agreement, plus the post-termination retention period described in the Terms of Service.
• Nature and purpose of processing: hosting, storage, and processing of fleet, logbook, and receipt data to enable Controller to track vehicles and fuel use, manage driver logbooks, generate PDF/CSV reports, send notifications and email alerts, and process subscription payments.
• Categories of Data Subjects: Controller’s Drivers and other personnel invited to the workspace; Controller’s Admin users.
• Categories of Customer Personal Data: name; email address; post address; hire date; birthday; personal ID; vehicle assignment; logbook entries (dates, times, distances, routes, purpose); fuel receipt images and data extracted from them (cost, VAT, liters, merchant details); Telegram account identifiers (where a Driver or Admin opts in); technical/usage data (IP address, browser type, session logs).
• Special categories of data: None are required by the Service. Controller shall not submit special categories of personal data (Article 9 GDPR) or criminal-offense data through the Service.
• Frequency of processing: Continuous, for the duration of the Main Agreement.

Annex II — Technical and Organizational Security Measures

The following measures reflect the security architecture of the FuelaFleet platform as implemented and verified at the date of this DPA. Processor may update these measures to reflect technical progress, provided no update materially reduces the overall level of protection afforded to Customer Personal Data.

1. Infrastructure & EU Data Sovereignty

• 100% EU Hosting: All FuelaFleet application servers and databases are physically hosted within the European Union (Czech Republic) via ZONER a.s. No US-based or non-EEA edge networks are used, ensuring strict adherence to GDPR and EU data sovereignty requirements.

• Default-Deny Host Firewall (UFW): The server operates behind a strictly enforced default-deny firewall at the operating system level. All inbound traffic is blocked by default; only ports required for encrypted web traffic (HTTPS/443) and server administration are explicitly permitted.

• SSH Hardening: Remote server administration is restricted to cryptographic key-based authentication on a non-standard port. Root login and password-based authentication are permanently disabled.

• Reverse Proxy Architecture: The application runs behind a hardened NGINX/Gunicorn reverse proxy. Server version disclosure is suppressed (server_tokens off). ProxyFix middleware ensures accurate logging of true client IP addresses for audit and intrusion detection purposes.

• Active Intrusion Prevention (Fail2Ban): An automated intrusion prevention system continuously monitors NGINX access logs. IP addresses exhibiting repeated suspicious behaviour — including port scanning, vulnerability probing, or brute-force patterns — are automatically and permanently banned at the firewall level without human intervention.

• EU-Bound AI Processing: All advanced Artificial Intelligence features (Voice Agent and Receipt Scanner) are processed exclusively via Google Cloud servers geographically restricted to the European Union (europe-west3).
• GDPR Compliance: No personal or fleet data is transferred outside the European Economic Area (EEA), ensuring absolute strict compliance with the General Data Protection Regulation (GDPR).

2. Network-Layer & Anti-DDoS Protection

• NGINX-Layer Rate Limiting: Traffic rate limiting is enforced at the NGINX layer, before requests reach the application. Attempts to flood the service — including volumetric HTTP floods and Slow Loris-style connection exhaustion attacks — are intercepted and dropped with a 503 response at the web server layer, protecting application and database resources.

• Slow Loris & Connection Timeout Protection: NGINX is configured with strict client body, header, keepalive, and send timeouts to neutralize connection-exhaustion attacks that attempt to hold open large numbers of idle connections.

• Infrastructure-Level DDoS Mitigation: The hosting provider, ZONER, s.r.o., provides upstream network-level DDoS mitigation as part of its VPS infrastructure, providing an additional layer of protection against volumetric attacks below the application stack.

3. Application-Layer Threat Prevention

• Stacked Rate Limiting with Persistent Redis Backend: FuelaFleet employs dual-layer rate limiting backed by a persistent Redis datastore, ensuring rate-limit state survives server reboots and deployments:
  • IP-Level: Login attempts are strictly limited to 5 per minute per IP address.
  • Account-Level (Distributed Botnet Defence): If a botnet rotates IP addresses to target a specific account, the account is automatically locked after 20 cumulative failed attempts, rendering large-scale credential-stuffing attacks ineffective regardless of the number of source IPs used.

• SQL Injection (SQLi) Prevention: All database interactions use strictly parameterized queries. User-supplied input is treated as data only and cannot alter query structure or execute arbitrary database commands.

• Cross-Site Scripting (XSS) Prevention: The Jinja2 templating engine provides automatic output escaping for all rendered content. A strict Content-Security-Policy (CSP) HTTP header provides a second layer of defence, preventing the execution of any injected or unauthorized scripts even in the event of a template-level bypass.

• Cross-Site Request Forgery (CSRF) & Open Redirect Prevention: All state-changing requests (POST/PUT/DELETE) are protected by strictly enforced cryptographic session cookies. FuelaFleet additionally validates that the HTTP Referrer header matches the application’s exact domain before executing any automatic redirect, neutralizing both CSRF and phishing-based redirect attacks.

• Malicious File Upload & Image Bomb Prevention: Uploaded receipt files are subject to strict MIME-type and file extension validation, blocking executable and script files entirely. Every image is subsequently routed through the Pillow image-processing library, which validates the file’s internal structure. Malformed files, disguised executables, and image-bomb payloads are detected and destroyed in memory before any data is written to disk. The maximum permitted file size is 5 MB, enforced at the NGINX layer.

• Broken Object Level Authorization (BOLA / IDOR) Defence: A global Security Interceptor validates the absolute ownership of every data object (vehicle, trip, expense) against the requesting account’s account_id and subscription plan limits on every request. It is not possible for a user to enumerate or access another tenant’s data by manipulating URL parameters or API identifiers.

4. Identity, Session & Browser Security

• Password Requirements: The platform programmatically enforces a minimum password length of 8 characters, requiring a combination of letters and numbers for all user accounts.

• Cryptographic Password Storage: Passwords are never stored in plaintext. All passwords are hashed and salted using the PBKDF2-SHA256 algorithm prior to storage.

• Cryptographic Session Binding: Active session cookies are cryptographically bound to the user’s current password hash. A password change or reset immediately invalidates all active sessions across all devices, providing automatic protection against session hijacking following a credential compromise.

• BFCache & Ghost-Session Eradication: Strict Cache-Control HTTP headers (no-store, no-cache, must-revalidate) are combined with client-side JavaScript memory-clearing routines. Following logout, browsers are prevented from serving cached snapshots of authenticated pages via the Back button, eliminating ghost-session data exposure on shared or public devices.

• HTTP Security Headers: The following security headers are applied to all responses:

  • Strict-Transport-Security (HSTS): Forces all connections to use HTTPS, preventing protocol-downgrade and man-in-the-middle attacks.

  • Content-Security-Policy (CSP): Restricts the sources from which scripts, styles, and other resources may load, blocking injected script execution.

  • X-Frame-Options: DENY: Prevents the application from being embedded in iframes, blocking clickjacking attacks.

  • X-Content-Type-Options: nosniff: Prevents browsers from MIME-sniffing responses away from the declared content type.

  • Referrer-Policy: Controls the information sent in the Referrer header, limiting data leakage to third-party sites.

5. Role-Based Access Control & Multi-Tenant Data Isolation

• Strict Role-Based Access Control (RBAC): Four distinct access roles are enforced at the backend level:

  • Administrators: Full workspace access.

  • Team Managers: Cryptographically scoped to vehicles and drivers assigned to their department_id only.

  • Accountants: Hard-coded read-only access; the backend rejects all POST (write) requests from this role at the server level.

  • Drivers: Strictly limited to their own assigned vehicles and trip logs.

• Multi-Tenant Isolation: Each Customer’s data is logically isolated within its own workspace. The Security Interceptor enforces ownership validation on every data access request, making cross-tenant data access mathematically impossible through URL or parameter manipulation.

6. Data Encryption

• Encryption in Transit: All data transmitted between user devices and FuelaFleet servers is encrypted using TLS 1.2 / TLS 1.3 (HTTPS), protecting against interception and man-in-the-middle attacks.

• Encryption at Rest: Customer Personal Data is stored on VPS infrastructure provided by ZONER a.s. Physical storage volumes are protected by enterprise-grade infrastructure security protocols maintained by ZONER a.s. as part of their data centre operations within the EU.

• Cryptographic Password Storage: As noted in Section 4, all passwords are stored exclusively as PBKDF2-SHA256 salted hashes.

7. Data Integrity, Backups & Resilience

• Tiered Automated Backup System: Customer Personal Data is protected by two independent backup mechanisms:

  • Application-Layer Backups: An automated Linux cron job executes an uninterruptible database snapshot (SQLite .backup API operating in WAL mode) every night at 03:00. Backups are retained on a 14-day rolling cycle in an isolated, access-controlled directory on the server.

  • Infrastructure-Layer Backups (ZONER 7/14 Protocol): ZONER a.s. independently backs up the entire VPS container and storage volume using their 7/14 Backup Protocol, providing complete disaster recovery capability at the infrastructure level, entirely within the EU. In the event of catastrophic server failure, the complete environment — including the operating system, application, and all data — can be restored from ZONER’s infrastructure snapshots independently of the application-layer backups.

• Database Write-Ahead Logging (WAL Mode): The SQLite database operates in WAL (Write-Ahead Logging) mode, which improves concurrent read performance, ensures atomic transactions, and reduces the risk of database corruption during unplanned outages or hard shutdowns.

• Financial Data Integrity Controls: All financial and distance inputs are scrubbed through an absolute-value float conversion function (abs(float())) at the application layer, preventing manipulation through negative-value injection.

• Payroll & Historical Period Locking: Once a monthly logbook period is co-signed by both the Driver and the Team Manager, the database record is cryptographically locked. The backend rejects any subsequent attempt to add, modify, or delete entries within a locked payroll period, ensuring the integrity of exported financial and tax records.

Annex III — Authorized Sub-processors

Controller authorizes Processor to engage the following Sub-processors. Processor will update this list and notify Controller in accordance with Section 6 above.