SERVICE LEVEL AGREEMENT

Provider and Client are each a "Party" and together the "Parties". This SLA sets out the service levels that Provider commits to for the TACHRON production service, the support and escalation process, the measurement and publication of service levels, and the service credits that apply if the committed availability is not achieved.

1. Purpose, Scope and Order of Precedence

1.1 This SLA forms an integral part of the Agreement. Terms not defined in this SLA have the meaning given to them in the Agreement.

1.2 This SLA applies exclusively to the TACHRON production environment subscribed to by Client under the Agreement. It does not apply to test, staging, sandbox, trial, beta or pilot environments or features (see Section 9).

1.3 Client is a business customer (entrepreneur within the meaning of Section 14 German Civil Code (BGB)) and uses TACHRON in order to provide services to its own customers (in particular transport undertakings). This SLA governs the relationship between Provider and Client only. Client's customers and end users (including drivers) do not acquire any direct rights under this SLA.

1.4 In the event of conflict, the following order of precedence applies (in line with Section 1.4 GTC): (a) the Data Processing Agreement pursuant to Art. 28 GDPR / UK GDPR ("DPA") with respect to the processing of personal data; (b) the individual contract; (c) this SLA, whereby the main text of this SLA prevails over its annexes, in particular over the Service Description in Annex 1; (d) the GTC. Liability is governed exclusively by Section 6 GTC, subject to Section 8.5 of this SLA. Governing law and jurisdiction are set out in Section 12.3.

2. Definitions

3. Service Description

3.1 TACHRON is a cloud-based tachograph compliance engine for providers of fleet management systems (FMS) and transport management systems (TMS). Client submits DDD Files to TACHRON via API or web interface; TACHRON evaluates them and returns structured results. The binding functional scope, the supported rule sets and the integration interfaces are set out in the Service Description (Annex 1) and the API documentation, each in its current version.

3.2 Core functionality comprises in particular:

• Archiving: storage of the original DDD Files unaltered (preserving their digital signatures), encrypted at rest and in transit, for the retention period specified by the Client, with retrieval and download at any time. This supports Client's customers in fulfilling their obligations under Art. 33(2) Reg. (EU) 165/2014. Client is responsible for specifying a retention period that meets the applicable statutory minimum (at least twelve (12) months from the date of recording under Art. 33(2) Reg. (EU) 165/2014; for records used to document working time, at least two (2) years under Art. 9(b) Directive 2002/15/EC and the national implementing laws).
• Infringement detection and reporting: identification of infringements in plain language, indicative fine information, links to training content and a structured answer dialogue for drivers. This supports transport undertakings in organising and checking drivers' work and instructing drivers pursuant to Art. 33(1) Reg. (EU) 165/2014 and Art. 10 Reg. (EC) 561/2006.

3.3 The rule sets evaluated by TACHRON (EU/EEA, AETR, United Kingdom, Switzerland, working time and Mobility Package I) are listed in Annex 1. Provider will implement changes in law covered by Annex 1 within the periods set out in Section 5 (Regulatory Update Objective).

3.4 No legal advice; responsibility of transport undertakings. TACHRON is a technical decision-support tool. Results, infringement classifications and fine information are generated automatically on the basis of the data contained in the DDD Files and any manual entries and do not constitute legal advice. Fine information is indicative; actual fines depend on the competent authority and the circumstances of the individual case. Responsibility for compliance with driving-time, rest-time, working-time and tachograph obligations, for data retention vis-à-vis control authorities and for decisions taken on the basis of TACHRON results remains with the respective transport undertaking and, within its sphere, with Client. This includes compliance with employee data protection and any co-determination requirements (e.g. works council consultation) that apply to the use of TACHRON results for monitoring drivers. Decisions with legal or similarly significant effects on drivers shall not be based solely on automated TACHRON results; the driver answer dialogue supports the required human review. The TACHRON evaluation engine is a deterministic, rule-based system whose rules are defined by Provider on the basis of the applicable legislation; it is not an AI system within the meaning of Art. 3(1) Regulation (EU) 2024/1689 (AI Act).

3.5 Optional channels (e.g. messaging or chatbot integrations operated by third parties such as WhatsApp) and professional services (e.g. integration support) are not part of this SLA unless expressly agreed otherwise, and may be subject to separate terms. Where such channels use AI systems that interact directly with drivers, Provider ensures that drivers are informed that they are interacting with an AI system (Art. 50(1) AI Act). Information on the AI models used, their hosting location and the related sub-processors is published in the Privacy Policy.

4. Service Availability

4.1 Committed Availability

Provider shall ensure an Availability of the TACHRON production environment at the Service Delivery Point of at least 99.9 % per Calendar Month (corresponding to a maximum of approx. 43 minutes of Downtime in a 30-day month).

4.2 Definition of "Available"

TACHRON is Available if the following Core Functions can be used at the Service Delivery Point in accordance with the Service Description:

1. upload of DDD Files via API and web interface;
2. retrieval of processed data and of infringement results;
3. retrieval and download of archived DDD Files; and
4. authentication and authorisation for the above functions.

A Core Function is deemed not Available in a Measurement Interval if the synthetic monitoring checks of that function under Section 4.3.1 fail, i.e. return a server-side error (HTTP 5xx), no response within 30 seconds, or an incorrect result. These criteria refer exclusively to the synthetic monitoring checks, not to Client's production traffic. Degraded performance that does not meet these criteria is not Downtime but may constitute an Incident under Section 6.

4.3 Measurement and Calculation

4.3.1 Provider measures Availability by automated synthetic monitoring: defined test requests are sent to each Core Function at the Service Delivery Point once per Measurement Interval. Each Measurement Interval in which a Core Function is not Available (Section 4.2) counts as one minute of Downtime. If Client reports an Incident affecting a Core Function that the synthetic monitoring did not detect, the period from the properly submitted report until restoration also counts as Downtime, provided Provider confirms the unavailability on the basis of its system logs.

4.3.2 Availability is calculated as follows:

Availability (%) = (Scheduled Service Time − Downtime) ÷ Scheduled Service Time × 100

4.3.3 Provider's monitoring data, as published on the Status Page, are used as the basis of calculation. Client may provide evidence of further Downtime (e.g. its own monitoring logs); Provider will take such evidence into account in good faith.

4.4 Planned Maintenance

4.4.1 Standard maintenance window: Sundays, 05:00 to 09:00 local time Germany (CET/CEST). Provider will use this window only as needed; during it, TACHRON may be temporarily unavailable or degraded.

4.4.2 Additional planned maintenance outside the standard window shall be announced at least five (5) Business Days in advance by e-mail and/or via the Status Page, shall be scheduled outside Business Hours where reasonably possible, and shall not exceed four (4) hours per Calendar Month. Planned maintenance exceeding these limits or announced at shorter notice counts as Downtime.

4.4.3 Emergency maintenance (e.g. to remedy critical security vulnerabilities) may be carried out at short notice. Emergency maintenance counts as Downtime unless it is required due to circumstances listed in Section 9.

4.4.4 Uploads submitted during maintenance shall either be rejected with a defined error code permitting automatic retry by Client or be queued and processed after the maintenance; no accepted data shall be lost.

4.5 Data Location

Client data (including DDD Files, derived data and backups) are stored and hosted exclusively in data centres located in the European Union / European Economic Area (AWS regions Frankfurt and Ireland). Access from, or transfer to, countries outside the EU/EEA (including remote access by sub-processors for support purposes) takes place only in accordance with the DPA and Chapter V GDPR. For Clients established in the United Kingdom, storage in the EU/EEA is based on the UK adequacy regulations for the EEA (UK GDPR). Details, including the list of sub-processors, are set out in the DPA. Information on the jurisdiction to which the ICT infrastructure used is subject and on the measures against unlawful international governmental access to non-personal data (Art. 28 Data Act) is published in the Privacy Policy at https://www.tachron.eu/legal/privacy-policy/.

5. Performance Objectives

5.1 In addition to Availability, Provider monitors the following performance objectives (KPIs). They are measured by Provider in the production environment. Unless expressly stated otherwise, they are target values; failure to meet them does not trigger Service Credits, but Provider shall analyse the causes and take reasonable remedial measures. Client's statutory rights in the event of defects remain unaffected.

5.2 Systematic errors in the application of rule sets (i.e. errors affecting a rule set as such, not merely individual records owing to incorrect source data) are Incidents of severity High, or Critical if they affect all Clients and render infringement results unusable. After correction, Provider shall re-evaluate the affected data free of charge for the retention period, where technically feasible.

6. Support and Incident Management

6.1 Support Channels and Support Hours

Support is provided in German and English. Client shall designate up to three (3) trained contact persons authorised to submit Incident reports. Support is second-level support for Client; support for Client's customers and drivers is provided by Client.

6.2 Severity Levels

The severity level is proposed by Client when submitting the report and determined by Provider in reasonable discretion on the basis of the objective impact; Provider will inform Client of any reclassification, giving reasons.

6.3 Response and Restoration Times

6.3.1 Times run only during the stated service hours. Response Times are binding commitments; Restoration Times are targets that Provider will make every reasonable effort to achieve. Restoration may be effected by a workaround; in that case the Incident is reclassified to a lower severity until the permanent fix.

6.3.2 For Critical and High Incidents, Provider will publish status updates on the Status Page at least every 60 minutes (Critical) or every 4 Business Hours (High). For Critical Incidents, Provider will additionally provide Client with a written root-cause analysis (post-incident report) within five (5) Business Days after restoration.

6.3.3 Times are suspended for as long as Provider is waiting for information or cooperation from Client that is necessary to resolve the Incident.

6.4 Client Cooperation

Client shall report Incidents without undue delay via the designated channels, describing them as precisely as possible (time, affected endpoints, request IDs, example files, error messages), perform reasonable first-level analysis within its own systems and grant Provider the access to information necessary for analysis. Section 4 GTC applies in addition.

7. Escalation

If an Incident is not progressing as required, either Party may escalate it. For Critical and High Incidents, Provider escalates automatically as follows:

Provider will inform Client of the current escalation level on its own initiative for Critical Incidents and otherwise upon request. Each Party shall notify the other in text form of changes to its escalation contacts (Annex 2).

8. Service Credits

8.1 Amount

If the Availability in a Calendar Month falls below the committed Availability under Section 4.1, Client receives the following Service Credit, calculated on the basis of the Reference Fee (Section 2) for the affected TACHRON subscription:

8.2 Claim Procedure

8.2.1 Provider determines the Availability for each Calendar Month on the basis of its monitoring data (Status Page). If a Service Credit has arisen, Provider notifies Client by e-mail within ten (10) Business Days after the end of the Calendar Month, stating the Availability achieved and the amount of the Service Credit.

8.2.2 If Client considers that a Service Credit has arisen that was not notified, Client may claim it in text form within sixty (60) days after the end of the affected Calendar Month, stating the dates and times of the Downtime. Provider will review the claim within ten (10) Business Days and notify Client of the result by e-mail.

8.2.3 Service Credits are set off against the next invoice(s) by way of a credit note or corrected invoice in accordance with applicable VAT law; any amount exceeding the next invoice is carried forward to subsequent invoices. Service Credits are not paid out, including upon termination of the Agreement. Client's statutory rights pursuant to Section 8.5.2 remain unaffected.

8.3 Cap

Service Credits are capped at 50 % of the Reference Fee per Calendar Month. This cap applies only to Service Credits and does not limit the rights set out in Section 8.5.

8.4 Extraordinary Termination for Repeated Failure

If Availability falls below 99.0 % in three (3) consecutive Calendar Months, or below 98.0 % in any two (2) Calendar Months within a period of six (6) Calendar Months, Client may terminate the affected TACHRON subscription for cause, irrespective of whether it has been concluded on a monthly basis or for a fixed or minimum term. Termination must be declared in text form within sixty (60) days of the end of the last relevant Calendar Month and takes effect on the date specified by Client, but no later than thirty (30) days after receipt of the notice.

In the case of subscriptions with a fixed or minimum term, Client is released from all payment obligations for the period after termination takes effect; fees paid in advance for that period are refunded pro rata. In the case of monthly subscriptions, Client's right of ordinary termination remains unaffected. Sections 10.5 and 10.6 apply.

8.5 Relationship to Other Claims

8.5.1 Service Credits constitute a lump-sum reduction of the fees for the failure to meet the committed Availability. Their receipt does not require proof of damage by Client.

8.5.2 Client's statutory rights and rights under the Agreement in the event of defects or breach of contract, in particular to claim damages and to terminate for cause, remain unaffected. Service Credits shall be credited against any reduction in fees (Minderung) and any damages claimed for the same Downtime.

8.5.3 Liability for damages is governed exclusively by the liability provisions of the Agreement (Section 6 GTC). Nothing in this SLA limits liability for intent or gross negligence, for injury to life, body or health, under the German Product Liability Act, under a guarantee, or for the breach of essential contractual obligations (Kardinalpflichten) to the extent mandatory under applicable law.

9. Exclusions

9.1 The following periods and events do not count as Downtime and do not give rise to Service Credits, to the extent that the unavailability is caused by them:

• Planned Maintenance within the limits of Section 4.4;
• force majeure, i.e. events beyond Provider's reasonable control which could not have been prevented by reasonable precautions, such as natural disasters, epidemics, war, terrorism, riots, embargoes, official orders, industrial action (other than at Provider or its sub-processors), or large-scale outages of public power or communication networks;
• malicious attacks (e.g. DDoS) on Provider's infrastructure, provided Provider has taken protective measures in accordance with the state of the art and the technical and organisational measures (TOMs) agreed in the DPA;
• causes in Client's sphere, in particular Client's systems, software, networks and internet connectivity, use contrary to the Agreement or the API documentation (e.g. exceeding agreed rate limits), or unauthorised use of Client's credentials, unless attributable to Provider;
• third-party services and applications integrated or used by Client that are not part of TACHRON (e.g. Client's internet service provider or messaging platforms);
• suspension of the service by Provider in accordance with the Agreement (e.g. justified suspension for a serious security risk or material payment default after prior notice);
• test, staging, sandbox, trial, beta or pilot environments and features designated as such.

9.2 Sub-processors and suppliers engaged by Provider (e.g. hosting and cloud providers) are not third parties within the meaning of Section 9.1; their failures are attributable to Provider unless they themselves constitute force majeure.

9.3 Provider shall notify Client without undue delay of the occurrence of an exclusion event and use reasonable efforts to minimise its effects.

10. Data Security, Backup, Data Retrieval and Switching

10.1 Security incidents. Provider shall notify Client of personal data breaches as soon as possible, and in any event no later than forty-eight (48) hours after becoming aware of them (Art. 33(2) GDPR / UK GDPR), in accordance with the DPA. Where not all information is available at that time, it may be provided in phases without undue further delay, so that Client and its customers can meet their obligations under Art. 33 and 34 GDPR / UK GDPR. Further security obligations are set out in the DPA and its TOMs.

10.2 Other security incidents. Irrespective of whether personal data are affected, Provider shall inform Client of significant security incidents affecting TACHRON that are likely to impair Client's use or the security of Client data as soon as possible, and in any event no later than forty-eight (48) hours after becoming aware of them (initial notification), followed by updates as the analysis progresses and a final report after the incident has been closed. This enables Client to meet any reporting obligations of its own (e.g. under Directive (EU) 2022/2555 (NIS2) and its national implementations, or the UK NIS Regulations).

10.3 Backup and business continuity. Provider performs encrypted backups of Client data at least daily, retains them for thirty (30) days, stores them in a geographically separate EU/EEA location (replication between the AWS regions Frankfurt and Ireland) and performs restore and disaster recovery tests in accordance with the Business Continuity Plan (BCP), at least once per calendar year.

10.4 Recovery objectives in the event of a Disaster: Recovery Point Objective (RPO) of no more than 24 hours and Recovery Time Objective (RTO) of no more than 36 hours. Original DDD Files acknowledged as received shall not be lost. In the event of a Disaster, the RTO applies instead of the Restoration Times under Section 6.3; the resulting unavailability counts as Downtime unless Section 9 applies.

10.5 Data export and retrieval period. During the term of the Agreement or the affected subscription, Client may at any time export all DDD Files and derived data in a structured, commonly used and machine-readable format via the open, documented API (devportal.tachron.eu), free of charge. After the end of the term, Client has a retrieval period of thirty (30) calendar days. During the retrieval period, access is limited to (a) reading and exporting infringement results, context data and other derived data (including activity timelines and driver answers) and (b) downloading or deleting DDD Files; no new DDD Files can be uploaded or evaluated. Provider will remind Client by e-mail at least thirty (30) days before the end of the term. After the retrieval period has expired, Provider erases Client data in accordance with the DPA, unless statutory retention obligations apply. Client is responsible for securing archived DDD Files that its customers must retain. Section 3.5 and Section 7.3 GTC apply accordingly.

10.6 Switching (Data Act). Provider grants the following switching rights to all Clients, irrespective of their seat and of whether Chapter VI of Regulation (EU) 2023/2854 (Data Act) applies in the individual case. Client may request, with a notice period of no more than two (2) months, to switch to another provider or to port its exportable data to its own infrastructure; this right exists irrespective of an agreed fixed or minimum term. Following the notice period, a transitional period of no more than thirty (30) calendar days applies, during which the service continues with due care, a high level of security is maintained and Provider provides reasonable assistance, including information on known risks to continuity. The Agreement for the affected subscription ends upon successful completion of the switching process; if Client requests the erasure of its data instead of switching, it ends at the end of the notice period. Provider confirms the end of the Agreement in text form. This is followed by the retrieval period under Section 10.5, with the access restrictions set out there. After the retrieval period has expired, Provider fully erases all exportable data in accordance with the DPA. The categories of exportable data are listed exhaustively in Annex 3; the data structures, formats and standards are documented in an up-to-date online register at devportal.tachron.eu (Art. 26 Data Act). Provider does not charge any switching or data egress charges. Section 3.6 GTC applies accordingly.

11. Status Page

11.1 From the Effective Date, Client has access to the Status Page. The Status Page shows the current and historical availability of the TACHRON APIs and systems, current and resolved Incidents and planned maintenance. Historical data are available for at least the preceding twelve (12) Calendar Months.

11.2 Provider does not provide periodic performance reports or service review meetings. Service Credits are notified by e-mail in accordance with Section 8.2.

12. Amendments and Term

12.1 This SLA enters into force on the Effective Date and remains in force for the term of the Agreement.

12.2 Amendments to this SLA require text form (e.g. e-mail) and the agreement of both Parties. Provider may update technical details (e.g. support channels, monitoring methods) unilaterally, provided this does not reduce the service levels, Response Times or Service Credits to Client's detriment. Provider shall notify Client of such updates at least thirty (30) days in advance. The current version of this SLA is published at https://www.tachron.eu/legal/sla.

12.3 Governing law and jurisdiction. This SLA and the Agreement are governed by the laws of the Federal Republic of Germany, excluding the UN Convention on Contracts for the International Sale of Goods (CISG). The exclusive place of jurisdiction for all disputes arising out of or in connection with this SLA or the Agreement is Stuttgart, Germany (Section 9.3 GTC). This also applies to Clients established in the United Kingdom, Switzerland or other countries outside the EU/EEA. The Parties agree that this clause constitutes an exclusive choice of court agreement within the meaning of Art. 25 Regulation (EU) No 1215/2012 (Brussels Ia), Art. 23 of the Lugano Convention 2007 and the Hague Convention on Choice of Court Agreements of 30 June 2005. Mandatory statutory exclusive jurisdictions remain unaffected.

12.4 All further provisions are governed by the Agreement. Should any provision of this SLA be or become invalid, the validity of the remaining provisions shall remain unaffected.

12.5 This SLA is available in German and English. In the event of discrepancies between the two versions, the German version prevails.

Signatures

For Provider: Axveru GmbH Place, date: Aidlingen, 4/11/2026 Signature Name: Holger Karn Title: Managing Director

For Client: [Client legal name] Place, date: [place, date] Signature Name: [signatory name] Title: [signatory title]

Annex 1 – Service Description and Regulatory Coverage (Summary)

This Annex summarises the rule sets evaluated by TACHRON. The detailed and binding functional scope is set out in the current product and API documentation at devportal.tachron.eu. References are to the respective legal acts as amended.

Automatic rule derivation: TACHRON derives the applicable rule sets, vehicle types, journeys, home country, cabotage and posting situations from the DDD Files. The quality of the results depends on the completeness and correctness of the recorded data (including manual entries and country entries). Statutory working-time rules and sector-wide collective agreements are applied automatically; company agreements require configuration.

Annex 2 – Contacts

Annex 3 – Exportable Data (Art. 25(2)(e) and (f) Data Act)

The following categories of data constitute exportable data and can be exported via API in structured, machine-readable formats (e.g. original DDD binary format, JSON):

Excluded from exportable data, as they constitute Provider's intellectual property or trade secrets: the rule-engine logic and rule configuration, the reference test suite, internal scoring and quality metrics, and Provider's source code. This exclusion does not impede or delay the switching process.