Nachweisplan: Grundschutz-Nachweise nach Grundschutz++ planen

Die Vorgaben stehen verteilt in Kapitel 4 des Standards (Prozessschritt Realisierung). Zusammengezogen ergeben sie die Pflichtfelder eines Nachweisplans:

Der Methodik-Teil des Anwenderkatalogs fasst einen Teil davon als Anforderungen: UMS.1.1 („Umsetzung MUSS den Umsetzungsstatus der Anforderungen im Anforderungspaket vollständig [regelmäßig] überprüfen“), UMS.3.1 (Zuständige für die Umsetzung bisher nicht erfüllter Anforderungen „eindeutig zuweisen“) und UMS.4.1 („ein realistisches Zieldatum“ festlegen). Ein gepflegter Nachweisplan ist die Unterlage, mit der Sie diese drei Anforderungen belegen: Er zeigt, wann der Status zuletzt geprüft wurde, wer für offene Anforderungen zuständig ist und bis wann sie erfüllt sein sollen.

300-1 nennt als Spanne möglicher Verfahren Interviews, Dokumentenprüfungen, automatisierte Konfigurationsprüfungen und technische Scans (Kapitel 4.1). Für den Plan hilft es, je Anforderung die Art festzulegen, bevor die Arbeit verteilt wird. Eine organisatorische Anforderung wie die Freigabe der Leitlinie belegt ein Dokument mit Freigabevermerk. Eine technische Anforderung wie die Überwachung des Patchstands belegt am besten ein Bericht aus dem Werkzeug, das ohnehin läuft.

Der Anwenderkatalog gibt dafür einen Anhaltspunkt. Im Build vom 29. Oktober 2026 enthalten 961 der 1.000 Anforderungen in ihrer Anforderungsformulierung eine Angabe im Feld documentation aus dem Namensraum documentation_guidelines, mit 62 verschiedenen Werten (eigene Auszählung). Am häufigsten sind „Konfigurationshistorie“ (183 Anforderungen), „IT-Betriebskonzept“ (116), „Beschaffungskriterien“ (70), „Detektions-Konzept“ (61), „Arbeitsanweisung“ und „Schulungsplan“ (je 60). 300-1 erläutert das Feld nicht. Nach seinem Namen gibt es an, in welcher Art von Dokument die Umsetzung festgehalten wird. Nutzen Sie es als Vorschlag für den Ablageort des Nachweises; vorgeschrieben ist es im Standard nicht.

Fiktives Beispiel. Die Anforderungen und ihre Katalogangaben stammen aus dem Anwenderkatalog Grundschutz++ (Build 2026-10-29), Parameter in eckigen Klammern. Maßnahmen, Rollen, Werkzeuge und Termine sind erfunden und zeigen nur, wie die Spalten gefüllt werden.

Hinweis zur temporären Nichterfüllung: Kapitel 4.1.2 sagt, eine temporäre Nichterfüllung löse keine Risikobetrachtung aus. Kapitel 2.11 verlangt für SOLLTE-Anforderungen, die in der Umsetzungsplanung enthalten, aber noch nicht erfüllt sind, eine Restrisikobetrachtung und die Freigabe des Risikos durch die Institutionsleitung; Kapitel 4.1.1 verlangt, das Risiko zu identifizieren und der Leitung mitzuteilen. Wie beide Stellen zusammenpassen, ist eine offene Auslegungsfrage. Wer auf der sicheren Seite bleiben will, identifiziert das Restrisiko, teilt es der Leitung mit und lässt es von ihr freigeben.

Drei Angaben fehlen in der Tabelle aus Platzgründen und gehören in Ihren Plan: die Ablage des Nachweises (Pfad, Ticket- oder Berichtsnummer), das Datum der letzten Prüfung mit Ergebnis und die Person, die geprüft hat. Erst damit sind die Mindestangaben aus Kapitel 4.3 vollständig.

Kommt ein Nachweis aus einem Werkzeug, gehören nach Kapitel 4.3 drei Angaben dazu: welches Werkzeug, wann geprüft, mit welchem Ergebnis. Einen Bericht des Werkzeugs hängen Sie an Maßnahme und Anforderung. In der empfohlenen Historie sehen Sie später, wer wann mit welchem Werkzeug geprüft hat.

Im Plan bedeutet das: Der Eintrag „Bericht aus der Softwareverteilung“ reicht nicht. Halten Sie fest, welches Werkzeug in welcher Version den Bericht erzeugt, welche Systeme es erfasst und wer den Bericht abnimmt. Deckt ein Werkzeug nur einen Teil der Assets einer Zielobjektkategorie ab, gehört die Lücke in den Plan, mit einem zweiten Nachweis oder einer Begründung. Ein technischer Bericht sagt außerdem nur etwas über den Zeitpunkt seiner Erzeugung; der Turnus im Plan muss zum Parameter der Anforderung passen.

Wie Sie Prüfziel, Methode, Ergebnis und Einschränkung eines solchen Nachweises festhalten, zeigt die Seite Automatisierte Nachweise.

Der Nachweisplan gehört zum Umsetzungsplan aus Kapitel 4.3. In der Praxis lohnt es sich, ihn als eigene Sicht zu führen, weil er von anderen gelesen wird: Der IT-Betrieb will wissen, was er bis wann liefert, das interne Audit will wissen, wo es nachsehen kann, und die Leitung will sehen, wie viele Nachweise fehlen.

• Woher die Anforderungen kommen, regelt das Anforderungspaket; wie ein Status vergeben und eine Abweichung dokumentiert wird, steht unter Anforderungen bewerten und Abweichungen dokumentieren.
• Wie der Plan mit den übrigen Unterlagen zu einem Sicherheitskonzept zusammenkommt, beschreibt Sicherheitskonzept.
• Welche Unterlagen für ein Audit bereitliegen sollten, zeigt die Seite Zertifizierung.
• Für dauerhaft nicht erfüllte SOLLTE-Anforderungen ersetzt der Plan die Risikobetrachtung nicht; siehe Risikoanalyse.

1. Anforderungspaket exportieren. Jede Anforderung bekommt eine Zeile, auch die nicht anwendbaren; deren Begründung ist ihr Nachweis.
2. Maßnahmen zuordnen. Je Anforderung mindestens eine Maßnahme mit eigener Kennung; Maßnahmen, die mehrere Anforderungen abdecken, mit allen Zuordnungen.
3. Nachweisart festlegen, etwa Interview, Dokumentenprüfung, Konfigurationsprüfung oder Scan; die Katalogangabe im Feld documentation als Vorschlag für den Ablageort.
4. Rollen eintragen. Liefernde und prüfende Rolle getrennt, bei komplexen Maßnahmen fachlich und operativ.
5. Termine ableiten. Turnus aus dem Parameter, Frist für nicht erfüllte Anforderungen, Ereignisse, die eine Aktualisierung auslösen.
6. Freigeben und nachhalten. Vorgehen von der Leitung freigeben lassen (Kapitel 4.4), Fortschritt kontinuierlich verfolgen (Kapitel 4.5), Ergebnis in den Managementbericht.