Was diese Fallakte ist und was nicht
Fiktiver Fall. Der IT-Zweckverband Musterregion, seine Kommunen, Systeme, Personen, Zahlen und Entscheidungen sind erfunden. Die Fallakte ist nicht vom BSI geprüft, nicht zertifiziert und nicht auf reale Kommunen oder Dienstleister übertragbar. Sie zeigt, wie die Vorgaben von BSI-Standard 300-1 in einer Akte aussehen können, und ersetzt keine Bewertung in Ihrer Institution.
Gemeinsamer Quellenstand aller fünf Teile: BSI-Standard 300-1 „Methodik Grundschutz++“, Version 1.0 vom 20.10.2026, und Anwenderkatalog Grundschutz++, Build vom 29.10.2026 (Commit c3f37859 vom 30.10.2026). Kennungen und Texte von Anforderungen stammen aus diesem Build, alle Mengenangaben haben wir selbst nachgezählt. Die Akte deckt die Projektmonate PM 1 bis PM 15 ab; spätere Monate kommen nur als geplante Fristen vor. Die Zählung in Projektmonaten soll verhindern, dass Daten wie tatsächlich eingetretene Ereignisse wirken.
Das BSI hat im Meilensteinplan auf seiner Grundschutz++-Seite für Dezember 2026 ein eigenes Anwendungsbeispiel an der fiktiven Beispielbehörde „BDIT“ angekündigt. Diese Fallakte ist davon unabhängig und kann von ihm abweichen.
Die Fallakte in fünf Teilen:
- Erhebung und Planung (diese Seite)
- Anforderungsanalyse: Informationsverbund, Assets, Anforderungspaket
- Realisierung: Umsetzungsstatus, Risikoregister, Umsetzungsplan
- Überwachung: Kennzahlen, internes Audit, Managementbewertung
- Verbesserung: Nichtkonformitäten, Korrekturplan, Wirksamkeitsprüfung
Die Methodik selbst erklären die Fachseiten, auf die jeder Abschnitt verweist. Hier steht nur, was der IZM entschieden und dokumentiert hat.
Steckbrief: der IT-Zweckverband Musterregion
Die folgenden Annahmen gelten unverändert für alle fünf Teile. Sie sind so gewählt, dass möglichst viele Regeln von 300-1 vorkommen: viele Auftraggeber, ein gemeinsames Portal, externe Redaktionen und ein Serverraum im Untergeschoss an einem Fluss.
| Merkmal | Festlegung im Fall (fiktiv) |
|---|---|
| Institution | IT-Zweckverband Musterregion (IZM), getragen von zwölf Kommunen K01 bis K12; rund 180 Beschäftigte |
| Institutionsleitung | Geschäftsleitung des IZM (Rolle R-01); sie entscheidet im Rahmen der Beschlüsse der Verbandsversammlung |
| Betrachteter Bereich | Geschäftsbereich Portaldienste mit 14 Beschäftigten: Betrieb des gemeinsamen Bürgerportals, über das Einwohnerinnen und Einwohner der zwölf Kommunen Anträge online stellen |
| Standort | ein Standort mit Verwaltungsgebäude und Technikgebäude; Serverraum RZ-1 im Untergeschoss des Technikgebäudes, das Gelände liegt an einem Fluss |
| Ausgangslage | kein ISMS nach IT-Grundschutz, einzelne Sicherheitsregelungen im IT-Betrieb, ein Datenschutzbeauftragter, ein ISB in Teilzeit |
| Anlass | die Leistungsvereinbarungen mit den Kommunen verlangen ein ISMS nach BSI-Grundschutz; der IZM beginnt direkt mit Grundschutz++ (zur Wahl des Weges siehe Grundschutz++ jetzt oder später) |
| Quellenstand | 300-1 Version 1.0; Anwenderkatalog Build 2026-10-29 |
Kennungsschema der Fallakte
Jedes Objekt der Akte bekommt beim ersten Auftreten eine Kennung, die sich danach nicht mehr ändert. Wird ein Objekt verworfen, bleibt die Kennung belegt und erhält einen Vermerk. So lassen sich Entscheidungen aus Teil 1 noch im Audit in Teil 4 zurückverfolgen.
| Präfix | Objekt | ab Teil |
|---|---|---|
| K01 bis K12 | Kommune (Auftraggeber) | 1 |
| K13 | beitretende Kommune | 4 |
| KX, CP, IP | Kontextfaktor, Compliance-Vorgabe, interessierte Partei | 1 |
| L, DL, KR | Lücke, Regel zur Dokumentenlenkung, Kommunikationsregel | 1 |
| GP-A bis GP-D | Geschäftsprozesse im Anwendungsbereich | 1 |
| R | Rolle in der Sicherheitsorganisation | 1 |
| Z, LL | Sicherheitsziel, Leitlinie | 1 |
| EV | Entscheidungsvorlage an die Geschäftsleitung | 1 |
| OF | offene Frage oder offene Entscheidung | 1 |
| IV, S, AS | Informationsverbund, Schnittstelle, Asset | 2 |
| EIG | eigene Anforderung des IZM (keine BSI-Anforderung) | 2 |
| B, P | Befund aus der Asset-Erfassung, Ressourcenpfad | 2 |
| RR, RS, MN, NW | Risiko, Restrisiko einer eingeplanten Anforderung, Maßnahme, Nachweis | 3 |
| KZ, FS, MB, SV | Kennzahl, Auditfeststellung, Managementbewertung, Sicherheitsereignis | 4 |
| NK, SW, VP, KV | Nichtkonformität, systemische Schwäche, Verbesserungspotenzial, Eintrag im Korrektur- und Verbesserungsplan | 5 |
Anforderungen behalten ihre Kennung aus dem Anwenderkatalog, etwa GC.6.1. Eigene Anforderungen haben das Präfix EIG, damit niemand sie für Katalogtexte hält. K1 bis K7 bezeichnen die Kriterien der Bewertungsmatrix auf der Seite Schutzbedarfsfeststellung und sind keine Objekte der Akte.
Kontext, Compliance-Liste und interessierte Parteien
Kapitel 2.1 bis 2.4 von 300-1 verlangen, äußere und innere Einflussfaktoren, gesetzliche und vertragliche Vorgaben sowie die Erwartungen der interessierten Parteien zu erfassen. Der Standard verlangt dafür keinen langen Bericht; wesentliche Aspekte sollen knapp festgehalten werden (Kap. 2.1). Der IZM hat jede Zeile mit einer Folge für das ISMS versehen, damit später erkennbar ist, wo der Faktor wieder auftaucht.
| Kennung | Faktor oder Vorgabe (fiktiv) | Folge für das ISMS | wieder in Teil |
|---|---|---|---|
| KX-01 | Lage des Geländes an einem Fluss, Serverraum im Untergeschoss (äußerer Faktor; 300-1 nennt die Lage an Flüssen als Beispiel, Kap. 2.1.1) | Hochwasser als Thema für Standortanforderungen und Risikobetrachtung | 3 |
| KX-02 | zwölf Kommunen mit eigenen Fachverfahren, an die das Portal Anträge übergibt | viele externe Schnittstellen, Abstimmung mit zwölf Auftraggebern | 2 |
| KX-03 | Personalmangel im IT-Betrieb, ISB in Teilzeit (innerer Faktor Ressourcenmangel, Kap. 2.1.2) | Ressourcenfreigabe als eigene Entscheidungsvorlage | 1, 3 |
| KX-04 | Formulare werden von Redaktionen der Kommunen selbst gepflegt | externe Nutzende mit weitreichenden Rechten im Portal | 2, 4 |
| CP-01 | Leistungsvereinbarungen mit K01 bis K12, darin die Forderung nach einem ISMS nach BSI-Grundschutz | Anlass des Vorhabens; vertragliche Anforderungen an Übergabe und Verfügbarkeit | 2 |
| CP-02 | Verträge zur Auftragsverarbeitung mit den Kommunen | Vorgaben zu Löschfristen und Meldewegen | 3 |
| CP-03 | Wartungsvertrag mit dem Hersteller der Portalsoftware, mit Fernzugang | Dienstleistung im Informationsverbund | 2 |
| CP-04 | mögliche landesrechtliche Vorgaben zur Informationssicherheit für kommunale Dienstleister | offene Frage OF-02 an die Rechtsabteilung des IZM | 2 |
| IP-01 | Kommunen als Auftraggeber: erwarten Nachweise und Übergabe ohne Verlust | Nachweisplanung, Berichte an die Verbandsversammlung | 4 |
| IP-02 | Einwohnerinnen und Einwohner: erwarten Vertraulichkeit ihrer Anträge und ein erreichbares Portal | Schutzbedarf GP-A | 1 |
| IP-03 | Personalrat: Mitbestimmung bei Protokollierung und Auswertung von Zugriffen | Beteiligung vor Einführung von Protokollauswertungen | 3 |
| IP-04 | Datenschutzbeauftragter des IZM | Anhörung bei Schutzbedarf und Löschfristen | 1 |
Lücke L-01: Für die Kommunen K07 und K11 lagen die aktuellen Leistungsvereinbarungen bei Abschluss von Teil 1 nicht vor. Die Compliance-Liste ist damit unvollständig. Der IZM hat die Lücke offen dokumentiert, statt die Inhalte aus den Verträgen der anderen Kommunen zu unterstellen.
Offene Frage OF-02: Ob für den IZM als kommunalen Dienstleister landesrechtliche Vorgaben zur Informationssicherheit gelten, hat der ISB nicht selbst beurteilt. Die Frage liegt bei der Rechtsabteilung. Wir ordnen in solchen Fällen die Vorgaben ein, die eine Institution nennt oder die in ihren Unterlagen stehen; ob sie rechtlich gelten, prüft deren Rechtsabteilung.
Nach Kapitel 2.4 legt die Institution in Abstimmung mit der Leitung fest, welche verbindlichen Verpflichtungen als Anforderungen in das ISMS aufgenommen werden. Im Fall sind das CP-01 bis CP-03. Aus ihnen entstehen in Teil 2 eigene Anforderungen, soweit der Katalog sie nicht schon abdeckt.
Anwendungsbereich und Geschäftsprozessliste
Die Geschäftsleitung hat den Anwendungsbereich auf den Geschäftsbereich Portaldienste am Standort des IZM festgelegt (EV-01). Ausgeschlossen sind die interne Verwaltung des IZM, die Rechenzentrumsdienste für die Fachverfahren der Kommunen und die Telefonanlage. Der Ausschluss ist begründet: Diese Bereiche haben eigene Verantwortliche und folgen in einem späteren Zyklus; ihre Übergänge zum Portalbetrieb werden in Teil 2 als Schnittstellen beschrieben. Was 300-1 zum Unterschied zwischen Anwendungsbereich und Informationsverbund sagt, steht auf der Seite Informationsverbund abgrenzen.
Für die Prozessliste gab es keine Prozesslandkarte. Der IZM hat deshalb die vereinfachte Geschäftsprozessanalyse nach Anhang 2 genutzt und die dort geforderten Mindestangaben erhoben: Kennung, Name, fachlich verantwortliche Stelle, Kurzbeschreibung und wesentliche Anwendungen.
| Kennung | Name | fachlich verantwortlich | Kurzbeschreibung (Zweck, Ergebnis, Beitrag zu den Zielen) | wesentliche Anwendungen |
|---|---|---|---|---|
| GP-A | Online-Anträge entgegennehmen und übergeben | Leitung Portaldienste (R-03) | Einwohnerinnen und Einwohner stellen Anträge mit Nachweisen online; der IZM prüft sie formal und übergibt sie an das Fachverfahren der zuständigen Kommune. Ergebnis: vollständiger, unverfälschter Antrag bei der Kommune. Beitrag: Online-Angebot der Kommunen nach den Leistungsvereinbarungen CP-01. | Bürgerportal, Formularbaukasten, Übergabedienst |
| GP-B | Gebühren online bezahlen | Leitung Portaldienste (R-03) | Gebühren werden im Antrag über einen externen Zahlungsdienstleister bezahlt; der Zahlungsstatus geht mit dem Antrag an die Kommune. Ergebnis: Antrag mit bestätigtem Zahlungsstatus bei der Kommune; Beitrag: Leistungsvereinbarung CP-01 erfüllen. | Bürgerportal, Zahlungsschnittstelle |
| GP-C | Formulare und Inhalte pflegen | Redaktionsleitung Portal | Redaktionen der Kommunen pflegen Formulare und Texte; der IZM stellt den Formularbaukasten bereit. Ergebnis: veröffentlichtes, geprüftes Formular; Beitrag: Online-Angebot der Kommunen. | Formularbaukasten |
| GP-D | Anfragen zum Portal beantworten | Leitung Servicedesk | Der Servicedesk beantwortet Anfragen von Einwohnerinnen, Einwohnern und Kommunen zum Portal. Ergebnis: beantwortete Anfrage; Beitrag: Erreichbarkeit des Portals für Einwohnerinnen, Einwohner und Kommunen. | Ticketsystem, E-Mail |
GP-C wurde als eigener Prozess geführt, obwohl die Formulare in GP-A verwendet werden. Der Grund: Die Pflege hat eigene Beteiligte (die Redaktionen der Kommunen) und ein eigenes Ergebnis. Diese Trennung hat in Teil 2 und Teil 4 Folgen, weil der Formularbaukasten in beiden Prozessen vorkommt.
Schutzbedarf je Geschäftsprozess
Der Schutzbedarf wurde in je einer Sitzung mit der fachlich verantwortlichen Stelle, dem ISB und dem Datenschutzbeauftragten bewertet. Maßstab waren die beiden Kategorien aus 300-1 Kapitel 2.6 und die Kriterien K1 bis K7 aus der Bewertungsmatrix auf der Seite Schutzbedarfsfeststellung. Die Einstufung hoch folgt der Definition des Standards: Die Auswirkungen können beträchtlich sein. Die Schadensszenarien des Standards dienten als Hilfestellung, nicht als abschließende Liste.
| Prozess | Vertraulichkeit | Integrität | Verfügbarkeit | Begründung (fiktiv) |
|---|---|---|---|---|
| GP-A | hoch (K2) | hoch (K6) | normal, mit Vorbehalt OF-01 | Anträge enthalten Nachweise, teils mit Gesundheitsangaben (etwa für Parkerleichterungen); ein Abfluss würde die Betroffenen erheblich beeinträchtigen und das Vertrauen in alle zwölf Kommunen beschädigen. Verfälschte Anträge führen zu falschen Bescheiden der Kommunen, die sich auf die Übergabe verlassen. Ein Ausfall von bis zu zwei Arbeitstagen ist über Fristverlängerungen und Papieranträge auffangbar. |
| GP-B | normal | hoch (K6) | normal | Zahlungsdaten liegen beim Zahlungsdienstleister, der IZM erhält nur Zahlungsstatus und Betrag. Ein verfälschter Status führt zu Bescheiden ohne Zahlung oder zu doppelten Forderungen. |
| GP-C | normal | normal | normal | Formulare und Texte sind öffentlich; Fehler werden in der Redaktion bemerkt und korrigiert. Die Wirkung verfälschter Formularlogik auf Anträge ist bei GP-A erfasst. |
| GP-D | normal | normal | normal | Anfragen enthalten selten mehr als Kontaktdaten; Ausfälle sind über Telefon und E-Mail auffangbar. |
Offene Entscheidung OF-01: Drei Kommunen verlangen in ihren Leistungsvereinbarungen, dass das Portal nach einer Störung innerhalb eines Arbeitstags wieder Anträge annimmt. Der Portalbetrieb hielt deshalb „hoch“ bei der Verfügbarkeit von GP-A für richtig, die Leitung Portaldienste „normal“. Die Geschäftsleitung hat „normal“ freigegeben, das Wiederherstellungsziel von einem Arbeitstag als Sicherheitsziel Z-03 aufgenommen und die Einstufung zur Überprüfung im zweiten Zyklus vorgemerkt. Diese Entscheidung kommt in Teil 4 und Teil 5 wieder.
Reihenfolge: GP-A und GP-B haben beide hohen Schutzbedarf. 300-1 empfiehlt, mit dem wichtigsten Prozess der höchsten Kategorie zu beginnen, und lässt bei mehreren Prozessen die Leitung wählen (Kap. 2.6). Die Geschäftsleitung hat GP-A für den ersten Zyklus gewählt, GP-B folgt im zweiten (EV-03). Für beide Prozesse ist eine explizite Risikobetrachtung erforderlich (Kap. 2.11). Wie die Einstufung methodisch abläuft, zeigt die Seite Schutzbedarfsfeststellung.
Leitlinie, Rollen und Dokumentenlenkung
Die Leitlinie LL-01 beschreibt Ziele und Strategie und legt die Verpflichtung der Geschäftsleitung fest, wie es Kapitel 2.7 vorsieht. Der Standard nennt messbare Ziele, etwa nach SMART. Der IZM hat drei Ziele formuliert, an denen sich die Kennzahlen in Teil 4 messen lassen: Z-01, für jede Anforderung im Anforderungspaket liegt ein höchstens drei Monate alter Umsetzungsstatus vor; Z-02, kritische Schwachstellen an Portal-Assets sind binnen sieben Tagen behoben; Z-03, das Portal nimmt nach einer Störung binnen eines Arbeitstags wieder Anträge an, gemessen als höchstens 24 Stunden ab Beginn der Wiederherstellung. Die Geschäftsleitung hat die Leitlinie freigegeben, das Intranet und eine Unterweisung haben sie allen Beschäftigten bekannt gemacht.
Bei den Rollen ist ein Befund offen geblieben. Der ISB ist zugleich stellvertretender Leiter des IT-Betriebs. Kapitel 2.8 nennt die Konstellation IT-Leitung und ISB ausdrücklich als Beispiel für einen zu vermeidenden Interessenkonflikt, und die Katalog-Anforderung GC.9.1.1.1 sieht vor, die Zuständigkeit für Informationssicherheit einer Person zuzuweisen, die unmittelbar der Institutionsleitung unterstellt ist; der Parameter schlägt dafür „einer unabhängigen Person“ vor. GC.9.1.1.3 verlangt Maßnahmen gegen Interessenkonflikte. Die Erläuterung zu GC.9.1.1.3 nennt als Lösung unter anderem die Einrichtung des ISB als Stabsstelle oder ein Vier-Augen-Prinzip.
| Rolle | Aufgabe im ISMS | Besetzung im Fall (fiktiv) | Befund |
|---|---|---|---|
| R-01 Geschäftsleitung | Gesamtverantwortung, Freigaben nach Kap. 2.10, Freigabe der Restrisiken | Geschäftsführerin und Stellvertreter | - |
| R-02 ISB | Steuerung des Sicherheitsprozesses, Moderation der Risikobetrachtung | ISB in Teilzeit, zugleich stellvertretender Leiter IT-Betrieb | Interessenkonflikt, GC.9.1.1.1 und GC.9.1.1.3 nicht erfüllt; Lösung in EV-04 vertagt |
| R-03 Leitung Portaldienste | Eigentümerin von GP-A und GP-B, Risikoeigentümerin | Bereichsleiterin Portaldienste | - |
| R-04 IT-Betrieb | Betrieb der Systeme, operative Umsetzung | Team Rechenzentrum, sechs Administrierende im Portalbetrieb | - |
| R-05 Datenschutzbeauftragter | Anhörung, keine ISB-Aufgaben | interner DSB | getrennt vom ISB, wie Kap. 2.8 es nahelegt |
| R-06 Auditteam | internes Audit (ab Teil 4) | Revision einer Trägerkommune im Auftrag des IZM | Auftrag in EV-04 enthalten |
| R-07 Vertragsmanagement | Verträge mit Kommunen, Hersteller und Zahlungsdienstleister | Stabsstelle Recht und Verträge | L-01 offen |
| R-08 Redaktionsleitung | fachliche Verantwortung für GP-C | Redaktionsleitung im Portalbetrieb | - |
Beteiligung des ISB: Kapitel 2.8 verlangt, den ISB in sicherheitsrelevante Projekte einzubinden und festzulegen, wann das geschieht. Der IZM hat festgelegt: Der ISB wird bei jeder Änderung informiert, die eine neue Schnittstelle, ein neues Asset oder einen neuen Dienstleister betrifft, und vor jeder Inbetriebnahme beteiligt.
Dokumentenlenkung DL-01: Alle Unterlagen der Fallakte liegen in einer Ablage mit Versionsstand, freigebender Rolle und Prüfdatum. Das ist die Grundlage für das Verfahren nach Kapitel 2.9 und für die Nachvollziehbarkeit im Audit.
Kommunikationsregel KR-01: legt fest, wer intern und gegenüber Kommunen, Hersteller und Öffentlichkeit zu Sicherheitsthemen kommuniziert und auf welchem Weg, einschließlich der Berichte an die Verbandsversammlung und des Meldewegs an die Kommunen.
Rahmen für die Risikobetrachtung
Weil GP-A und GP-B hohen Schutzbedarf haben, braucht der IZM eine explizite Risikobetrachtung. Kapitel 2.11 verlangt den Rahmen dafür schon im ersten Prozessschritt, auf strategischer, methodischer und organisatorischer Ebene, und lässt ihn von der Institutionsleitung autorisieren. Das Verfahren ist frei wählbar, solange die Mindestkriterien aus Anhang 3 erfüllt sind. Der IZM hat ein einfaches szenariobasiertes Verfahren mit drei Stufen gewählt. Die Skalen und die Matrix sind eigene Festlegungen des Falls, keine Vorgabe des BSI. Den Parameter von RISK.1.1 („nach einem anerkannten Standard“) hat der IZM mit „in Anlehnung an ISO/IEC 27005, unter Einhaltung der Mindestkriterien aus Anhang 3“ festgelegt; 300-1 Kap. 2.11 nennt ISO/IEC 27005 und ISO 31000 als mögliche Grundlagen.
| Ebene | Festlegung des IZM (fiktiv) | Mindestkriterium (Anhang 3) |
|---|---|---|
| strategisch | Risikoappetit gering für Vertraulichkeit und Integrität von Antragsdaten; Verzögerungen bis zwei Arbeitstage hinnehmbar. Akzeptanzkriterien: „niedrig“ akzeptierbar; „mittel“ befristet akzeptierbar, höchstens zwölf Monate; „hoch“ zu behandeln, sonst nur als Ausnahme durch die Geschäftsleitung | 7, 8, 27, 28 |
| methodisch | Risikoszenarien auf Grundlage der elementaren Gefährdungen G 0.1 bis G 0.47; Eintrittshäufigkeit selten (seltener als alle fünf Jahre), gelegentlich (alle ein bis fünf Jahre), wiederkehrend (mindestens jährlich); Auswirkung begrenzt, beträchtlich, existenzbedrohend | 1 bis 4, 6, 10, 18, 19 |
| organisatorisch | Risikoeigentümer ist der Eigentümer des Geschäftsprozesses (für GP-A die Leitung Portaldienste R-03); der ISB moderiert und führt das Risikoregister | 5, 16 |
| Autorisierung | Risikorichtlinie, Rollen, Kriterien und Risikoappetit von der Geschäftsleitung unterzeichnet (EV-06) | 9 |
| Eintrittshäufigkeit | begrenzt | beträchtlich | existenzbedrohend |
|---|---|---|---|
| selten | niedrig | mittel | hoch |
| gelegentlich | niedrig | hoch | hoch |
| wiederkehrend | mittel | hoch | hoch |
Ob ein eigenes Verfahren alle 35 Kriterien abdeckt, prüfen Sie mit der Checkliste auf der Seite Risiko-Mindestkriterien. Wie eine Risikobetrachtung abläuft, zeigt die Seite Risikoanalyse. Die Risiken des IZM selbst stehen in Teil 3.
Entscheidungsvorlagen an die Geschäftsleitung
Die Verantwortung für das ISMS liegt nach Kapitel 2.10 bei der Institutionsleitung und kann nicht delegiert werden. 300-1 zählt in Kapitel 2.10 die Entscheidungsvorlagen auf, die ihr insbesondere vorgelegt werden: Anwendungsbereich, Schutzbedarf der Geschäftsprozesse, Reihenfolge der Prozesse, Ressourcen und Leitlinie. Die Liste ist nicht abschließend; der IZM hat den Risikorahmen als sechste Vorlage ergänzt.
| Vorlage | Gegenstand | Ergebnis in PM 3 (fiktiv) |
|---|---|---|
| EV-01 | Anwendungsbereich Portaldienste mit Ausschlüssen | beschlossen |
| EV-02 | Schutzbedarf GP-A bis GP-D | beschlossen, Verfügbarkeit GP-A mit Vorbehalt OF-01 |
| EV-03 | Reihenfolge: GP-A im ersten Zyklus, dann GP-B, GP-C, GP-D | beschlossen |
| EV-04 | Ressourcen: ISB als Stabsstelle mit voller Stelle, Auftrag an das Auditteam | Auftrag Auditteam beschlossen; ISB-Stelle vertagt bis zum Haushaltsbeschluss der Verbandsversammlung |
| EV-05 | Leitlinie LL-01 mit den Zielen Z-01 bis Z-03 | beschlossen |
| EV-06 | Rahmen der Risikobetrachtung | beschlossen |
Die Vertagung von EV-04 ist der wichtigste offene Punkt von Teil 1. Sie lässt den Interessenkonflikt beim ISB bestehen. Für eine MUSS-Anforderung wie GC.9.1.1.1 gibt es keinen Ausweg über eine Risikoakzeptanz (Kap. 4.1.2); die Frage kommt in Teil 3 als nicht erfüllte MUSS-Anforderung mit Maßnahme und Frist zurück.
Ergebnis von Teil 1: Methodik-Status nach dem ersten Schritt
Die Methodik-Anforderungen des Anwenderkatalogs gelten für jeden Informationsverbund (300-1 Kap. 3.4.1). Der IZM hat ihren Stand schon am Ende von Schritt 1 erhoben, als vorläufige Liste, die in Teil 3 in die vollständige Statuserhebung eingeht. Die Anforderungstexte sind gekürzt, die Kennungen stammen aus dem Build vom 29.10.2026.
| Anforderung (Modalverb) | Inhalt, gekürzt | Stand PM 3 (fiktiv) | Beleg in der Akte |
|---|---|---|---|
| GC.2.1, GC.2.2 (MUSS) | externe und interne Rahmenbedingungen analysieren | erfüllt | KX-01 bis KX-04 |
| GC.3.1 (MUSS) | Verfahren zur Erfassung von Compliance-Verpflichtungen verankern | erfüllt | Compliance-Liste CP-01 bis CP-04 |
| GC.3.1.1 (MUSS) | gesetzliche Verpflichtungen analysieren | nicht erfüllt, bis OF-02 beantwortet ist | Anfrage an die Rechtsabteilung |
| GC.3.1.3 (SOLLTE) | vertragliche Verpflichtungen analysieren | nicht erfüllt, temporär (L-01) | Liste fehlender Verträge |
| GC.4.1, GC.4.2 (MUSS) | externe und interne interessierte Parteien analysieren | erfüllt | IP-01 bis IP-04 |
| GC.5.1 bis GC.5.1.4 (MUSS) | Ziele, Strategie, Verpflichtung der Leitung, Leitlinie und ihre Freigabe | erfüllt | LL-01, EV-05 |
| GC.6.1 (MUSS) | abgegrenzten Geltungsbereich nach Freigabe der Leitung festlegen | erfüllt | EV-01 |
| GC.7.1, GC.7.1.1, GC.7.1.2 (MUSS) | Verfahren, Geschäftsprozesse, Schutzbedarf | erfüllt | Prozessliste, EV-02 |
| GC.7.2 (MUSS) | Risikobetrachtung für Prozesse mit hohem Schutzbedarf ausführen | nicht erfüllt, eingeplant für Schritt 3 | - |
| GC.8.1 (MUSS) | Verfahren zur Ressourcenplanung verankern | nicht erfüllt | EV-04 vertagt |
| GC.9.1, GC.9.1.1 (MUSS) | Sicherheitsorganisation, Rollen und Zuständigkeiten | erfüllt | Rollentabelle R-01 bis R-08 |
| GC.9.1.1.1, GC.9.1.1.3 (MUSS) | unabhängiger ISB unmittelbar unter der Leitung; Interessenkonflikte vermeiden | nicht erfüllt | Befund zu R-02 |
| GC.10.1, GC.10.1.2 (MUSS) | Kommunikationsmanagement; Beteiligung bei sicherheitsrelevanten Projekten | erfüllt | Kommunikationsregel KR-01; Regel zur ISB-Beteiligung |
| GC.11.1 (MUSS) | Dokumentenlenkung über den Lebenszyklus | erfüllt | DL-01 |
| GC.12.1, RISK.1.1, RISK.1.3, RISK.1.5 (MUSS) | einheitliche Risikomethodik, Rolle Risikoeigentümer, Freigabe durch die Leitung | erfüllt | Risikorichtlinie, EV-06 |
Offen am Ende von Teil 1:
- OF-01 Verfügbarkeit von GP-A: normal mit Vorbehalt, Überprüfung im zweiten Zyklus
- OF-02 landesrechtliche Vorgaben: bei der Rechtsabteilung
- L-01 fehlende Leistungsvereinbarungen K07 und K11
- EV-04 ISB-Stelle vertagt, Interessenkonflikt besteht fort
Diese Punkte sind kein Hindernis für Teil 2. 300-1 verlangt nicht, dass Schritt 1 vollständig erfüllt ist, bevor die Anforderungsanalyse beginnt. Sie müssen aber im Umsetzungsplan landen, sonst verschwinden sie.
Wie es weitergeht
In Teil 2 grenzt der IZM den Informationsverbund für GP-A ab, erfasst die Assets mit ihren Abhängigkeiten, ordnet sie Zielobjektkategorien zu und rechnet das Anforderungspaket aus dem Katalog-Build nach.
- Weiter mit Teil 2: Anforderungsanalyse
- Methodik zum ersten Prozessschritt: BSI-Standard 300-1, Informationsverbund abgrenzen, Schutzbedarfsfeststellung
Blackfort Technology unterstützt bei der Erhebung und bereitet Entscheidungsvorlagen für die Leitung vor, 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.