1st, 2nd und 3rd Level Support: Was der Unterschied bedeutet – und was Ihr SLA dazu regeln muss
Inhaltsverzeichnis
Veröffentlicht: 02. November 2026 · Lesezeit: ca. 12 Minuten
Viele Unternehmer glauben, mit einer vereinbarten Reaktionszeit von vier Stunden seien sie auf der sicheren Seite. Der Irrtum liegt nicht in der Zahl – sondern darin, was diese vier Stunden tatsächlich bedeuten. Reaktionszeit heißt: Ein Techniker meldet sich. Nicht: Ihr System läuft wieder. Wer das verwechselt, unterschreibt ein SLA, das im Ernstfall weniger leistet als erwartet.
Ein zweiter verbreiteter Irrtum: „Unser IT-Dienstleister kümmert sich um alles.“ In der Praxis sind Support-Anfragen in Ebenen aufgeteilt – und nicht jede Ebene ist automatisch Vertragsgegenstand. Wer nicht weiß, welche Support-Stufe sein Anbieter übernimmt, stellt das häufig erst beim ersten ernsthaften Problem fest.
Die Support Level SLA Regelung ist einer der am häufigsten missverstandenen Bestandteile eines IT-Dienstleistungsvertrags. Viele Unternehmen unterzeichnen Vereinbarungen, ohne zu wissen, welche der drei klassischen Support-Ebenen – 1st, 2nd und 3rd Level – ihr Anbieter überhaupt abdeckt, und was bei einem Ausfall konkret passiert.
Dabei ist die Abgrenzung entscheidend: Der 1st Level nimmt Anfragen an und löst Standardprobleme. Der 2nd Level bearbeitet komplexere Störungen, die eine tiefere Systemkenntnis erfordern. Der 3rd Level – oft Hersteller oder spezialisierte Entwickler – greift bei Fehlern ein, die in die Systemarchitektur eingreifen. Fehlt im SLA die Zuordnung, wer welche Ebene verantwortet, entstehen Graubereiche, die im Störungsfall keiner ausfüllt.
Dieser Beitrag erklärt, was hinter den drei Support-Ebenen steckt, wie Sie sie sinnvoll gegenüberstellen und was eine rechtssichere, NIS-2-konforme Support Level SLA Regelung konkret enthalten muss – damit Ihr Betrieb im Ernstfall nicht auf Antworten wartet, die vertraglich gar nicht geschuldet sind.
| Kennzahl | Wert | Quelle |
|---|---|---|
| Branchenübliche Reaktionszeit bei kritischen Störungen (KMU, Deutschland) | 1–4 Stunden | it-dienstleister.de, 2025 |
| Typische Lösungszeit nach Eskalation (Mittelstand) | 4–8 Stunden | it-dienstleister.de, 2025 |
| Aufpreis Business-SLA gegenüber Standard-SLA (KMU) | 20–35 % | hostspezial.de, 2025 ⚠️ |
| Empfohlene Reaktionszeit bei 24/7-Verträgen (Richtwert) | ≤ 30 Minuten | bavaria-informatics.com |
Support Level SLA Regelung: Was hinter 1st, 2nd und 3rd Level Support steckt – und warum die Abgrenzung zählt
Wenn Ihr Mitarbeiter einen Drucker nicht findet oder sich nicht mehr anmelden kann, landet diese Anfrage beim 1st Level Support. Diese Ebene ist der erste Kontaktpunkt: Helpdesk, Ticketsystem, Telefon. Hier werden Standardprobleme nach Lösungsvorlagen bearbeitet – Password-Reset, Neustart, einfache Konfigurationsfehler. Die Bearbeitungszeit ist kurz, die Qualifikation eher generalistisch.
Reicht das nicht aus, eskaliert das Ticket zum 2nd Level. Dort arbeiten Techniker mit tieferer Systemkenntnis: Netzwerkkonfiguration, Serverprobleme, Softwarekonflikte, Berechtigungsstrukturen in Active Directory. Hier entstehen die meisten Unklarheiten in SLA-Vereinbarungen – denn dieser Bereich ist personalintensiv und oft nicht pauschal im Vertrag enthalten.
Der 3rd Level bezeichnet Experten, die in die Systemarchitektur eingreifen: Hersteller-Support (z. B. Microsoft Premier Support, Cisco TAC), spezialisierte Entwickler oder interne Architekten. Diese Ebene ist selten Vertragsbestandteil bei externen IT-Dienstleistern – wer sie braucht, zahlt meist gesondert oder ist auf Hersteller-SLAs angewiesen.
Die Support Level SLA Regelung muss genau hier ansetzen: Welche Ebene verantwortet Ihr Dienstleister? Bis zu welcher Komplexität? Und was passiert, wenn ein Problem eskaliert werden muss – wer koordiniert das, und wer trägt die Folgekosten?
- Lassen Sie sich schriftlich bestätigen, welche Support-Ebenen Ihr Vertrag abdeckt (1st, 2nd, 3rd).
- Klären Sie, ob 2nd-Level-Support pauschal oder auf Stundenbasis abgerechnet wird.
- Definieren Sie, welches System welche Eskalationsstufe auslöst – und wer das entscheidet.
- Fragen Sie explizit, ob und wie Hersteller-Support (3rd Level) koordiniert wird.
- Prüfen Sie, ob Förderoptionen für eine strukturierte IT-Betreuung bestehen – die IT-Förderberatung der TTG GmbH gibt einen ersten Überblick, welche Programme für Ihre Situation in Frage kommen.
Besonders Betriebe im Raum Göttingen, die mit einem überregionalen Anbieter zusammenarbeiten, unterschätzen häufig, dass 2nd-Level-Kompetenz vor Ort – nicht nur remote – im Ernstfall den Unterschied macht.
Option A: Integriertes Full-Service-SLA – Stärken und Grenzen
Ein Full-Service-SLA fasst alle drei Support-Ebenen unter einem Vertrag zusammen. Der Dienstleister übernimmt die vollständige Verantwortung: von der Erstreaktion über die technische Entstörung bis hin zur Koordination des Hersteller-Supports. Aus Sicht der Unternehmensführung ist das der komfortabelste Ansatz – eine Anlaufstelle, eine Rechnung, eine Verantwortlichkeit.
In der Praxis sieht das allerdings differenzierter aus. Viele Anbieter, die ein Full-Service-SLA vermarkten, decken den 3rd Level lediglich koordinierend ab – die eigentliche Entstörung liegt beim Hersteller, dessen eigene SLA-Fristen gelten. Wer das nicht prüft, hat im Ernstfall zwei parallele Uhren laufen: die des eigenen Vertrags und die des Herstellers.
Stärken eines integrierten Full-Service-SLA:
- Klare Einzelverantwortung – kein Ping-Pong zwischen Dienstleister und Hersteller
- Einheitliche Eskalationslogik und Ticketverwaltung
- Für Geschäftsführer gut steuerbar: ein Ansprechpartner, ein KPI-Reporting
- Einfachere NIS-2-Compliance, da Zuliefererbewertung zentral geregelt werden kann
Grenzen dieses Modells:
- Höhere monatliche Pauschale – Business-SLAs kosten erfahrungsgemäß 20–35 % mehr als Standard-Verträge
- Qualität des 3rd-Level-Supports hängt stark vom Dienstleister-Netzwerk ab
- Wenig Transparenz, wenn Hersteller-Tickets nicht sichtbar ins Kundensystem gespiegelt werden
- Überdimensioniert für Betriebe, deren kritische Systeme rein cloudbasiert laufen (z. B. Microsoft 365 ohne On-Premise-Infrastruktur)
Die Support Level SLA Regelung in einem Full-Service-Vertrag sollte explizit festhalten, bis zu welchem Komplexitätsgrad der Dienstleister selbst entstört – und ab wann er nur noch koordiniert. Fehlt diese Unterscheidung, ist die vermeintliche Vollabdeckung im Ernstfall eine Lücke.
Die Managed Services der TTG GmbH bilden alle drei Support-Ebenen strukturiert ab – inklusive definierter Eskalationswege und monatlichem Reporting, das Reaktions- und Lösungszeiten transparent macht.
Option B: Gestaffeltes Ebenen-SLA – Stärken und Grenzen
Beim gestaffelten Modell werden 1st, 2nd und 3rd Level Support separat beauftragt und vertraglich einzeln geregelt. Typisch für Betriebe, die einen internen IT-Mitarbeiter beschäftigen: Dieser übernimmt den 1st Level, der externe Dienstleister deckt den 2nd Level ab, und für den 3rd Level bestehen direkte Hersteller-Supportverträge – etwa Microsoft Unified Support oder ein dedizierter DATEV-Betreuungsvertrag.
Dieses Modell ist flexibel und häufig günstiger im Monatsbeitrag. Wer intern Kapazität hat, zahlt nur für das, was wirklich extern erbracht wird. Gleichzeitig entsteht eine klare Aufgabenteilung, die – wenn sie sauber dokumentiert ist – zu schnellen Reaktionen führen kann.
Der entscheidende Schwachpunkt liegt in der Koordination. Sobald ein Problem die Grenze zwischen zwei Ebenen überschreitet, braucht es klare Eskalationsregeln: Wer entscheidet, dass ein Ticket eskaliert wird? Wer kommuniziert mit dem Hersteller? Wer trägt die Kosten, wenn ein 3rd-Level-Ticket nicht innerhalb der SLA-Frist bearbeitet wird?
Stärken des gestaffelten Modells:
- Geringere Pauschale, wenn interner 1st-Level vorhanden ist
- Spezialisierte Anbieter je Ebene möglich – optimale Qualität pro Bereich
- Transparente Kostenzuordnung nach tatsächlichem Aufwand
Grenzen dieses Modells:
- Koordinationsaufwand steigt – besonders bei sicherheitsrelevanten Vorfällen
- NIS-2-Konformität schwerer nachzuweisen: Lieferkettenbewertung muss für jeden Anbieter separat erfolgen
- Hersteller-SLAs (3rd Level) sind selten auf KMU-Bedürfnisse zugeschnitten – Reaktionszeiten können deutlich länger sein
- Ohne schriftliche Eskalationsmatrix entsteht im Ernstfall Unklarheit, wer zuständig ist
Aktuell zeigt sich, wie wichtig klare Zuständigkeiten sind: Kürzlich wurden aktiv ausgenutzte Zero-Day-Lücken in Ivanti Connect Secure und Synology bekannt (heise Security, Oktober/November). Wer in einem gestaffelten Modell arbeitet, muss im Vorfeld festgelegt haben, wer in solchen Fällen das Patch-Management koordiniert – sonst verliert sich die Zuständigkeit zwischen den Ebenen.
Die Support Level SLA Regelung in einem gestaffelten Modell braucht zwingend eine schriftliche Eskalationsmatrix mit definierten Übergabepunkten – und einen Ansprechpartner für geförderte IT-Sicherheitslösungen, der die Gesamtverantwortung koordiniert.
Direkte Gegenüberstellung: Wann welches Modell passt
Die Entscheidung zwischen Full-Service-SLA und gestaffeltem Ebenen-SLA hängt weniger von der Unternehmensgröße ab als von drei Faktoren: interne IT-Kapazität, Kritikalität der Systeme und regulatorische Anforderungen. Die folgende Tabelle gibt Orientierung – keine starre Empfehlung, sondern eine Entscheidungshilfe.
| Situation | Empfehlung | Warum |
|---|---|---|
| Kein eigenes IT-Personal vorhanden | Full-Service-SLA | Klare Einzelverantwortung, kein Koordinationsaufwand intern |
| Interner IT-Mitarbeiter (1st Level) vorhanden | Gestaffeltes Modell | Externe Kosten auf 2nd/3rd Level beschränken, intern entlasten |
| ERP, DATEV oder kritische On-Premise-Systeme im Einsatz | Full-Service-SLA mit expliziter 2nd/3rd-Level-Abdeckung | Ausfallkosten übersteigen SLA-Mehrkosten schnell |
| Rein cloudbasierte Umgebung (M365, keine eigenen Server) | Gestaffeltes Modell oder Basis-SLA | Hersteller (Microsoft) trägt 3rd-Level-Verantwortung, weniger Komplexität vor Ort |
| NIS-2-Pflicht oder DORA-Anforderungen relevant | Full-Service-SLA mit Auditrechten und Meldepflicht-Klauseln | Lieferkettenbewertung und 24-h-Meldepflicht müssen vertraglich verankert sein |
| Knappes Budget, stabile IT-Landschaft | Gestaffeltes Modell mit schriftlicher Eskalationsmatrix | Kosten kontrollierbar, Risiko beherrschbar wenn Übergaben klar definiert |
Unabhängig vom Modell gilt für jede Support Level SLA Regelung: Prioritätsklassen (P1–P4) müssen schriftlich definiert sein. P1 (Totalausfall kritischer Systeme) sollte eine Reaktionszeit von maximal 30–60 Minuten vorsehen, P4 (kosmetische Probleme, kein Produktionsausfall) kann mit 8 Stunden auskommen. Wer diese Abstufung nicht im Vertrag hat, behandelt jeden Drucker-Jam wie einen Server-Ausfall – oder umgekehrt.
- Definieren Sie mindestens vier Prioritätsklassen (P1–P4) mit je eigener Reaktions- und Lösungszeit.
- Streichen Sie „Best Effort“-Formulierungen ohne konkrete Messgröße aus dem Vertrag.
- Legen Sie maximal drei KPIs fest: First Response Time, MTTR und SLA-Compliance-Rate.
- Prüfen Sie, ob Ihr gewähltes Modell NIS-2-konform ist – insbesondere hinsichtlich Auditrechten und 24-h-Meldepflicht. Die BAFA – Bundesförderung Wirtschaft und Mittelstand fördert unter bestimmten Voraussetzungen auch die Beratung zur regulatorischen Compliance.
- Verankern Sie Kundenpflichten (Ticket-Qualität, Erreichbarkeit Key-User, Freigaben) explizit im SLA – fehlen sie, kann der Anbieter SLA-Verstöße nicht valide nachweisen.
Unserer Einschätzung nach ist die Frage „Full-Service oder gestaffelt?“ weniger wichtig als die Frage, ob die Support Level SLA Regelung überhaupt messbare Kennzahlen enthält. Viele Verträge, die wir in der Beratung sehen, sind in beiden Varianten zu vage – und damit im Ernstfall nicht durchsetzbar. Hilfe bei der Überprüfung bietet auch das ISO/IEC 27001 zertifizierte Leistungsportfolio der TTG GmbH, das klare Prozess- und Dokumentationsstandards voraussetzt.
Was die Praxis zeigt: Typische Ausgangslage in mittelständischen Betrieben
Typisch ist folgende Konstellation: Ein produzierender Betrieb mit 40 bis 80 Mitarbeitern betreibt ein ERP-System (z. B. proALPHA oder Sage), eine Windows-Serverinfrastruktur mit Active Directory und einen externen IT-Dienstleister, der per Rahmenvertrag „IT-Betreuung“ schuldet. Im Vertrag steht eine Reaktionszeit von vier Stunden – aber keine Abgrenzung, welche Support-Ebene gemeint ist. Der 2nd-Level-Techniker ist in Personalunion auch für andere Kunden zuständig; der Hersteller-Support läuft über eine separate Hotline, deren Kontaktdaten nur dem IT-Dienstleister bekannt sind.
Fällt das ERP aus, beginnt die Uhr zu ticken – aber welche Uhr? Die Reaktionszeit des Dienstleisters endet mit dem ersten Rückruf. Die eigentliche Entstörung beginnt danach. Liegt das Problem auf 3rd-Level-Seite (Datenbankkorruption, Lizenzproblem im Hersteller-Backend), kann die Lösungszeit mehrere Tage betragen – ohne dass der Dienstleister eine SLA-Verletzung begeht, weil seine Verantwortung vertraglich nicht weiter reicht.
Dieses Muster sehen wir regelmäßig – unabhängig von Branche oder Unternehmensgröße. Die Lösung ist nicht zwingend ein teureres Modell, sondern eine präzisere Support Level SLA Regelung: Welche Systeme fallen unter welche Prioritätsklasse? Wer eskaliert aktiv zum Hersteller? Welche Workaround-Pflicht besteht, bis das System vollständig wiederhergestellt ist?
Für Betriebe, die ihre IT-Infrastruktur strukturieren oder modernisieren möchten, lohnt sich ein Blick auf Förderprogramme: InnoInvest (Thüringer Aufbaubank, läuft bis 2029) unterstützt Digitalisierungsvorhaben mit bis zu 50.000 € – vorausgesetzt, der Antrag wird vor Projektbeginn gestellt. Weitere Informationen zu förderfähigen Maßnahmen finden Sie bei der Thüringer Aufbaubank – Förderprogramme. Ergänzend können KMU mit KI-Bezug die IT-Infrastruktur mit Förderung realisieren – die BAFA KI-Beratungsförderung übernimmt bis zu 80 % der Beratungskosten.
Die TTG GmbH begleitet solche Projekte seit über 25 Jahren und kennt die typischen Vertragslücken, die erst im Störungsfall sichtbar werden. Das schließt die Abstimmung mit dem Bitkom-Leitfaden für KMU-IT-Verträge ebenso ein wie die Dokumentation nach aktuellen Sicherheitsstandards.
Unsere Einschätzung: Welches Modell für welchen Betrieb – und worauf es wirklich ankommt
Wenn wir gefragt werden, welches Modell besser ist, lautet die ehrliche Antwort: Das kommt auf Ihren Vertrag an – nicht auf das Modell. Ein Full-Service-SLA mit vagen Formulierungen schützt weniger als ein gestaffeltes Modell mit präzisen Eskalationspfaden und messbaren KPIs. Die Support Level SLA Regelung ist entscheidender als die Vertragsstruktur dahinter.
Für Betriebe ohne eigenes IT-Personal empfehlen wir ein Full-Service-SLA mit explizit geregelter 2nd- und 3rd-Level-Abdeckung, definierten Prioritätsklassen und einer Workaround-Pflicht für P1/P2-Störungen. Für Betriebe mit internem IT-Mitarbeiter ist das gestaffelte Modell häufig effizienter – vorausgesetzt, die Eskalationslogik steht schwarz auf weiß im Vertrag.
Drei Punkte, die in keinem SLA fehlen dürfen – unabhängig vom Modell:
- Reaktionszeit ≠ Lösungszeit: Beide müssen separat definiert und messbar sein. Der Branchenstandard liegt bei 1–4 Stunden Reaktionszeit und 4–8 Stunden Lösungszeit für kritische Störungen – aber nur, wenn beides schriftlich fixiert ist.
- Kundenpflichten: Mitwirkungspflichten (Erreichbarkeit, Ticketqualität, Freigaben) gehören ins SLA. Fehlen sie, ist der Anbieter im Streitfall fein raus.
- NIS-2-Klauseln: Bestehende Verträge prüfen auf 24-h-Meldepflicht, Auditrechte und Lieferkettenbewertung – ggf. Nachtrag verhandeln, bevor Behörden prüfen.
Die Support Level SLA Regelung ist kein einmaliges Thema beim Vertragsabschluss. Sie sollte jährlich überprüft werden – spätestens wenn sich Ihre IT-Landschaft ändert, neue Systeme eingeführt werden oder regulatorische Anforderungen (NIS-2, DORA) das Unternehmen erstmals betreffen.
Wenn Sie wissen möchten, ob Ihr aktueller IT-Vertrag die wesentlichen Punkte abdeckt, sprechen Sie uns an. Ein erstes Gespräch bringt meistens schnell Klarheit – ohne aufwändige Analyse. Beratungsgespräch unverbindlich anfragen – wir melden uns innerhalb eines Werktages.
Auch Betriebe im Raum Eichsfeld, die bisher ohne schriftliche Eskalationsregeln arbeiten, profitieren von einer strukturierten Vertragsprüfung – oft reicht ein Nachtrag, um die größten Lücken zu schließen.
Ihre Checkliste: So starten Sie jetzt
- Prüfen Sie, welche Support-Ebenen (1st, 2nd, 3rd Level) Ihr aktueller IT-Vertrag explizit abdeckt – und welche ausgeschlossen sind.
- Fordern Sie eine schriftliche Eskalationsmatrix an: Wer eskaliert wann, auf welche Ebene, und wer trägt die Koordination zum Hersteller?
- Definieren Sie mindestens vier Prioritätsklassen (P1–P4) mit je eigener Reaktions- und Lösungszeit – P1 maximal 60 Minuten Reaktion, P4 bis 8 Stunden.
- Streichen Sie alle „Best Effort“-Formulierungen ohne konkrete Messgröße aus dem Vertrag oder lassen Sie diese durch messbare KPIs ersetzen.
- Verankern Sie Kundenpflichten schriftlich: Erreichbarkeit Key-User, Ticketqualität, Freigabeprozesse – ohne diese Punkte ist der Anbieter im Streitfall kaum in der Pflicht.
- Prüfen Sie Ihren Vertrag auf NIS-2-Konformität: 24-h-Meldepflicht, Auditrechte und Lieferkettenbewertung müssen explizit geregelt sein.
- Legen Sie maximal drei SLA-KPIs fest: First Response Time, Mean Time to Repair (MTTR) und SLA-Compliance-Rate – mehr Kennzahlen erhöhen den Auswertungsaufwand ohne proportionalen Nutzen.
- Informieren Sie sich über Förderprogramme (z. B. InnoInvest, BAFA KI-Beratungsförderung), bevor ein Digitalisierungsprojekt startet – das Vorabantragsprinzip gilt für alle Programme.
Häufig gestellte Fragen
Was bedeutet Reaktionszeit im SLA – und warum bin ich damit noch nicht aus dem Schneider?
Reaktionszeit bezeichnet den Moment, bis ein Techniker auf Ihre Anfrage reagiert – also eine erste Rückmeldung gibt. Sie sagt nichts darüber aus, wann Ihr System wieder läuft. Diese Verwechslung ist einer der häufigsten Irrtümer bei SLA-Verhandlungen. Bestehen Sie deshalb auf einer separaten, messbaren Lösungszeit (MTTR) für jede Prioritätsstufe. Nur so wissen Sie, womit Sie im Ernstfall wirklich rechnen können.
Brauchen wir als kleines Unternehmen wirklich eine Support Level SLA Regelung mit drei Ebenen?
Nicht zwingend drei separate Ebenen – aber klare Zuständigkeiten schon. Auch ein 10-Personen-Betrieb hat kritische Systeme (E-Mail, Buchhaltung, Zugriff auf Kundendaten). Wenn diese ausfallen und unklar ist, wer zuständig ist, entstehen schnell Ausfälle von einem ganzen Arbeitstag. Eine einfache, schriftlich fixierte Eskalationslogik schützt besser als ein aufwändiger Mehrseiten-SLA ohne messbare Kennzahlen.
Was kostet ein Business-SLA im Vergleich zum Standardvertrag – und lohnt sich das?
Business-SLAs kosten erfahrungsgemäß 20–35 % mehr als Standard-SLAs. Ob sich das lohnt, hängt davon ab, wie teuer ein Stunden-Ausfall für Ihren Betrieb ist. Fällt ein ERP-System für vier Stunden aus, sind Kosten durch Produktionsunterbrechung, Nacharbeit und Kundenkommunikation schnell höher als der monatliche SLA-Aufpreis für ein ganzes Quartal. Die Rechnung lohnt sich in den meisten Fällen.
Was hat NIS-2 mit unserem IT-Dienstleister-Vertrag zu tun?
NIS-2 verpflichtet betroffene Unternehmen, auch ihre IT-Zulieferer zu bewerten und Verantwortlichkeiten vertraglich zu regeln. Konkret bedeutet das: Incident-Response-Prozesse und 24-Stunden-Meldefristen müssen im SLA verankert sein. Bestehende Standard-SLAs großer Anbieter erfüllen diese Anforderungen häufig nicht. Wenn Ihr Unternehmen unter NIS-2 fällt, sollten Sie Ihren Vertrag zeitnah prüfen lassen – und ggf. einen Nachtrag verhandeln.
Können wir Fördergelder für die Überprüfung oder Neugestaltung unserer IT-Verträge nutzen?
Direkt für Vertragsberatung sind Fördermittel selten vorgesehen. Allerdings fördert die BAFA KI-Beratungsförderung bis zu 80 % der Kosten für strategische IT-Beratung bei KMU. InnoInvest (Thüringer Aufbaubank) unterstützt Digitalisierungsprojekte mit bis zu 50.000 €, wenn die Investition mindestens 30.000 € beträgt. Wichtig: Der Antrag muss vor Projektbeginn genehmigt sein. Lassen Sie sich vorab beraten, welches Programm zu Ihrem Vorhaben passt.
Martin Trappe ist Geschäftsführer der TTG Daten- und Bürosysteme GmbH in Dingelstädt. Mit über 25 Jahren Erfahrung im IT-Mittelstand betreut er kleine und mittelständische Unternehmen in Nordthüringen, Eichsfeld und Südniedersachsen. Die TTG GmbH ist ISO/IEC 27001 zertifiziert – dem höchsten Standard für Informationssicherheit.
Kontakt aufnehmen · Über TTG GmbH
Wissen Sie gerade, welche Ihrer Systeme bei einem Ausfall wie lange ungeschützt wären – und wer in diesem Fall auf welcher Vertragsebene zuständig ist?
IT-Betreuung abgeben, die funktioniert
Störungen, Updates, Backups und Sicherheit laufend betreut – mit festen Ansprechpartnern und klaren Reaktionszeiten. Die TTG GmbH betreut KMU in Nordthüringen und Eichsfeld.
