Hinweis und Rückblende auf Teil 1 und 2
Fiktiver Fall. Institution, Systeme, Statuswerte, Risiken und Entscheidungen sind erfunden. Die Fallakte ist nicht vom BSI geprüft, nicht zertifiziert und nicht auf reale Kommunen oder Dienstleister übertragbar. Echt sind die Kennungen, Modalverben und Gefährdungszuordnungen der Anforderungen aus dem Anwenderkatalog Grundschutz++, Build 2026-10-29; Methodik nach BSI-Standard 300-1, Version 1.0.
Was bisher geschah: Der IT-Zweckverband Musterregion (IZM) betreibt ein Bürgerportal für zwölf Kommunen. In Teil 1 hat die Geschäftsleitung den Prozess GP-A „Online-Anträge entgegennehmen und übergeben“ mit hohem Schutzbedarf bei Vertraulichkeit und Integrität für den ersten Zyklus gewählt und einen Risikorahmen mit drei Stufen autorisiert (niedrig, mittel, hoch). Die ISB-Stelle blieb vertagt (EV-04). In Teil 2 entstand für den Informationsverbund IV-PORTAL mit 24 Assets ein Paket aus 928 Katalog-Anforderungen und zwei eigenen (EIG-01 zur Freigabe von Formularlogik, EIG-02 zur Signatur übergebener Anträge). Der Formularbaukasten AS-02 gilt als nicht hinreichend abgedeckt; die Datensicherung steht im selben Serverraum wie die Systeme (Befund B-01).
Zwischen Teil 2 und Teil 3 hat die Rechtsabteilung die offene Frage OF-02 geprüft und ihr Ergebnis in die Compliance-Liste eingetragen; GC.3.1.1 ist damit erfüllt.
Wie der IZM den Status erhoben hat
Kapitel 4.1.1 verlangt, den Status jeder Anforderung vollständig zu überprüfen, mit den Werten erfüllt, nicht erfüllt oder nicht anwendbar. Der IZM hat die 930 Einträge zwischen PM 5 und PM 7 erhoben, mit den Verfahren, die Kapitel 4.1 nennt: Interviews mit den Teams, Prüfung von Dokumenten, Auswertung von Konfigurationsexporten und vorhandene Berichte aus Werkzeugen. Jede Zeile der Statusliste NW-02 enthält das Prüfdatum, die prüfende Person und den Verweis auf den Nachweis. Damit belegt die Liste zugleich UMS.1.1, das eine vollständige Überprüfung im festgelegten Turnus verlangt, hier vierteljährlich.
Bei Anforderungen, die auf mehrere Assets fallen, galt eine einfache Regel: erfüllt nur, wenn an jedem betroffenen Asset erfüllt. Die Erläuterung zu UMS.1.1 geht in dieselbe Richtung; sie lässt eine Anforderung erst als umgesetzt gelten, wenn auch alle mit ihr in Abhängigkeit stehenden Anforderungen umgesetzt sind. Wie die drei Status allgemein vergeben werden und was der Katalog dazu abweichend sagt, steht auf der Seite Anforderungen bewerten und Abweichungen dokumentieren.
Statusbilanz nach Modalverb
Die Zahlen sind fiktiv, ergeben aber zusammen genau das Paket aus Teil 2. Die beiden SOLLTE-Anforderungen mit Niveau „erhöht“ (DET.4.12.1, REA.2.5) und die beiden eigenen Anforderungen sind in der SOLLTE-Zeile enthalten.
| Modalverb | im Paket | erfüllt | nicht erfüllt | nicht anwendbar | Folge nach 300-1 Kap. 4.1.2 |
|---|---|---|---|---|---|
| MUSS | 149 | 117 | 27 | 5 | für jede nicht erfüllte Anforderung Maßnahmen festlegen; keine Ausnahme, keine Risikoakzeptanz |
| SOLLTE | 578 | 480 | 65 (63 temporär, 2 dauerhaft) | 33 | temporär: begründen und einplanen; dauerhaft: Risikobetrachtung |
| KANN | 203 | 38 | 164 | 1 | optional; Auswahl in der Risikobehandlung möglich |
| Summe | 930 | 635 | 256 | 39 |
Unter den 27 nicht erfüllten MUSS-Anforderungen sind 21 Methodik-Anforderungen der Praktiken Monitoring-Evaluation (PERF, 13) und Verbesserung (VRB, 8). Das ist in diesem Stadium folgerichtig: Audit, Managementbewertung und Korrekturverfahren gehören zu den Schritten 4 und 5, die noch nicht durchlaufen sind. Die übrigen sechs sind GC.1.1 (Errichtung und Aufrechterhaltung des ISMS; laut Erläuterung erst erfüllt, wenn die Vorgehensweise mindestens einmal vollständig durchlaufen ist), GC.8.1 (Ressourcenplanung), GC.9.1.1.1 und GC.9.1.1.3 (unabhängiger ISB, Interessenkonflikte), TEST.1.1 (Verfahren für Änderungen, das die Formularlogik bisher nicht erfasst) und NOT.1.1 (veraltete Regelungen zur Notfallvorsorge).
Statusbeispiele aus der Liste, mit Begründung
Die folgende Auswahl zeigt alle Arten von Einträgen, die in der Akte vorkommen, einschließlich mehrerer Einträge, die sich im Audit in Teil 4 als falsch herausstellen (BER.3.16 bis BER.3.19, KONF.8.1, NOT.4.16.1). Die Anforderungstexte sind gekürzt; Kennung, Modalverb und Zielobjektkategorie stammen aus dem Build.
| Anforderung (Modalverb, Kategorie) | Status | Begründung und Nachweis (fiktiv) |
|---|---|---|
| GC.9.1.1.1 unabhängiger ISB, unmittelbar der Leitung unterstellt (MUSS, ohne) | nicht erfüllt | ISB ist zugleich stellvertretender Leiter IT-Betrieb. Maßnahme MN-01, Frist PM 9. Ein Vorschlag aus der Geschäftsleitung, das Risiko bis zum nächsten Haushalt zu akzeptieren, wurde zurückgewiesen: Für MUSS-Anforderungen sind Ausnahme und Risikoakzeptanz nach Kap. 4.1.2 nicht möglich. |
| PERF.3.1 Verfahren für Auditprogramme verankern (MUSS, ohne) | nicht erfüllt, eingeplant | Auditprogramm entsteht in Teil 4; MN-12, Fristen PM 9 (Auditprogramm) bis PM 11 (erstes Audit) |
| GC.7.2 Risikobetrachtung für Prozesse mit hohem Schutzbedarf (MUSS, ohne) | erfüllt für IV-PORTAL (GP-A) | Risikoregister mit RR-01 und RR-02 für GP-A, siehe unten; die Risikobetrachtung für GP-B folgt mit dessen Modellierung im zweiten Zyklus (EV-03) |
| BER.3.16 Gruppenkonten im Regelbetrieb untersagen (SOLLTE, ohne) | erfüllt | NW-05: Kontenexport aus dem Verzeichnisdienst AS-13 ohne Gruppenkonten |
| BER.3.17, BER.3.18, BER.3.19 Regeln für Gruppenkonten (SOLLTE, ohne) | nicht anwendbar | keine Gruppenkonten vorhanden, die zugrunde liegende Komponente existiert nicht (Kap. 4.1.1); die Erläuterungen zu BER.3.17 und BER.3.18 nennen die Anforderung in diesem Fall entbehrlich |
| DEV.1.1 Verfahren zur Entwicklung von IT-Produkten (MUSS, ohne) und 33 weitere Anforderungen der Praktik DEV | nicht anwendbar | Der IZM entwickelt im Verbund keine IT-Produkte, das Portal ist beschafft. Die Erläuterung zu DEV.1.1 nennt in diesem Fall die ganze Praktik entbehrlich. |
| KONF.3.3 SIM-PIN bei Mobilfunkanschluss (SOLLTE, IT-Systeme) | nicht anwendbar | kein IT-System im Verbund hat einen Mobilfunkanschluss |
| NOT.4.5 Archivierung langfristig benötigter Daten (SOLLTE, Daten) | nicht anwendbar | Antragsdaten werden 90 Tage nach Übergabe gelöscht; die Erläuterung nennt die Anforderung entbehrlich, wenn keine Daten langfristig benötigt werden |
| KONF.11.4 Durchprobieren von Zugriffslinks blockieren (SOLLTE, Webanwendungen) | erfüllt | Vorschlag „nicht anwendbar, weil sich alle anmelden“ verworfen: Der Antragsstatus ist per Vorgangsnummer ohne Anmeldung abrufbar, und die Erläuterung nennt die Anforderung nur dann entbehrlich, wenn die Webanwendung ohne Authentifizierung keinerlei Zugriff auf schützenswerte Informationen bietet; der Antragsstatus mit Vorgangsbezug ist eine solche Information. NW-09: Konfigurationsexport des Reverse Proxy |
| KONF.12.10 Cookie-Attribute aktivieren (SOLLTE, Webanwendungen) | nicht erfüllt, temporär | ein Attribut fehlt im Sitzungs-Cookie, Behebung mit dem Herstellerupdate in PM 10; MN-07; Restrisiko RS-02 |
| KONF.8.1 Vorliegen von Sicherheitsupdates überwachen (SOLLTE, IT-Systeme) | erfüllt | NW-11: automatisierter Bericht der Softwareverteilung mit Werkzeug, Zeitpunkt und Ergebnis „41 von 41 erfassten Systemen ohne offene kritische Updates“ |
| NOT.4.16.1 Wiederherstellung anhand von Stichproben überprüfen (SOLLTE, Daten) | erfüllt | NW-14: Testprotokoll aus PM 4 mit drei Stichproben |
| BER.5.9 Mehr-Faktor-Authentisierung für weitreichende Berechtigungen (SOLLTE, ohne) | nicht erfüllt, temporär | Administrierende haben MFA; die Redaktionen, die Formularlogik veröffentlichen können, noch nicht; MN-21, Frist PM 11 |
| GEB.1.4 schützenswerte Assets außerhalb exponierter Bereiche platzieren (SOLLTE, Standorte) | nicht erfüllt, dauerhaft | Serverraum RZ-1 im Untergeschoss am Fluss (KX-01); ein Umzug ist auf absehbare Zeit nicht geplant; Risikobetrachtung RR-03 |
| TEST.3.1.5 dedizierte Testumgebung installieren (SOLLTE, ohne) | nicht erfüllt, dauerhaft | Die Lizenz des Bürgerportals umfasst bis zum Vertragsende keine Testinstanz; Risikobetrachtung RR-04 |
| BER.4.1.2 JIT-/JEA-Berechtigungen (KANN, ohne) und DET.6.2.1 Sandbox-Analyse verdächtiger Dateien (KANN, ohne) | nicht erfüllt | in der Risikobehandlung von RR-01 ausgewählt, MN-53 und MN-54 |
| EIG-01 Freigabe von Formularlogik durch unabhängige Rolle (SOLLTE, eigene Anforderung) | nicht erfüllt, temporär | MN-55, Frist PM 9 |
Für „nicht anwendbar“ hat der IZM nur die beiden Gründe aus Kapitel 4.1.1 zugelassen: Die zugrunde liegende Komponente existiert nicht im Verbund, oder die Anforderung ist funktional nicht erfüllbar. Fehlende Relevanz zählt nicht. Insgesamt kamen 47 Vorschläge für „nicht anwendbar“ aus den Teams; 39 wurden mit Begründung übernommen, acht verworfen und als erfüllt oder nicht erfüllt eingetragen, darunter KONF.11.4. Welche der 39 Begründungen halten, prüft das interne Audit in Teil 4.
Temporär nicht erfüllte SOLLTE-Anforderungen: eine offene Auslegungsfrage
Für die 63 temporär nicht erfüllten SOLLTE-Anforderungen sagt der Standard an zwei Stellen Unterschiedliches. Kapitel 4.1.2: „Eine temporäre Nichterfüllung löst keine Risikobetrachtung aus.“ Kapitel 2.11: „Für SOLLTE-Anforderungen, die in der Umsetzungsplanung enthalten, aber noch nicht erfüllt sind, muss eine Restrisikobetrachtung durchgeführt werden.“ Kapitel 4.1.1 verlangt zusätzlich, das noch nicht gemilderte Risiko zu identifizieren und der Institutionsleitung mitzuteilen. Wie beides zusammenpasst, ist offen.
Der IZM hat den vorsichtigeren Weg gewählt. Die Erläuterung zur Katalog-Anforderung UMS.1.2 erlaubt, die Risiken nicht umgesetzter Anforderungen zu konsolidieren, damit die Leitung sie nachvollziehen kann. Der ISB hat deshalb ein gemeinsames Restrisiko RS-01 für die übrigen 62 Einträge gebildet, mit der spätesten Frist als Ende, und KONF.12.10 als RS-02 einzeln geführt, weil es die Vertraulichkeit von GP-A betrifft. Beide hat die Geschäftsleitung freigegeben. Kapitel 4.1.1 ist nicht auf SOLLTE-Anforderungen beschränkt. Der IZM hat der Geschäftsleitung deshalb auch das bestehende Risiko der 27 eingeplanten MUSS-Anforderungen mitgeteilt, als Teil der Vorlage EV-07. Eine Akzeptanz ist das nicht: Für diese Anforderungen bleiben Maßnahmen und Fristen Pflicht (Kap. 4.1.2).
Risikoregister für GP-A
Alle drei Anlässe für eine explizite Risikobetrachtung aus Kapitel 2.11 kommen im Fall vor: hoher Schutzbedarf von GP-A, das nicht hinreichend abgedeckte Asset AS-02 und zwei dauerhaft nicht erfüllte SOLLTE-Anforderungen. Die Restrisikobetrachtung für eingeplante, noch nicht erfüllte SOLLTE-Anforderungen steht im Abschnitt davor (RS-01, RS-02). Bewertet wurde mit der Matrix aus Teil 1. Bei hohem Schutzbedarf identifiziert der IZM Risiken zuerst auf Ebene des Prozesses und ergänzt kritische Assets (Kap. 4.2.1). Für die dauerhaft nicht erfüllten Anforderungen sind die elementaren Gefährdungen aus dem Katalog berücksichtigt, wie es Kriterium 17 verlangt. Die Spalten decken die Mindestangaben nach Kriterium 15 ab.
| Angabe | RR-01 | RR-02 | RR-03 | RR-04 |
|---|---|---|---|---|
| Anlass | hoher Schutzbedarf GP-A | hoher Schutzbedarf GP-A; AS-02 nicht hinreichend abgedeckt | GEB.1.4 dauerhaft nicht erfüllt | TEST.3.1.5 dauerhaft nicht erfüllt |
| Untersuchungsobjekt | GP-A; kritisch AS-01, AS-19 | GP-A; kritisch AS-02, AS-20 | AS-17, AS-16; betrifft GP-A bis GP-D | AS-01, AS-02 |
| Beschreibung | Unbefugter Zugriff auf Antragsdaten und Nachweise über Schwachstellen des Portals, hochgeladene Schadsoftware oder missbrauchte Administrationszugänge | Manipulierte oder fehlerhafte Formularlogik verfälscht Antragsdaten, die unbemerkt bei den Kommunen ankommen | Wassereinbruch im Untergeschoss zerstört Systeme und Sicherungen zugleich (B-01) | Updates und Änderungen gehen ungetestet in den Betrieb und verursachen Fehlfunktionen |
| Elementare Gefährdungen | G 0.19, G 0.23, G 0.28, G 0.32, G 0.39 | G 0.21, G 0.22, G 0.31 | laut Katalog zu GEB.1.4: G 0.5, G 0.6, G 0.7, G 0.18; vom IZM ergänzt: G 0.3 Wasser | laut Katalog zu TEST.3.1.5: G 0.28, G 0.18 |
| Schutzziele | Vertraulichkeit | Integrität | Verfügbarkeit, Integrität | Integrität, Verfügbarkeit |
| Risikoeigentümer | R-03 | R-03 | R-03 federführend für GP-A bis GP-D (Kap. 4.2.1) | R-03 |
| Bewertung vorher | gelegentlich, beträchtlich: hoch | gelegentlich, beträchtlich: hoch | selten, existenzbedrohend: hoch | gelegentlich, begrenzt: niedrig |
| Priorität | 1 | 1 | 2 | 3 |
| Behandlungsoption | Reduktion | Reduktion | Reduktion | Akzeptanz |
| Maßnahmen | MN-53 (BER.4.1.2), MN-54 (DET.6.2.1), MN-58 (TEST.3.1.11) | MN-55 (EIG-01), MN-56 (TEST.4.1.1), MN-21 vorgezogen (BER.5.9) | MN-59 Kopie der Sicherung bei K05 (eigene Maßnahme), MN-60 Hochwasserschutz (eigene Maßnahme) | - |
| Bewertung nachher | selten, beträchtlich: mittel | selten, beträchtlich: mittel | selten, beträchtlich: mittel | niedrig |
| Entscheidung | befristet akzeptiert, zwölf Monate | befristet akzeptiert, zwölf Monate | befristet akzeptiert, zwölf Monate; Umzug offen (OF-05) | akzeptiert |
Die Maßnahmen stammen zuerst aus den KANN-Anforderungen mit Niveau „erhöht“, die 300-1 dafür vorsieht (Kap. 3.4.2): BER.4.1.2 (Rechte erst zum Zeitpunkt des Zugriffs, hier für Administrationszugänge zu AS-07 und AS-13), DET.6.2.1 (verdächtige hochgeladene Dateien in einer isolierten Umgebung testen), TEST.3.1.11 (bekannte Schwachstellen bei kritischen Änderungen testen), TEST.4.1.1 (kritische Änderungen auch durch eine unabhängige Person autorisieren). NOT.4.12 (eine Kopie der Datensicherung georedundant aufbewahren) hat der IZM geprüft, aber nicht gewählt: Die Erläuterung versteht unter georedundant in der Regel 200 km Luftlinie oder mehr, und ein so weit entferntes Rechenzentrum stand nicht zur Verfügung. Wo der Katalog nichts Passendes enthielt oder nicht umsetzbar war, kamen die eigene Anforderung EIG-01 und zwei eigene Maßnahmen hinzu.
Freigaben: Die Restrisiken von RR-01 bis RR-04 hat die Geschäftsleitung autorisiert (Kriterium 30), die befristeten mit Ablaufdatum (Kriterium 28). Die Umsetzungsplanung der Maßnahmen hat die Risikoeigentümerin R-03 freigegeben (Kap. 4.2.3, Kriterium 31). Weil die drei ersten Risiken zunächst „hoch“ waren, also außerhalb der Akzeptanzkriterien, wurden Bewertung und Behandlung nach den Maßnahmen erneut ausgeführt (Kriterium 26). Überprüft wird mindestens jährlich und bei wesentlichen Änderungen (Kriterium 35).
Offene Entscheidung OF-05: Ein Umzug des Serverraums in ein oberes Geschoss würde GEB.1.4 erfüllbar machen. Die Geschäftsleitung hat eine Machbarkeitsprüfung beauftragt, aber nichts entschieden. Bis dahin bleibt GEB.1.4 dauerhaft nicht erfüllt. Wie eine Risikobetrachtung im Einzelnen abläuft, zeigt die Seite Risikoanalyse.
Umsetzungsplan: Auszug mit Zuständigkeit, Frist und Nachweis
Der Umsetzungsplan enthält 60 Maßnahmen: MN-01 bis MN-52 für die eingeplanten MUSS- und SOLLTE-Anforderungen und MN-53 bis MN-60 aus der Risikobehandlung; zusammen decken sie alle 90 eingeplanten Anforderungen ab (27 MUSS, 63 SOLLTE temporär). Einzelne Maßnahmen aus der Risikobehandlung adressieren zugleich eingeplante Anforderungen, etwa MN-55 für EIG-01 und TEST.1.1. Kapitel 4.3 verlangt, jede Maßnahme mit den Anforderungen zu verknüpfen, die sie adressiert, und mindestens die Anforderung, das Datum der Umsetzung oder Überprüfung und die dokumentierende oder prüfende Person festzuhalten. Priorisiert hat der IZM nach Risikohöhe, nach Abhängigkeiten und, wie Kapitel 4.3 empfiehlt, mit Vorrang für Anforderungen der Elternknoten. Geführt wird der Plan im Ticketsystem des IT-Betriebs (Kap. 4.4).
| Maßnahme (fiktiv) | adressiert | fachlich / operativ zuständig | Frist | Nachweis | prüft |
|---|---|---|---|---|---|
| MN-01 ISB als Stabsstelle der Geschäftsleitung einrichten | GC.9.1.1.1, GC.9.1.1.3 | R-01 / Personalabteilung | PM 9 | Organigramm, Bestellung | Auditteam R-06 |
| MN-07 Sitzungs-Cookie mit allen Attributen ausliefern | KONF.12.10 | R-03 / IT-Betrieb R-04 | PM 10 | Scanbericht mit Werkzeug, Zeitpunkt, Ergebnis | ISB |
| MN-12 Auditprogramm aufstellen und erstes internes Audit durchführen | PERF.3.1, PERF.3.1.1 bis PERF.3.1.4, PERF.3.2 | R-01 / Auditteam R-06 | PM 9 bis PM 11 | Auditprogramm, Auditbericht | Geschäftsleitung |
| MN-21 MFA für Redaktionszugänge | BER.5.9; vorgezogen für RR-02 | R-08 / IT-Betrieb | PM 9 statt PM 11 | Konfigurationsexport des Portals | ISB |
| MN-53 Administrationsrechte für AS-07 und AS-13 nur auf Anforderung und befristet | BER.4.1.2; RR-01 | R-04 / Team Identitäten | PM 10 | Protokoll der Rechtevergaben | ISB |
| MN-54 Sandbox-Prüfung verdächtiger Uploads | DET.6.2.1; RR-01 | R-04 / IT-Betrieb | PM 11 | Konfiguration, Testbericht mit präparierter Datei | ISB |
| MN-55 Freigabe von Formularlogik durch die Redaktionsleitung des IZM vor Veröffentlichung | EIG-01; TEST.1.1; RR-02 | R-08 / Redaktionsleitung | PM 9 | Freigabeprotokoll im Formularbaukasten | ISB |
| MN-59 tägliche Kopie der Datensicherung in das Rechenzentrum der Kommune K05 außerhalb des Überflutungsgebiets | RR-03 (eigene Maßnahme; NOT.4.12 bleibt nicht erfüllt, weil der Abstand unter den in der Erläuterung genannten 200 km liegt) | R-03 / IT-Betrieb | PM 11 | Sicherungsprotokoll, Vereinbarung mit der Kommune | ISB |
| MN-60 mobile Hochwasserbarrieren und Wassermelder im Untergeschoss | RR-03 (eigene Maßnahme) | R-03 / Haustechnik | PM 10 | Abnahmeprotokoll, Alarmtest | ISB |
MN-59 schafft eine neue Schnittstelle zur Kommune, deren Rechenzentrum die Kopie aufnimmt. Nach den Regeln aus Teil 1 ist das ein Fall für die Beteiligung des ISB und eine Änderung im Informationsverbund, die in der Validierung in Teil 4 berücksichtigt wird. Wie Nachweise je Maßnahme zu planen sind, beschreibt die Seite Nachweisplan.
Freigabe und Fortschritt: Die Geschäftsleitung hat den Plan mit EV-07 freigegeben, weil sie die Ressourcen bereitstellt (Kap. 4.4), und die ISB-Stabsstelle für PM 9 beschlossen. Den Fortschritt verfolgt bis dahin die Stabsstelle Controlling und nicht der ISB, denn als stellvertretender Leiter IT-Betrieb setzt er viele Maßnahmen selbst mit um. Das vermeidet den Interessenkonflikt, den Kapitel 4.5 zwischen Umsetzung und Fortschrittsverfolgung ausschließen will. Der Statusbericht geht monatlich an die Geschäftsleitung.
Ergebnis von Teil 3 und offene Punkte
Am Ende von PM 8 liegen drei Unterlagen vor: die Statusliste NW-02 mit 930 Einträgen und Begründungen, das Risikoregister mit RR-01 bis RR-04 und den Restrisiken RS-01 und RS-02, und der freigegebene Umsetzungsplan mit 60 Maßnahmen. Für GP-A ist damit erstmals belegt, welche Anforderungen erfüllt sind und wer die übrigen bis wann erfüllt.
Offen am Ende von Teil 3:
- OF-01 Verfügbarkeit von GP-A, Überprüfung im zweiten Zyklus
- OF-03 Anmeldedienst als Schnittstelle statt Asset
- OF-04 Abdeckung des Formularbaukastens, vom Portalbetrieb weiter bestritten
- OF-05 Umzug des Serverraums
- L-01 Leistungsvereinbarungen K07 und K11 weiter ausstehend (GC.3.1.3 temporär nicht erfüllt)
- Auslegungsfrage Kap. 2.11 und 4.1.2 zur temporären Nichterfüllung, vorsichtig gelöst über RS-01
Ob die Statusliste stimmt, zeigt sich erst bei der Überprüfung. In Teil 4 prüft das interne Audit Stichproben, darunter Einträge, die hier als erfüllt oder nicht anwendbar stehen.
Wie es weitergeht
In Teil 4 misst der IZM seine Ziele mit eigenen Kennzahlen, lässt das erste interne Audit durchführen, wertet die Monitoring-Verfahren aus und legt der Geschäftsleitung die Managementbewertung vor.
- Weiter mit Teil 4: Überwachung
- Zurück zu Teil 2: Anforderungsanalyse
- Methodik zum dritten Prozessschritt: Anforderungen bewerten und Abweichungen dokumentieren, Risikoanalyse, Risiko-Mindestkriterien, Nachweisplan
Blackfort Technology unterstützt bei Statuserhebung, Risikobetrachtung und Umsetzungsplanung, siehe Beratung.
Rechtehinweis: Kurze Zitate und Fundstellen aus BSI-Standard 300-1 „Methodik Grundschutz++“, Version 1.0 vom 20.10.2026, © Bundesamt für Sicherheit in der Informationstechnik 2026, Quelle: BSI-Seite zu Grundschutz++. Sie stehen nicht unter CC BY-SA 4.0; der Lizenzhinweis am Seitenende gilt nur für die Auszüge aus den Katalogdaten.