General terms and conditions and service level agreements

Terms and conditions of secunet
Cloud (aaS and Managed Services)

1. General Terms and Conditions Cloud

As of: 14/11/2025

§ 1 General

Secunet refers to secunet Security Networks AG as well as secunet International GmbH, stashcat GmbH, and SysEleven GmbH, in which secunet Security Networks AG directly or indirectly holds at least 50% of the shares or voting rights. The respective contract is concluded exclusively between the relevant secunet company (hereinafter referred to as “secunet”) and the respective contractual partner. Any contractual obligation or liability on the part of other secunet companies are excluded, unless expressly agreed otherwise in writing.

§ 2 Subject matter of the contract Cloud

  1. Under this contract (framework agreement), secunet offers the contractual partner the option for the temporary use of the contractual service in return for payment.
  2. The specific content of the contractual service owed by secunet in detail is set out in the individual contract.

§ 3 Provision of the contractual service

  1. secunet provides the contractual services (IT services) for the contractual partner on its own public cloud platforms. Resources are used in accordance with a fair use model. secunet does not guarantee a minimum level of resources. The contractual partner shall use the contractual services of the public cloud in such a way that the use of the contractual services of other contractual partners is not affected. secunet reserves the right to take measures in the event of misuse in order to protect the availability of other contractual partners and their projects.
  2. When providing the contractual service, secunet shall ensure that sufficient capacity is available to cover the contractual partner’s higher requirements at short notice within the usual ranges. Requirements that exceed this will be met subject to availability. The contractual partner may at any time submit a binding request to secunet for an increase in the capacity of the contractual service it uses, with a lead time of two (2) months.
  3. Insofar as secunet provides the contractual service on its infrastructure, this shall take place at the interface of the data network within which the contractual service runs (transfer point) to other networks. secunet is not responsible for establishing and maintaining the data connection between the contractual partner’s IT system and the transfer point.

§ 4 Rights of use for cloud

  1. secunet grants the contractual partner a simple right of use that is limited in terms of content to the purpose of the contract and in terms of location to the place of contractual use, limited in time to the duration of the contract, and non-transferable, unless otherwise expressly agreed between the contractual partner and secunet.
  2. secunet is entitled to update its service and provide the contractual partner with a new version instead of the version provided for use at the start of the contract, provided that the change is reasonable for the contractual partner. The change is reasonable for the contractual partner if the contractual service is not fundamentally altered and is acceptable to the contractual partner in view of the circumstances. In this case, the new version shall constitute the contractual service and shall be subject to the provisions of this contract, and the contractual partner’s rights under this contract with regard to a previously provided contractual service shall expire even without an express request for return. The changes relate, for example, to updates/upgrades of underlying software and will be notified to the contractual partner prior to their implementation if negative effects on the contractual service (e.g., availability, features) are to be expected. If changes are made unplanned, e.g., for security reasons, the contractual partner will be informed as soon as possible. The contractual partner shall have no claim to a newer version of the contractual service originally provided.
  3. Without secunet’s consent, the contractual partner is not entitled to make changes, extensions, or other modifications to the service (within the meaning of Section 69c No. 2 UrhG) or to decompile (within the meaning of Section 69e UrhG) the service insofar as this exceeds what is legally permissible. The above provisions of this section on the granting of rights, secunet’s right to update, and the reservation of consent shall apply equally if and to the extent that work results have been developed on behalf of the contractual partner.
  4. Furthermore, unless expressly agreed otherwise with secunet, the contractual partner is not entitled to obtain further business secrets by observation, investigation, dismantling, or testing (“reverse engineering”) insofar as the software provided is not publicly available.
  5. Insofar as the contractual partner provides secunet with protected content (e.g., graphics or programs protected by copyright or trademark law, hereinafter referred to as “contractual partner materials”), the contractual partner grants secunet a simple right of use, limited in terms of content to the purpose of the contract, limited in terms of location to the place of contractual use, and limited in terms of time to the duration of the contract, for the performance of the contractual service.
  6. The Contractual Partner warrants that it holds all necessary rights to the Contractual Partner Materials provided in order to grant secunet the corresponding rights. If the Contractual Partner does not hold the necessary rights, it shall obtain the necessary rights.
  7. secunet is entitled to block access to the user account created for the use of the contractual service if there are indications that the access data of the user account has been compromised. In this case, secunet shall inform the user via the contact information stored by the user in the user account.

§ 5 Rights of use for work results

  1. If copyright-protected work results are created by secunet within the scope of this contract, all rights of use thereto shall be exclusively reserved to secunet, including rights to register industrial property rights.
  2. If copyright-protected work results arise at secunet within the scope of this contract, secunet grants the contractual partner a simple right of use limited in terms of content to the purpose of the contract and in terms of location to the place of use specified in the contract, limited in time to the duration of the contract, provided that this does not conflict with any legal restrictions and/or rights of use of third parties and no further rights of use have been expressly agreed in writing between the contractual partner and secunet with reference to this provision.
  3. If and to the extent that a database or database work is created during the term of the contract, in particular through the compilation of application data, through permitted activities of the contractual partner, all rights thereto shall be vested in the contractual partner.

§ 6 Terms of use for the cloud

  1. The contractual partner shall not use secunet’s contractual services in any way that compromises the contractual services provided by secunet to the contractual partner or that results in secunet’s performance vis-à-vis its contractual partner being restricted.
  2. The contractual partner is obliged to observe the following terms of use:
    a) The contractual partner shall not use secunet’s contractual services for abusive and/or illegal purposes or to an extent that jeopardizes public safety. Abusive purposes include, in particular, the distribution, downloading, or publication of content and/or activities that may violate or impair the rights of third parties. Abusive purposes also include the publication and distribution of depictions of sexual abuse, content that is likely to harm the welfare of children and young people and/or seriously endanger their morals, cyberstalking, content that serves to incite hatred or terrorism, that incites criminal acts or is illegal for any other reason.
    b) If and to the extent that secunet becomes aware of a violation of the Terms of Use, secunet will block and/or remove the relevant content. Secunet shall be deemed to have become aware of such violations if it is requested by the competent authority to block or remove certain content. Secunet shall also be deemed to have become aware of such violations if a user reports content that violates the Terms of Use. Secunet does not moderate content on its services.
    c) To the extent permitted by law, secunet will inform the contractual partner about the blocking/removal of their content.
    d) If secunet becomes aware of this due to a report from a user, it will examine the extent to which the blocking of the content will be maintained, taking into account all interests and ensuring proportionality.
    e) In the event of the blocking/removal of its content, the contractual partner is entitled to contest the decision.

§ 7 Third-party software products

  1. The contractual service includes third-party software components. The contractual partner undertakes to comply with the relevant license terms and conditions, which secunet will provide in advance if the contractual partner obtains this software from secunet and manages it independently.
  2. The contractual partner is aware that the license terms for third-party software components may be changed by the third party. If the change in the terms and conditions affects secunet’s provision of the contractual service to the contractual partner, secunet is entitled but not obliged to use an adequate substitute for the provision of the contractual service. secunet will inform the contractual partner of any changes in advance.
  3. If the software contains errors, secunet is entitled to provide a replacement solution.

§ 8 Contractual partner’s obligations to cooperate

  1. The contractual partner shall receive access data for accessing secunet’s contractual services and may, depending on the service, create and manage additional access data. All access data must be kept confidential at all times and may not be made available to unauthorized third parties. If the contractual partner suspects or becomes aware that its access data is being used without authorization, the contractual partner shall inform secunet immediately and make reasonable efforts to prevent unauthorized use. The contractual partner is responsible for all activities in connection with its access data.
  2. The contractual partner is responsible for ensuring that data is backed up properly and regularly in accordance with the state of the art. This shall be carried out outside the scope of secunet’s contractual services. In addition, the contractual partner is solely responsible for entering and maintaining the data and information required to use the software.
  3. secunet shall be released from its obligation to provide the agreed service if and to the extent that the contractual partner fails to fulfill its obligations to cooperate. Any existing schedules shall be automatically adjusted accordingly. If the contractual partner is responsible for the failure to cooperate and if secunet suffers damage as a result, the contractual partner shall compensate secunet for this damage.
  4. The contractual partner shall ensure that data stored on secunet systems is free of any malware.
  5. The contractual partner shall always use the latest versions of applications, tools, and software provided by secunet. If the contractual partner violates this obligation to cooperate, secunet shall be entitled to extraordinary termination.
  6. The contractual partner is fully responsible for updates within its area of responsibility. Before updating, the contractual partner shall ensure that it has the necessary backups for recovery and has checked that the new versions function correctly.
  7. If the contractual partner fails to fulfill its obligations to cooperate despite repeated reminders when updating the software within its area of responsibility, secunet reserves the right to carry out these updates. secunet will set the contractual partner a reasonable deadline for the update.
    secunet shall inform the contractual partner 30 days prior to an update carried out by secunet
    a) that and when an update will be carried out by secunet and
    b) to which new version of the software it will be updated.
  8. The contractual partner is obliged to report functional failures, malfunctions, impairments, and security incidents to secunet immediately and as precisely as possible. If the contractual partner fails to cooperate, § 536c BGB shall apply analogously.
  9. Any false reporting of security incidents shall have no negative consequences for the reporting party.
  10. secunet shall not be in default as long as the contractual partner fails to fulfill its obligation to cooperate in accordance with the contract. In all other respects, the statutory provisions shall apply.

§ 9 Disclosure of License and Terms of Use

If the contractual partner is entitled to grant a third party rights of use to the contractual service, it is obliged to ensure that the end customer is obliged to comply with the license and usage conditions. The granting of rights of use to the contractual service to a third party is only permitted with the prior consent of secunet.

§ 10 Contract term and termination Framework agreement

  1. This contract is concluded for an indefinite period and begins with the conclusion of the so-called onboarding service.
  2. Termination of the framework agreement requires the deletion of the organization in the onboarding service. The deletion of an organization is carried out by the last remaining user of an organization. Deletion of the organization is only possible upon termination of all individual contracts, with the restriction that the termination of the framework agreement only becomes effective upon termination of the last remaining individual contract.
  3. The right to extraordinary termination remains unaffected. secunet has an extraordinary right of termination in particular if
    a) the contractual partner fails to properly fulfill its obligations under this contract despite prior written warning and setting of a reasonable deadline, or
    b) if the contractual partner violates the terms of use. This applies in particular if the blocking/removal of the content is due to an official or court order or
    c) the contractual partner fails to meet its payment obligations despite a reminder after invoicing, or
    d) if the contractual partner has filed for insolvency proceedings or
    e) if insolvency proceedings have been opened against the contractual partner’s assets or the opening of such proceedings has been rejected due to lack of assets.

§ 11 Contract term and termination Commitment and On-Demand

  1. The term of use of the contractual service is based on the agreement in the contract and begins with the provision of the contractual service. If an automatic extension of the term of a contractual service has been agreed, this is based on the agreement in the contract.
  2. The notice period is based on the agreement made in the contract. If no notice period has been agreed, the following applies: If a commitment of at least twelve (12) months is agreed in a contract, the term is extended by a further twelve (12) months if the contract is not terminated in writing with six (6) months’ notice to the end of the term. If the use of on-demand services is agreed in the contract, no fixed term is agreed. The contractual partner may terminate the use of the on-demand service at any time without notice.
  3. Termination of a contract or termination of the use of the on-demand service shall not be equated with termination of the framework agreement.
  4. The provision on extraordinary termination of the framework agreement applies accordingly.
  5. If the contractual partner wishes to switch to a cloud solution from another service provider before the end of the contract term or transfer all exportable data and/or digital assets to the contractual partner’s own infrastructure, the Special Conditions for Cloud Switching in the secunet Group (EU Data Act) shall apply in addition.

§ 12 Termination

  1. Upon termination of the right of use, the contractual partner shall immediately cease using the contractual service.
  2. The contractual partner is obliged to return or delete any contractual service provided to secunet immediately after termination of the right of use or, if and as long as it is legally obliged to store it for a longer period, immediately after expiry of the storage period. This also applies to all copies made by the contractual partner for this purpose. Upon request, the contractual partner must provide secunet with written confirmation that this has been done. In the event of termination of the contract or withdrawal from the contract, this paragraph shall apply accordingly.
  3. Termination of use of services shall result in the deletion of the data generated or stored therein. Unless otherwise agreed in the contract, the contractual partner shall have the option at any time to download its data itself in the usual format(s) offered by the service before termination of use and to back it up outside the contractual services of secunet or in suitable storage offerings from secunet.
  4. Upon request, secunet may cooperate with the contractual partner and/or the third party designated by the contractual partner to ensure that no disruptions to service provision occur during the transition and that the contractual partner or the third party designated by the contractual partner is able to commence operation of the contractual services after the date of termination of the contract. In this respect, secunet may prepare and provide appropriate documentation. The contractual partner shall cooperate in this regard. Upon receipt of written notification that the contractual partner has been able to read and process all transferred data, the data shall be deleted from the systems in secunet’s data center and the contractual partner shall be notified of this deletion in writing (at least in text form).
  5. If the contractual partner uses the contractual service beyond the end of the contract period because a switch to its own IT systems or to another provider or for another reason was not implemented in time after termination of the contract, this use shall be remunerated until the final cessation of use. This continued use does not extend a terminated contractual relationship or constitute a new contract for the use of the contractual services.

§ 13 Offsetting and right of retention

The contractual partner shall only be entitled to offset claims if its counterclaims are undisputed or have been legally established. The contractual partner shall only be entitled to assert rights of retention on the basis of counterclaims arising from the same contractual relationship.

§ 14 Remuneration for cloud services

  1. Each contract is billed on a monthly basis.
  2. Billing is based on the prices specified in the contract or the price list valid at the time the service is ordered via the self-service portal, according to the volume consumed or the service booked. Invoice items whose amount is known in advance in the billing month are billed monthly in advance. Services that are billed according to consumption, such as traffic, are billed retrospectively in the following month. If services are billed according to time, the intervals can be found in the corresponding product descriptions. The service records are deemed to have been accepted if the contractual partner does not object to them within a maximum of ten (10) working days of receipt.
  3. Unless otherwise indicated, prices quoted by secunet are exclusive of the applicable statutory value added tax.
  4. In the case of agreed partial services and for partial invoices, the provisions regarding remuneration and pricing shall apply accordingly.
  5. Invoices are due for payment without deduction within thirty (30) days of receipt. The conditions and consequences of default are governed by the statutory provisions. If part of an invoice is disputed, the undisputed part must always be paid.

§ 15 Standard reporting channel

The contractual partner must submit all types of notifications by email tosupport@syseleven.de or via the ticket system. In urgent cases (malfunctions, security incidents, etc.), the notification must also be made by telephone to secunet’s emergency numbers:
+49 30 233 2012 30 (during service hours) or
+49 30 609 89 22 11 (24/7 emergency hotline)

§ 16 Incident management for malfunctions, security incidents, and vulnerabilities

  1. secunet provides regularly updated information about malfunctions, security incidents, and vulnerabilities (hereinafter referred to as “incidents”) on the status page if the affected contractual partners cannot be informed individually and directly.
  2. secunet acts at its own discretion when detecting and remedying incidents in services offered by secunet and used by the contractual partner. Depending on the severity of the incident, secunet reserves the right to take measures without prior notice or consultation with the contractual partner. These include, among other things:
    a) isolation of the affected systems,
    b) completely restricting the accessibility of contractual partner systems, or
    c) the shutdown of compromised services.
    This list is not exhaustive.
  3. If secunet becomes aware of security vulnerabilities in installations for which the contractual partner is responsible, secunet shall inform the contractual partner. The contractual partner is obliged to remedy the vulnerability promptly. If this does not happen, secunet reserves the right to take measures to protect its own systems.
  4. Once an incident has been resolved, secunet informs the affected contractual partners about the measures taken and any further steps that may be necessary.

§ 17 Cloud warranty

  1. secunet guarantees the functionality and operational readiness of the contractual service. Unless expressly stated otherwise below or in the contract, the statutory warranty provisions shall apply.
  2. secunet shall be liable for defects in the contractual service provided by secunet in accordance with the warranty provisions of tenancy law (Sections 536 et seq. BGB), but with the proviso that, contrary to Section 536a (1) BGB, liability for damages shall only exist in the event of fault in accordance with the provisions of the contract.
  3. Any defects must be reported immediately using the contact options available on the secunet website, providing a detailed description of the defect complained about. Complained defects must be reproducible.
  4. A defect exists if secunet does not perform the contractual service in accordance with the contract and this has a significant effect on the suitability for the use agreed in the contract.
  5. The contractual partner shall have no warranty claims
    a) in the case of only insignificant deviations from the agreed quality or only insignificant impairment of the usability of secunet’s contractual performance
    b) in the event of incorrect operation by the contractual partner
    c) in the event of the use of hardware, software, or other equipment of the contractual partner that is not suitable for the use of the contractual service
    d) if the contractual partner does not report a defect immediately and secunet was unable to remedy the defect as a result of the failure to report it immediately, or
    e) if the contractual partner is aware of the defect at the time of conclusion of the contract and has not reserved its rights with express reference to this provision.
  6. If a defect has been reported by the contractual partner and the contractual partner’s warranty claims are not excluded, secunet is entitled to remedy the defect within a reasonable period of time by taking measures of its own choosing. The contractual partner shall give secunet reasonable time and opportunity to remedy the defect. Subsequent performance shall also be deemed to have been fulfilled if the contractual partner is shown ways of avoiding the effects of the defect. An equivalent new program version of the software underlying the contractual service or an equivalent previous program version of the software underlying the contractual service that did not contain the error shall be adopted if this is reasonable for the contractual partner.
  7. If it is impossible or fails to remedy the defect, if there is a culpable or unreasonable delay, or if secunet seriously and definitively refuses to remedy the defect, the contractual partner is entitled in particular to reduce the remuneration owed in accordance with the extent of the impairment (reduction) if it asserts the credit balance specified in the contract within ten (10) days.
  8. If secunet provides services for troubleshooting or rectification upon request without being obliged to do so, it may demand remuneration for this in accordance with its usual rates. This applies in particular if a defect cannot be proven.

§ 18 Liability Cloud

  1. secunet shall be liable – regardless of the legal basis – for damages and reimbursement of futile expenses only in cases of intent or gross negligence or culpable breach of a material contractual obligation. In the event of a breach of a material contractual obligation, secunet’s liability shall be limited to typically foreseeable damage, except in cases of intent and gross negligence.
  2. The contractual partners’ liability for data loss is limited to the restoration costs that would have been incurred if the other contractual partner had made regular and appropriate backup copies and taken the necessary precautionary measures. Section 254 of the German Civil Code (BGB) remains unaffected.
  3. The above limitations of liability do not apply to injury to life, limb, or health, to statutory liability under the Product Liability Act, or to the assumption of a guarantee.
  4. The above limitations of liability shall also apply directly in favor of secunet’s employees, representatives, and vicarious agents.
  5. In the event that contractual services provided by secunet are used by unauthorized third parties using the contractual partner’s access data, the contractual partner shall be liable for any fees incurred within the scope of civil liability until receipt of the order to change the access data or notification of loss or theft, provided that the contractual partner is at fault for the unauthorized third party’s access.
  6. If a third party asserts against one contractual partner that a service provided by the other contractual partner infringes the rights of third parties, the one contractual partner shall notify the other immediately. The contractual partner who infringes the rights of a third party is entitled, but not obliged, to defend the asserted claims at its own expense, insofar as this is permissible. The other contracting party is not permitted to acknowledge claims by third parties without the prior consent of the contracting party that has infringed the rights of third parties, or to admit the underlying facts or to conclude a settlement in this regard.

§ 19 Special conditions for free trial

  1. If the contracting party uses secunet’s contractual services free of charge and exclusively for testing purposes (hereinafter referred to as “trial installation”), the trial installation shall be limited in time and shall be based on the term agreed in the contract.
  2. If a free trial has been agreed, no warranty shall be provided, insofar as this is legally permissible.
  3. Within the scope of the free trial of the service, the provider shall be liable in accordance with the statutory provisions of Sections 599 and 600 of the German Civil Code (BGB).

§ 20 Limitation period

All claims arising from this contract shall become time-barred within a period of one year from the start of the statutory limitation period. This shall not apply to claims arising from liability for intent and gross negligence, in cases of malice, claims arising from the Product Liability Act and in cases of an assumed guarantee, as well as in cases of injury to life, limb or health.

§ 21 Confidentiality

  1. Confidential information is any information about facts relating to a business operation that is known only to a limited group of people, i.e., that is not public knowledge and should be kept secret due to the legitimate interests of the business owner, regardless of its nature and form. This includes, in particular, verbal information, letters, memoranda, reports, documents, studies, analyses, drawings, letters, computer printouts, software programs, specifications, data, graphic representations, tables, sound recordings, pictorial reproductions, and any type of copies of the aforementioned information for which the disclosing contracting party has taken appropriate confidentiality measures.
  2. The contracting parties shall treat confidential information as strictly confidential and shall not disclose it to third parties without the prior written consent of the other contracting party. None of the following companies shall be considered third parties: secunet Security Networks AG, secunet International GmbH, stashcat GmbH, and SysEleven GmbH, insofar as information must be made available to them by secunet in order to fulfill the purpose of the contract. The contracting parties may disclose confidential information to employees who need the respective confidential information for the purposes of executing the contract, provided that the respective employee has undertaken to maintain confidentiality by signing a written confidentiality agreement.
  3. The above obligation does not apply to information that
    a) was already public knowledge at the time of receipt by the receiving contracting party;
    b) was already in the possession of the receiving contracting party at the time of receipt by the receiving contracting party;
    c) becomes public knowledge after receipt without the receiving contracting party’s involvement;
    d) becomes accessible from third parties without any obligation of secrecy and non-use, provided that these third parties have not received the information directly or indirectly from the receiving contracting party; or
    e) must be disclosed due to legal provisions, official or court decisions. The disclosing contracting party shall only inform the disclosing contracting party to the extent that legal provisions, official or court decisions require disclosure of confidential information.
  4. Unless the contracting parties have agreed otherwise, the confidentiality obligations under the provisions of this paragraph shall end five
  5. years after the termination of this contract.

§ 22 Data protection

The contracting parties shall comply with all laws, guidelines, and regulations applicable to them and secunet concerning data protection and data security. If personal data is entrusted to one contracting party, the other contracting party shall keep it confidential and protect it from misuse by taking appropriate technical and organizational measures. When processing or passing on personal data, the relevant data protection laws and the provisions of the contractual agreements with secunet shall be observed.
a) The contractual partner shall only employ staff who have undertaken to maintain confidentiality when handling personal data in order to fulfill their obligations. Corresponding declarations of commitment from employees must be submitted at secunet’s request.
b) The contractual partner is prohibited from processing, disclosing, making accessible, or using personal data without authorization for any purpose other than the lawful performance of its tasks.
c) The loss, unlawful transfer, or disclosure of personal data must be reported to secunet immediately at Datenschutz@secunet.com, as there may be information obligations.

§ 23 Compliance

  1. The contractual partner undertakes to comply with the provisions of the Code of Conduct for Suppliers and Business Partners (Code of Conduct for Suppliers and Business Partners) and, in particular, to observe the applicable legal regulations on combating corruption and the applicable antitrust laws.
  2. In the event of a breach of these obligations, the provider is entitled to terminate this contract without notice. The contractual partner shall indemnify the provider against all damages and claims by third parties arising from the breach and shall hold the provider harmless.

§ 24 Export restrictions

  1. The contracting parties are obliged to independently review and comply with all foreign trade regulations applicable to them, in particular import, export control, customs, and national, European, and international sanctions and embargo regulations. This applies both to independent exports or cross-border transfers, in particular resales, of deliveries and to cross-border delivery and service relationships.
  2. The contracting party responsible under foreign trade regulations must obtain any necessary (export) licenses from the competent authorities. It shall bear all customs duties, fees, and other charges incurred in connection with cross-border deliveries and services. secunet is not obliged to provide advice.
  3. Within the framework of their contractual relationships, the contracting parties mutually agree to regularly check their data for any entries on economic, financial, or trade-related sanctions lists in compliance with data protection regulations, in particular with regard to compliance with the above-mentioned sanctions and embargo regulations.
    With regard to the aforementioned sanctions list screening, the following also applies:
    (i). The contracting parties assure that neither they themselves nor their employees, nor any natural or legal persons in which they hold a direct or indirect majority ownership interest, are listed on any of the above-mentioned sanctions lists.
    (ii). The contractual partner is obliged to immediately notify secunet in writing (compliance@secunet.com) of any positive results confirmed during the check against the aforementioned sanctions lists.
    (iii). In the event of a positive screening result, secunet is entitled to terminate the contract for cause.
    (iv). The contractual partner shall indemnify secunet against all claims by third parties resulting from the breach of statutory and contractual obligations.
  4. In accordance with Council Regulation (EU) No. 833/2014, the following applies:
    a) The contractual partner may not sell, export, or re-export goods delivered under or in connection with this contract and falling within the scope of Article 12g of Council Regulation (EU) No. 833/2014, either directly or indirectly, to the Russian Federation, nor may it carry out such actions for use in the Russian Federation.
    b) The Contracting Party shall use all reasonable efforts to ensure that the purpose of paragraph 4 a) is not undermined by third parties in the commercial chain, including possible resellers.
  5. Any culpable breach of the preceding paragraph shall constitute a material breach of the provisions of this contract, and secunet shall be entitled to take appropriate measures, including, but not limited to:
    (i). Termination of this contract; and
    (ii). assertion of a contractual penalty amounting to 5% of the value of the goods sold, exported, or re-exported in violation of paragraph 4 a); and
    (iii). Assertion of a contractual penalty in the event of a breach of paragraph 4 b), whereby the amount of the contractual penalty shall be determined by secunet at its reasonable discretion in accordance with § 315 BGB (German Civil Code). The amount may be reviewed by a court in the event of a dispute. The contractual penalty shall be offset against claims for damages.
  6. The contractual partner shall immediately inform secunet of any problems in the application of paragraph 4, including any relevant activities of third parties that could frustrate the purpose of paragraph 4 a). Upon request, the contractual partner shall provide secunet with information on compliance with the obligations under paragraph 4 within two weeks.

§ 25 audit

  1. secunet or a third party commissioned by secunet shall be entitled to carry out audits at the contractual partner’s premises in order to verify the proper fulfillment of this contract and the individual contracts as well as the requirements of the Code of Conduct for Suppliers and Business Partners (Code of Conduct for Suppliers and Business Partners of secunet). In addition to observing the necessary security measures and any confidentiality obligations of the contractual partner towards third parties, secunet shall:
    a) notify the contractual partner of audits at least two weeks in advance,
    b) take into account the contractual partner’s operational processes,
    c) limit audits to the rooms and facilities affected by the subject matter of the contract,
    d) comply with data protection regulations and act on the premise of affecting the contractual partner’s trade and business secrets as little as possible.
  2. Any use of such secrets beyond what is necessary to enforce secunet’s contractual and legal claims against the contractual partner is prohibited.
  3. Each contractual partner shall bear its own costs of verification. However, the contractual partner shall also bear secunet’s costs if the verification reveals violations of this contract or legal provisions.

§ 26 Amendment of the contractual provisions

  1. secunet is entitled to amend individual provisions of the contract if there is a valid reason for doing so and the amendment is necessary for the continuation of the contract and reasonable for the contractual partner. A valid reason in this sense exists, among other things, if a change in the legal situation or the highest court ruling or doubts about interpretation that have arisen make it necessary to amend the provisions concerned. A valid reason also exists if a change in market conditions or other legal, economic, or technical conditions that was not foreseeable at the time the contract was concluded and over which secunet has no influence has occurred, leading to a disruption of the contractual equivalence and requiring an adjustment of the terms and conditions to restore equivalence.
  2. secunet shall notify the contractual partner of the upcoming changes in writing (e-mail) at least six weeks before the amended terms and conditions are scheduled to take effect. The contractual partner is entitled to object to the changes within six (6) weeks of receiving the notification. If the contractual partner does not object within the deadline and continues to use the service after the objection period has expired, the amended contractual terms and conditions shall be deemed to have been agreed. secunet shall inform the contractual partner of its right of objection and the consequences of not exercising this right in the notification of change.
  3. Provisions that affect the main performance obligations of the contracting parties and thus significantly change the relationship between main and counter-performance obligations, as well as other fundamental changes to the contractual obligations that are equivalent to the conclusion of a new contract, are excluded from the right to amend individual provisions of the contract. Such amendments require an express contractual agreement.

§ 27 Final provisions

  1. This contractual relationship is subject to German law, excluding the UN Convention on Contracts for the International Sale of Goods and the provisions of international private law.
  2. The courts in Germany shall have exclusive jurisdiction for all disputes arising from or in connection with this contractual relationship. However, secunet may, at its discretion, also bring an action before the courts competent for the contractual partner’s place of business.
  3. The establishment of this contractual relationship and all agreements that contain an amendment, supplement, cancellation, or specification of this contractual relationship—in whole or in part—must be made in writing. If this contractual relationship contains references to the written form, the written form may also be replaced by electronic form or text form, provided that no legally binding formal requirements apply. The text form requires an electronic signature using a software solution. The aforementioned formal requirement also applies to the amendment or cancellation of this text form clause.
  4. Should individual provisions of this contract be or become invalid or unenforceable, or should a loophole become apparent in this contract, this shall not affect the legal validity of the remaining provisions. To fill the gap, the contracting parties shall then agree on an appropriate provision which, as far as possible, comes closest to what the contracting parties would have agreed had they recognized the gap. This applies accordingly to invalid provisions that are not part of secunet’s General Terms and Conditions.
  5. Deviating, conflicting, or supplementary general terms and conditions shall not become part of the contract unless their validity is expressly agreed to in writing at least.
  6. Upon request by the other party, the contracting parties undertake to hand over or destroy all business documents and any business material, such as software copies, relating to the contract to the other contracting party in accordance with data protection regulations, at the latest upon termination of the contractual relationship, in compliance with the statutory retention periods. The deletion of the data must be confirmed to the other contracting party upon request. This does not apply to backup copies of electronic data traffic
  7. Even if this contract is written in English it has to be understood that it was prepared by German lawyers against a German commercial and legal background. If any term of the contract is open to interpretation, the intended German meaning shall prevail.

2. Special conditions for implementing the requirements of cloud switching in the secunet Group (EU-Data Act)

Status: 14/11/2025

The companies in the secunet Group (hereinafter referred to as “secunet”) offer various data processing services (hereinafter referred to as “contractual services”) for temporary use via web-based access in return for payment.
The following Special Terms and Conditions apply to agreements on the change of the respective contractual service within the meaning of the EU Data Act (REGULATION (EU) 2023/2854 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of December 13, 2023, on harmonized rules for fair data access and use and amending Regulation (EU) 2017/2394 and Directive (EU) 2020/1828 (Data Regulation)) between secunet and the contractual partner.

§ 1 Rights and obligations of the contractual partner

  1. The contractual partner is entitled to switch to another cloud solution offered by another service provider at any time or to transfer all exportable data and/or digital assets (hereinafter collectively referred to as “data”) to the contractual partner’s own infrastructure.
  2. The contracting party shall notify secunet of the change request at least in text form via the known contact option, without the need for a notice of termination.
  3. If the contract between secunet and the contractual partner for the originally agreed contractual service has been terminated in due time but the switch has not yet been successfully completed, the originally agreed service shall continue to be remunerated until the switch has been successfully completed. This continued use does not extend a terminated contractual relationship or constitute a new contract for the use of the services.

§ 2 ‘s obligations

  1. secunet shall provide the contractual partner or a third party authorized by the contractual partner or the new service provider commissioned by the contractual partner with appropriate support in completing the change.
  2. secunet shall continue to provide the contractual services originally agreed between the contractual partner and secunet until the changeover has been successfully completed. The changeover shall be deemed to have been successfully completed when the exportable and transferable data has been extracted and made available in a suitable manner for data retrieval. Data retrieval shall be carried out by the contractual partner itself, by a third party commissioned by it, or by the new service provider commissioned by it.

§ 3 Information obligations, transparency, technical aspects

  1. secunet shall provide information that supports the change of the contractual partner to the extent necessary and relevant. This includes, among other things, information
    • on the initiation of the change and change procedures,
    • machine-readable data formats that enable data export, including open interfaces and compatibility information (online register),
    • about known technical limitations and restrictions that may affect the change,
    The list of information is not exhaustive.
    The information is available at www.syseleven.de.
  2. secunet provides information via the above link about the jurisdiction to which the ICT infrastructure is subject, as well as a general description of the technical, organizational, and contractual measures that secunet has taken to prevent international government access to or international transfer of non-personal data stored in the Union.
  3. The contractual partner is aware that the transfer of data may pose risks to the uninterrupted provision of the agreed service. If and to the extent that secunet becomes aware of any potential risks, it will inform the contractual partner immediately.
  4. secunet will provide the contractual partner with a list of the data categories that may be transferred in the course of the changeover. In addition, secunet will inform the contractual partner of any data categories that are specific to the internal functioning of the originally agreed service and, due to their nature and characteristics, are not made available for export because of the risk of breach of trade secrets.

§ 4 Transfer periods

  1. The transfer process shall commence upon notification by secunet that the exportable data is available for export, but no later than two months after notification of the transfer request by the contractual partner (hereinafter referred to as the “transfer period”).
  2. If secunet is unable to comply with the transition period for technical reasons (hereinafter referred to as “technical impracticability”), it shall notify the contractual partner of this, stating the reasons, within 14 working days of notification of the change request. secunet is entitled to extend the transition period at its own discretion. The extension shall not exceed a period of seven months from notification of technical impracticability.
  3. If the contractual partner determines that it cannot comply with the transition period, it shall be entitled to extend the transition period once by a period that is reasonable for its own purposes. It shall inform secunet immediately of the extension of the transition period.
  4. After the transition period has expired, the data must be retrieved by the contractual partner or a third party commissioned by them or the new service provider commissioned by them (hereinafter referred to as the “data retrieval period”). The data retrieval period, which may not be less than 30 calendar days, begins at the end of the agreed transition period.

§ 5 Termination of the contract

  1. Once the changeover has been successfully completed, the contract is terminated and the contractual partner is informed of this by secunet. The changeover is deemed to have been successfully completed once the exportable and transferable data has been extracted and made available in a suitable form for data retrieval.
  2. The contract shall also be terminated if the contractual partner wishes to delete its exportable data and/or digital assets at secunet without the need for a change. The contract shall be terminated upon deletion, but no later than two months after the declaration of intent to delete.

§ 6 Standard service fees, lump-sum compensation

  1. The contractual partner was informed of the standard service fees (the remuneration to be paid) for the originally agreed contractual service before the contract was concluded. These can be found in the price list and/or the offer provided to the contractual partner. The originally agreed remuneration must be paid until the change has been successfully completed.
  2. If a contract was agreed between secunet and the contractual partner for the originally agreed service with a fixed term and/or fixed purchase quantities of resources (both hereinafter referred to as “commitment”) and this commitment is terminated prematurely due to the change request, secunet shall be entitled to claim the remuneration that would have been incurred until the end of the contract term, less any expenses saved, in the form of lump-sum damages.

§ 7 Exceptions for customer-specific adaptations; trial installation

  1. If most of the central functions of secunet’s standard services have been customized specifically to the needs of the contractual partner at the latter’s request, the contractual partner may not invoke secunet’s obligations under these Special Terms and Conditions. The same applies if the entire service has been developed specifically at the request of the contractual partner.
  2. If secunet provides support at the request of the contractual partner in connection with a change to a new service provider or to the contractual partner’s own infrastructure, secunet shall be entitled to claim the costs incurred in connection with the change.
  3. The contractual partner may not invoke the obligations of these Special Terms and Conditions if the agreed service was provided for testing and/or evaluation purposes (trial version) for a limited period of time, either for a fee or free of charge.

§ 8 Final provisions

These Special Terms and Conditions apply exclusively to change requests within the meaning of the EU Data Act of the contractual partner. They apply in addition to secunet’s General Terms and Conditions for Cloud Services.

SysEleven *aaS – product-specific terms and conditions for IT services in the “as-a-service” model

Last updated: 17 November 2025
This chapter provides a general description of services and procedures that apply for all products. We explain more about the individual products and their services in the specific product descriptions within the following chapters.
In some places, product descriptions may deviate from the general description. If there are deviating or contradictory descriptions, please orient yourself on this order of priority. Validity is defined in descending order of priority:
1.) Service level agreements
2.) Product-specific descriptions
3.) General information about the services


1.1. Product descriptions

Product-specific descriptions are contained in the individual chapters.


1.2. Registration

Each contracting partner may create or be assigned to multiple organisations. An organisation is the anchor point to which all other objects such as users or projects are assigned.
More details in this regard can be found in our documentation at https://documentation.syseleven.de/en/products/syseleven-iam/usage/organizations/
and https://documentation.syseleven.de/en/discover/core-concepts/iam/.


1.2.1. Registration self-service

The registration process is divided into the following steps:
a. Registration of user account – admin account
For registration, the user enters a work e-mail address, first and last name as well as password.
This initiates a double opt-in procedure. Clicking on the link provided in the confirmation e-mail concludes the user registration process.
b. Creating an organisation
After the user is registered successfully, an organisation is created. To create the organisation it is necessary to communicate the business name of the company, the company’s registered address and a billing address if this is not the same as the registered address.
Once the organisation has been created successfully, the organisation is released by us and the user is able to access the products. The user can consult the price list to find the prices for use. By creating the organisation, the user declares their authorisation to submit legally binding declarations on behalf of the company.
Please follow this description for registration:
https://documentation.syseleven.de/en/discover/get-access/
Note: Using a product requires the registration of at least one user.


1.2.2. Registration by us

If agreed upon and if usage is not exclusively based on a self-service model, registration can also be carried out by our employees. We will contact you for this purpose.


1.2.3. Registration of other users

Once the organisation has been registered and created successfully, the user is authorised to invited other users to join the organisation. The additional users receive an e-mail in which they are invited to register and join the organisation. To register, it is necessary to provide a work e-mail address, first and last name as well as password. Here as well, a double opt-in procedure is used. The user receives a confirmation e-mail at the work e-mail address provided. Clicking on the link provided in this e-mail concludes the registration process. The first time a user logs in after an invitation, the user has to confirm the invitation in order to join that organisation. After registering successfully and accepting the invitation, this user can access our products and services. The Client’s admin account is able to restrict and expand the rights of all users. All users can trigger costs by calling up services if they are granted corresponding rights.
The processing of data provided during the registration process is described in the Privacy Policy. These can be viewed on our website at
https://www.syseleven.de/en/privacy-policy/


1.3. Provision of services

All services ordered by the user are assigned to projects and billed along with these projects. Where possible, these projects are created by the Client itself or by us.
The service obtainable for the user results from the specific valid product descriptions for the individual products (“Product-specific descriptions”) as well as this general description. All relevant documents can be viewed online at https://www.syseleven.de/agb-sla/
The user can find the available service level from the SLA descriptions of the individual products (“Service level agreements”). These can also be accessed online at the link above in their current valid versions.


1.4. Use of the products

The user must possess the necessary technical knowledge in order to ensure correct administration of the IT service by the user.
Documentation is available for the user’s assistance, which can be accessed via the website at https://documentation.syseleven.de/en/discover/


1.4.1. Recommended settings

The provided software is not preconfigured for production operation. We recommend that each user review the configuration of software, particularly with regard to critical security settings, and to adjust the settings to the user’s own needs.


1.4.2. Backup & restore

The user is responsible for backing up the latest status of its services and the accompanying data that is administered in order to be able to restore them independently at any time.
Unless otherwise described for the individual products in the product descriptions, in this context the user will use the options in the software provided by the product.
Note: Any duplications of data as part of particular services do not perform the function of a backup since they do not allow access to older versions of data.


1.4.3. Verification and authorisation

The user may use the functions offered by the software to:

  • Manage access to the interface, IT service and the service itself
  • Adjusting other security-related settings, e.g.
      • configuration of user rights,
      • backup measures, to ensure the integrity and availability of data and the security of the service.

We recommend configuring authorisations restrictively and limiting user access to the necessary minimum.


1.5. Installation of software

If this is offered, the user may independently install software on the provided service. The user is independently responsible for its administration and operation.
There is no assistance for software administration unless this is expressly offered with the product.
When providing the software for installation, we do not provide any licences for or on behalf of the user as a rule. The user accepts the applicable licence terms of the particular manufacturer at the time of installation, and an agreement is established between the user and the particular manufacturer. The user bears sole responsibility for ongoing correct licensing of the software installed by the user.
Note: Our service ends with provision of the software for installation. We make no guarantees for the faultless function and security of this software. The evaluation of software quality and security as well as the decision regarding installation and its complete administration is the sole responsibility of the user.


1.6. Customer data

Customer data refers to all information that the user transfers to our systems while using the product, or engages to be transferred by authorised persons or systems. The administration of customer data is the responsibility of the user.


1.6.1. Erasure of customer data

Each user will erase customer data independently and promptly when it is no longer required. If there is any remaining data after the end of the contract, we will erase this no later than after 7 days.


1.6.2. Unannounced access to customer data by us

If it becomes necessary due to unforeseeable events for us to inspect customer data in order to perform the contract and this was not authorised by the user in advance, we will inform the user afterwards regarding the following details according to the best effort principle:

  • What was accessed?
  • Who had access?
  • When and for how long did access occur?
  • Why was access necessary?


1.7. Storage and calling up of data

The user is aware that, where relevant, particular data will only be stored if the user has explicitly activated storage. The procedures for this are described in the product documentation.
During contract implementation, any user data that falls under the user’s responsibility and is managed by the user cannot be provided by us for calling up or transferred to the user. The user must call up these data independently and promptly before the termination of use.


1.8. Maintenance work

We reserve the right to regularly perform maintenance work on the products to retain security and availability, and to further develop the products.
Planned maintenance work which are anticipated to impact the usability of products for all users are generally announced 7 working days before being carried out, at least on our status page.
Note:

  • The user is recommended to regularly check the status page for announcement and take suitable measures.
  • The user can reduce the impact of maintenance work by executing suitable redundancy measures. Examples for this include infrastructures with redundant design (VMs, storage) on which queries are distributed. The development of georedundant services also helps considerably in this regard.

1.9. Support

The following support plans are available:

1.9.1. Overview of product support

Product/support plan

Self-service

Business

Priority

Cloud platform

·

·

·

GPU Passthrough

·

 

 

DBaaS

·

Kubernetes aaS

·

·

·

 

 

 

 



1.9.2. Overview of operational support

Product/support plan

Self-service

Business

Priority

Cloud platform

·

·

·

GPU Passthrough

·

 

 

DBaaS

·

Kubernetes aaS

·

·

·

1.10. Cessation of use

If the user ceases to use a product or releases the resources employed, the user will no longer have access to its data. These data will be erased automatically. The time of erasure depends on the product used. There is no option of having us restore the data.

2 Product description IT services in “as a Service” model

Last updated: 17 November 2025
This chapter summarizes the general description for all products in an “as a Service” model (hereinafter referred to as “aaS”):

  • SysEleven OpenStack Cloud (“Public Cloud”)
  • DB as a Service
  • Kubernetes as a Service

These product-specific descriptions extend or replace the general description in Chapter 1 General information regarding our self-service products and aaS services.
If provisions in the two chapters contradict in whole or in part, the provision in this chapter shall take priority.

2.1. Shared responsibility

We offer various products in an as-a-service model based on a model of shared responsibility.
The nature of an “as a Service” product makes it logical for us to share responsibility for accessibility with the user. In the following sections, we indicate which elements are our responsibility and which fall under the user’s responsibility.

2.1.1. What do we do?

Our area of responsibility encompasses supplying and updating the required platform for providing the software, including the interfaces and services required for use.
To this end, we provide interfaces and channels which allow the user to flexibly manage resources.
The user receives an administrative account to manage the service.

2.1.2. What does the user do?

Users can call up and return software via defined interfaces.
Our service ends with the provision of a software in an operable basic configuration, and additional tools for administration where relevant. The necessary configuration is fully under the user’s area of responsibility.

2.2. Use of the products

2.2.1. 3rd party tools

Insofar as we and the software support them and they are available on the market, the user can use typical third-party tools to configure and operate the software.

2.3. Maintenance work

Planned maintenance work that only effects individual users or a small number of users and which require us to impair access to IT services will be communicated specifically to the affected users, 7 working days in advance as a rule.

2.4. Malfunction reports

If the user wishes to call up an agreed service from fixed-term contracts and this is not available, the user must contact support using the standard reporting channels. The user will not be billed for times starting from receipt of the report up to provision of the service.

3 Product description SysEleven OpenStack Cloud (“Public Cloud”)

Last updated: 17 November 2025
The descriptions in this chapter extend or replace the general descriptions in Chapter 2 Product-specific description IT services in “as a Service” model.
If deviating descriptions are presented in this chapter, these take priority over the descriptions in Chapter 2 Product-specific description IT services in “as a Service” model.
The SysEleven OpenStack Cloud is hereinafter referred to as Public Cloud.

3.1. Purpose of this document

This description, along with the documentation, is the central source of information relating to the services (products plus accompanying services) which we perform in the context of our Public Cloud and its platform-related services for its users. These include:

  • Infrastructure aaS
  • Compute
  • Compute with GPU
  • Storage (Volume Storage, Object Storage)
  • DNS aas
  • LB aaS

It contains a quantitative and qualitative service description of the services we offer and accompanying service elements.
A distinction is made between primary services and supporting services.
A primary service (customer-oriented service) is to be understood as a service that is visible for the user. This assists the user’s business divisions and business processes or promotes the result which the user desires to achieve.
A supporting service, in contrast to primary service, is to be understood as a support service that is not directly visible for the user, yet which is essential for the performance of primary services. The performance of supporting services is included as part of the performance of primary services.

3.2. Object of service

We offers our users computing, storage and network resources (hereinafter referred to as “Resources”) under the concept “Infrastructure as a Service” (IaaS) as well as platform-based services using OpenStack.

3.3. Use of the product

3.3.1. Upper limit of use

The maximum resources available to call up are agreed based on an agreed upper limit of maximum usable resources (hereinafter referred to as “Quota”). This quota can be changed by mutual agreement.

3.3.2. Required activities of the user

A user manages its IaaS resources independently. This also includes management of the selected operating system, particularly installation, operation, life-cycle management (integrating patches) and backup). This list is not intended to be exhaustive.
The user is responsible for the security of the resources employed.
When producing VMs, the user may use public operating system images that we support or other images that we provide. The proper function of these images is not an integral component of the product. We offer no guarantee of function or availability. The documentation contains information about images provided by us and references to licensing at
https://documentation.syseleven.de/en/products/syseleven-stack/
When providing the images for installation, we do not provide any licences for or on behalf of the user as a rule. The user accepts the applicable licence terms of the particular manufacturer at the time of installation, and an agreement is established between the user and the particular manufacturer. The user bears sole responsibility for ongoing correct licensing of the software installed by the user.
For VMS with GPU, the following applies:

  1. The use of Nvidia GPUs (including driver) by the user is also subject to Nvidia’s current valid end user license terms, which the user accepts by using this IT service; depending on the installation type (see https://documentation.syseleven.de/)
    1. these must be actively confirmed or
    2. these are stored in the usual directories for review after installation or
    3. these must be accepted upon download from the Nvidia source.
  2. If these licensing terms are not available, the user can procure them directly from Nvidia.
  3. If the end user licensing terms contain requirements for use and/or restrictions of use regarding the Nvidia products, these also apply for the relationship between the user and us regarding the use of the IT service.
  4. We have the right to terminate the use of the IT service with immediate effect if the user violates the Nvidia end user licensing terms and a prior request to cease the violation is not complied with.
  5. The user will regularly back up interim results to ensure that the impact of outages is minimized. We do not store any data.
  6. The user can obtain these in the on-demand model or as a commitment
  7. Users with commitment have a higher priority for allocation of VMs with GPU
  8. The following applies for commitments:
    1. These are always billed, even if the user does not call up the agreed-upon service.
    2. We are allowed to use services that are not called up in other ways
  9. The following applies when calling up based on an on-demand model:
    1. The user can issue a request for a VM with GPU. If capacities are available, the service is provided.
    2. We reserve the right to temporarily revoke the service from the user after prior announcement.

3.4. Regions

This description applies for the regions

  • HAM1 (Hamburg) and
  • DUS2 (Düsseldorf).

You can learn more under 4.6.1.1 Regions.

3.5. Service management

3.5.1. Purpose of service management

In order to guarantee the suitability and usability of the services we offer at all times, the primary and supporting services are maintained and further developed according to the defined life cycle (internal definition regarding the life cycle of a service according to the reliability criteria for individual components).

3.5.2. Best management practices and proof of effectiveness

In order to act in accordance with the principles of service management, we orient our service management based on best management practices pursuant to ITIL®.

3.5.3. Scope of service management

The established service management system which we use includes all

  • Directives,
  • Processes,
  • Functions,
  • Standards,
  • Guidelines,
  • Resources and tools,
    which guarantee that we can achieve the specified service targets.

The service management processes introduced in line with best management practices pursuant to ITIL® include

  • Capacity Management,
  • Service Continuity & Availability Management,
  • Service Level Management incl. Service Catalogue Management,
  • Service Reporting,
  • Information Security Management,
  • Budgeting and Accounting for IT-Services,
  • Incident and Service Request Management,
  • Problem Management,
  • Business Relationship Management,
  • Supplier Management,
  • Configuration Management,
  • Change Management as well as
  • Release and Deployment Management.

3.6. Services

3.6.1. Primary and supporting services

The following describes all primary and supporting services with regard to functionality, quantity and quality. In addition, corresponding service targets (service level) are agreed for each primary service, which must be achieved as an integral component of the contract.

3.6.1.1 Dashboard

A dashboard is available in which the customer can create, manage, extend, delete and monitor OpenStack resources. The dashboard also offers access to additional products and services.
Access to resources – similarly to the operation of a physical data centre – is only possible using a corresponding network or Internet connection. Within a customer network, the software makes it possible for us to distribute various resources among different locations.
• https://dashboard.syseleven.de/

3.6.1.2 SSO

Authentication/Authorisation
An integrated identity and access management service with SSO is available for Public Cloud and additional products and services that we provide.
This software is responsible not only for simple authorisation, but also takes over the process of user authentication. Centralising the entire authentication process to a single identity provider facilitates the single sign-on method, among other benefits. The following APIs are available for the user:
• https://idp.apis.syseleven.de/ (users)

3.6.1.3 CLI Tools

The client (also known as OSC) is a command line client for the Public Cloud which compiles the command set for Compute, Identity, Image, Object Storage and Block Storage APIs into a single shell with a unified command structure. With this client, each customer can manage its resources in the Public Cloud:
• https://docs.syseleven.de/SysEleven-stack/en/howtos/openstack-cli#overview

3.6.1.4 Documentation

We offer technical documentation to assist the user with the use of OpenStack services.
The availability of technical features and the nature of their use may different between the regions, particularly in the areas of authentication and authorisation (IAM).

3.6.1.5 Public Cloud API

We provide access to the cloud functionality for developers based on REST (Representational State Transfer). The Public Cloud API can be used by established user accounts with the “Customer” type. The web service end points are:
• https://api.dus2.cloud.syseleven.net
• https://api.ham1.cloud.syseleven.net

3.6.2. Compute

3.6.2.1 Private Node Pools

With Private Node Pools, we offer the user the exclusive use of a group of servers that are virtually separated from the Public Cloud servers. For this purpose, multiple servers – at least 3+1 – are compiled into a Private Node Pool. In this context, 3 servers are intended for production operation and one additional server is provided as a stand-by replacement. The user then has exclusive access to the server resources and can create virtual servers on them as usual.
Individual flavours are also possible here, which are defined in collaboration. We provide advice regarding necessary features for operation in order to ensure qualities such as availability and live migration of VMs. Overprovisioning of CPU threads and positioning guidelines for VMs are also defined individually for a Private Node Pool.
For Private Node Pools, an individual service level agreement is established.
Note:

  • Private Node Pools cannot be created or managed by the user. They are exclusively defined on an individual basis with the user during a project along with the corresponding operating parameters.
  • VMs can only be migrated within a Private Node Pool.
3.6.2.2 Virtual server (VM)

The user has the option of hiring various resources as needed and compiling them into a virtual server (hereinafter referred to as VM). A VM comprises the following components:

  • Memory (RAM),
  • Virtual processor cores (vCPU),
  • Storage,
  • Network cards (optional).
  • GPU (optional)
3.6.2.3 Flavours

There are pre-defined ratios between vCPUs and RAM, known as flavours. Provision of vCPUs and RAM is only possible in the ratios defined by the flavours.
VMs that provide one or more GPUs use non-virtualised Nvidia graphics cards with direct and complete access to the GPUs via pass-through mapping.
A list of the flavours offered in the regions can be found at:
• https://documentation.syseleven.de/en/products/syseleven-stack/concepts/flavors-catalog/

3.6.2.4 API

All end user functions (and some administrative functions) of Nova are provided in each region via a REST-API which can be used to establish more complex logic or automation with Nova. These can be used directly or via various SDKs.
• https://api.ham1.cloud.syseleven.net:8774
• https://api.dus2.cloud.syseleven.net:8774

3.6.2.5 Processors

When purchasing hardware, we make sure that the processor generations are always up to date. When calling up the processor generation, however, the oldest model in the region is always reported. This does not necessarily match the actual processor model. The customer has no option of selecting a particular model.

3.6.2.6 SSH key support

Our Public Cloud supports importing SSH keys. These can be uploaded via an OpenStack API endpoint or via one of the available dashboards.

3.6.3. Storage

3.6.3.1 Block Storage (volumes)

The block storage we provide, also known as cinder volume, enables the customer to access a redundant storage system. This system is 100% made up of enterprise level drives.
We rely on a purely software-based solution (software defined storage, hereinafter referred to as SDS). This SDS is a scalable, fault-tolerant distributed storage system. The SDS supports live migration from VMs and is integrated into the APIs provided by OpenStack, Cinder or Nova:

Characteristics

 

Use

Shared

Minimum and maximum specifications

1 GiB – 32 TiB per volume

Sequential reading and writing speed

600 MB/s for 8 MiB block size

Full random reading and writing speed

6000 IOPS for 4 KiB block size

Encryption (encryption at rest)

Yes, automatic

3.6.3.2 Block storage/cinder API

Cinder is a block layer service for OpenStack. It virtualizes the management of Block Storage and provides end users with a self-service API to request and consumer these resources without requiring knowledge about where their memory is actually used or on what device type.
Block storage can also be used with multi-attachment volumes. This is useful, for example, to improve the scalability of app servers or to reduce single points of failure: If your system is dependent on a file system for storing information, e.g. images, you can use multi-attachment volumes to enable the file system for a series of VMs without requiring network storage solutions such as NFS.
• https://api.ham1.cloud.syseleven.net:8776/v3/
• https://api.dus2.cloud.syseleven.net:8776/v3/

3.6.3.3 Object Storage

Our Public Cloud offers S3-compatible object storage (compatibility refers here to the main attributes of an S3 API and therefore does not offer the same scope of functions as AWS). This stores and calls up any unstructured data objects via an HTTP-based RESTful API. Using data replication and an existing scaling architecture, storage is highly fault-tolerant. With corresponding access rights, access to object storage is established using the OpenStack API. The S3 API can be used with various S3 clients and/or SDKs.
With georedundant replicated object storage, the requirements for memory use are twice as high, since the data are automatically replicated into the corresponding associated region.

Region

Replication by region

HAM1

DUS2

DUS2

HAM1

3.6.3.4 Local Storage

We offer local storage instances with a particularly low latency.
When one of the corresponding flavours is selected, a virtual server is generated on a server with local storage. We allocate these VMs to local storage according to the definition in the list of flavours with local storage. The following applies in this context:

  • Local storage can be combined with our block storage/cinder
  • Local storage instances cannot be expanded or reduced
  • Local storage is not offered in all regions

Note:

  • Local storage instances offer simple data replication onto the server where they operate.
  • The user is responsible for ensuring the necessary backups.
  • If access to a VM with local storage is no longer available, then access to the local storage is no longer possible either.

The list of flavours can be accessed at:
https://documentation.syseleven.de/en/products/syseleven-stack/concepts/flavors-catalog/

3.6.3.5 Snapshots

Users can generate copies of individual block storages, known as snapshots. It may be necessary to restart the VM in this process.
Two different snapshot types are available:

  • Instance snapshots can be generated from instances that use network storage.
  • Volume snapshots can be generated from each volume, whether from a root hard disk for an instance or from an additional volume.

Snapshots can be used as a template for new server instances.

3.6.3.6 Images

We provide a range of images. These are the current LTS versions of unmodified cloud images for

  • Ubuntu,
  • CentOS and
  • Debian.

These are administered and promptly renewed when the manufacture publishes new versions. Then they are automatically made available to the Public Cloud. The current list can be found in our documentation:
https://documentation.syseleven.de/en/products/syseleven-stack/
We reserve the right to add non-LTS and test or beta versions.

Note:

  • We reserve the right to add non-LTS and test or beta versions.
  • Please note the provider’s recommendations and do not use them for production purposes.
  • We also discontinue EOL (End of Life) images and remove them from our portfolio.
3.6.3.7 Image upload

Our Public Cloud allows users to transfer and use their own images:
https://documentation.syseleven.de/en/products/syseleven-stack/usage/storage/images/

3.6.3.8 Glance

This OpenStack component offers a RESTful API which makes it possible to request VM image meta data and call up the current image:
• https://api.ham1.cloud.syseleven.net:9292
• https://api.dus2.cloud.syseleven.net:9292

3.6.4. Network

Our Public Cloud offers a network service. This also delivers an Internet connection.
We use a software defined network. In this way, each user is able to generate their own virtual network structure that is completely separate from the network structures of other customers. This relates to L2 services, broadcast domains, DHCP as well as L3 management: each customer is able to independently issue IP addresses in their own virtual network and there is no risk of collision with networks managed by other customers.

3.6.4.1 Network interface

Our Public Cloud makes it possible to equip virtual instances with network interfaces. Using these virtual interfaces is necessary in order to connect multiple virtual instances together or connect them to the Internet.

Internal throughput

MTU 1500

up to 50 GBit/s

External throughput

MTU 1500

up to 50 GBit/s

3.6.4.2 External network

We currently have an external network connection with a bandwidth of more than 400 Gbit/s (distributed over multiple locations).
Depending on the location, capacities are available for operating services that transfer data to or from the Internet. Thanks to a direct connection between the regions at the German location, the upstreams can be used across different locations.
The total capacities of the respective locations are described below.

Location

Connection

Redundancy level

DE-HAM1 

2 x 100  GBit/s

N+1

DE-DUS2

2 x 100 GBit/s

N+1

Depending on the circumstances, the maximum external throughput can only be achieved with a corresponding upstream from the provider.

3.6.4.3 Internal network

Every hypervisor has a high availability 50 Gbit/s connection to the non-blocking switching fabric.
Our internal network comprises multiple IP networks, each structured redundantly. Each server has a redundant connection to the IP network.

Characteristic

 

Availability

99.99+% p. a.

Capacity

Redundant, 2 x 25 GBit/s

3.6.4.4 Network sub-services

Location

DE-HAM1

DE-DUS2

Basic networking

yes

yes

Floating IPs

yes

yes

Security groups

yes

yes

IPsec VPN (VPNaaS)

yes

yes

Customer public IP space (Bring your own IP)

yes

yes

L4 Load balancing (TCP) (Neutron-LBaaS)

no

no

L7 Load balancing (HTTP/HTTPS) (Octavia-LBaaS)

yes

yes

Neutron DNS integration and PTR records

yes

yes

Firewall rules (FWaaS)*

Coming soon

Coming soon

Dynamic routing (BGP)

no

no

Metering support

no

no

Quality of service (QoS)

no

no

Service function chaining (SFC)

no

no

Port Trunking

yes

yes

IPv6

yes

yes

* Firewall functionality can be replicated with security groups (see below).

3.6.4.5 IP address management

We provide the user with public IP addresses which, depending on the intended use, can be booked permanently or during the existence of a virtual server. These IPs that we provide are only necessary if connections need to be established via the Internet. Internally, virtual machines can be networked freely. For this purpose, we offer a DHCP server which enables and simplifies the allocation of IP addresses. However, an independent addressing scheme can also be established.
Public IPv4 addresses
Virtual machines can access the Internet using a virtual router (SNAT). SNAT enables the simultaneous use of a public address (compared with private IP addresses) by multiple hosts. Typically, the router in the network adopts the SNAT which establishes the Internet connection (for this reason, this router is the default gateway for a host as a rule). In order to access the Internet with VMs and load balancers, we offer a floating IP service (DNAT). Destination network address translation (DNAT) is a NAT method executed for incoming IP data packages. NAT (network address translation) is a method used in IP routers that connects local networks to the Internet.
For Internet access, we offer the network “ext-net”.
Management can be handled via public OpenStack API endpoints as well as with user interface (GUI).
Security groups
A security group acts as a virtual firewall for a VM as well as other virtual resources. Security group rules specify the network access. These rules can also reference different security groups or refer to themselves.
If a security group is not specified, a default setup is provided. You can find more about this at:
https://documentation.syseleven.de/en/products/syseleven-stack/
Firewall groups
Firewall groups are not currently available for all customers. The functionality is described here:
https://documentation.syseleven.de/en/products/syseleven-stack/usage/networking/firewall-groups/
Private IPv4 addresses
Our cloud networks operate as a “virtual bridge”.
Simple allocation of one or more of our cloud subnets to a specific network is possible. Subnets can be used for managing IP addresses and configuring DHCP servers.
VMs and virtual routers use our Public Cloud stack port to connect virtual networks. A port is a connection point for a single device, such as a network interface card (NIC), to a network. The port also describes the associated network configurations, such as MAC and IP addresses. IP addresses need to be configured by the customer.
Multiple isolated layer-2 networks can be created. Different networks can also use overlapping IP address spaces if they are not connected to one another. To communicate between two networks, it is always necessary to use a router.
In our private network, any RFC1918-compliant Ipv4 address can be used. -https://www.rfc-editor.org/rfc/pdfrfc/rfc1918.txt.pdf
Dedicated IP pool
On request, users can reserve their own dedicated IP pool from us with public IPs from which they dynamically operate their VMs. By default, the pool is an IPv4 /28 or IPv4 /27 subnet. Larger networks may be available on request.

3.6.4.6 Load Balancing – LBaaS

We offer users a layer-7 as a load balancer service. The layer-7 load balancer enables header insertion and PROXY protocol support. In addition, health checks for all upstream instances of the members in both load balancer pools.

3.6.4.6.1 Customer public IP space (Bring your own IP)

To connect the Internet without a NAT, fixed IP addresses can be used instead of floating IP addresses. For this purpose, users must bring along their own public IP addresses. These can be easily transferred to our public cloud network. Users can also make use of both address types simultaneously.

3.6.5. Supporting services

3.6.5.1 DHCP

We provide an IP configuration via DHCP for each network interface of a virtual server.
The type of configuration differs depending on whether the network interface is connected to the public Internet or the private Ethernet.
Public Internet:
The following parameters are provided for configuration via DHCP:

  • public IP address,
  • network mask (255.255.255.255),
  • gateway address,
  • DNS server address and
  • MTU

Private networks:
The following parameters are provided for configuration via DHCP:

  • private IP address (10.x.x.x),
  • network mask (255.255.255.0) and
  • MTU

Our DHCP server always uses the address A.B.C.1 in the Class C network corresponding to the issued IP address.
For each network interface, configuration via DHCP can be optionally switched on or off. For newly created network interfaces, configuration via DHCP is switched on.

3.6.5.2 DNSaaS

We offer DNS as a Service. The user can use the following functions:

  • Managing DNS records and zones with a high-availability, authoritative DNS infrastructure across our five regions.
  • API use for various clients.
  • Web interface to manage zones and records
  • Secondary zones. Hidden master and our DNS infrastructure acts as slaves.
  • Import/export function with master file format (RFC 1035)
  • Zone transfer to different projects.

This means e.g. subdomains can also be managed in other OpenStack projects.
Available at https://designate.cloud.syseleven.net:9001

3.6.5.3 VPNaaS

We offer VPN as a Service. The user can use the following functions:

  • Possible connection to a private cloud using our Public Cloud
  • Operation of georedundant setups
  • Possible connection of public clouds from other providers using our Public Cloud
  • Use of VPN networks in our Kubernetes products.
  • Connection of back-office networks (e.g. ERP in protected company Intranet) with the networks of our Public Cloud and
  • Hybrid setups with us which distribute the workload across different platforms
3.6.5.4 DDoS protection (optional)

Our customers’ infrastructure can be protected transparently on the network level against DDoS attack if the customer has book this service for a fee.

3.6.6. General supportive services

3.6.6.1 Operation
3.6.6.2 Regions

We currently have two regions (HAM1 and DUS2) with the latest expansion level of our Public Cloud, one for each location, in which the SysEleven OpenStack Cloud is provided. The security requirements for the regions are subject to the standard ISO 27001. The data are not forwarded to third parties (regions, countries). The regions are connected with one another. The bandwidth is more than 500 Gbit/s.

Distance

HAM1

DUS2

HAM1

401 km

DUS2

401 km

Our regions are directly connected to the Internet.

Düsseldorf DUS2 – Region

Tier classification

Tier-III, carrier neutral

Certifications

EN 50600 Level 3.

ISO 27001 according to BSI basic level of protection.

ISAE 3402 Type 2.

Power supply

Availability 99.99+% p. a.

Battery buffer

YES

Emergency power

Emergency diesel generator with N+1 redundancy

Air conditioning

 25 °C

Early fire detection

Yes

Fire extinguishing system

Yes

Hamburg HAM1 – Region

Tier classification

Tier-III, carrier neutral

Certifications

EN 50600 Level 3.

ISO 27001 according to BSI basic level of protection: 

Power supply

Availability 99.99+% p. a.

Battery buffer

YES

Emergency power

Emergency diesel generator with N+1 redundancy

Air conditioning

 25 °C

Early fire detection

Yes

Fire extinguishing system

Yes

3.6.6.3 Infrastructure components

Core Network

We operate a core network across all regions in Düsseldorf and Hamburg (as well as Berlin and Frankfurt) for a redundant connection of our Public Cloud. All services that we provide are connected to the Internet via the core network.
The core network is exclusively made up of devices from renowned manufacturers. Thanks to modern fibreglass technologies, the core network is capable of transporting several 100 GBit/s.
OpenStack cloud underlay network
We operate various 2x25GBit/s Ethernet networks at each location. All Ethernet networks are operated with state-of-the-art technology from renowned manufacturers. Our Public Cloud network connects nodes to ensure the exchange of data in the cloud.
Hardware nodes
We operate nodes which reflect the products “Compute” and “Storage”. All nodes are built up of hardware from renowned manufacturers with years of experience. Each of these nodes is connected with the 2x25GBit/s Ethernet network.

4 Added services

Last updated: 17 November 2025
The use of this service is optional. This reduces the tasks required for users when administering standard software.
We offer various types of Software aaS. This allows users to access the software without having to install it themselves.
The scope of workload reduction depends on the service.
The following descriptions extend or replace the general descriptions in Chapter 2 Product-specific description IT services in “as a Service” model.
If deviating content is presented here, these take priority over the descriptions in Chapter 2 Product-specific description IT services in “as a Service” model.

4.1. Description SysEleven Open Stack Cloud: DBaaS

4.1.1. Characteristics of the product

We provide a function managed by us that generates dedicated database management systems (hereinafter referred to as “DBMS”) which the user may access. It is the sole responsibility of the customer to manage each DBMS using configurations. The customer shall gain access to the Database-as-a-Service API (hereinafter referred to as “the Interface”), via which the customer can generate and delete DBMS independently.
A list of supported databases can be viewed online at:
https://documentation.syseleven.de/en/products/syseleven-dbaas/
DBaaS is a product with shared responsibility. The product is intended for experienced DBMS administrators.

4.1.1.1 Our tasks

Providing and administering the interface for provisioning and erasing DBMS.
Providing an admin account on the DBMS
We provide DBMS with various basic configurations, among which the user can choose a suitable configuration.

4.1.1.2 Tasks of the user

Using the admin account, the user must perform all administrative tasks for a DBMS such as

  • Configuring the DBMS
  • Creating and managing additional users
  • Managing databases
  • Capacity management and more

Users should have experience in the operation of DBMS.

4.1.2. Support

For this product, product support is only available in the self-service plan.

5 Product description – SysEleven OpenStack Cloud: Kubernetes aaS (formerly MetaKube Core)

Last updated: 17 November 2025
The descriptions in this chapter extend or replace the general descriptions in Chapter 2 Product-specific description IT services in “as a Service” model.
If deviating descriptions are presented in this chapter, these take priority over the descriptions in Chapter 2 Product-specific description IT services in “as a Service” model.

5.1. Characteristics of the product

  1. With Kubernetes aaS, we offer a managed Kubernetes environment as a shared platform for users who can use this to create and manage Kubernetes clusters in their projects.
  2. The user obtains access to corresponding APIs to use the IT service.
  3. Kubernetes aaS cannot operate as a stand-alone and requires the services of our Public Cloud, which the user must order separately.
  4. Kubernetes aaS worker nodes are displayed in the Kubernetes aaS GUI as regular IaaS resources.
  5. Kubernetes aaS offers an operational Kubernetes environment that provides the user with the typical required configurations and functions for handling their workload. Users of Kubernetes aaS do not have to deal with procuring Kubernetes. In contrast, when compared to a proprietary Kubernetes environment, there are limitations in the options for adapting the Kubernetes environment. These restrictions are necessary in order to guarantee secure and stable operation.
  6. Kubernetes aaS only supports features for stable versions within the framework of the upstream Kubernetes project (known as “stable releases”). Unless explicitly documented elsewhere, Kubernetes aaS does not support any alpha or beta versions (hereinafter referred to as prior versions) along with their features; this applies even if those version are available in the upstream Kubernetes project.
  7. We can deviate from this procedure in the following exceptional cases:
    1. We have explicitly requested the user to test these new features.
    2. Features are activated with a feature flag. In this case, the user must explicitly decide to use these features (see previews further below).

5.2. Areas of responsibility

Kubernetes aaS is not a fully managed cluster solution. Some components, e.g. worker nodes, indicate joint responsibility, whereby the user is required to assist with the administration of their Kubernetes cluster. User input is required, for example, in order to apply a security patch for the operating system (OS) of a worker node.
All worker nodes are subject to joint responsibility shared between us and the user. Users have the option of registering with their worker nodes and making changes independently, for example kernel updates or installing/removing packages.
We advise all users against using access for such changes unless we explicitly request this. Otherwise, support will lapse for these worker nodes or clusters.

5.2.1. Parts of the IT service managed by us

5.2.1.1 Platform

With Kubernetes aaS, the customer obtains a fully managed graphical user interface and a fully managed API. This contains all components and services that the user required to operate their Kubernetes cluster and provide the cluster to their end users. These include all master Kubernetes components such as

  • API server
  • Controller manager
  • Cloud controller
  • etcd cluster
  • Scheduler and
  • Machine controller

We also monitor the following components:

  • Kubelet or Kubernetes API server
  • Etcd
  • DNS services (e.g. CoreDNS)
  • Kubernet proxy or network-operated

The services are managed in the sense that we provide, operate and are responsible for the availability and functionality of the services. Users cannot modify these managed components. We restrict the options of modification in order to ensure a consistent and scalable user experience.

5.2.1.2 Worker nodes

As part of our responsibilities for Kubernetes aaS, we take on the following tasks:
a. The worker nodes obtain automated operating system patches from us depending on the image selected and provided by us:
o optional (Flatcar formerly CoreOS) or
o mandatory (Ubuntu)
b. In the event of undefined or unclear statuses, we assist the user with troubleshooting or recovering the function of the worker node, or provision of a new worker node.
c. We supply Kubernetes versions and test their functionality in Kubernetes aaS in advance.
d. We provide the necessary packages for the Kubernetes version upgrades on the worker node.
Our Kubernetes aaS manages backups of Etcd snapshots for the cluster and can reassign the cluster at any time. Recovery is carried out within the context of a service request from the user.

5.2.2. Parts of the IT service managed by the user

5.2.2.1 Clusters/worker nodes

When a cluster is generated, the user defines the Kubernetes worker nodes that are created by Kubernetes aaS. The user’s workloads are later executed on these worker nodes. The user is able to configure these.
It falls under the user’s area of responsibility when making changes to the worker nodes to ensure that neither the user’s data nor the user’s workload are lost.
Depending on the circumstances, it may be necessary to restart the worker node for recovery. An automatic restart will not occur. This will only be the case for automated operating system updates. Depending on the selected IaaS provider, various methods may be used. More details on this process can be found in the documentation of the selected IaaS provider.

5.2.3. Restrictions during the configuration of worker nodes

As an “as a Service” service, Kubernetes aaS requires specific network configurations and connection options. Adjustments to NSG rules, blocking specific ports and using block or allow lists in Kubernetes aaS can make it impossible for Kubernetes aaS to manage these worker nodes.
It is not permitted to completely prevent outgoing data traffic. If the user has done so, it is the user’s responsibility to undo these changes. Support will be suspended until the settings have been reverted.

5.3. Product-specific tasks of the user

5.3.1. Installing updates

We do not automatically restart worker nodes in order to apply patches at the operating system level. Although we distribute operating system patches to the worker nodes, the user is responsible for restarting the worker nodes in order to apply the changes.
For flatcar images, the user can configure and automate the restarting process.
For Ubuntu, restarting is not generally required.
Shared libraries, daemons such as SSHD and other components at the system or operating system level are patched automatically.
Users are responsible for executing Kubernetes version upgrades themselves. They can execute these upgrades via the Kubernetes aaS GUI or the API. This applies for updates to improve the security or functionality of Kubernetes.

5.3.2. Configuration of worker nodes

Users can expand on the standard configuration of their worker nodes. For example, users can use the Secure Shell (SSH) in order to regularly configure worker nodes like VMs. However, the base operating system image should not be modified. Changes made by users may not be retained when upgrades, scaling, updates or restarts are executed.

5.3.3. Images

Nevertheless, users can create their own base image supported by Kubernetes aaS and use this within Kubernetes aaS. In this context, the user is responsible for the correct functioning of this operating system image within Kubernetes aaS. We do not guarantee any support for self-created images and clusters operated with them.

5.3.4. Allocation of IaaS resources

Kubernetes aaS manages the life cycle and processes for worker nodes on behalf of the customer. The user can independently modify IaaS resources that are allocated to the worker nodes via the Kubernetes aaS GUI or API.

5.3.5. Workload-specific configurations

For workload-specific configurations or packages, we recommend using Kubernetes daemon sets (https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/).
By using privileged Kubernetes daemon sets and start containers, users can optimize, modify or install software from third-party providers on cluster worker nodes. Examples of such modifications include adding user-defined software for security scans or updating sysctl settings.
This approach is recommended if the requirements outlined above are fulfilled. Our support cannot help the user with diagnostics or eliminating problems if the worker node is no longer available due to improper modifications or other modifications to daemon sets provided by the customer.

5.3.6. Importing cluster patches

The user is responsible for restarting or updating in order to call up a cluster patch that we have supplied. If users do not use the patches according to the MetaKube instructions, their cluster will continue to be susceptible for security problems that are eliminated by the patches.

5.3.7. Importing kernel updates

Kernel updates are installed by users via new creation of worker nodes by selecting the corresponding images. For this purpose, we provide a rolling update mechanism that must be activated by the user. Configuration of services by the user may be responsible for service outages that occur.

5.4. Elimination of faults and security incidents

In many cases, user workloads continue to be executed even if there are breakdowns in Kubernetes master nodes, Etcd and other components managed by us.
If a serious security problem (e.g. Google rating ‘Remote executable’) occurs in one or more components of Kubernetes aaS, we will patch all affected clusters in order to rectify the problem. Alternatively, the team will provide the users with instructions for an upgrade.
For worker nodes that are affected by a security problem, we use a patch without downtime (where available) and inform the users regarding the change.
If a security patch requires restarting the worker node, we will inform the users regarding this requirement.

5.5. Support

Worker nodes execute private user code and may contain private or confidential data. Support can only access worker nodes to a limited extent, only after express authorisation and at the user’s request, to assist in the event of a problem. We have implemented technical and procedural measures to ensure that unauthorised access to worker nodes cannot occur under any circumstances.
We provide support based on the following regulations in the support policies. The rules relate to our Public Cloud service as an IaaS provider. No support is offered for other providers. The user is recommended to consult the corresponding documentation of the specific IaaS provider.
Under technical support for Kubernetes aaS, we do not offer any assistance for worker nodes that do not run in our Public Cloud service.

SysEleven Managed Services – Product-Specific Terms and Conditions for Managed IT services

Last updated: 17 November 2025

The following contents describe the product “Individual managed IT services”. This product enables users of our Public Cloud to hand over the operation of individual software to us within a project.


1.1. Product description

We operate an individual IT service and, if additionally agreed, carry out coordinated actions in the event of a disruption to the IT service, which are defined in an operating manual.
We install the product on the platforms and operate using our toolings.


1.1.1. Our tasks

As part of operation, we assume responsibility for the availability of the IT service under the conditions of the agreed service level agreement and take over the following tasks for the IT service:

  • Life cycle management
  • Configuration according to best practices or the requirements of the contracting partner
  • Alerting
  • Monitoring
  • Trending
  • Backup

We work

  • in line with standardised operating processes,
  • according to the agreed SLA and
  • according to an agreed operating concept.

We normally install the IT services for operation ourselves. If a previously existing IT service managed by the user needs to be brought into operation, this installation will be reviewed by us before commissioning.
We support the user with the interplay of IT services operated by us and by the user to the extent that we act as administrator of the IT services operated by us, for example by analysing log files for troubleshooting or performance optimisation at the user’s request.


1.1.1.1 Standard software

We offer operation for a range of standard software that follows our best practices for configuration, maintenance and troubleshooting. The user can obtain the currently supported software from its contact person. A list of the currently supported software and other detailed information can be viewed here:
https://documentation.syseleven.de/en/products/metakube-operator/managed-services/


1.1.1.2 Individual software

For individual software, we offer the option of operation according to an operating manual.
The following applies:

  • We provide a template to the user for preparing the operating manual and assist the user in filling the template.
  • For the actions described in the operating manual which are performed by us as well as their effects, the user bears sole responsibility.
  • For actions based on an operating manual, we ensure performance without guaranteeing the success of the described actions.

To maintain availability of the managed IT services, we may react to unforeseeable situations without consulting the user and

  • Change the configurations of the IT services or
  • Restart the IT services
  • View customer data, e.g. log files

As a user, you agree to this in advance. This consent cannot be revoked, as it is a binding requirement for our provision of services.
The user agrees to invoicing based on working hours performed according to the price list, plus any material costs incurred for the implementation of these measures. During performance, we will endeavour to maintain a reasonable balance between the contract value and the costs of implementation along with any follow-up costs.
The user shall receive login data to its front-end area in which it can see how much resources are consumed by the software in use.


1.1.2. Tasks of the user

The user assists us with the operation of the IT services by providing documentation, personnel and other necessary information. This is particularly the case for

  • Troubleshooting throughout the entire period agreed in the service level agreement for the availability of the IT service by providing a contact person
  • Selecting the configuration of the IT service by indicating operating parameters such as quantity structures for the anticipated load on the IT service.

If the assistance is not given to the necessary extent, the user will release us from our responsibilities.


1.1.3. Compulsory termination of the product

If updates are no longer developed for the software required for the IT service, the status of the product is “End of Life” (EOL). This leads to restrictions in the operational responsibility accepted by us and can lead to full transfer of operational responsibility onto the user.
If the mandatory prerequisites for the product are no longer fulfilled, we reserve the right of termination in this situation and this product.


1.2. Changes to the object of service (change request procedure)

The object of our service may require changes to the configuration of the IT services or the volume of resources allocated to IT services. In the following we describe how changes are carried out.

  1. All change requests must be submitted directly via the standard reporting channel. Change requests shall be accepted and documented in the ticketing system on working days from Monday to Friday between 9:00 a.m. and 5:00 p.m.
  2. A change request of this type must include the following information as a minimum:
    – Description of the desired change;
    – Intent and purpose of the desired change;
    – Special circumstances and background information that has to be taken into account in relation to the desired change;
    – Urgency of the desired change.
  3. We shall then immediately review the impact the desired change will have on the structure of the services to be performed under the contract, in particular in terms of the agreed fee. If we determine that the change request can be readily implemented, the change shall be made and documented in the ticketing system.
  4. We review all change requests from the user for configurations or the type of service to be performed with a view to compliance with the terms agreed in the SLA. If availability is restricted by the user’s change request, we have the right to reject the user’s change request and will prepare proposals where possible that address the user’s preferences without restricting availability.
  5. If this is not possible, the user will release us from the obligation to grant a credit due to non-compliance with availability of the affected components.
  6. If we determine that the work to be undertaken cannot be performed or can only be performed with a delay due to the amount of work expected to be required to review the impact of the change, we shall inform the user of this and shall advise the user that the change request can only continue to be reviewed if the services concerned are postponed accordingly. If the user consents to this postponement, we shall review the change request. If, however, the user decides to withdraw its change request, the initiated change request process shall come to an end.
  7. Unless the desired change can be implemented immediately and without the need for additional consultations with the user, we shall – after reviewing the effects of the desired change – explain how it will impact on the agreements made. This explanation shall either propose how the desired change be implemented or clarify why the desired change is not feasible. The parties shall immediately try to come to an agreement on the contents of a proposal to implement the change request and, if successful, shall outline the results of this negotiation in a supplementary agreement. If the parties fail to reach an agreement or end the change request process for another reason, the content and scope of the services shall stay the same as originally planned. (Such supplementary agreements should only be made in exceptional circumstances. In many cases, the nature of business is too dynamic for such procedures.)
  8. The user must bear any costs resulting from the change request. In particular, these include the expenses incurred for reviewing the change request and preparing a proposed change as well as compensation for any downtimes. The hourly rate for this work shall be in line with the price list valid on the date on which the contract was concluded.
  9. To ensure that we can provide services in accordance with this contract, we may change their scope or deviate from the agreed services, in particular by enabling larger volumes, without receiving an explicit prior order from the user in this regard. We shall inform the user of such changes as soon as they have been implemented. After receiving notification thereof, the user may reject the changes, deviations or additional services. If the user does not oppose the changes or deviations within two weeks of receiving notification thereof from us, we shall bill the user for the services provided in accordance with the price list valid at the time. If the user does not oppose the changes in writing within the aforementioned period, the change, deviation or additional services shall be deemed to have been approved.
  10. If the service has to be amended due to the user’s failure to properly assist us, in particular as a result of corrections to information provided before the list was approved or due to the late submission of information, this shall be deemed as a change in services within the rules of this agreement.


1.3. Maintenance work

Planned maintenance work which require us to impair availability will be communicated specifically to the affected users, 7 working days in advance as a rule.


1.4. Backups

We prepare backups for the IT services operated by us and customer data contained therein following a 7 day, 4 week and 3 month pattern insofar as this is supported by the software for the IT services.
The user releases us from the duty of preparing backups if implementation is not possible at the scheduled intervals due to the nature and volume of data. If this should occur, the user will be informed.


1.5. Customer data

Customer data refers to all information that the user transfers to our systems while using the product, or engages to be transferred by authorised persons or systems. The administration of customer data is the responsibility of the user.


1.5.1. Erasure of customer data

Each user will erase customer data independently and promptly when it is no longer required. If there is any remaining data after the end of the contract, we will erase this no later than after 7 days.


1.5.2. Unannounced access to customer data by us

If it becomes necessary due to unforeseeable events for us to inspect customer data in order to perform the contract and this was not authorised by the user in advance, we will inform the user afterwards regarding the following details according to the best effort principle:

  • What was accessed?
  • Who had access?
  • When and for how long did access occur?
  • Why was access necessary?

1.6. Support

We only provide support for managed IT services that are not part of the user’s production environment (typically development (DEV) and acceptance environments (STAGE)) during daily working hours.


1.7. Cessation of use

On request and if included in the product, we provide the user with backups of the customer data for the product in a common format. These data exclusively refer to data stored by the user on our systems when using the product.
The user must request the transfer of data no later than four weeks before the end of contract or cessation of use, depending on which comes first. If no request is made by the deadline, timely provision of the data by the end of contract cannot be guaranteed. The transfer itself can also occur after the end of the contract, depending on internal availability of resources. A claim to provision of data only exists insofar as the request was submitted within the deadline.

2 Sets of managed IT services

Last updated: 17 November 2025
With this product, the user can engage for us to operate multiple connected IT services (hereinafter referred to as core setup). The added value compared to the operation of individual IT services relates to the agreement for availability across the entire core setup.
The present description supplements the product description “1 Description of service for individual, managed IT services” with the necessary information for this setup.
If any content is contradictory either in part or in whole, the content in this description has priority.


2.1. Product description

The operation of the entire setup (core setup and all other IT services) occurs exclusively on our platforms and follows the model of shared responsibility.
The user makes use of our tooling to ensure that operation is as smooth as possible.
Additional IT services outside the core setup are excluded from our area of responsibility.
The user may only carry out installation or configuration of IT services in consultation with us insofar as this falls under our area of responsibility. In particular, the user must ensure faultless interplay of all IT services after the modifications. If expenses are required on our part for this purpose, these will be billed to the user.


2.2. Areas of responsibility

As a rule, there are other additional IT services (typically the application) operated by the user. For this reason, management of the entire services is based on a model of shared responsibility where we and the user each bear responsibility for the IT services we have assumed, and the interfaces between the IT services operate jointly and based on coordination.


2.2.1. Our tasks

2.2.1.1 Accessibility of data

We shall make the data contractually stored by the user in its core setup available online permanently, globally and, as a general rule, publicly via the network maintained by us and the Internet to which this network is connected, unless otherwise agreed. Additional regulations in this regard are specified in the established service level agreement.
We cannot be held responsible for the success of the various means of accessing the website, unless problems are caused exclusively by the network operated by us, including the interfaces maintained by us with third-party networks.


2.2.1.2 Provision of tooling

We provide tooling with which the core setup can be managed jointly, for example an interface with which the user can independently install and manage additional IT services for the setup.


2.2.2. Tasks of the user

The user is fully responsible for all tasks related to IT services outside the core setup.

3 Glossary

See Service Level Agreement

SysEleven Service Level Agreement

Genereal

Last updated: 17 November 2025

The regulations of the Service Level Agreement expand on or supplement the regulations in the Terms of Business for the Cloud Service in the secunet Group. Insofar as this document contains deviating regulations, these take priority over the regulations in the Terms of Business for the Cloud Service in the secunet Group
Service level agreements apply for specific products. The products are described in the corresponding documents.

  • Products in the area of self-service including aaS products
  • Products in the area of managed services

We use the term “Product” as a generic designation for work, IT services and services. In the product-specific chapter, this is described in more detail for the product in question.
The object of this SLA is the definition of performance parameters known as “Service level objectives” (hereinafter referred to as SlO) to set targets, measure and control the quality of the services to be performed according to the contracts for the products selected by the user, as well as the definition of measures in the event of malfunctions and non-fulfilment of the agreed SLO.
The SLOs to be fulfilled according to the individual contracts are separately outlined in detail in the product-specific SLAs below.


1.1. Review period for determining availabilities

Any specified availability applies in the specified scope for a review period of 12 months unless deviating agreements are made for specific services. For services that are billed as on-demand, the review period is the calendar month.


1.2. Exceptions

The user releases us from the obligations of this SLA

  • in the event that the user fails to comply with contractually agreed terms, conditions, deadlines and cooperation obligations
  • in the event that the user fails to grant access to us, our representatives and/or suppliers as requested, enters into default, or refuses or fails to provide the approval to carry out necessary tasks in a timely manner
  • during an agreed test or configuration phase
  • if our non-fulfilment of the service level objectives is owing to circumstances for which we are not responsible
  • during suspension of service in line with the contractual stipulations
  • in the event of missing documentation for troubleshooting that falls under the user’s area of responsibility

1.3. Alerting

Unless otherwise indicated, we react to alarm messages in our own monitoring system.


1.4. Reporting channel

Malfunction reports must occur using the standard reporting channel (see General Terms and Conditions). In both cases, the malfunction report must also be submitted by phone using our emergency numbers.

1.5. Service level objectives

1.5.1. Availability

We will adopt economically appropriate measures to achieve the stipulated availabilities. Statements regarding availability do not constitute a guarantee that this will be achieved.
If an availability is not specified for the products offered, we do not guarantee any availabilities for the offered services.
We can decline requests for resources if no resources are available for booking. If requests for providing resources are declined, this is not considered a malfunction or non-availability within the meaning of the SLA.
The specified availabilities do not apply if the environment chosen the user (for example a region) is affected by a total breakdown and the user has not accepted or performed a potential expansion of the environment (for example two regions) at the same time, which would have prevented a breakdown of the user’s services.
Regarding stated availabilities, the following applies:

  • We do not guarantee any availability for IT services not administrated by us.
  • We do not guarantee any availability for products operated by us without a redundant design.


1.5.2. Reaction times

Malfunctions are eliminated as quickly as possible.

1.6. Error classes for malfunctions

We will eliminate malfunctions occurring in the IT services based on the following regulations.
The user will apply the error classes at its own discretion considering our interests, in a malfunction report indicating the impacts of the malfunction. We reserve the right to change the error class after review in consultation with the user.

1.6.1. Category A (very high priority)

A malfunction preventing operation that lasts for longer than 5 minutes and is not caused by the user for which no alternative solution is available. This leads to a considerable impairment of the user’s services in the production environment. There is no option of generating and/or using substitute instances of the service.

1.6.2. Category B (high priority)

Like Category A, but with only a partial impairment of the user’s services.

1.6.3. Category C (normal priority)

Like Category A, but with only a minor impairment or for which a temporary substitute solution is available. The user’s services can continue operation for the most part.

1.6.4. Category D (low priority)

Like Category C, but with no impairment or only a minor impairment of the user’s services.


1.7. Troubleshooting

It is up to our due discretion to choose which methods to apply when rectifying a malfunction.
Unless otherwise agreed in the individual contract, the following applies:

  • We act according to our due discretion and orient our prioritisation decisions based on the urgency and impact of the malfunction wherever possible.
  • Work to rectify the malfunction begins as quickly as possible.
  • Users can request information about the progress of work at a central office.
  • Insofar as we prepare backups for the contractually defined products according to the product descriptions, we use these to restore the condition after a breakdown if required.

1.7.1. Recovery time

Unless otherwise agreed, there is no guaranteed recovery time. If we determine that the malfunction cannot be successfully rectified within an agreed recovery time, the user will immediately be notified of the additional time required to rectify the malfunction.


1.7.2. Work-around solutions

If malfunctions in Category A or B are present, we will provide a work-around solution within the rectification period until complete rectification of the malfunction if these malfunctions cannot be remedied within that period.
All of our services require maintenance windows. We will adopt economically appropriate measures to prevent interruptions in the services due to maintenance windows. Maintenance for which no service interruptions are anticipated are carried out silently, i.e. without announcement.

1.8. Calculating the achieved availability

If we have specified an SLO for the target availability of a product, this applies as an average for the time period in question which depends on the product.
In general, the review period is one month for all services procured on-demand, and one year for all services procured in commitments.
The availability actually achieved is calculated as follows, whereby the entire time corresponds to the agreed time frame and the downtime in minutes:

Availability in %=100*(total time-downtime)/total time

1.8.1. Availability report

We provide a status page for tracking and we monitor the functionality of the products. If included in the product, we inform the contact person defined by the user according to the best effort principle, allowing the user to check whether they are affected and to adopt corresponding measured. Upon recovery of availability, this contact person will also be informed.

1.8.2. Downtime

Downtime is defined as the period during which the product is affected by a Category A malfunction in productive operation. The downtime is stated in minutes.
The required time to feed in the user’s data does not count as downtime.
The downtime is measured starting with the user’s notification via the standard reporting channel.
The downtime ends as soon as we have eliminated the malfunction and the user has been notified via the status page, by e-mail or phone that the malfunction was rectified. Recovery of the service is also considered notification of malfunction elimination. We eliminate malfunctions based on the best effort principle.

1.8.2.1 Exceptions

In the following, we describe when we do not classify a given non-availability of a product as a downtime.
Causes outside our area of responsibility
As a rule, downtimes are excluded which are demonstrably attributed to errors of the software manufacturer, unless we are also the software manufacturer. We will adopt economically appropriate measures to detect errors of the software manufacturer at an early stage.
The downtimes are not affected by malfunctions which

  • are caused by changes to the network infrastructure that were not carried out by us and are therefore not within its sphere of influence (e.g. routing on the Internet).
  • occur due to modifications performed by the user independently there were not inspected or approved by us.
  • which are attributed to the general operating risk of an internet connection, for example impairments due to DDoS attacks.

Maintenance work

We regularly conduct maintenance work on a regular basis both on the underlying hardware and on the software required for providing the services in order to maintain the security and availability and for ongoing development of the products.
Maintenance work may lead to interruptions in the availability of our products. These do not count as downtimes according to the SLA agreements.
Planned maintenance work which is anticipated to impact the availability of our products for the users are generally announced 7 working days before being carried out, at least on our status page. The user is recommended to regularly check the status page for announcement and take suitable measures. The status page can be accessed on the Internet at
https://www.syseleven-status.net/


1.8.3. Malfunctions

A malfunction occurs when our product does not work as contractually agreed.

1.8.3.1 Exceptions

The following are not considered malfunctions:

  • Malfunctions reported by the user although no malfunction was present.
  • Periods in which
    • scheduled maintenance work was performed after prior announcement
    • or unscheduled but urgently required maintenance work is performed
  • Restrictions or breakdowns in services which
    • occur due to unusual use of the products by the user
    • were trigged by modifications that were carried out by the user improperly or in a manner that influenced productive operation.
  • were caused by changes made by us on behalf of the user. In principle, when executing changes it is possible for known, unavoidable malfunctions to occur, for instance when restarting services, or for unknown reasons
  • are caused by a lack of performance capacity in the product due to insufficient technical resources (e.g. RAM) for ordinary operation of the product, and which the user does not extend or engage another party to extend, or otherwise independently extend, despite corresponding notifications from us.

1.9. Credit

If we do not fulfil our own quality commitments and do not comply with the specified SLO, we will grant the user a credit based on the following definition:


1.9.1. Calculating the credit amount

The user’s entitlement to credit due to non-fulfilment of the target availability for the product is based on the average availability achieved in the period under consideration. Credits are then granted only for those months which fell below the specified availability.
To calculate the credit, the measurements and drawings carried out by us will be used as the exclusive basis. The amount of credits for each affected contract is limited to 25% of the calculated contract value for the unavailable product
Credits are deducted in the following month from the costs of use for the same product. If the credit exceeds these costs, the remaining amount is forfeited.
Credits are exclusively granted for the product directly affected by the malfunction. For additional products that make use of the malfunctioning product and therefore fail to deliver the expected search results, no credit is granted.
Credits are granted for products paid in advance or granted retroactively, after the use of billed products, and the amount is determined differently in each case.

1.9.1.1         Products paid in advance: Credits are accounted for as follows

Difference between achieved availability and target availability of product in %

Credit in % of the amount invoiced in advance

Less than or equal to 10%

10%

Greater than 10%

25%

1.9.1.2 Products called off on demand: Credits are accounted for as follows

Difference between achieved availability and target availability of product in %

Credit in % of average invoice amounts for this product in the past three months

Less than or equal to 10%

10%

Greater than 10%

25%

2 Service level agreement for infrastructure

Last updated: 17 November 2025

The regulations in this section apply additionally to the regulations in Section I Service Level Agreement. Insofar as this section contains deviating regulations, these take priority over the regulations in Section I.
The following SLOs apply for the connection of regions to the WAN/Internet and for the availability of the infrastructure in the data centres.
We guarantee a redundant connection to the WAN/Internet for each data centre and for each region.
All infrastructure in the data centres is designed in a redundant manner.

2.1. Service level objectives

2.1.1. Availability

Availability for infrastructure in data centres on average per year 99.9%
Availability for WAN/Internet on average per year 99.9%


2.1.2. Reaction times

We react to malfunctions in Category A and B during service hours within 30 minutes. Outside of service hours, within 60 minutes.

3 Service level agreement for individual, managed IT services

Last updated: 17 November 2025

The regulations in this section apply additionally to the regulations in Section I Service Level Agreement. Insofar as this section contains deviating regulations, these take priority over the regulations in Section I.
The following SLOs apply in general for individual IT services that are operated by us on the user’s behalf. This excludes the offer of product managed hosting (PVC), for which separate SLA agreements are provided.


3.1. Shared areas of responsibility

Operation of IT services in a user environment is based on the model of shared responsibility. Where available, the modes of collaboration and distribution of responsibilities between the user and us are described in detail in the specific product descriptions. We do not offer any SLA for components in the setup that are operated by the user.


3.2. SLA variants

We offer a range of SLA variants that are differentiated in terms of alerting and in their SLOs.
We only grant SLOs for IT services in the user’s production environments, not for development environments (“Dev”), acceptance environments (“Stage”) and all other environments.

3.3. Troubleshooting

3.3.1. Sequence

The elimination of malfunctions in SLA Priority is carried out with priority over malfunctions with SLA Business.
The elimination of malfunctions in SLA Business is carried out with priority over malfunctions with SLA Base.

3.3.2. Non-catalogue software

For software that is debugged by agreement, SLA Priority applies.

3.4. Alerting

SLA

 

Base

We react to a malfunction report from the user via the standard reporting channel during service hours

Business

We react 24/7 to malfunction reports from the user via the standard reporting channel during service hours

Priority

We react proactively to malfunction reports from the monitoring system and inform the user


3.5. Service level objectives

3.5.1. Availabilities

SLA

Single instances

Redundant instances

Base

None

Business

None

99.5%

Priority

None

99.8%

3.5.2. Reaction times during service hours

SLA

Error class category

 

A

B

C

D

Base

Best effort

Business

1 hour

2 hours

4 hours

Priority

30 minutes

1 hour

2 hours

4 hours


3.5.3. Reaction times outside of service hours

SLA

Error class category

 

A

B

C

D

Base

Best effort

Business

4 hours

Next Business Day

Priority

60 minutes

2 hours

4 hours

Next Business Day


3.5.4. Additional time window

SLA

Start of work

Recovery time after start of work

 

During service hours

Outside of service hours

During service hours

Outside of service hours

Base

4 hours

Best effort

Business

1 hour

2 hours

5 hours

8 hours

Priority

30 minutes

1 hour

3 hours

5 hours


3.6. Downtime

The downtime is measured starting with the receipt of the alarm message in our monitoring system or the user’s notification via the standard reporting channel.

4 Service level agreement for a set of managed IT services

Last updated 17 November 2025

The regulations in this section apply additionally to the regulations in Section III Service Level Agreement for individual, managed IT services. Insofar as this section contains deviating regulations, these take priority over the regulations in Section III.
We guarantee a total availability agreed with the user for a set of IT services defined in the contract which must be available in order for the user’s core setup to be deemed as available. This is referred to as the core setup hereinafter.
The availability of the core setup is reviewed from outside our network. To this end, a suitable test will be arranged with the user. As a rule, this is a normal request, for example an HTTP or HTTPS request, to the core setup. Evaluation of the request is carried out upon consultation with the user. If no method is agreed, the status code returned in the response from the server to the request shall be decisive.
We and the user each have corresponding obligations to demonstrate availability for the parts of the setup under our respective responsibilities.
For IT services managed by us that are not part of the managed core setup or whose availability has no impact on the SLOs of the core setup, the SLA regulations for individual managed IT services shall apply.
If the components under the user’s responsibility are partly responsible for non-availability according to the agreed measuring procedure, the user will release us from the obligations under the framework of this SLA.

4.1. Service level objectives

Deviating service level objectives are exclusively defined in writing within the contract.

4.2. Credit

The credit is calculated based on the costs incurred for the core setup. If one of these services is not available, the entire core setup will accordingly be deemed as not available according to the agreement. In this context, it is immaterial how many and which of the services are malfunctioning.

5 Service level agreement for managed setups (PVC) 

Last updated: 17 November 2025

The regulations in this section apply additionally to the regulations in Section I Service Level Agreement. Insofar as this section contains deviating regulations, these take priority over the regulations in Section I.
The following SLOs apply for IT services that are operated by us on the user’s behalf in the managed cloud (PVC) (hereinafter referred to as “Core setup”).

5.1. Shared areas of responsibility

Operation of IT services in a user environment (setup) is based on the model of shared responsibility. Components in the setup that are operated by the user are excluded from our area of responsibility.


5.2. Troubleshooting

5.2.1. Sequence

We act according to our due discretion and orient our prioritisation decisions based on the urgency and impact of the malfunction. If we have a malfunction manual, which must be agreed upon separately for a fee, this indicates the order of priority.
The elimination of malfunctions with SLA Premium is carried out with priority over malfunctions with SLA Standard.

5.2.2. Individual software

For software that is not included in our standard catalogue, we offer 24/7 fault elimination according to the operating manual among other services. The requirement for this service is booking SLA Premium.
5.3. SLA variants
We offer two SLA variants (Standard and Premium) that feature differing SLOs.
Upon recovery of the service, the user will be informed.

5.4. Alerting

SLA

 

Standard

We react 24/7 to malfunction reports from the user via the standard reporting channel during service hours

Premium

We react proactively to malfunction reports from the monitoring system and inform the user according to the best effort principle


5.5. Service level objectives

5.5.1. Availability

5.5.1.1 Individual services

SLA

Single instances

Redundant instances

Standard

None

99.5%

Premium

None

99.8%



5.5.1.2 Core application

Availability of services that are required for the core application, installation and managed by us, on virtual servers.

SLA

Standard

Premium

 

99.6%

99.8%


5.5.2. Reaction times during service hours

SLA

Error class category

 

A

B

C

D

Standard

1 hour

2 hours

4 hours

Premium

30 minutes

1 hour

2 hours

4 hours


5.5.3. Reaction times outside of service hours

SLA

Error class category

 

A

B

C

D

Standard

4 hours

Next Business Day

Premium

60 minutes

2 hours

4 hours

Next Business Day


5.5.4. Additional time window

SLA

Start of work

Recovery time after start of work

 

During service hours

Outside of service hours

During service hours

Outside of service hours

Standard

1 hour

2 hours

5 hours

8 hours

Premium

30 minutes

1 hour

3 hours

5 hours


5.6. Fault elimination for individual software

For software that is not included in our standard catalogue, we offer optional 24/7 fault elimination in SLA Premium at additional cost, according to the operating manual.

5.7. Availability report

We provide a status page for tracking availability.
The standard availability report is generated automatically and includes the KPI “Availability of setup” determined by the accessibility of the public IP address delivering the website accessible at the domain with an error-free status code. As a standard feature, all measurement points are considered via a web interface (optionally including outside of Europe). Filter options can be used to optionally adjust the measurement points and anchor them in the report.
Using the user front end, the user defines the report recipients and notification options.

5.8. Downtime

The downtime is measured starting with the receipt of the alarm message in our monitoring system or the user’s notification via the standard reporting channel. 

5.9. Credit

We exclusively grant credits for IT services for which SLA Premium was booked.

5.9.1. Example calculation for annual target availability of 99.9%
Determination of achieved availability

Month

1

2

3

4

5

6

7

8

9

10

11

12

Yearly average

Achieved availability in %

100

99.9

100

99.8

99.7

99.95

100

99.9

99.85

99.99

99.95

100

99.9125

100

99

99

100

100

100

100

100

100

100

100

100

99.83


In the first case, the agreed target availability was achieved and there is no entitlement to a credit. In the second case, the target availability was not reached and there is an entitlement to a credit for months 2 and 3. 

5.9.2. Determining the contract value

The contract value is calculated from the average of the contract values for the months that fail to achieve the target availability. For the second case above, the following contract value is calculated:

Month

1

2

3

4

5

6

7

8

9

10

11

12

Calculated contract value

Contract value in euros

2K

2K

3K

3K

2K

2K

4K

4K

3K

4K

3K

3K

€2,500


5.9.3. Determination of credit

In the second case above, the yearly average for achieved availability is 99.83%. This results in a claim of 10% on the calculated contract value of €2,500. Accordingly, the credit is € 250.

6 Service level agreement for IT services using “as a service” model

Last updated 17 November 2025

The regulations in this section apply additionally to the regulations in Section I Service Level Agreement. Insofar as this section contains deviating regulations, these take priority over the regulations in Section I.
IT services offer as aaS are designed to install, operate or use applications in distributed setups.
We offer various products in an “as a Service” model which are independently used by the user.
We only specify availabilities for the interfaces operated by us for use of the products.
The user configures its setup to achieve the target availability as far as calculations are concerned. This can occur for example by distributing the workload across multiple virtual servers, data centres or regions.

6.1. Service level objectives

6.1.1. Availability

The availability of interfaces is 99.9%, unless otherwise agreed upon.

6.2. Credit

Credits are exclusively granted for the service directly affected by the malfunction. For additional services that make use of the malfunctioning service and therefore fail to deliver the expected search results, no credit is granted.

7 Service Level Agreement – SysEleven OpenStack Cloud

Last updated 17 November 2025

The regulations in this section apply additionally to the regulations in Section VI Service Level Agreement – IT services in “as a Service” model. Insofar as this section contains deviating regulations, these take priority over the regulations in Section VI.

7.1. Service level objectives

7.1.1. Availability

The availability of the platform (IaaS) is 99.95% per year. The platform includes:

  • Virtual server (VM)
  • Object Storage (not geo-redundant)
  • Block Storage (volumes)

If volumes connected to virtual services are temporarily unavailable because a malfunction is present, VMs are still deemed as available.
For geo-redundant object storage, availability is 99.99% per year
The availability of the platform-related additional service is 99.95% per year. Platform-related additional services are:

  • DNSaaS
  • LBaaS
  • DHCP

External and internal network are each available at 99.99% per year.

7.2. Maintenance work

Hardware nodes are maintained at regular intervals. As a rule, this maintenance work does not cause any interruption of our services. VMs for customers which support live migration are not influenced in terms of their availability.

8 Service Level Agreement – SysEleven OpenStack Cloud: GPU

Last updated: 17/11/2025

The regulations in this section apply additionally to the regulations in Section VII Service Level Agreement – SysEleven OpenStack Cloud. Insofar as this section contains deviating regulations, these take priority over the regulations in Section VII.
The following SLOs apply for the use of VMs with GPUs based on the passthrough method.


8.1. Alerting

The start of a non-availability is deemed to be the receipt of the report from the user on the standard reporting channel.

8.2. Service level objectives

The SLOs for virtual servers (VM) apply unless otherwise defined here.

8.3. Maintenance work

VMs with GPUs are always subject to maintenance windows with service interruptions, as there is no option of live migration.

9 Glossary


Working day
Working days refer to the days Monday through Friday within service hours. Holidays are not considered working days.
Service level
The service level is the description of the nature and scope of the service, its quality and availability.
Service level objective (SLO)
An SLO consists of a metric, target (availability) and period.
Year
A period of 365 calendar days of 8,760 hours in which the service is performed. The first year starts with the day that the service is provided ready for operation and ends 365 days later.
Recovery time
The recovery time is the period within which the availability of a product is restored to its initial condition under our responsibility. Recovery of the condition at the time of malfunction, e.g. by feeding in user data from a backup, is not included. The period of time corresponding to the condition at the time of malfunction depends on the type and scope of data in the user setup and the collaboration of the user, and can therefore not be defined in a generally applicable manner.
Reaction time
Refers to the time that passes when a malfunction report is submitted until confirmation by an employee authorized by us.
Start of work
Defined as the time which may pass after the reaction response from us until troubleshooting work begins.
Malfunctions (incidents)
A malfunction (incident) involves an unplanned interruption or reduction in quality of a service.
Contract value
For invoice items paid in advance on a monthly basis, the contract value is the amount due monthly for the IT service that is performed.
Service hours
The service hours correspond to normal office hours and apply from Monday to Friday between 9:00 a.m. and 5:00 p.m., excluding legal holidays in Berlin. We reserve the right to adjust the service hours after prior announcement.
Night and weekend hours
All hours outside the defined service hours (see above).
Best effort
We endeavour to achieve the best possible results given the available technical opportunities and resources.
Replacement solution
Replacement solutions refer to all products that are maintained as redundant by us (including those in other regions) or alternatives offered specifically in the event of a malfunction which eliminate the impact of a malfunction in error class A or minimize the impact such that error class A no longer applies.
A replacement solution is also present if the control level allows the user to establish new instances of the software affected by a malfunction and to feed in its data.
Dev environment
Dev environment refers to those software installations that the user uses to develop the production environment with the help of developers.
Stage environment
Stage environments are used to adopt changes in the production environment. These can be used by the user as well as by us for testing purposes.
Production environment
The production environment encompasses all software installed by the user, or by us on the user’s behalf, that is needed to provide the user’s service.
Control level
Control level refers to the interfaces used by the user to set up and modify its environments.
Service transfer point
The service transfer point defines the point at which our area of responsibility ends. As a rule, this is the communication interface of a software on which the software can be used.
Emergency
A malfunction in Category A.