Zum Inhalt springen
Legiscope
Menü
Cybersecurity

Wirksamkeitsprüfung von Sicherheitskontrollen: einen Prüfplan erstellen

Prüfplan für Sicherheitskontrollen: Ziel, erwarteter Nachweis, Dokumentenprüfung, Interview, Funktionstest, Stichprobe und begründeter Befund.

Ein Prüfplan für Sicherheitskontrollen legt vor der Prüfung fest, welche Aussage am Ende tragfähig sein soll und wodurch sie belegt wird. „MFA eingeführt“ ist ein Maßnahmenname, keine Prüfung der Wirksamkeit. Ein nachvollziehbarer Plan fragt beispielsweise, ob privilegierte Konten im festgelegten System während des Prüfzeitraums tatsächlich nur mit dem vorgesehenen zweiten Faktor genutzt werden konnten, welche Ausnahmen bestanden und wie ein Umgehen entdeckt würde. Dieser Beitrag liefert ein Arbeitsblatt, das Kontrollziel, erwarteten Nachweis, Gespräch, Funktionstest und Schlussfolgerung miteinander verbindet.

Der Überblick über Umfang und Ablauf eines Datenschutz-Audits bleibt der Einstieg für ein gesamtes Prüfprogramm. Hier wird eine einzelne Kontrolle so vorbereitet, dass ein Prüfer sie mit einer geeigneten Methode beurteilen kann. Die aktuelle NIST SP 800-53A Revision 5 mit Release 5.2.0 beschreibt anpassbare Bewertungsverfahren; der BSI-Baustein DER.3.1 Audits und Revisionen ordnet unabhängige Audits und weitere Revisionen ein. Beide sind methodische Quellen. Eine konkrete rechtliche Prüfpflicht ergibt sich erst aus dem anwendbaren Recht oder Vertrag und seinem Kontext.

Die Prüfentscheidung vor der Methode bestimmen

Schreiben Sie zuerst auf, welche Entscheidung die Prüfung unterstützen soll. Soll eine neue Funktion freigegeben, eine frühere Abweichung geschlossen oder die regelmäßige Wirksamkeit einer Kontrolle beurteilt werden? Die Frage beeinflusst Umfang und Beweisanforderung. Für die Erstfreigabe kann eine kontrollierte Funktionsprobe entscheidend sein; für die Aussage über sechs Monate Betrieb benötigen Sie zusätzlich Daten über den Zeitraum, Änderungen und Ausnahmen. Wer diesen Unterschied übersieht, beschreibt einen einmaligen erfolgreichen Test als dauerhafte Wirksamkeit.

Identifizieren Sie Kontrollinhaber, Systemverantwortliche und Prüfer. Der Kontrollinhaber erklärt die beabsichtigte Wirkung und stellt Unterlagen bereit; der Prüfer bewertet das Ergebnis. Bei einem unabhängigen Audit sollte die Person, die die Kontrolle betreibt, nicht allein den Schluss über die eigene Leistung ziehen. Eine interne Revision kann anders organisiert sein, muss aber ihren Prüfcharakter ehrlich bezeichnen. Der BSI-Grundschutz-Check verbindet Dokumente, Interviews und Beobachtung vor Ort, ohne ein bloßes Gespräch mit nachgewiesener Funktion gleichzusetzen.

Begrenzen Sie das Prüfobjekt. Benennen Sie Systeme, Geschäftsprozess, Nutzergruppen, Orte, Zeitraum und Version der Regel. Eine Zugriffskontrolle in der zentralen Anwendung sagt nichts über ein ausgelagertes Administrationsportal aus, wenn dieses nicht einbezogen wurde. Erfassen Sie Abhängigkeiten, etwa Identitätsdienst, Verzeichnis oder Logplattform. Bei einer Kontrolllücke kann die Ursache außerhalb des eigentlichen Systems liegen. Der Prüfplan sollte diese Grenze von Anfang an sichtbar machen und die Entscheidung nicht später mit stillschweigenden Erweiterungen retten.

Ziel und erwartete Wirkung präzisieren

Formulieren Sie die Kontrolle als überprüfbare Wirkung: welches unerwünschte Ereignis soll verhindert, entdeckt oder begrenzt werden? „Es gibt eine Richtlinie zur Rechtevergabe“ beschreibt einen Gegenstand. „Entzogene Berechtigungen sind nach Austritt nicht mehr nutzbar“ beschreibt eine Wirkung. Daraus entstehen Fragen nach Zeit, Datenquelle, Probe und Fehlersignal. Für jede Kontrolle kann es mehrere Ziele geben; trennen Sie sie, wenn verschiedene Nachweise nötig sind.

Unterscheiden Sie Gestaltung, Umsetzung und Wirksamkeit. Eine gut entworfene Regel kann in der Praxis nicht aktiviert sein. Eine aktivierte Regel kann durch einen Notfallzugang umgangen werden. Ein funktionierender Mechanismus kann wegen fehlender Überwachung nach einem Fehler lange außer Kraft bleiben. Der Plan sollte daher nicht nur die Existenz einer Dokumentation prüfen. Welche Ebene Sie benötigen, hängt von Entscheidung und Risiko ab. Die TOM-Vorlage hilft bei der Beschreibung einer Maßnahme, nicht bei der automatischen Feststellung ihrer Wirksamkeit.

Legen Sie Erfolgskriterien vor Sichtung der Ergebnisse fest. Ein Beispiel: Für alle privilegierten Zugänge zur betrachteten Anwendung ist der zweite Faktor aktiv; genehmigte technische Ausnahmen sind befristet und gesondert überwacht; ein Testkonto ohne zweiten Faktor erhält keinen Zugang. Ein Kriterium kann qualitative Bedingungen und messbare Schwellen enthalten, wenn diese für das Unternehmen begründet sind. Übernehmen Sie keine pauschale Zahl aus einer fremden Matrix. Dokumentieren Sie auch, welche Abweichung den Schluss verhindert, damit das Ergebnis nach der Prüfung nicht passend umdefiniert wird.

Das Arbeitsblatt mit Nachweis und Methode ausfüllen

Ein guter Plan enthält mehr als eine Liste von Dokumenten. Er benennt das Prüfziel, die Datenquelle, die Auswahl, den Testschritt, die erwartete Beobachtung und die Grenze des Schlusses. Schreiben Sie ihn so, dass eine zweite prüfende Person denselben Sachverhalt nachvollziehen kann. Der Plan darf während der Arbeit begründet angepasst werden; jede Änderung sollte jedoch als solche erkennbar bleiben.

Feld Leitfrage
Kontrollziel Welche konkrete Wirkung soll im angegebenen Umfang eintreten?
Prüfzeitraum Welche Monate, Änderungen und Ausnahmen umfasst die Aussage?
Erwartete Evidenz Welche Versionen, Protokolle, Konfigurationen oder Fälle belegen das Ziel?
Methode Dokument prüfen, Beteiligte befragen oder Funktion testen?
Auswahl Welche Objekte und Fälle werden ausgewählt und weshalb?
Erfolgskriterium Welche Beobachtung trägt oder widerlegt den Schluss?
Ergebnis Bestanden, teilweise, nicht bestanden oder mangels Daten nicht beurteilbar?
Folgemaßnahme Wer korrigiert, wann und mit welchem erneuten Nachweis?

Für eine Kontrolle der Wiederherstellbarkeit kann die erwartete Evidenz eine genehmigte Sicherungsversion, ein geschützter Speicherort und das Protokoll einer Wiederherstellungsprobe sein. Das Interview klärt, wer die Probe ausführt und welche Abhängigkeiten bestehen; der Test zeigt, ob die Daten und Funktionen zurückkommen. Der Leitfaden zu Backup und Restore liefert dafür technischen Kontext. Das Prüfblatt macht aus dem allgemeinen Schutzkonzept eine konkrete Entscheidung über die betrachtete Wiederherstellung.

Dokumentenprüfung, Gespräch und Test kombinieren

Die drei Methoden beantworten unterschiedliche Fragen. Durch Einsicht in eine Richtlinie oder Konfiguration lässt sich feststellen, welche Regel definiert oder welcher Zustand dokumentiert wurde. Ein Interview hilft, tatsächliche Abläufe, Ausnahmen und implizite Entscheidungen zu verstehen. Ein Funktionstest beobachtet Verhalten unter einer kontrollierten Bedingung. NIST SP 800-53A nutzt diese Methoden als anpassbare Bewertungswerkzeuge. Der Plan sollte angeben, weshalb eine Methode für das Prüfziel genügt oder weshalb eine zweite nötig ist.

Ein Gespräch allein kann die Existenz eines Verfahren plausibel machen, aber nicht beweisen, dass jedes relevante Ereignis verarbeitet wurde. Eine Konfiguration kann zeigen, dass ein Alarm eingeschaltet ist; erst ein geeignetes Testereignis und die Verfolgung bis zur zuständigen Person zeigen, ob die Kette wirksam ist. Umgekehrt kann ein einzelner erfolgreicher Test nicht die Behandlung aller historischen Fälle beweisen. Beschreiben Sie diese Grenzen im Ergebnis. Ein methodischer Mix ist keine Formalität, sondern eine Antwort auf die konkrete Beweisfrage.

Planen Sie technische Tests sicher. Definieren Sie Testkonten, Zeitfenster, zulässige Aktionen, Abbruchbedingungen und Verantwortliche. Ein Prüfer sollte nicht unbeabsichtigt produktive Daten verändern oder eine Sicherheitsmaßnahme im laufenden Betrieb abschalten. Wenn ein direkter Test zu riskant ist, können ein isoliertes System, eine konfigurierte Testfunktion oder eine dokumentierte alternative Evidenz geeignet sein. Benennen Sie dann die verbleibende Unsicherheit. Die Auditplanung hilft bei der Abstimmung des gesamten Auftrags; der einzelne Kontrolltest braucht zusätzlich seine konkrete Schutzgrenze.

Eine Stichprobe begründen statt nur zählen

Eine Stichprobe muss zur Aussage passen. Wenn die Frage lautet, ob alle privilegierten Konten erfasst sind, genügt eine Liste der bereits bekannten Konten nicht; suchen Sie auch nach möglichen Gegenbeständen, etwa lokalen Administratorkonten oder Dienstkonten. Bei einer Freigabeprüfung wählen Sie Fälle aus unterschiedlichen Teams, Rollen und Änderungszeitpunkten. Erklären Sie, weshalb diese Auswahl relevante Varianten enthält und welche Population nicht abgedeckt wurde.

Dokumentieren Sie die Grundgesamtheit und die Auswahlmethode. Die Feststellung „zehn Fälle geprüft“ ist wenig aussagekräftig, wenn unklar bleibt, ob es zwölf oder zehntausend Vorgänge gab. Eine risikoorientierte Auswahl kann ungewöhnliche, besonders privilegierte oder zeitkritische Fälle einbeziehen. Sie ist nicht zwingend statistisch repräsentativ. Geben Sie deshalb keine prozentuale Fehlerquote für die Gesamtheit an, wenn die Auswahl das nicht trägt. Für eine breitere Aussage kann eine zusätzliche systematische Auswertung nötig sein.

Nehmen Sie Ausnahmen ausdrücklich auf. Ein Notfallkonto, eine Altanwendung oder ein externer Dienstleister kann gerade die kritische Variante sein. Wenn solche Fälle aus der Probe ausgeschlossen werden, darf das Ergebnis sie nicht stillschweigend abdecken. Begründen Sie die Ausnahme und planen Sie gegebenenfalls eine eigene Prüfung. Der AVV-Prüfkontext ist beispielsweise relevant, wenn eine Sicherheitskontrolle beim Auftragsverarbeiter betrieben wird und die eigene Stichprobe nur die Kundenseite erfasst.

Qualität und Zeitbezug der Evidenz prüfen

Eine Evidenz kann authentisch, aber unpassend sein. Ein Prüfbericht für eine andere Gesellschaft, ein anderer Zeitraum oder ein anderes System belegt die betrachtete Kontrolle nur begrenzt. Erfassen Sie Dokumentversion, Erstellungszeit, prüfende Stelle und betroffenen Umfang. Prüfen Sie, ob nach dem Bericht Änderungen eingetreten sind. Eine nachträglich aktualisierte Richtlinie erklärt nicht automatisch das Verhalten vor ihrer Einführung. Halten Sie solche zeitlichen Brüche getrennt fest.

Achten Sie auf die Herkunft automatischer Nachweise. Eine Dashboard-Anzeige kann auf einer unterbrochenen Datenquelle beruhen; ein grüner Wert ist dann kein positiver Kontrollbefund. Dokumentieren Sie letzte erfolgreiche Erhebung, relevante Filter und manuelle Ergänzungen. Wenn eine Quelle fehlt, lautet das Ergebnis zunächst „nicht ausreichend beurteilbar“, nicht automatisch „Kontrolle fehlgeschlagen“ und auch nicht „Kontrolle wirksam“. Eine technische Prüfung kann den Zustand anders belegen, sofern ihr Umfang zur Entscheidung passt.

Schützen Sie Belege angemessen. Prüfprotokolle können Systemarchitektur, Schwachstellen und personenbezogene Ereignisse enthalten. Legen Sie fest, wer sie sehen darf, wie lange sie für die Nachweiszwecke benötigt werden und wie sensible Details in einem breiter verteilten Bericht reduziert werden. Der Prüfplan benötigt einen Verweis auf die sichere Ablage, aber nicht zwingend Kopien sämtlicher Logzeilen. Ein Befund muss nachvollziehbar bleiben, ohne neue unnötige Risiken durch Beweisanhänge zu erzeugen.

Einen Befund mit seiner Grenze formulieren

Das Ergebnis sollte Ziel, Methode, Beobachtung und Schluss in dieser Reihenfolge wiedergeben. Beispiel: „Für acht ausgewählte privilegierte Konten wurden Konfiguration und Anmeldeversuch geprüft. Sieben erforderten den zweiten Faktor; ein älteres Dienstkonto war ausgenommen und konnte sich ohne ihn anmelden. Die Kontrolle ist im beschriebenen Umfang nicht vollständig wirksam.“ Diese Formulierung zeigt mehr als eine Ampel. Sie nennt auch die Grenze: Andere Konten wurden nicht getestet, und die historische Nutzung der acht Konten wurde nicht vollständig beurteilt.

Bei Teilbefunden trennen Sie Design- und Betriebsprobleme. Eine Regel kann richtig formuliert, aber nicht auf alle Systeme ausgerollt sein. Eine technische Sperre kann funktionieren, während der Prozess zum Entfernen alter Berechtigungen unvollständig ist. Die Korrekturmaßnahmen unterscheiden sich. Benennen Sie die wahrscheinliche Ursache nur soweit belegt; eine plausible Hypothese ist noch kein gesicherter Befund. Die BSI-Risikoanalyse unterstützt die Behandlung verbleibender Risiken, ersetzt aber nicht die Beobachtung der Kontrolle.

Eine nicht beurteilbare Kontrolle braucht ebenfalls eine Entscheidung. Fehlen Protokolle für einen Teil des Zeitraums, kann die Leitung einen engen neuen Test, eine vorläufige Schutzmaßnahme oder eine Frist zur Verbesserung der Datenerhebung beschließen. Der Schluss darf nicht durch das Wort „teilweise“ verschleiert werden, wenn tatsächlich keine Aussage möglich ist. Dokumentieren Sie, was gerade bekannt ist und welche Frage offen bleibt. Ein späterer Bericht muss den ursprünglichen Befund erkennbar fortschreiben, statt ihn stillschweigend zu überschreiben.

Den Prüfplan an einem durchgehenden Beispiel anwenden

Ein Unternehmen will prüfen, ob die Rechte ausgeschiedener Beschäftigter rechtzeitig entzogen werden. Das Ziel lautet: Nach dem festgelegten Ende der Berechtigung kann ein ehemaliger Nutzer weder die Anwendung noch den Administrationszugang nutzen. Die Grundgesamtheit sind alle Austritte in einem definierten Quartal. Der Prüfer wählt Fälle aus Fachabteilungen, privilegierten Rollen und dem Außendienst und hält die Auswahlmethode fest. Erwartete Evidenz sind Austrittsmeldung, Ticket, Identitätsprotokoll und ein kontrollierter Zugangsversuch für ein geeignetes Testkonto.

Die Dokumentenprüfung zeigt, dass fast alle Tickets abgeschlossen sind. Im Interview erklärt die IT, dass lokale Administratorrechte auf einem Spezialgerät separat entzogen werden. Dieser Schritt ist im Ticket nicht aufgeführt. Ein kontrollierter Test mit einem dafür eingerichteten Konto zeigt, dass der Zugang nach Deaktivierung der zentralen Identität weiterhin möglich ist. Der Befund betrifft nicht nur ein fehlendes Häkchen: Die Kontrollgestaltung deckt eine konkrete Zugangsmöglichkeit nicht ab. Die Fachseite entscheidet über sofortige Sperrung, Anpassung des Austrittsprozesses und erneute Prüfung der betroffenen Geräteklasse.

Für die erneute Prüfung reicht kein überarbeitetes Prozessdokument allein. Der Plan verlangt einen tatsächlichen Fall oder einen kontrollierten Test, in dem zentraler und lokaler Zugang entzogen werden, plus eine Prüfung, ob offene Altberechtigungen bereinigt wurden. Der Kontrollinhaber liefert die Nachweise, eine andere Person beurteilt die Wirksamkeit. Der neue Schluss bezieht sich auf die korrigierte Version und den neuen Zeitraum; er löscht nicht den ursprünglichen Befund. So bleibt nachvollziehbar, ob die Maßnahme tatsächlich besser geworden ist.

Vom Einzelbefund zur Prüfplanung des nächsten Zyklus

Priorisieren Sie erneute Prüfungen nach Risiko, Änderung und Befundlage. Eine Kontrolle, deren Mechanismus ausgetauscht wurde, braucht andere Nachweise als eine unverändert betriebene Kontrolle mit zuverlässiger Überwachung. Berücksichtigen Sie Vorfälle, neue Dienstleister, geänderte Daten und auslaufende Ausnahmen. Ein fester Jahresplan kann Orientierung geben, aber er sollte Anlassprüfungen nicht verhindern. Das Informationssicherheitsmanagement nach BSI 200-1 liefert den organisatorischen Rahmen für Verantwortlichkeit und Verbesserung.

Halten Sie für den nächsten Zyklus fest, welche Evidenz besonders hilfreich war und welche Prüfung unnötige Arbeit erzeugte. Eine automatisierte Auswertung kann eine manuelle Stichprobe ergänzen, wenn Quelle und Regel verlässlich sind. Sie kann nicht jedes Interview oder jeden Funktionstest ersetzen. Der Prüfplan ist dann gut, wenn er die nächste Entscheidung verbessert: Welche Kontrolle wirkt im benannten Umfang, wo ist der Nachweis begrenzt und welche konkrete Änderung wird erneut geprüft? Eine lange Liste von Kontrollnamen ohne diese Verbindung ist kein Wirksamkeitsnachweis.

Änderungen am Plan während der Prüfung offenlegen

Manchmal zeigt sich erst im Gespräch, dass die ursprünglich geplante Datenquelle einen Teil des Systems nicht erfasst. Passen Sie den Plan dann begründet an: Was fehlte, welche neue Quelle kommt hinzu, und verändert dies die Aussage über den bereits geprüften Zeitraum? Behalten Sie die frühere Planversion. Sonst sieht ein späterer Leser nur eine scheinbar von Anfang an vollständige Prüfung und kann weder Lücke noch Nachsteuerung nachvollziehen. Eine Anpassung ist kein Makel, solange ihr Anlass und ihre Wirkung erkennbar bleiben.

Vermeiden Sie außerdem eine nachträgliche Verkleinerung des Umfangs, nur weil ein schwieriger Teil schlecht abschneidet. Wenn privilegierte Dienstkonten zum ursprünglichen Ziel gehörten, können sie nach einem Fehler nicht stillschweigend aus der Grundgesamtheit verschwinden. Sie können einen separaten Befund und einen begrenzten positiven Schluss für die übrigen Konten formulieren. Die offene Ausnahme bleibt aber sichtbar und erhält eine eigene Maßnahme. Diese Disziplin schützt die Glaubwürdigkeit des gesamten Prüfprogramms: Der Leser sieht, welche Aussage getragen ist und welche weitere Kontrolle noch aussteht.

L
Verfasst von
Legiscope
Legiscope

Diesen Leitfaden in die Praxis umsetzen

Erfahren Sie, wie Legiscope Datenschutzverzeichnisse, Quellen und prüfungsgesteuerte Arbeit verbindet.

Individuelle Demo buchen
Weiterlesen

Ähnliche Artikel

01Cybersecurity

Beste NIS2-Compliance-Software 2026 (Deutschland)

Welche NIS2-Compliance-Software passt für deutsche Unternehmen? Kurzantwort: eine Plattform, die vier Dinge nachweisbar abbildet — die Registrierung bei der zuständigen Behörde (in Deutschland dem…

6. Juli 2026
02Cybersecurity

BSI 200-1: ISMS Managementsystem nach IT-Grundschutz

In einem Satz. Der BSI-Standard 200-1 definiert das Managementsystem für Informationssicherheit (ISMS) — Rahmen, Rollen, Verantwortungen, Prozesse — und ist die organisatorische Klammer um die…

3. Juni 2026
03Cybersecurity

BSI 200-2: IT-Grundschutz-Methodik im Detail

In einem Satz. Der BSI-Standard 200-2 beschreibt die operative IT-Grundschutz-Methodik in sieben Phasen — von der Initiierung des Sicherheitsprozesses über Strukturanalyse, Schutzbedarfsfeststellung,…

3. Juni 2026
04Cybersecurity

BSI 200-3: Risikoanalyse nach IT-Grundschutz

In einem Satz. Der BSI-Standard 200-3 liefert eine vereinfachte Risikoanalyse-Methodik, die bei Anwendung des IT-Grundschutzes eine vertiefte Betrachtung für hohen oder sehr hohen Schutzbedarf, nicht…

3. Juni 2026
05Cybersecurity

BSI 200-4: Notfallmanagement und BCMS praktisch aufbauen

Der BSI-Standard 200-4 beschreibt, wie eine Organisation ein Business Continuity Management System (BCMS) aufbaut und betreibt. Sein Ausgangspunkt ist eine praktische Frage: Welche Leistungen müssen…

3. Juni 2026
06Cybersecurity

BSI Active Directory Härtung: Leitfaden 2026

In einem Satz. Das BSI-Modul APP.2.2 "Active Directory Domain Services" kombiniert Microsofts Tier-Modell, LAPS für Local-Admin-Passwörter, Hardening nach Microsoft Security Baselines und…

26. Juni 2026
07Cybersecurity

BSI BYOD-Richtlinie Deutschland: Leitfaden 2026

Bring Your Own Device bedeutet, dass Beschäftigte private Geräte für dienstliche Aufgaben verwenden. Eine tragfähige BYOD-Richtlinie legt fest, welche Geräte zugelassen sind, welche Unternehmensdaten…

26. Juni 2026
08Cybersecurity

BSI C5: Cloud Computing Compliance Criteria

In einem Satz. Der BSI Cloud Computing Compliance Criteria Catalogue (C5) ist ein 2016 vom BSI eingeführter und 2020 aktualisierter Kriterienkatalog mit 121 Anforderungen in 17 Themenbereichen, der…

3. Juni 2026