Ziel der ISMS-Tool-Auswahl ist es, die Software zu finden, die auf die eigene Organisation und Situation am besten passt. Wichtige Voraussetzung dafür ist, dass Sie als Verantwortlicher für die Auswahl die Rahmenbedingungen und Anforderungen der eigenen Organisation erhoben und verstanden haben. Mit der folgenden Liste können Sie die Anforderungen bei den Ansprechpartnern in Ihrer Organisation strukturiert abfragen.

Die Ergebnisse fließen in wichtige Vorüberlegungen ein und sind Grundlage für die Kriterienkataloge, mit denen später die Anbieter verglichen werden.

1 ISMS-Software

1.1 Anforderungen an die Funktionalität

Welche Standards sollen in der Software abgebildet werden können?

z.B. ISO 27001, IT-Grundschutz, TISAX usw.

1.2 Besonderheiten in der Organisation

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)

1.3 Mengengerüste

1.3.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?

1.3.2 Daten

Die Datenmengen helfen bei der Abschätzung 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)

1.4 Schnittstellen

1.4.1 Fachliche Schnittstellen

Aus welchen anderen Systemen soll die ISMS-Anwendung fachliche Daten beziehen?

z.B. aus einer CMDB

An welche anderen Systeme soll die ISMS-Anwendung fachliche Daten übergeben?

1.4.2 Technische Schnittstellen

Soll es eine Anbindung an ein Benutzerverwaltung (LDAP, Active Directory) geben?

Soll es eine technische Anbindung für die Benutzer-Anmeldung geben?

z.B. SSO über Kerberos, Authentifizierung gegen LDAP

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

2 Allgemeine Anforderungen

2.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
- IT-Sicherheitsgesetz
- Datenschutzgrundverordnung mit besonderen Kategorien von Daten
- Sozialgesetzbücher

Ist die Software mitbestimmungspflichtig?

2.2 Anforderungen des IT-Betriebs

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

2.2.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)

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

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

2.3 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?

2.4 Datenschutz

Welche Anforderungen an den Schutz personenbezogener Daten sind zu erfüllen?

Dürfen personenbezogene Daten des Unternehmens bzw. der Organisation im Cloud-System eines externen Anbieters gespeichert werden?

2.5 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?

2.6 Barrierefreiheit

Barrierefreiheit ermöglicht Menschen mit Behinderungen die Nutzung des Systems.

Welche Anforderungen bestehen innerhalb Ihrer Organisation an Software im Hinblick auf Barrierefreiheit?

3 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.