Ziel der ISMS-Tool-Auswahl ist es, die Software zu finden, die auf die eigene Organisation und deren spezifische Situation am besten passt. Eine gut durchdachte Auswahl stellt sicher, dass die implementierte Lösung nicht nur funktional, sondern auch nachhaltig und effizient zur Umsetzung des Informationssicherheits-Managementsystems (ISMS) beiträgt.
Wichtige Voraussetzung dafür ist, dass Sie als Verantwortlicher für die Auswahl die Rahmenbedingungen und Anforderungen der eigenen Organisation erhoben und verstanden haben. Dazu gehören sowohl technische, organisatorische als auch prozessuale Aspekte. Es empfiehlt sich, alle relevanten Stakeholder frühzeitig einzubinden - etwa die IT-Abteilung, die Fachabteilungen, die Datenschutzbeauftragten sowie das Management -, um sicherzustellen, dass die Anforderungen ganzheitlich erfasst werden.

1 Übersicht

Mit der folgenden Liste können Sie die Anforderungen bei den Ansprechpartnern in Ihrer Organisation strukturiert abfragen. Die Ergebnisse dieser strukturierten Abfragen fließen in wichtige Vorüberlegungen ein und bilden die Grundlage für die Erstellung von Kriterienkatalogen, anhand derer die verschiedenen Anbieter systematisch verglichen und bewertet werden können. Diese Kriterienkataloge stellen sicher, dass die Entscheidungsfindung transparent und nachvollziehbar erfolgt und die beste Wahl für Ihre Organisation getroffen wird.
Abschließend ist es empfehlenswert, die identifizierten Anforderungen nach Priorität zu klassifizieren - beispielsweise in Muss-Kriterien, Soll-Kriterien und Kann-Kriterien. Dadurch können Sie sicherstellen, dass zentrale Anforderungen erfüllt werden, während gleichzeitig eine gewisse Flexibilität für spätere Anpassungen gewahrt bleibt.
Die Liste ist nach diesen Punkten gegliedert:
  • Anforderungen an die ISMS-Software
  • Allgemeine Anforderungen
  • Weitere Überlegungen

2 Anforderungen an die ISMS-Software

2.1 Anforderungen an die Funktionalität

Welche Standards sollen in der Software abgebildet werden können?
z.B. ISO 27001, IT-Grundschutz, TISAX usw.

2.2 Besonderheiten der Organisation, Mandantenfähigkeit

Welche Besonderheiten gibt es in Ihrer Organisation, die in einem ISMS-Tool vermutlich berücksichtigt werden müssen bzw. schwierig werden könnten.
Gibt es spezielle Organisationsstrukturen, die abgebildet werden müssen?
Gibt es Unterorganisationen, deren Daten getrennt geführt werden müssen?
Gibt es spezielle Prozesse und Abläufe?
Wie stark getrennt müssen die Daten dieser Unterorganisationen sein?
 
Ist die Trennung über ein Kennzeichen in der Datenbank ausreichend oder müssen sie in getrennten Datenbanken gehalten werden? (z.B. nach regulatorischen Vorgaben oder aus Sicherheitsgründen)
Gibt es Fälle, in denen Unterorganisationen mit eigentlich getrennten Datenbeständen ihre Daten doch gegenseitig sehen können sollen?
 
Zum Beispiel bei übergreifenden Vorhaben oder bei gemeinsam betriebenen Systemen.
Sind Gesellschaften aus Ländern mit grundsätzlichen anderen Rechtssystemen einzubeziehen, deren Daten strikt abzutrennen sind? (z.B. China)

2.3 Fachliche Schnittstellen

Aus welchen anderen Systemen soll die ISMS-Anwendung fachliche Daten beziehen?
 
In vielen Organisationen gibt es eine Configuration Management Database (CMDB), in der die IT-Assets gespeichert sind. In bestimmten Fällen kann es sinnvoll sein, diese anzubinden, um die Assets nicht doppelt pflegen zu müssen. Allerdings kann die Synchronisation zwischen zwei unterschiedlichen Systemen schnell zu einem komplexen Problem heranwachsen, so dass Aufwände und Nutzen gut abgewogen werden sollen.
 
Schnittstellen könnten auch zu Systemen sinnvoll sein, die einen Compliance-Status liefern.
An welche anderen Systeme soll die ISMS-Anwendung fachliche Daten übergeben?

3 Allgemeine Anforderungen

3.1 Gesetzliche und regulatorische Rahmenbedingungen

Welchen speziellen gesetzlichen Vorschriften unterliegt das Unternehmen bzw. die Organisation, die bei der Einführung eines ISMS bzw. einer Software allgemein relevant sind? Welche Anforderungen ergeben sich daraus?
 
Beispiele:
- BaFin BAIT / KAIT / VAIT
- NIS2, IT-Sicherheitsgesetz
- Datenschutzgrundverordnung mit besonderen Kategorien von Daten
- Sozialgesetzbücher
Ist die Software mitbestimmungspflichtig durch den Betriebsrat?

3.2 Mengengerüste

3.2.1 Anzahl der Benutzer

Die Zahl der Benutzer ist häufig relevant für die Berechnung der Lizenz der Tools und für die Dimensionierung der Infrastruktur.
Wieviele Nutzer sollen grundsätzlich mit dem System arbeiten können? (named user)
 
Einige Lizenz- und Nutzungsmodelle basieren auf "named user", d.h. die Höhe der zu entrichtenden Lizenz bzw. Nutzungsgebühr berechnet sich u.a. aus der Anzahl der Benutzer, die grundsätzlich zur Nutzung freigegeben sind.
Lassen sich die Benutzer nach Nutzungsintensität gruppieren?
 
Das können beispielsweise sein: Power User, die das System durchgängig nutzen und täglich viele Arbeitsschritte durchführen. Im Unterschied zu Gelegenheitsnutzern, die nur manchmal mit dem System arbeiten müssen und dann nur wenige Arbeitsschritte absolvieren müssen.
 
Diese Zahlen sind für die Abschätzung der maximal gleichzeitig mit dem System arbeitenden Nutzer hilfreich. Beispiel: 5 Power User, die täglich und fortdauernd mit dem System arbeiten; 30 Gelegenheitsnutzer, die sich ca. einmal pro Woche für ca. 20 Minuten anmelden. Das System bzw. die Lizenz muss dann nicht auf 35 gleichzeitige Nutzer ausgelegt werden, sondern es kann auf einem geringeren Wert basieren, da wahrscheinlich niemals alle 30 Gelegenheitsnutzer gleichzeitig auf das System wollen.
Wieviele Nutzer sollen gleichzeitig mit dem System arbeiten können? (concurrent user)
 
Einige Lizenz- und Nutzungsmodelle basieren auf "concurrent user", d.h. die Höhe der zu entrichtenden Lizenz bzw. Nutzungsgebühr berechnet sich u.a. aus der Anzahl der Benutzer, die gleichzeitig mit dem System arbeiten können.
 
Außerdem muss die Infrastruktur entsprechend ausgelegt werden: Je mehr Nutzer gleichzeitig auf dem System sind, desto leistungsfähiger müssen Server, Datenbank usw. ausgelegt werden, um gute Antwortzeiten zu gewährleisten.
 
Hierbei ist zu beachten, dass es unterschiedliche Situationen geben kann. Neben dem Normalbetrieb ist ggf. mit Spitzen zu rechnen, z.B. vor anstehenden Audits.
 
In die Abschätzung sollten ggf. unterschiedliche Nutzungsintensitäten einbezogen werden. Im Beispiel oben könnte gerechnet werden: 5 Power User + 3 Gelegenheitsnutzer = 8 Nutzer, die gleichzeitig mit dem System arbeiten können.
Wie werden sich diese Zahlen in den kommenden Jahren voraussichtlich verändern?
Könnten sich diese Zahlen durch anstehende organisatorische Umstrukturierungen verändern?

3.2.2 Daten

Eine Abschätzung der Datenmengen hilft bei der Berechnung der notwendigen Speicherkapazitäten.
Mit welchen Datenmengen ist bei den Stammdaten zu rechnen?
z.B. Anzahl der Organisationseinheiten
Mit welchen Datenmengen ist bei den Bewegungsdaten zu rechnen?
z.B. Anzahl der Assets
Wieviele Daten kommen regelmäßig hinzu? (z.B. monatlich oder jährlich)
Mit welchen Mengen ist zukünftig durch organisatorische Veränderungen zu rechnen? (z.B. durch Übernahme von anderen Unternehmen)

3.3 Anforderungen des IT-Betriebs

Was wird bevorzugt: On-premises-Installation oder Cloud?

3.3.1 On-premises / Installation im eigenen Rechenzentrum:

Welche IT-Plattformen stehen im eigenen Rechenzentrum bzw. auf den Clients zur Verfügung und müssen von der ISMS-Software unterstützt werden? (Datenbanken, Server, Browser usw.)
Was sind weitere Lieferpflichten für einen internen Betrieb? (z.B. Betriebshandbuch)

3.3.2 Cloud / Software-as-a-Service (SaaS)

Welche Anforderungen muss ein Cloud-Anbieter erfüllen?
z.B. Zertifizierung nach ISO 27001, BSI C5

3.3.3 Technische Schnittstellen

Soll es eine Anbindung an ein Benutzerverwaltung (LDAP, Active Directory) geben?
Soll es eine technische Anbindung für die Benutzer-Anmeldung geben?
 
Beispiele sind Single Sign-On (SSO) oder eine Authentifizierung gegen LDAP
 
Bei einer SSO-Lösung meldet sich ein Anwender nur einmal an seinem Arbeitsplatzrechner an. Beim Zugriff auf die ISMS-Anwendung muss er sich nicht nochmal anmelden, sondern wird automatisch angemeldet. Technische Lösungen sind beispielsweise SAML oder Kerberos.
Soll ein Monitoring-System angeschlossen werden, um den Systemzustand zu überwachen?
Welche Mail-Systeme sollen angebunden werden?
 
Die Systeme verschicken Mails, um Nutzer über anstehende Aufgaben und Termine zu benachrichtigen

3.4 Datensicherheit und Informationsschutz

Welche Anforderungen an die Datensicherheit sind zu erfüllen, damit kritische Informationen nicht an Externe wie Wettbewerber, Akteure anderer Staaten, Kriminelle usw. abfließen können?
Dürfen die oft heiklen Daten zu einem ISMS (z.B. Details zur IT-Infrastruktur, Schutzmaßnahmen) bei einem externen Anbieter liegen?
Gibt es Ausschluss-Kriterien, z.B. keine Anbieter aus den USA bzw. die dem Patriot-Act unterliegen?

3.5 Datenschutz

Welche Anforderungen an den Schutz personenbezogener Daten sind zu erfüllen?
Bearbeitung der Betroffenenrechte nach EU DGSVO? (Auskunft, Export, Löschung/Anonymisierung, EInschränkung der Verarbeitung)
Löschen von Daten nach Ablauf der Aufbewahrungsfristen bzw. Wegfall des Verarbeitungszwecks?
Unter welchen Bedingungen dürfen personenbezogene Daten des Unternehmens bzw. der Organisation in Cloud-Systemen eines externen Anbieters verarbeitet werden?

3.6 Ausfallsicherheit und Wiederherstellung

Wie soll die Verfügbarkeit des Systems sein?
Welche Verfügbarkeit des ISMS-Tools sollte das eigene Rechenzentrum bzw. der SaaS-Anbieter gewährleisten?
Recovery Time Objective (RTO): Wie lange darf das ISMS-System im Fall eines Notfalls ausfallen?
Recovery Point Objective (RPO): Wieviel Datenverlust kann in einem Notfall in Kauf genommen werden?

3.7 Barrierefreiheit

Barrierefreiheit ermöglicht Menschen mit Behinderungen die Nutzung des Systems.
Welche Anforderungen bestehen innerhalb Ihrer Organisation an Software im Hinblick auf Barrierefreiheit?

4 Weitere Überlegungen

Gibt es andere Bereiche im Unternehmen bzw. in der Organisation, die eine solche Software bereits im Einsatz haben könnten?
 
Fragen:
- Kann eine bestehende Instanz mitgenutzt werden?
- Erfahrungsaustausch?
Für welche Bereiche wäre die Nutzung einer solchen Software ebenfalls interessant?
Mit welchen Veränderungen in der Organisation ist zukünftig zu rechnen? Zum Beispiel Zukäufe/M&A, Zusammenlegung mit anderen Organisationen, Abspaltungen.
Zur besseren Lesbarkeit wird im Text immer nur ein Geschlecht genutzt, es sind jedoch immer alle Geschlechter gemeint.