Zutrittssysteme: Service-Level-Matrix für Sicherheitsdienste
Facility Management: Zutritt » Ausschreibung » Services » SLA-Matrix

Anhang A: Service Levels und SLA-Kennzahlen
In diesem Anhang werden die Service Level und SLA-Kennzahlen (Service Level Agreement Kennzahlen) für sicherheitstechnische Systeme eines KRITIS-Unternehmens der Schwerindustrie tabellarisch zusammengefasst. Berücksichtigt sind anerkannte Branchenstandards und Richtlinien (z. B. BSI IT-Grundschutz, ISO/IEC 27001, ISO/IEC 20000, VdS 3406, VDI 3810 Blatt 6) sowie hypothetische Best-Practice-Zielwerte für ein hochkritisches Zutrittskontrollsystem mit 24/7-Betrieb, hoher Integrationstiefe (Schnittstellen zu Zeitwirtschaft, Fremdfirmenportal, Sicherheitstechnik) und einer aktiven Innovationspartnerschaft. Die Tabelle gibt einen Überblick; im Anschluss wird jede SLA-Kennzahl und -Kategorie ausführlich erläutert.
SLA-Matrix: Sicherheitsrelevante Leistungen strukturiert bewerten
Übersichtstabelle: SLA-Kategorien, Definitionen und Zielvorgaben
SLA-Kennzahl | Klassifizierung / Definition | Typische Vorgaben & Best-Practice-Zielwerte |
---|---|---|
Prioritätsklassen (Störung) | Einteilung der Störungen nach Dringlichkeit und Auswirkung. Üblich sind vier Prioritätsstufen: Kritisch – regulärer Betrieb nicht möglich (Systemausfall, zentrale Funktionen ausgefallen); Hoch – erhebliche Beeinträchtigung des Betriebs (wichtige Funktionen gestört, Workaround begrenzt möglich); Mittel – moderate Beeinträchtigung (einzelne Bereiche betroffen, Workaround möglich); Niedrig – geringfügige Störung (leichte Einschränkung einzelner Nutzer, rein kosmetisches Problem). | 4-Klassen-Modell branchenüblich. Kritisch (Prio 1): gesamte Anlage betroffen; Hoch (Prio 2): größerer Teil betroffen; Mittel (Prio 3): begrenzter Teil/Nutzer betroffen; Niedrig (Prio 4): kaum Auswirkung. Diese Priorisierung entspricht ITIL/ISO 20000-Best Practices und bildet die Grundlage für differenzierte Reaktions-/Lösungszeiten je Stufe. |
Reaktionszeit (Response Time) | Zeit bis zur ersten Reaktion auf eine Störungsmeldung (z. B. Bestätigung und Beginn der Problembearbeitung). Wird ab Eingang der qualifizierten Meldung gemessen. Hohe Priorität erfordert schnelle Reaktion, z. B. sofort oder innerhalb Minuten. Niedrige Priorität erlaubt längere Reaktionszeit (innerhalb Stunden oder am nächsten Werktag). | Standards: SLA-Vereinbarungen definieren verbindliche Reaktionszeiten je Priorität (ISO 20000 fordert definierte Reaktionsziele). Branchenübliche Werte: Kritisch: innerhalb 30–60 Minuten; Hoch: ≤ 2 Stunden; Mittel: ≤ 8 Stunden; Niedrig: 1 Werktag. Best Practice (KRITIS Zutrittskontrolle): Kritisch < 30 Min (24/7, ggf. automatische Alarmierung), Hoch < 1 h, Mittel < 4 h, Niedrig < 8 h (innerhalb Servicezeit), um schnelle Störungsbearbeitung sicherzustellen. |
Wiederherstellungszeit (Recovery Time) | Zeit bis zur vollständigen Wiederherstellung der Systemfunktion nach einer Störung (Ende der Behebung). Oft zweistufig: temporärer Workaround zur Betriebsaufrechterhaltung und danach finale Behebung. Abhängig von Störungspriorität und Komplexität. Kritische Ausfälle erfordern kürzeste Wiederanlaufzeit (Stunden), weniger kritische dürfen länger dauern (Tage). | Typische Ziele: Festlegung als RTO (Recovery Time Objective) je Priorität. Z. B. Kritisch: 4–8 Stunden (ggf. mittels Workaround binnen 1–2 h); Hoch: 24 Stunden; Mittel: 72 Stunden; Niedrig: 5–10 Tage. Best-Practice für 24/7 Zutrittskontrollsystem: Kritische Störung < 4 h behoben (Workaround sofort, z. B. manuelle Zutrittskontrolle durch Wachdienst, und dauerhafte Reparatur in <4h); Hoch: < 8–24 h; Mittel: ≤ 72 h; Niedrig: im nächsten planmäßigen Wartungsfenster (ca. 1 Woche). |
Zielverfügbarkeit (Uptime) | Betriebszeit-Verfügbarkeit des Systems, meist als Prozentsatz der Zeit pro Jahr (oder Monat), in der das System uneingeschränkt funktionsfähig ist. Kritische Infrastrukturen verlangen hohe Verfügbarkeiten. Unterbrechungen (geplante Wartung + ungeplante Ausfälle) sollten minimiert werden. | Branchenstandard: In der Industrie gelten 99,9 % Verfügbarkeit (≈ VK-2, max. ~8,8 h Ausfall/Jahr) oft als Mindestwert. BSI definiert Verfügbarkeitsklassen: z. B. VK-3 = 99,99 % (hochverfügbar, <53 min Ausfall/Jahr). Best-Practice-Ziel (KRITIS): mindestens 99,99 % (Vier Neunen) Uptime, ggf. durch redundante Systeme (Failover-Server, USV etc.) – entspricht hoher Verfügbarkeitsklasse für KRITIS-Systeme. |
Unterstützungsleistungen bei Ausfällen | Support-Leistungen des Dienstleisters im Störungsfall. Umfasst Remote-Support (Fehleranalyse, Neustarts, Patch-Einspielung via Fernzugriff) und Vor-Ort-Service, falls Hardware-Eingriff nötig. Beinhaltet auch Ersatzteillogistik: Vorhalten kritischer Ersatzteile und deren schnelle Bereitstellung. Wichtig ist 24/7-Erreichbarkeit einer Hotline und gestaffelte Support-Level (First-Level für Annahme, Second-Level für Technik) zur effizienten Entstörung. | Standards: ISO 20000 und VdS 3406 fordern definierte Serviceprozesse und Ressourcen. Praxis: 24/7-Service für kritische Systeme, Helpdesk jederzeit erreichbar. Remote-Analyse sofort bei Meldung. Vor-Ort-Techniker bei kritischen Ausfällen innerhalb 2–4 Stunden verfügbar (Vertraglich oft 4h Onsite bei Prio 1). Ersatzteile: entweder vorab vor Ort gelagert oder Lieferung innerhalb weniger Stunden. Best Practice: Wartungsvertrag mit garantierter Wiederherstellung innerhalb 4 h (oder 6/8 h je nach Vereinbarung) durch Bereitstellung von Ersatzteilen und Fachtechnikern. Außerdem präventive Wartung (VDI 3810) zur Vermeidung von Ausfällen. |
Monitoring & Reporting | Überwachung des Systemstatus und Berichtswesen über SLA-Einhaltung. Dazu gehört kontinuierliches Monitoring (z. B. automatische Störungsmeldungen durch das Zutrittskontrollsystem oder SIEM-Anbindung) und regelmäßiges SLA-Reporting an den Kunden. Eskalationsmanagement: vordefinierte Prozesse, um Vorfälle, die nicht fristgerecht gelöst werden, an höhere Stellen zu eskalieren. Ebenso werden regelmäßige Service-Meetings zur Review der Leistungskennzahlen abgehalten. | Branchenvorgaben: BSI und ISO 27001 verlangen fortlaufende Überwachung sicherheitskritischer Systeme und Behandlung von Sicherheitsvorfällen (BSI ORP.3). Üblich: Monatliches SLA-Reporting mit Kennzahlen (Verfügbarkeit, Reaktions-/Lösungszeiten, Ausfallursachen). Eskalationsverfahren sind Bestandteil des SLA – z. B. automatische Management-Info, wenn kritische Störung > X Stunden dauert. Best Practice: Einrichtung eines Dashboards für Live-Monitoring, sofortige Alarmierung bei Störung, monatliche Review-Meetings zur SLA-Performance sowie jährliche Strategiegespräche mit dem Dienstleister. In einer Innovationspartnerschaft werden im Reporting auch Verbesserungsvorschläge und neue Technologien besprochen. |
Erläuterungen zu den SLA-Kategorien und Kennzahlen
Im Folgenden werden die obigen Kategorien detaillierter erläutert. Neben praxisnahen Best-Practice-Werten werden auch relevante Standards und Richtlinien zitiert, um die Fundierung dieser SLA-Anforderungen zu unterstreichen.
Prioritätsklassen für Störungen (Kritisch/Hoch/Mittel/Niedrig)
Zur effektiven Störungsbearbeitung werden Vorfälle nach Priorität klassifiziert. Diese Priorisierung richtet sich maßgeblich nach der Auswirkung auf den Geschäftsbetrieb und der Dringlichkeit der Reaktion.
Üblich sind vier Stufen, etwa analog zu ITIL/ISO 20000:
Kritisch (Priority 1): Sehr schwere Störung, der reguläre Betrieb ist nicht mehr möglich. Ein kompletter Systemausfall oder der Ausfall zentraler Funktionen führt zu einer unternehmensweiten Geschäftsunterbrechung. Beispiel: Das gesamte Zutrittskontrollsystem ist ausgefallen – kein Mitarbeiter oder Dienstleister kann das Werk betreten/verlassen. Sofortige Aufmerksamkeit ist erforderlich (Notfall).
Hoch (Priority 2): Erhebliche Störung, geschäftskritische Abläufe sind stark beeinträchtigt, jedoch läuft das Gesamtsystem noch eingeschränkt. Z.B. Ausfall eines wichtigen Teilsystems oder einer Schnittstelle, wodurch einzelne Bereiche oder viele Nutzer betroffen sind. Arbeiten sind nur mit Umgehungsmaßnahmen oder Performance-Einbußen möglich. Schnelle Entstörung ist nötig, wenn auch nicht ganz so unmittelbar wie bei kritisch.
Mittel (Priority 3): Moderat wichtige Störung, begrenzte Auswirkungen auf den Betrieb. Oft sind einzelne Abteilungen oder Funktionen beeinträchtigt, jedoch existieren Workarounds und der Großteil des Systems läuft weiter. Beispiel: Eine einzelne Zutrittskontroll-Lesergruppe in einem Nebengebäude ist ausgefallen, aber alternative Eingänge sind verfügbar. Die Behebung kann im Rahmen der nächsten Routineeinsätze erfolgen, sollte aber dennoch fristgerecht (z. B. innerhalb 2–3 Tagen) passieren.
Niedrig (Priority 4): Geringfügige Störung ohne nennenswerte Betriebsbeeinträchtigung. Oft kosmetische Fehler oder Komforteinschränkungen. Beispiel: Eine Anzeigefunktion im Besucher-Portal funktioniert nicht korrekt, aber alle sicherheitsrelevanten Funktionen laufen. Kein dringender Handlungsbedarf; Bündelung mit planmäßiger Wartung möglich.
Diese Kategorisierung spiegelt anerkannte Best Practices wider und wird z. B. vom BSI-Grundschutz empfohlen, um Risiken systematisch zu bewerten. Eine klare Definition jeder Klasse ist wichtig, damit Kunde und Serviceanbieter ein gemeinsames Verständnis der Schweregrade haben. In Service Level Agreements wird oft eine Tabelle mit den Prioritätsstufen, Kriterien und Beispielen aufgenommen. So beschreibt z. B. ein Anbieter: „Fehlerklasse 1 = Critical: Es kommt zu einer sehr ernsten Beeinträchtigung des Geschäftsablaufs im gesamten Unternehmen… völliger Systemstillstand…; Fehlerklasse 2 = Major: mittelschwere Beeinträchtigung… bei einzelnen Abteilungen…; Fehlerklasse 3 = Minor: leichte Beeinträchtigung einzelner Anwender, Schönheitsfehler“. Diese Einstufungen legen die Basis für die nachfolgenden SLA-Kennzahlen (Reaktionszeiten, Wiederherstellungszeiten etc.), da höhere Prioritäten strengere Vorgaben erhalten.
Reaktionszeiten (Response Time Objectives)
Die Reaktionszeit bezeichnet den Zeitraum vom Eingang einer Störungsmeldung bis zur ersten Reaktion des Dienstleisters. Eine Reaktion kann z. B. die Bestätigung der Störung und der Beginn von Diagnose-/Eindämmungsmaßnahmen sein. Kurze Reaktionszeiten sind entscheidend, um den Kunden zu beruhigen und mit der Problembehebung zu starten. In vielen SLAs ist festgelegt, dass der Dienstleister zunächst innerhalb einer bestimmten Frist aktiv auf die Meldung reagieren muss (z. B. per Anruf oder E-Mail), um zu bestätigen: „Wir haben den Vorfall erhalten und arbeiten daran.“.
Branchenüblich werden Reaktionszeiten nach Störungspriorität gestaffelt. Kritische Vorfälle verlangen sofortige Aufmerksamkeit – hier werden in der Praxis Reaktionszeiten von 15 bis 60 Minuten vereinbart. Beispielsweise garantiert ein SLA einer Sicherheitsleitstelle eine 30-minütige Reaktionszeit (24/7) ab Alarmierung für kritische Ereignisse. Hohe Priorität (schwerer Fehler, aber nicht völliger Ausfall) liegt häufig bei 1–2 Stunden bis zur Reaktion. Mittlere Priorität kann innerhalb einiger Stunden (typisch 4–8 Stunden während der Servicezeiten) beantwortet werden. Niedrige Priorität – z. B. ein triviales Problem – wird oft mit Reaktion bis zum nächsten Geschäftstag festgelegt (z. B. 1 Werktag).
Standards und Frameworks wie ISO/IEC 20000 (IT Service Management) fordern, dass für jeden definierten Incident-Typ Serviceziele festgelegt werden, einschließlich Reaktionszeiten je Priorität. Der ITIL-Leitfaden empfiehlt eine Priorisierungsmatrix aus Impact und Urgency, um die Reaktionszeit entsprechend festzulegen. Dies sorgt für effiziente Ressourcenzuteilung – kritische Tickets werden zuerst bearbeitet.
Im Kontext eines KRITIS-Zutrittskontrollsystems (hochkritisch, 24/7) wären besonders ambitionierte Reaktionszeiten wünschenswert: Bei einem kompletten Ausfall der Zutrittssteuerung (Prio 1) sollte der Dienstleister z. B. innerhalb 15 Minuten reagieren (automatisierte Alarmmeldungen aus dem System, unmittelbarer Anruf des Service-Verantwortlichen). Kleinere Störungen könnten eine etwas längere Frist haben, aber auch hier sind proaktive Überwachung und schnelle Rückmeldung wichtig. Monatliche Berichte sollten die Einhaltung der Reaktionszeitziele ausweisen, damit der Betreiber sieht, ob der Dienstleister vertragstreu schnell genug reagiert.
Ein Beispiel aus einem SLA eines Cloud-Dienstleisters (Bynder) zeigt eine ähnliche Staffelung: Priorität A (hochkritisch) – Reaktionszeit innerhalb 1 Stunde, Priorität B – innerhalb 24 Stunden, C – 48 Stunden, D – 48 Stunden. Für ein sicherheitstechnisches System in der Schwerindustrie wären jedoch deutlich kürzere Zeiten für die höheren Prioritäten angebracht (wie oben skizziert), da hier physische Sicherheit und Produktionsschutz auf dem Spiel stehen.
Wiederherstellungszeiten (Recovery Time Objectives)
Die Wiederherstellungszeit beschreibt, wie schnell das System nach einer Störung wieder voll funktionsfähig ist. Sie wird oft als RTO (Recovery Time Objective) in Business-Continuity-Planungen definiert – d. h. die maximal tolerierte Wiederanlaufzeit. In SLAs wird hierzu festgelegt, binnen welcher Zeit der Service wiederhergestellt sein muss.
Wichtig ist zu unterscheiden: Nicht jeder Vorfall kann sofort komplett behoben werden – deshalb arbeiten viele Dienstleister mit Zwischenlösungen (Workarounds). Beispielsweise könnte bei Ausfall des Zutrittskontroll-Servers ein ersatzweises manuelles Zutrittsverfahren durch den Werkschutz eingeleitet werden (Liste berechtigter Personen, Notfallausweise etc.), um den Betrieb übergangsweise aufrecht zu erhalten. Endgültige Wiederherstellung (z. B. Tausch des defekten Servers und Neustart des Systems) erfolgt dann innerhalb der vereinbarten Frist.
Die vorgesehene Wiederherstellungszeit hängt von der Priorität ab und wird in abgestufter Form vereinbart. Typische Beispiele aus der Praxis:
Kritische Störung (Prio 1): Wiederherstellung in 4 Stunden. D.h. innerhalb von 4h muss entweder der Normalbetrieb wieder laufen oder ein akzeptabler Workaround implementiert sein. In hochverfügbaren Umgebungen wird teils sogar 2 Stunden oder weniger für die Wiederinbetriebnahme vereinbart – oft nur erreichbar durch redundante Komponenten (Failover). NetCologne IT Services z. B. sieht im höchsten SLA „Platinum“ vor: Workaround in 1 Stunde, finale Reparatur in 5 Werktagen, bei „Gold“: Workaround in 4h. Für ein KRITIS-System wäre ein Workaround sofort (<1h) und dauerhafte Lösung <4h anzustreben (ggf. durch Austausch auf Cold-Standby-System).
Hohe Priorität (Prio 2): Wiederherstellung häufig bis Ende des nächsten Tages (~ innerhalb 24 Stunden). Beispiel: In Bynders SLA ist für „kritische Störungsmeldung“ (ihrer zweithöchsten Kategorie) sowohl Reaktion als auch Lösung innerhalb 24 Stunden vorgesehen. In unserem Umfeld könnte man anpeilen: 8–24h bis zur Lösung, da ein Zutrittssystem für Teilbereiche ausgefallen zwar störend ist, aber mit Notmaßnahmen (z. B. einzelnen Türen manuell besetzen) kurzfristig überbrückbar.
Mittlere Priorität (Prio 3): Wiederherstellung innerhalb 72 Stunden (3 Tagen) ist üblich, teils auch bis zu 5 Werktage. Hier kann die Behebung z. B. mit einer regulären Wartungsfahrt kombiniert werden. NetCologne SLA Gold sieht final 10 Werktage für minor issues vor, aber 72h wären für sicherheitstechnische Systeme kundenfreundlicher.
Niedrige Priorität (Prio 4): „Best Effort“ – kein verbindliches Zeitlimit außer ggf. “innerhalb der nächsten Wartung” (z. B. < 2 Wochen). Oft werden geringfügige Fehler in größeren Updates gesammelt. Bynder deklariert z. B. für niedrigste Priorität lediglich „beste Bemühungen“ statt eines festen Ziels.
Generell fordern Standards wie BSI-Standard 200-4 (Notfallmanagement) und ISO 22301 (Business Continuity) die Festlegung von RTO-Werten für kritische Prozesse. Ein KRITIS-Betreiber muss definieren, wie lange ein sicherheitskritisches System maximal ausfallen darf, ohne dass gravierende Folgen entstehen. Für unser schwerindustrielles Beispielunternehmen würde man diese maximal tolerierbare Ausfallzeit sehr kurz ansetzen (wenige Stunden), da ein längerer Ausfall des Zutrittssystems Sicherheitsrisiken (Unbefugte könnten die Anlage betreten) und Betriebsunterbrechungen (Mitarbeiter können ihre Arbeitsplätze nicht erreichen) verursacht.
Zur Einhaltung kurzer RTOs sind technische und organisatorische Vorkehrungen nötig: z. B. hochverfügbare Architektur (Redundanz, Cluster, USV-Stromversorgung), vorbereitete Notfallprozesse (Handersatzverfahren mit Wachdienst) und geschultes Personal, das im Ernstfall schnell reagiert. SLA-Vereinbarungen machen diese Erwartungen verbindlich und oft mit Strafzahlungen im Nichterfüllungsfall untermauert (z. B. pro überschrittener Stunde Ausfall eine Gutschrift).
Zielverfügbarkeiten (Uptime in %)
Für sicherheitstechnische Systeme in kritischen Infrastrukturen ist die Verfügbarkeit ein zentrales Kriterium. Sie wird meist als Prozentsatz an Betriebszeit pro Jahr angegeben.
Ein häufig genutzter Maßstab sind die sogenannten „Neunen“: z. B. 99 % (zwei Neunen), 99,9 % (drei Neunen) usw., was immer geringere Ausfallzeiten bedeutet:
Branchenstandards: Das BSI hat für Rechenzentren eine Klassifizierung entwickelt, die auch allgemein verwendet wird. Dabei entspricht z. B. 99,9 % Verfügbarkeit (VK-2) einer max. Ausfallzeit von ~8 Stunden 46 Minuten pro Jahr, 99,99 % (VK-3) etwa 53 Minuten, 99,999 % (VK-4) ca. 5–6 Minuten. In kritischen Bereichen wird häufig mindestens 99,9 % gefordert – Cloud-Dienste werben typischerweise mit „Three Nines“ als Mindeststandard. Allerdings reichen 99,9 % in der Praxis oft nicht aus, da dies noch fast 9 Stunden Ausfall pro Jahr bedeuten kann.
Best Practices: Für ein 24/7-betriebenes Zutrittskontrollsystem eines KRITIS-Betriebs sollte eher 99,99 % angestrebt werden, was <1 Stunde Ausfall/Jahr bedeutet. Dies qualifiziert als hochverfügbares System nach allgemeiner Definition. In einzelnen Fällen (etwa bei höchst sicherheitskritischen Anlagen) könnte sogar 99,999 % ins Visier genommen werden, wobei dies extrem aufwendig ist – erlaubt nur ~5 Minuten Downtime pro Jahr und erfordert voll redundante disaster-tolerante Architekturen. Das BSI definiert sogar eine Klasse VK-5 „Disaster Tolerant“, bei der Funktion unter allen Umständen gewährleistet sein muss (z. B. durch geo-redundante Systeme). Für unser Szenario ist VK-3 oder VK-4 realistisch und bereits sehr hoch.
Um solche Verfügbarkeiten zu erreichen, werden im SLA entsprechende Maßnahmen und Monitoring vereinbart: Permanente Überwachung (zur Früherkennung von Problemen), regelmäßige Wartung (Vermeidung von Ausfällen) und schnelle Reaktion/Wiederherstellung wie oben beschrieben. Redundanzen (z. B. zwei parallel laufende Zutrittsserver in Hot-Standby) sind praktisch unumgänglich für >99,9%. Eine USV (unterbrechungsfreie Stromversorgung) für alle sicherheitsrelevanten Komponenten ist Stand der Technik (z. B. fordert VdS und BSI für Alarmempfangs- und Zutrittssysteme Akkupuffer, oft 72 Stunden für KRITIS).
Verfügbarkeitsnachweis: Im SLA-Reporting wird meist die Ist-Verfügbarkeit monatlich und jährlich dokumentiert, z. B.: Bynder garantiert 99,9 % monatliche Verfügbarkeit und berechnet diese als (Gesamtzeit – Ausfallzeit) / Gesamtzeit. Bei Unterschreitung greifen Vertragsstrafen/Gutschriften. Für unseren Anwendungsfall würde der Dienstleister z.B. verpflichtet, Ausfälle sofort zu melden und ggf. der Kunde hätte Anspruch auf SLA-Gutschriften, falls die jährliche Uptime unter 99,99 % fällt.
Unterstützungsleistungen bei Ausfällen (Support, Ersatzteile, etc.)
Neben Zeiten und Prozentwerten müssen in einem SLA auch die qualitativen Unterstützungsleistungen festgelegt sein, die der Servicepartner im Störungs- oder Wartungsfall erbringt.
Gerade in der Sicherheitstechnik spielt der Supportumfang eine große Rolle:
Remote-Support: Viele Probleme lassen sich per Fernzugriff diagnostizieren oder beheben. Ein SLA sollte festlegen, dass ein Fernsupport 24/7 erreichbar ist (z. B. Hotline oder Leitstand). Oft gibt es einen 1st-Level (nimmt Meldungen auf, leitet einfache Schritte ein) und einen 2nd-Level-Support (Fachtechniker), der via VPN/Fernwartung aufs System zugreifen kann. Beispiel: Ein SLA von K&P IT-Service garantiert einen Rund-um-die-Uhr Support für Hardware mit 30 Min Reaktionszeit am Telefon – übertragen auf Zutrittssysteme hieße dies: jederzeit ein Techniker, der binnen Minuten zurückruft und remote erste Hilfe leistet.
Vor-Ort-Service: Nicht alle Störungen lassen sich aus der Ferne beheben (Hardwaredefekte, Verkabelungsprobleme, Türsteuerungen etc.). Daher werden Onsite-Einsätze vereinbart. Für kritische Anlagen ist ein 24/7-Bereitschaftsdienst üblich, der im Ernstfall Techniker ins Werk schickt. Die maximale Vor-Ort-Ankunftszeit wird als SLA-Kriterium festgelegt, z. B. „bei Prio 1 Störung innerhalb von 4 Stunden vor Ort“. Branchenüblich sind je nach SLA-Level verschiedene Servicefenster: z.B. 9/5 (Werktags 9h), 13/5, 24/7 und entsprechende Eintreffzeiten. In einem Premium-SLA könnte stehen: „Techniker-Einsatz vor Ort garantiert in 2 Stunden (Prio 1) bzw. 4 Stunden (Prio 2), rund um die Uhr.“
Ersatzteil-Logistik: Ein oft unterschätzter Faktor. Ersatzteile (z. B. Zutrittscontroller, Leser, Server-Komponenten) sollten verfügbar sein, damit die Wiederherstellung nicht an Lieferzeiten scheitert. Best Practice ist, kritische Ersatzteile beim Kunden vorzuhalten oder beim Serviceprovider in nächster Nähe. Manche Dienstleister unterhalten eigene Lager und garantieren z. B. Ersatzteil innerhalb 2 Stunden vor Ort. Alternativ wird eine bestimmte Wiederherstellungszeit garantiert, innerhalb derer ein defektes Teil ersetzt sein muss (z. B. 6h vor Ort Repair für Serverausfall). In der Tabelle der K&P-Services werden Optionen 4/6/8/12/24h Wiederherstellung angeboten – auf unser Zutrittssystem übertragen könnte man mindestens 8h, besser 4h fix vereinbaren für kritische Komponenten.
Zusatzleistungen: Dazu zählen regelmäßige Wartungstermine (präventive Instandhaltung gemäß z. B. VDI 3810, um Ausfälle zu vermeiden), Software-Updates (Einspielen von Sicherheitsupdates außerhalb der Betriebszeiten, um die Verfügbarkeit hoch zu halten), sowie Schulungen des Betreiberpersonals für den Umgang mit Störungen. In einer Innovationspartnerschaft könnte der Dienstleister außerdem Proaktive Verbesserungen anbieten – z. B. Vorschläge für Systemoptimierungen, Technologietrends (Biometrie, neue Firmware) – und den Kunden als Beta-Tester neuer Features einbeziehen, um einen Wissensvorsprung zu schaffen.
Für Entscheider im Facility- und Sicherheitsmanagement ist es wichtig, dass diese Unterstützungsleistungen vertraglich klar umrissen sind. Ein SLA sollte Kontaktwege und Reaktionsabläufe im Detail beschreiben: etwa “Störungsmeldungen sind über Hotline oder Web-Portal 24/7 möglich; der Dienstleister beginnt spätestens innerhalb 30 Min mit der Fehlerdiagnose remote. Kann die Störung nicht innerhalb 2h behoben werden, wird automatisch ein Techniker entsandt”. Auch Eskalationsstufen gehören dazu (wer wird informiert, wenn Fristen verstreichen – z.B. Security Manager, ggf. behördliche Meldung bei KRITIS-Vorfällen).
Monitoring- und Reportingpflichten (Überwachung, SLA-Reports, Eskalation)
Gerade in einem KRITIS-Umfeld verlangen die Regulatorik (BSI-Gesetz, IT-Sicherheitsgesetz) und Standards (ISO 27001) eine lückenlose Überwachung sicherheitsrelevanter Systeme und eine Nachweisführung über deren Betriebssicherheit.
Daher sind in SLAs typischerweise folgende Punkte vereinbart:
System-Monitoring: Der Dienstleister muss geeignete Monitoring-Tools einsetzen, um den Zustand des Zutrittskontrollsystems fortlaufend zu beobachten (Health-Checks, Verfügbarkeitsprüfung, Fehlermeldungen). Oft werden Schnittstellen zu einem SIEM (Security Information and Event Management) oder einem Leitstand definiert. So können Anomalien frühzeitig erkannt und gemeldet werden. Beispielsweise könnte das Zutrittssystem selbst Herzschlag-Meldungen an eine Leitstelle senden; bleibt ein Herzschlag aus, wird automatisch ein Alarmticket erzeugt.
SLA-Reporting: Ein guter SLA beinhaltet die Pflicht zu regelmäßigen Berichten. In der Regel werden monatliche SLA-Reports erwartet. Darin enthalten: Uptime-Metriken des letzten Monats, Anzahl Störungen nach Priorität, durchschnittliche und maximale Reaktions-/Lösungszeiten, erfüllte und nicht erfüllte SLA-Ziele, Trendanalysen usw. Dieses Reporting schafft Transparenz für den Kunden und bildet die Grundlage für SLA-Review-Gespräche. Cisco empfiehlt z.B. monatliche Service-Level-Review-Meetings, um die Einhaltung zu prüfen und Verbesserungen einzuleiten.
Eskalationsmanagement: Hierbei geht es um definierte Prozesse, wenn etwas nicht nach Plan läuft. Ein SLA sollte Eskalationsstufen festlegen: wen kontaktiert der Dienstleister, wenn z.B. eine kritische Störung nicht binnen der Zielzeit gelöst werden kann (z.B. Kunde-Management informieren, gemeinsam Notfallmaßnahmen entscheiden). Umgekehrt muss der Kunde wissen, wen er beim Dienstleister ansprechen kann, wenn er mit der Bearbeitung unzufrieden ist (z.B. Eskalation an den Service-Manager, dann an die Geschäftsführung des Anbieters). In ITIL und SLA-Standards gilt: Eskalationswege (fachlich und hierarchisch) gehören in jede SLA-Dokumentation. Im Sicherheitsbereich könnte eine Eskalationsregel lauten: “Bei Ausfall der Zutrittskontrolle > 1 Stunde muss der KRITIS-Koordinator informiert werden und der Dienstleister hat unverzüglich manuelle Sicherungsmaßnahmen (Wachpersonal) bereitzustellen.” Solche Vorkehrungen vermeiden, dass ein SLA-Verstoß ungeplant zum Sicherheitsvorfall wird.
Performance Review & Innovation: In einer Innovationspartnerschaft geht Reporting über das bloße Messen von KPIs hinaus. Es werden Qualitätskennzahlen diskutiert und Verbesserungsmaßnahmen abgeleitet. Z.B. kann im Quartalsbericht erkannt werden, dass wiederholt Störungen an einer Schnittstelle auftraten – dann erwartet der Kunde Vorschläge zur dauerhaften Lösung oder Modernisierung. Ebenso können neue Anforderungen (z.B. Integration eines neuen Fremdfirmenportals) und Technologietrends gemeinsam erörtert werden. Eine Best Practice ist hier, im SLA jährliche Strategiemeetings festzuschreiben, in denen der Dienstleister Beratungsleistungen zur Weiterentwicklung der Sicherheitsinfrastruktur erbringt.
Es stellen Monitoring und Reporting sicher, dass der Betrieb des sicherheitstechnischen Systems transparent und unter Kontrolle ist. Für KRITIS-Betreiber ist dies auch gegenüber Aufsichtsbehörden relevant – dokumentierte SLA-Berichte können im Audit zeigen, dass man die Verfügbarkeit und Sicherheit der Anlage aktiv managt. Die regelmäßige Überprüfung der SLA-Kennzahlen fördert einen kontinuierlichen Verbesserungsprozess, wie ihn sowohl ISO 9001 als auch ISO 27001 fordern.
Durch die Kombination aller obigen Elemente – klare Prioritäten, messbare Zeiten, hohe Verfügbarkeit, robusten Support sowie Monitoring/Eskalation – entsteht ein ganzheitliches SLA für ein Zutrittskontrollsystem. Dieses SLA stellt sicher, dass sowohl vertraglich zugesicherte Service Levels eingehalten werden, als auch dass im Ernstfall die richtigen Maßnahmen schnell ergriffen werden, um Sicherheit und Betrieb aufrechtzuerhalten. So wird wissenschaftlich fundiert (durch Standards untermauert) und praxisnah (durch Best-Practice-Werte) dargestellt, wie Service Levels im Facility Management für kritische Sicherheits-Systeme gestaltet werden können.