Von der Regime-Anforderung zur betrieblichen Kompetenz
Ein Regime benennt eine Erwartung. Das Unternehmen muss daraus wiederkehrende Arbeit ableiten: Wer muss handeln, welche Daten werden benötigt, welche Entscheidung ist erforderlich, was wird umgesetzt und wann wird erneut geprüft? Der Nachweis zeigt später, ob diese Kette funktioniert hat.
Regime ändern sich. Kompetenzen bleiben.
Mehr Regime bedeuten nicht automatisch mehr parallele Compliance-Strukturen. Die meisten dieser Anforderungen betrachten denselben Betrieb aus verschiedenen Blickwinkeln. Daten, Zuständigkeiten und Entscheidungen gehören im Alltag ohnehin zusammen.
Eine Regime-Anforderung wird im Unternehmen erst wirksam, wenn eine verantwortliche Rolle sie in einem wiederkehrenden Prozess bearbeitet, Entscheidungen dokumentiert, Maßnahmen umsetzt und die nächste Prüfung festlegt.
Der Nachweis steht am Ende dieser Kette. Er zeigt, wer gehandelt hat, auf welcher Grundlage entschieden wurde, was umgesetzt wurde und welche Punkte offen bleiben.
Ein neuer Mitarbeiter startet — und mit ihm ein Dutzend Compliance-Fragen
Ein neuer Mitarbeiter fängt an. Das Unternehmen will ihn schnell arbeitsfähig machen. Im selben Atemzug entstehen sicherheits- und compliancerelevante Daten: seine Rolle, der Systembedarf, Berechtigungen, die Freigabe, MFA, vielleicht eine Ausnahme, die Schulung und die spätere Überprüfung.
Für eine spätere Prüfung muss niemand diese Daten neu zusammensuchen, sofern der Prozess sie von Anfang an sauber führt. Genau darum geht es in diesem Beitrag: Eine Anforderung trifft auf einen Prozess, der bereits läuft und die relevanten Daten und Entscheidungen mitführt.
Sobald Rolle, Systembedarf, Freigabe, MFA, Schulung, Nachweis und Wiedervorlage im Ablauf zusammenspielen, wird aus einer Richtlinie eine gelebte Routine. Der Vorgang zeigt später, wer entschieden hat, was umgesetzt wurde, welche Ausnahme offen blieb und wann erneut geprüft wird.
Jedes Regime stellt eigene Erwartungen — und meint doch oft dieselbe Realität
NIS2 und das nationale BSIG, CRA, DORA, der AI Act, ISO 27001, IEC 62443, das Business Continuity Management: Sie unterscheiden sich in Geltungsbereich, Adressaten, Sprache, Fristen, Aufsicht und Prüftiefe. Wer eine konkrete Anforderung bedient, muss klären, welche Pflicht gilt, welche Rolle verantwortlich ist und welcher Vorgang davon betroffen wird.
Daraus folgt aber keine eigene Arbeitswelt für jede einzelne Anforderung. Die Regime schauen meist auf dieselben Systeme, Lieferanten, Zugriffe, Schwachstellen und Vorfälle, nur jeweils aus anderem Winkel. Prüfbar wird die Umsetzung, wenn ein konkreter Vorgang zeigt, welche Daten verwendet wurden, wer entschieden hat und welche Maßnahme tatsächlich durchgeführt wurde.
Anforderungen landen zuerst im Prozess, nicht im Nachweisordner
Im Unternehmen landen regulatorische Anforderungen zuerst in den Prozessen, die ohnehin laufen: Benutzeranlage und Rollenwechsel, Lieferantenzugriff, Einkauf, Patch- und Schwachstellenbehandlung, Produktentwicklung, die Behandlung von Sicherheitsvorfällen, Wiederanlauf und Notbetrieb.
Compliance entsteht genau dort, sobald diese Prozesse die regulatorisch relevanten Daten, Entscheidungen und Zuständigkeiten mitführen. Eine zweite Organisation daneben schafft nur parallele Listen, die jemand pflegen und abgleichen muss.
Der neue Mitarbeiter zeigt das im Kleinen. Während das Unternehmen ihn arbeitsfähig macht, entstehen Rolle, Systembedarf, Berechtigung, Freigabe, MFA, womöglich eine Ausnahme, Schulung und der Termin für die spätere Überprüfung. Für eine Kundenanfrage oder interne Prüfung muss erkennbar sein, wer den Zugriff beantragt hat, wer freigegeben hat, welche Rechte eingerichtet wurden und wann der Review erfolgt.
Wie ein solcher Prozess konkret aussieht, zeigen die Praxisbeispiele zur Benutzeranlage und zum Lieferanten mit Systemzugriff.
Hinter den Prozessen stehen wenige wiederkehrende Kompetenzen
Eine betriebliche Compliance-Kompetenz ist Arbeit, die ein Unternehmen wiederkehrend beherrschen muss: mit klarer Zuständigkeit, aktueller Datenbasis, dokumentierter Entscheidung und erneuter Prüfung. Quer durch die Prozesse tauchen einige dieser Kompetenzen immer wieder auf.
Risiken einordnen · Zugriffe steuern · Lieferanten führen · Schwachstellen behandeln · Vorfälle bewerten und melden · Entscheidungen dokumentieren · Umsetzung prüfen.
Eine Kompetenz ist mehr als ein Dokument, eine Rolle, ein Projekt oder ein Tool. Sie ist die Fähigkeit, eine wiederkehrende Aufgabe auszuführen und die entstandenen Entscheidungen, Umsetzungen, Abweichungen und Prüftermine zu erklären. Eine einzige Kompetenz trägt dabei oft mehrere Anforderungen: Wer Schwachstellen behandeln kann, kann eine bewertete Lücke, eine kompensierende Maßnahme, eine Freigabe und einen neuen Prüftermin zeigen.
Eine Kompetenz zeigt sich erst im gelebten Ablauf
Eine Kompetenz zeigt sich erst, wenn ein Unternehmen sie in einem wiederholbaren Ablauf ausübt. So ein Ablauf verbindet mindestens sechs Dinge: einen Auslöser, die nötigen Daten, eine Prüfung, eine Entscheidung, die Umsetzung und einen konkreten Nachweis für einen Adressaten.
„Zugriffe steuern“ zeigt sich nicht in einer Richtlinie, sondern darin, dass Anträge, Prüfungen, Freigaben, technische Umsetzung, Ausnahmen und Reviews verlässlich ineinandergreifen. Die Richtlinie beschreibt die Absicht. Erst der gelebte Ablauf belegt die Fähigkeit.
Konkrete Abläufe dieser Art behandeln die Beiträge zur Patch-Ausnahme und zur Meldebewertung.
Systeme halten Entscheidung, Umsetzung und Prüftermin zusammen
Systeme stützen eine Kompetenz, indem sie Vorgänge erfassen, Daten und Belege zuordnen, Übergaben begleiten, Entscheidungen festhalten, Fristen auslösen und die Historie sichern. Sie halten fest, wer entschieden hat, was umgesetzt wurde, welche Abweichung offen bleibt und wann erneut geprüft wird.
Systemunterstützung ist kein eigenes Ergebnis. Sie sorgt dafür, dass Antrag, Datenbasis, Entscheidung, Umsetzung, Beleg und Wiedervorlage nicht auseinanderfallen.
Konkreter Vorgang · verantwortliche Rolle · verwendete Daten · Freigabe oder Entscheidung · tatsächliche Umsetzung · dokumentierte Abweichung · erneute Prüfung.
Systeme übernehmen weder Verantwortung noch Prozessgestaltung. Die verantwortliche Rolle entscheidet. Das System hält Entscheidungsgrundlage, Ergebnis, Belege und Wiedervorlage fest. Welche Systemfunktionen dafür genügen, klärt ein eigener Folgebeitrag dieser Reihe.
Der Nachweis zeigt, ob die Arbeit tatsächlich stattgefunden hat
Nachweise bleiben notwendig. Jeder Nachweis zeigt einen bestimmten Zustand für einen bestimmten Adressaten und Anlass. Kunde, Auditor, Aufsicht und Geschäftsführung verlangen dabei oft ganz unterschiedliche Formen.
Die Daten und Entscheidungen dahinter stammen im besten Fall aus den geführten Prozessen selbst. Der Nachweis ist dann das Ergebnis der Kompetenz und fällt im täglichen Durchlauf an. Eine Anfrage aus der Lieferkette lässt sich beantworten, wenn Vorgang, Freigabe, Umsetzung, offene Punkte und Belege zusammen auffindbar sind.
Hier treffen zwei Blickwinkel aufeinander. Der Betrieb denkt in Vorgängen und Durchläufen. Eine Prüfung schaut auf einen Zustand. Der Nachweis bringt beides zusammen: Aus dem laufenden Durchlauf macht er einen prüfbaren Zustand sichtbar.
Prüfbar wird die Umsetzung, wenn Prozesse Antrag, Datenbasis, Entscheidung, Umsetzung, Abweichungen und Prüftermin im Alltag hinterlassen. Eine Generalprobe vor dem Termin kann diese Spuren höchstens zusammenstellen. Erzeugen kann sie sie nicht.
Sechs Ebenen von der Pflicht bis zum Nachweis
Die sechs Ebenen spannen den Bogen von der regulatorischen Erwartung bis zum sichtbaren Nachweis. Jede Ebene beantwortet ihre eigene Frage.
Die Beiträge dieser Reihe
Dieser Beitrag erklärt das Dachmodell. Die folgenden Beiträge vertiefen die einzelnen Ebenen.
Drei Situationen verdichten die Arbeit aus vielen Prozessen
Die operativen Prozesse erzeugen die Tatsachen, auf die NIS2 später zugreift. Benutzeranlage erzeugt Angaben zu Rolle, Zugriff, Freigabe, MFA und Review. Lieferantenzugriff erzeugt Angaben zu Zweck, Berechtigungen, Authentifizierung, Vertrag und Meldeweg. Patch Management erzeugt Angaben zu Schwachstelle, Risiko, Entscheidung, Umsetzung und Ausnahme. Vorfallbehandlung erzeugt Angaben zu Kenntniszeitpunkt, Wirkung, betroffenen Systemen und Maßnahmen. Wiederanlauf erzeugt Angaben zu Prioritäten, Abhängigkeiten, Verantwortlichen und Tests.
Diese Informationen werden nicht für jeden regulatorischen Anlass neu erzeugt. Sie werden je nach Situation ausgewählt, bewertet und für einen bestimmten Adressaten zusammengestellt.
Die drei Prüfsituationen ersetzen die operativen Prozesse nicht. Sie greifen auf deren Daten und Entscheidungen zurück und verdichten sie für einen konkreten Zweck: Kundenanfrage, Meldebewertung oder Entscheidung der Geschäftsführung.
Der Compliance Arbeitsplatz führt diese drei Situationen als klar abgegrenzte Vorgänge. Er hilft dabei, die benötigten Informationen aus dem Betrieb zuzuordnen, Entscheidungen festzuhalten, offene Punkte zu terminieren und das für den jeweiligen Adressaten benötigte Ergebnis zusammenzustellen.
Die täglichen Prozesse erzeugen die Fakten. Die Prüfsituation bestimmt, welche dieser Fakten benötigt, wie sie bewertet und für wen sie dokumentiert werden.
Von der Einordnung zur betrieblichen Anwendung
Das Ordnungsmodell zeigt, wie regulatorische Erwartungen in Kompetenzen, Prozesse, Entscheidungen, Umsetzungen und Nachweise überführt werden. Die folgenden Beiträge vertiefen Prozessdesign, Systemunterstützung, Quality Gates und die Verbindung zwischen Betrieb und Prüfung.