Service Level Agreement

1. Introduction and Scope

This SLA defines the performance standards, response times, and service objectives for the support of the BlueID services. It forms the contractual basis for the provision of support services based on the incident classifications and service level definitions set forth in this document.

2. Definition of Incident Classifications

Incidents are categorized into four classifications to enable differentiated handling:

P1 – Critical: Incidents that completely impair the use of the solution (e.g. system outages or security breaches requiring immediate action). Example: Total service outage, critical security vulnerability.

P2 – High: Incidents that severely affect essential functions, yet do not immediately halt operations. Example: Functional disruptions that restrict core functionalities.

P3 – Medium: Incidents with moderate impact that cause errors but do not significantly restrict operations. Example: Non-critical errors, configuration issues.

P4 – Low: Incidents that have only minor impact on usage. Example: Cosmetic errors or display issues, queries regarding functionality without significant impairment.

3. Support Level and Response Times

The response time refers to the maximum period required by the service provider to respond to a reported incident during the agreed support hours. This includes the initial feedback to the customer as well as the initiation of preliminary actions for problem analysis. MTTR (Mean Time To Repair) represents the average time needed to fully resolve an incident—from the detection of the error through diagnosis to the restoration of the affected service.

The following table shows, for each incident classification, first the response time (upper row) and then the MTTR (lower row):

4. Availability and Operating Hours

4.1 Service Availability

The service is provided with an uptime of at least 99.50%. The accessibility and functionality of the services are monitored every minute by an independent service. The uptime is calculated on a rolling basis over the past 12 months.

4.2 Availability Targets by Incident Classification

• P1: For critical incidents, an initial response is provided within one business day, with the service being prioritized in recovery measures.
• P2 to P4: The recovery periods correspond to the aforementioned MTTR targets.

5. Communication Channels and Support Hours

5.1 Communication Channels

Support is provided primarily via a ticket system. For P1 incidents, telephone contact is additionally provided.

5.2 Support Hours

Support services are rendered on business days from 08:00 to 17:00.

6. Escalation and Monitoring Process

6.1 Escalation Procedure

Should an incident not be resolved within the agreed time, an escalation process will be initiated. This involves a reassessment of the incident and, if necessary, direct involvement of a Senior Engineer.

6.2 Reporting

A dashboard is provided to the customer within the ticket system, through which the status of all reported incidents can be viewed. Regular reports support the monitoring of SLA compliance.

7. Software Updates, Upgrades

7.1 Simultaneous Deployment for Web Applications, Portal, and API

Changes, software updates, and upgrades for the web app, the portal, and the API are deployed simultaneously and to all customers at the same time. This ensures that the service remains continuously up to date and is uniformly available to all users.

7.2 Firmware and SDK Updates

Firmware and SDK updates are also released simultaneously. However, the integration and implementation of these updates is solely the responsibility of the customer.

7.3 Duty to Inform

The provider ensures that all relevant information regarding new releases and associated changes is published promptly, so that the customer is informed in a timely manner of any necessary actions.

8. Compensation Provisions

8.1 Principle

If the agreed service levels for rates starting from “Smart” are not met, a proportional credit will be applied in the form of a reduction of the monthly fees for the following month. The credit is calculated based on the percentage ratio of the actual downtime to the average month length (30 days).

8.2 Measurement and Verification

The downtime is determined via an external monitoring tool that checks the accessibility and functionality of the services on a minute-by-minute basis. A credit is only granted if the affected customer has opened a specific ticket to confirm the downtime.

8.3 Calculation

The percentage credit corresponds to the ratio of the measured downtime to 30 days. For example: 4 downtime days / 30 days = 13.3% (commercially rounded: 13% reduction). If an incident constitutes an SLA breach, the credit is applied once in the following month in which the breach is first identified. Should the same incident persist in subsequent months, no repeated credit will be applied. If, in later, independent periods, SLA breaches occur again, a one-time credit will be granted for each of these separate incidents in the corresponding following month.

8.4 Exclusion for Free Rates

Customers using the Free rate are generally not entitled to compensation or credits.

8.5 Limitation

With this provision, all claims arising from non-compliance with the service levels are settled, unless mandatory legal provisions provide otherwise.

9. Term and Final Provisions

9.1 Term

This SLA becomes effective upon the commencement of the framework agreement and shall remain valid for the entire duration of the respective contract.

9.2 Amendments

Any amendments to this SLA must be made in writing and require mutual agreement. Should any provision be deemed invalid, the remaining provisions shall remain in full force and effect.

9.3 Translations

If this SLA is translated into other languages, or if any ambiguities or inconsistencies arise between different language versions, the German version shall be authoritative.