Ein Unternehmen muss regulatorisch relevante Prüfungen in vorhandene Abläufe einbauen. Bei Benutzeranlage, Lieferantenzugriff oder Patch-Ausnahme müssen Daten, Freigaben, Umsetzung und Review im selben Vorgang erkennbar bleiben.
Ein Prozess erfüllt seine Compliance-Aufgabe, wenn er Antrag, Prüfung, Entscheidung, Umsetzung, Ausnahme und Review nachweisbar miteinander verbindet.
Compliance ist eine Qualitätsanforderung an bestehende Prozesse. Ein Vorgang trägt sie mit, wenn schon während der Bearbeitung Antrag, Datenbasis, Freigabe, Umsetzung, Ausnahme und Wiedervorlage erkennbar bleiben. Daraus lässt sich später der Nachweis zusammenstellen, den ein Kunde, ein Prüfer oder die Geschäftsführung verlangt.
Das Ticket darf erst fachlich abgeschlossen sein, wenn erkennbar ist, was beantragt, geprüft, freigegeben und umgesetzt wurde und wann der nächste Review erfolgt.
Der Leitartikel beschreibt betriebliche Kompetenz als Arbeit, die ein Unternehmen wiederkehrend beherrscht. Sichtbar wird diese Kompetenz erst, wenn das Unternehmen einen Vorgang regelmäßig nach derselben nachvollziehbaren Logik bearbeitet. „Zugriffe steuern“, „Lieferanten führen“, „Schwachstellen behandeln“: Solange Auslöser, Daten, Zuständigkeit und Ergebnis offen bleiben, sind das nur Überschriften.
Der Prozess schlägt die Brücke zwischen regulatorischer Erwartung und Tagesgeschäft. Er hält fest, wie ein wiederkehrender Vorgang abläuft: von der Auslösung über Prüfung und Entscheidung bis zur Umsetzung und der späteren Überprüfung. Wer ihn gestaltet, beginnt beim betrieblichen Zweck. Das Ergebnis ergibt sich daraus.
Ein Beispiel zieht sich durch alle sechs Kapitel: die Benutzeranlage. Ein neuer Mitarbeiter soll zum Eintritt genau die Zugriffe bekommen, die seine Rolle braucht und die jemand freigegeben hat. Schon dieser Alltagsvorgang berührt Rolle, Systembedarf, Freigabe, MFA, Ausnahme, Schulung und die spätere Überprüfung.
Jeder relevante Prozess braucht einen klaren Beginn und ein klares Ende. Fünf Fragen klären das: Was löst den Vorgang aus? Welche Situation wird bearbeitet? Welches betriebliche Ziel steht dahinter? Wann gilt der Vorgang fachlich als abgeschlossen? Und welche Aussage muss danach möglich sein?
Auslöser gibt es viele: ein Mitarbeiter tritt ein, eine Rolle wechselt, jemand beantragt privilegierten Zugriff, ein Lieferant braucht Systemzugang, eine Schwachstelle wird gemeldet, ein Patch lässt sich nicht fristgerecht einspielen, ein Sicherheitsereignis tritt auf oder ein kritisches System fällt aus. Die Ergebnisse sind ebenso konkret: ein freigegebener Zugriff, ein befristeter Lieferantenzugang, eine behandelte Schwachstelle, eine dokumentierte Ausnahme mit Owner und Wiedervorlage.
Den Anstoß gibt die Eintrittsmeldung aus HR. Am Ende soll der neue Kollege zum Startdatum einen Zugriff haben, den jemand geprüft und freigegeben hat und der sich später überprüfen lässt. Ein geschlossenes Ticket reicht dafür nicht. Das Ergebnis muss erklären können, was geprüft, entschieden und umgesetzt wurde.
Ein Prozess entscheidet nur dann verlässlich, wenn von Anfang an klar ist, welche Daten er braucht. Es lohnt sich, sie zu trennen: Stammdaten, was im Vorgang selbst entsteht, Prüfergebnisse, Entscheidungen, die technische Umsetzung und das, was offen bleibt. Aus reinen Daten wird erst dann verwertbare Information, wenn Zweck, Kontext, Owner, Entscheidung und Zeitpunkt daran ablesbar sind.
Am Beispiel der Benutzeranlage liefern die Stammdaten Name, Eintrittsdatum, Organisationseinheit, Rolle und Vorgesetzten. Die Vorgangsdaten benennen benötigte Systeme, beantragte Rechte, Gerät, Arbeitsort und die Art der Beschäftigung. Die Prüfdaten betreffen Rollenangemessenheit, privilegierten Zugriff, Funktionstrennung, MFA-Anforderung und Schulungsbedarf. Die Entscheidungsdaten halten Antragsteller, Freigebenden, Datum, Auflage und Ausnahme fest. Die Umsetzungsdaten dokumentieren das erstellte Konto, das ausgegebene Gerät, die aktivierte MFA, die gesetzte Berechtigung und die bestätigte Übergabe.
Die Rollen bleiben dabei überschaubar: wer auslöst oder beantragt, wer fachlich verantwortet, wer prüft, wer entscheidet, wer ausführt, wer betroffen ist und wer später erneut prüft. Durchführung und Gesamtverantwortung liegen häufig in verschiedenen Händen. Eine ausführliche Verantwortungsmatrix über mehrere Prozesse hinweg nimmt der spätere Beitrag zu den Quality Gates auf.
Wie ein solcher Vorgang konkret aussieht, zeigt das Praxisbeispiel zur Benutzeranlage.
Ein Prozess braucht feste Stellen, an denen jemand Daten prüft und entscheidet. An diesen Punkten klärt sich: Sind die Eingangsdaten vollständig? Ist der Bedarf fachlich begründet? Passt der Vorgang zu den geltenden Regeln? Braucht es eine Ausnahme? Wer darf entscheiden, welche Auflage gilt, und wann muss eskaliert werden?
Bei der Benutzeranlage greift das ineinander: Der Vorgesetzte bestätigt Rolle und Systembedarf, der Systemowner gibt kritische Berechtigungen frei, die IT prüft die technischen Voraussetzungen und aktiviert MFA, eine Abweichung landet als dokumentierte Ausnahme im Vorgang, und ein Access Review bekommt einen Termin. Die Entscheidung muss dabei sichtbar bleiben. Sonst steht am Ende ein eingerichteter Zugriff, den niemand mehr begründen kann: das technische Ergebnis ist da, die Freigabe dahinter fehlt.
Hier geht es um den Zweck dieser Prüf- und Entscheidungspunkte. Wie sich Quality Gates im Detail bauen lassen, zeigt ein eigener Folgeartikel.
Die meisten Compliance-Lücken reißen an den Übergaben zwischen Bereichen auf. HR meldet den Eintritt, der Vorgesetzte beschreibt den Bedarf, Systemowner prüfen die Berechtigungen, die IT setzt die Zugriffe um, Compliance oder Security bewerten Ausnahmen, und bei wesentlichen Restrisiken entscheidet die Geschäftsführung. An jeder dieser Stationen muss klar sein, wer übernimmt, welche Information weitergereicht wird, was noch fehlt, welche Frist läuft und wann eskaliert wird.
Ausnahmen brauchen besondere Sorgfalt. Eine saubere Ausnahme nennt mindestens die betroffene Regel, eine Begründung, die Risikoeinordnung, eine kompensierende Maßnahme, die entscheidende Rolle, eine Gültigkeitsdauer und eine Wiedervorlage. Die Fälle kennt jeder Betrieb: MFA lässt sich vorübergehend technisch nicht aktivieren, ein Patch fehlt mangels Herstellerfreigabe, ein Lieferant braucht befristet privilegierten Zugriff, oder ein Altsystem trägt die gewünschte Kontrolle schlicht nicht.
Eine geführte Ausnahme beseitigt das Risiko nicht. Sie hält fest, welches Risiko man kennt, wer dafür geradesteht und wann erneut geprüft wird. Tiefer gehen die Beiträge zur MFA-Ausnahme und zum Patch Management.
Am Ende des Vorgangs muss erkennbar sein, was beantragt wurde, welche Daten vorlagen, wer geprüft und entschieden hat, was tatsächlich umgesetzt wurde, welche Abweichung offen bleibt und wann erneut geprüft wird.
Dieser Output muss kein eigenes Auditdokument sein. Oft genügen ein genehmigtes Ticket, ein strukturierter Datensatz, ein Freigabeprotokoll, ein Registereintrag, eine Systemhistorie oder ein zusammengeführter Bericht. Die Prozesssysteme müssen die Informationen erhalten, aus denen der konkrete Nachweis zusammengestellt werden kann.
Prüfbar wird die Durchführung, wenn Antrag und Umsetzung zusammenpassen, die Genehmigung dokumentiert ist, Antrag, Prüfung und Entscheidung getrennt erkennbar bleiben, Ausnahmen befristet sind, Zeitstempel und verantwortliche Rollen vorliegen, bestehende Rechte erneut geprüft werden und die zugehörigen Belege auffindbar bleiben.
Ein Prozess trägt Compliance, wenn sein normaler Durchlauf eine klare Aussage hinterlässt: was beantragt, geprüft, entschieden und umgesetzt wurde, welche Ausnahme akzeptiert wurde und wann wieder hinzusehen ist.
Das Ziel ist einfach formuliert: Ein neuer Mitarbeiter bekommt zum Eintritt die Arbeitsmittel und Zugriffe, die seine Rolle braucht und die jemand freigegeben hat. Der Weg dahin führt von der Eintrittsmeldung über Bedarf, Entscheidung, Umsetzung und Ausnahme bis zum terminierten Review.
Die folgende Übersicht zeigt für jeden Schritt drei Dinge: was das Unternehmen tut, was danach vorliegt und welche Spur eine spätere Prüfung nachvollziehen kann.
Ein gut gestalteter Prozess erzeugt relevante Daten einmal im betrieblichen Ablauf. Die Benutzeranlage hält unter anderem Rolle und Beschäftigungskontext, beantragte Systeme und Rechte, fachliche Begründung, Freigaben, tatsächlich eingerichtete Berechtigungen, MFA-Status, Ausnahmen, Schulungsnachweise und Reviewtermin fest. Diese Informationen können später in unterschiedlichen NIS2-Situationen benötigt werden.
Täglicher Prozess → Daten, Freigaben, Umsetzung und Ausnahmen → Kundenanfrage beantworten · Sicherheitsereignis bewerten · Geschäftsführungsentscheidung vorbereiten.
Keine Eins-zu-eins-Zuordnung: Ein Prozess kann mehrere Prüfsituationen versorgen, und eine Prüfsituation greift regelmäßig auf mehrere Prozesse zurück.
Der Compliance Arbeitsplatz setzt nicht an die Stelle des Benutzer-, Lieferanten- oder Incident-Prozesses. Er eröffnet den konkreten Compliance-Vorgang und führt die dafür benötigten Informationen, Entscheidungen, Belege und offenen Punkte zusammen.
Der Prozess erzeugt die Daten einmal. Die jeweilige Prüfsituation wählt die relevanten Informationen aus, ergänzt die notwendige Bewertung und führt sie zu einer Antwort, Meldung oder Entscheidung zusammen.
Diese acht Elemente passen auf jeden compliancerelevanten Vorgang. Sie bilden das gemeinsame Gerüst hinter Benutzeranlage, Lieferantenzugriff, Patch-Ausnahme und Wiederanlauf.
Kann der Prozess diese Fragen ohne Suche in persönlichen Postfächern beantworten, ist seine Durchführung später erklärbar.
Dasselbe Gerüst trägt auch andere Vorgänge. Jeder beginnt mit einem Auslöser und endet mit einer dokumentierten Entscheidung, einer bestätigten Umsetzung, benannten offenen Punkten und einem nächsten Prüftermin.
Ein Prozess trägt Compliance nur, wenn die nötigen Daten, Übergaben, Entscheidungen und Wiedervorlagen im Betrieb erhalten bleiben. Welche Systemfunktionen das mindestens leisten müssen, klärt der nächste Beitrag.