GS++QS-Checkliste

Aus ISMS-Ratgeber WiKi
Zur Navigation springenZur Suche springen
Under construction icon-blue.png Diese Seite ist derzeit noch ein Entwurf.

Weitere Informationen sowie Diskussionen über Änderungen an diesem Entwurf gibt es evtl. auf der Diskussion-Seite.



Hier ist eine detaillierte Checkliste für die Qualitätssicherung (QS) einer Praktik und ihrer einzelnen Anforderungen im Grundschutz++. Sie orientiert sich an den spezifischen Merkmalen des neuen Ansatzes und ist so gestaltet, dass sie sowohl für die QS der gesamten Praktik als auch für jede einzelne Anforderung anwendbar ist.

Einleitung

Diese Checkliste bildet einen vollständigen QS-Prozess für Praktiken und deren Anforderungen im Grundschutz++ ab – von der konzeptionellen Überprüfung bis zur technischen/formalen Dokumentation und Nachverfolgbarkeit.

Die Checkliste kann sowohl für eine Community-QS des Grundschutzes++ als auch für eigene/ergänzende Praktiken und Anforderungen einer Organisation oder anderer Standards in der Informationssicherheit verwendet werden, sofern diese im OSCAL-Format mit den zukünftigen ISMS-Tools verarbeitet werden sollen.

Überprüfung der Praktik als Ganzes

1. Vollständigkeitsprüfung

  • Ist sichergestellt, dass alle relevanten Aspekte der Praktik in expliziten Anforderungen abgebildet werden (Prozesse, Zielobjekte, Modalverben, Ereignisse, Maßnahmen)?
  • Wurden aktuelle Technologien oder Bedrohungslagen (z.B. Cloud, KI, IoT) sowie organisatorische, technische und personelle Aspekte berücksichtigt?
  • Decken die Anforderungen verschiedene Schutzbedarfsszenarien (Basis, Standard, erhöhter Bedarf) ab?

2. Redundanz- und Konsistenzprüfung

  • Gibt es Dopplungen oder widersprüchliche Anforderungen innerhalb der Praktik oder im Vergleich zu anderen Praktiken?
  • Ist die Zuordnung der Anforderungen zu Praktik und Zielobjekt logisch und konsistent?

3. Abdeckung der Schutzziele

  • Sind Vertraulichkeit, Integrität und Verfügbarkeit durch die Anforderungen angemessen adressiert?
  • Sind die jeweiligen Leistungskennzahlen plausibel und nachvollziehbar verteilt?

QS der einzelnen Anforderungen der Praktik

1. Formale Prüfung nach Satzschablone

  • Entspricht die Beschreibung der Anforderung der Vorgabe (Praktik, Zielobjekt, Modalverb, Ereignis, Handlungswort, Tags, Hinweise)?
  • Ist das Modalverb korrekt gesetzt und spiegelt die gewünschte Verbindlichkeit (MUSS/SOLLTE/KANN) angemessen wider?
  • Sind alle Pflichtfelder (z.B. Zielobjekt, Handlungswort) eindeutig ausgefüllt?
  • Sind Tags und Hinweise sinnvoll und helfen sie bei der Einordnung?

2. Inhaltsprüfung

  • Ist die Anforderung klar, prägnant und widerspruchsfrei formuliert?
  • Ist deren Sinnhaftigkeit für die jeweilige Praktik nachvollziehbar begründet?
  • Spiegelt sie aktuelle regulatorische/technische Anforderungen und bekannte gute Praxis wider?
  • Wurde bei der Erstellung auf die Community-Reviews und gängige Umsetzungsbeispiele Bezug genommen?

3. Plausibilitätsprüfung

  • Ist die Anforderung generell umsetzbar, auch für Organisationen unterschiedlicher Größe/Komplexität?
  • Passt das ausgewählte Modalverb zur tatsächlichen Kritikalität und zum Risiko?
  • Sind die Leistungskennzahlen in Bezug auf die Schutzziele angemessen gesetzt?

4. Verständlichkeit und Nachvollziehbarkeit

  • Ist die Anforderung für Dritte eindeutig verständlich (kein Interpretationsspielraum, keine Mehrdeutigkeiten)?
  • Wird die Zielgruppe adressatengerecht angesprochen?
  • Unterstützen Tags und Hinweise die Anwendung?

5. Prüfbarkeit und Nachweisbarkeit

  • Ist objektiv überprüfbar, ob die Anforderung erfüllt ist (z.B. durch Dokumentation, Test, Audit, Kontrollmechanismus)?
  • Ist erkennbar, wie der Erfüllungsgrad anhand von Leistungskennzahlen ermittelt werden kann?
  • Gibt es klare Abgrenzungskriterien zu benachbarten Anforderungen?

6. Sinnhaftigkeit und Zweckmäßigkeit

  • Trägt die Anforderung messbar zur Erreichung der Schutzziele und Praktikziele bei?
  • Gibt es einen erkennbaren Mehrwert der Anforderung außerhalb reiner Regelerfüllung?
  • Vermeidet die Anforderung einen unnötigen Mehraufwand („Overengineering“)?

Nachbearbeitung und Monitoring

  • Sind die Reviews und Korrekturen der Community dokumentiert und eingepflegt?
  • Wurde für die Anforderung ein Änderungs- und Versionsverlauf festgehalten?
  • Ist die Anforderung mit einer QSV-Freigabe versehen (inkl. Autor/in, Prüfer/in, Datum der letzten Prüfung)?