Service Level Agreement

Version 1.0 -  Aug. 6, 2025

1. Scope

This Service Level Agreement ("SLA") is incorporated by reference into the Terms. The definitions of the Terms apply. The SLA defines the service levels, support commitments, and remedies applicable to the Service.

2. Customer Support for Software

Maintenance and technical support to the Customer are provided via the support helpdesk ("Support Helpdesk"). The Support Helpdesk is operated by the Company on working days (excluding public holidays at the Company’s business seat) between 8:00 am to 5:00 pm CEST.

The support and maintenance services include:  

  • Analyses of problem issues;
  • Support and advice on configuration issues, technological developments, and IT security in connection with the service-related software;
  • Elimination of functional and security defects;
  • Remediation of reported error messages ("Incident");
  • Support for the installation of updates.

The Company warrants the support and maintenance services of the delivered software for the entire duration of the Agreement. If the Company intends to reduce or discontinue the support and maintenance services for the delivered software, the Customer must be immediately informed about this and alternative solutions.

3. Minimal Performance Standards

For the support and maintenance services and the availability of the software, the parties agree on reasonable response times, troubleshooting times, and minimum availability. Incidents are reported via the Support  Helpdesk.

3.1. Availability

Unless otherwise agreed, the Company guarantees the availability of the software of at least

UDI Connect and UDI Hub

  • Essential and Professional: 99.5%
  • Enterprise: 99.9%

during 24 hours for 365 days a year.

Downtime (e.g., for maintenance of the software) announced by the Company within a reasonable period of time will not be charged to the availability of the software.

Uptime is calculated as follows:

Uptime (%) = (Total Minutes in a Month - Downtime Minutes) / Total Minutes in a Month * 100

The Company can use the following maintenance windows for Scheduled Downtime as listed below. The Company will provide Customer with reasonable notice without undue delay of any major upgrades or emergency maintenance to the Service.

  • Regular Maintenance Timeframe:
    Saturday 10:00 am - Saturday 12:00 pm CET
  • Major Upgrades Timeframe:
    Up to 4 times per year Saturday 08:00 am - Saturday 12:00 pm CET
3.2. Disorders, Response Time, and Troubleshooting Period

The response time is the time it takes for  the Company to acknowledge an Incident after it is reported by the Customer. Resolution time is defined as the time it takes for the Company to provide either a resolution, a (temporary) workaround or an action plan for an incident after it is acknowledged.

Incidents are categorized by severity:

  • Priority 1: An incident should be categorized with the priority “very high” if the problem has very serious consequences for normal business processes or IT processes related to core business processes. Critical business operations cannot be performed.  

             This is generally caused by the following circumstances:  

  • A productive service is completely down.
  • The imminent system Go-Live or upgrade of a production system cannot be completed.
  • The Customer's core business processes are seriously affected.

The incident requires immediate processing because the malfunction may cause serious losses.

  • Priority 2: An incident should be categorized with the priority "high" if normal business processes are seriously affected. Necessary tasks cannot be performed. This is caused by incorrect or inoperable functions in the Service that are required immediately.

              The incident is to be processed as quickly as possible because a               continuing malfunction can seriously disrupt the entire productive               business flow.

  • Priority 3: An incident should be categorized with the priority "medium" if normal business processes are affected. The problem is caused by incorrect or inoperable functions in the Service.
  • Priority 4: An incident should be categorized with the priority "low" if the problem has little or no effect on normal business processes. The problem is caused by incorrect or inoperable functions in the Service that are not required daily, or are rarely used.

The following response and resolution times apply:

Service Plan

Initial Response / Time to Resolution
(Prio 1)

Initial Response / Time to Resolution
(Prio 2)

Response Time (Prio 3 and 4)

UDI Connect and UDI Hub Essential

1 business day /
3 business days

2 business day /
5 business days

3 business days

UDI Connect and UDI Hub Professional

4 hours / 1 business day

1 business day /
3 busines days

3 busines days

UDI Connect and UDI Hub Enterprise

1 hour / 12 hours

4 hours /
1 business day

1 business day

3.3. Troubleshooting

Upon receipt of an Incident, the Company:

  • Provides an initial response, including notifying the Customer with a reference number, status, and estimated time for resolution.
  • Provides a solution, workaround, or temporary fix that restores functionality.
  • Resolves software errors within a reasonable time through repair or replacement by uploading an update.

An Incident is considered resolved and closed when:

  • The issue has been resolved at the discretion of the Company’s support experts.
  • The Incident was not the responsibility of the Company.
  • Both parties agree that the Incident was not an Incident.

The Customer is informed via the Support Helpdesk that the Incident has been resolved.

4. Remedies for Service Failures

If the Company fails to meet the Uptime Commitment, the Customer is entitled to service credits as follows: 2% of monthly subscription fees for each 1% below System Availability SLA, not to exceed 50% of monthly subscription fees. Service credits are the sole and exclusive remedy for failure to meet the Uptime Commitment.

Claims under this SLA must be made in good faith and by submitting a support case within 30 days after the end of the relevant month in which  the Company did not meet the System Availability SLA.

The Company’s Uptime Commitment does not include unavailability due to:

  • Customer actions: Use of the Service in a manner not authorized under the Terms of Service or this SLA.
  • Force Majeure events: Events outside the Company’s reasonable control, including but not limited to natural disasters, acts of God, cyberattacks, strikes, or other unforeseeable events.
  • Third-party dependencies: Issues caused by third-party equipment, software, or services not controlled by the Company.
  • Customer infrastructure: Problems arising from the Customer’s equipment, software, network connections, or other infrastructure.
  • Customer Data or Materials: Errors or unavailability caused by the Customer's data, configurations, or materials.
  • Third-Party Products: Issues related to integrations or third-party applications used in conjunction with the Service.
  • Scheduled Maintenance: Routine scheduled maintenance or emergency maintenance as notified to the Customer in accordance with Section 3.1.
  • Beta or Free Trials: Features or services explicitly identified as Beta, Free, or Experimental under the Terms of Service.

The Company will maintain a publicly accessible status page on its website at www.udihub.io/status, which provides real-time updates and historical data on the System Availability percentage of the Service, including any incidents or maintenance events. It is the Customer's responsibility to regularly check the status page for updates regarding the Service.

5. Quality Agreement

The Company holds and maintains certifications for its Quality Management System (QMS) according to ISO 9001 and its Information Security Management System (ISMS) according to ISO 27001. The continuous maintenance of these certifications is mandatory.  

5.1. Product verification

The Company has a robust Secure Software Development Lifecycle (SSDLC), Test management and proper Change Management in place to meet highest product standards. As part of its SSDLC, the Company performs a product verification according to GAMP5 principles for each release of the Service which is summarized in a product release verification report. All release and release documentation artifacts are kept within the Company’s development toolchain and are available on request.

5.2. Backup and (Disaster) Recovery

The Company’s applications hosted on Amazon Web Services (AWS) store data using AWS-managed services, including Relational Database Service (RDS) and Simple Storage Service (S3).

Data backups are facilitated by AWS Backup service, which continuously backs up data in response to every data change.

Backups are retained for 35 days and stored in a geographically separate location within the European Union (EU data center) to ensure compliance with regional data protection regulations.

In the event of a data loss, restoring data can be initiated via the AWS Backup service and must be requested by contacting he Company through the Support Helpdesk.

To minimize potential data loss, both backup and restore procedures follow the guidelines below:

  • Backup Retention Period: 35 days
  • Backup Location: EU data center
  • Supported Services: AWS RDS and AWS S3

The Company has implemented a comprehensive Disaster Recovery Plan (DRP) to respond effectively in the event of emergencies, service outages, or major disruptions.

The Disaster Recovery Plan is subject to annual testing as part of the Provider’s Business Continuity Management (BCM) process to ensure ongoing effectiveness.

The following metrics reflect the Provider’s Recovery Time Objective (RTO) and Recovery Point Objective (RPO) for critical AWS components:

AWS Component

Recovery Time Objective (RTO)

Recovery Point Objective (RPO)

AWS RDS

24 hours

Near-Realtime
(Typically under 1 second)

AWS S3

24 hours

Near-Realtime
(Typically under 1 second)

5.3 Audit Right

Customer who have subscribed to the Enterprise service plan and/or their designated agents and/or auditors (internal and external), shall have the right to inspect, examine and audit the systems, records, data, service locations, practices and procedures of the Company that are used to provide the Services or Products, but not more than once every twelve months. The Company shall fully cooperate with Customer, its auditors and regulators in conducting audits.

All audits under this Section shall be subject to the following terms:

  • Customer must provide the Company at least sixty (60) days advance of any audit unless mandatory law or a competent Regulatory Body requires shorter notice.
  • The scope of any audit must be mutually agreed between the parties acting reasonably and in good faith. The parties will use current certifications or other audit reports to avoid or minimize repetitive audits.
  • Audits will be limited in time to a maximum of one (1) business day and must not interfere with the Company’s business operations or certifications. The Customer must, to the extent possible, rely on audit reports or other certifications or verifications available to avoid or minimize repetitive audits.
  • Customer may conduct the audit at a Provider office in Bad Hersfeld, Germany or remotely under reasonable time and manner conditions.  

6. Customer’s Responsibilities

When the Customer creates an account for the Service, an account for the Support Helpdesk will be automatically created for them. The Customer is responsible for managing their incidents via the Support Helpdesk, which includes searching for known solutions in available documentation and liaising with the  Company in the event of new problems.

To receive support services, the Customer will reasonably cooperate with the Company to resolve support incidents and will have adequate technical expertise and knowledge of their configuration of the Services to provide relevant information (e.g. reference ID, screenshots) to enable the Company to reproduce, troubleshoot and resolve the experienced error.

The Customer shall take reasonable measures to secure their access credentials and prevent unauthorized access to the Service. The Customer is responsible for any actions taken using their credentials.

The Customer is responsible for ensuring that their systems, software, and network configurations are compatible with the requirements of the Service.

Join our newsletter to stay up to date on features and releases.
By subscribing you agree to our Privacy Policy and provide consent to receive updates from our company.
Thank you! Your subscription is confirmed.
Oops! Please try again later.
© 2025 p36 GmbH. All rights reserved.