Guide
ISMS-Pilotprojekt: Teste den Arbeitsablauf, nicht nur die Oberfläche
Prüfe ISMS-Software an einem echten Fall: Verantwortung übergeben, einen Nachweis ersetzen und eine offene Maßnahme bis zur Entscheidung verfolgen.


Eine Demo zeigt, was eine Software kann. Ein Pilot zeigt, ob euer Team damit arbeiten kann. Dafür braucht ihr keine Kopie eures gesamten ISMS. Ihr braucht einen begrenzten Fall, klare Erwartungen und Menschen, die den Ablauf später tatsächlich nutzen.
Dieser Testplan ist unsere praktische Empfehlung für die Softwareauswahl. Er setzt keine feste Pilotdauer voraus. Für den grundsätzlichen Kriterienvergleich findest du hier den Leitfaden zu ISMS-Software. Im Pilot geht es um die Anwendung dieser Kriterien.
Wähle einen Fall mit einer echten Übergabe
Nimm einen bereits bekannten Arbeitsablauf. Zum Beispiel: Ein Wiederherstellungstest zeigt eine Lücke. Eine verantwortliche Person soll sie bearbeiten, einen neuen Nachweis hinterlegen und das Ergebnis prüfen lassen.
Der Fall sollte mindestens zwei Rollen und eine Entscheidung enthalten. Wenn nur eine Person Daten einträgt und dieselbe Person alles freigibt, prüft ihr die Zusammenarbeit kaum.
Halte den Umfang klein: ein Prozess, ein zugehöriges Risiko oder eine Anforderung, eine Maßnahme und wenige Nachweise. Nutze bereinigte Testdaten, sofern echte Informationen für die Bewertung nicht erforderlich sind. Vereinbare vorab, wer im Pilotsystem welche Daten sehen und ändern darf.
Schreibe Erwartungen auf, bevor der Anbieter den Ablauf zeigt
Formuliere beobachtbare Ergebnisse. „Intuitiv“ ist eine Einschätzung; „die zuständige Person findet ihre offene Aufgabe ohne Unterstützung“ lässt sich prüfen.
| Szenario | Erwartetes Ergebnis |
|---|---|
| Eine Lücke erfassen | Anforderung oder Risiko und offene Maßnahme sind zugeordnet |
| Verantwortung übergeben | Die neue zuständige Person erkennt Aufgabe und Fälligkeit |
| Einen Nachweis ersetzen | Aktueller Stand und vorheriger Bezug sind nachvollziehbar |
| Eine Rückfrage stellen | Begründung und Bearbeitungsstand bleiben beim Fall |
| Den Abschluss prüfen | Die entscheidende Person erkennt Grundlage und offene Punkte |
Diese Tabelle beschreibt Prüffragen, keine garantierten Funktionen eines bestimmten Produkts. Lasst euch jeden relevanten Ablauf in der vorgesehenen Konfiguration zeigen und führt ihn anschließend selbst aus.
Teste den zweiten Durchlauf
Der vorbereitete Idealfall ist nur der Anfang. Ändere danach eine Bedingung: Die verantwortliche Person ist abwesend. Der Nachweis deckt den Zeitraum nicht ab. Eine Maßnahme wurde geschlossen, obwohl eine Rückfrage offen ist.
Beobachte, ob die Beteiligten die Abweichung erkennen und den Fall weiterbearbeiten können. Hier zeigt sich, ob das System Orientierung gibt oder ob ihr wieder auf E-Mail und Zuruf ausweicht.
Prüfe auch die Sicht der jeweiligen Rolle. Eine Administration kann möglicherweise alles sehen; das sagt wenig darüber aus, ob ein fachlicher Bearbeiter die richtigen Informationen findet. Umgekehrt sollen für ihn nicht benötigte vertrauliche Inhalte nicht allein für einen bequemeren Test freigegeben werden.
Dokumentiere Beobachtung und Bewertung getrennt
Ein Testprotokoll muss kein Roman sein. Eine Zeile pro Beobachtung reicht, wenn sie eine Entscheidung ermöglicht.
| Feld | Was du festhältst |
|---|---|
| Szenario | Ausgangslage, beteiligte Rolle und Aufgabe |
| Erwartung | Vorher festgelegtes Ergebnis |
| Beobachtung | Was tatsächlich geschah, einschließlich nötiger Hilfe |
| Abweichung | Fehlende Funktion, Konfiguration, Datenqualität oder Schulungsbedarf |
| Gewicht | Bedeutung für euren täglichen Betrieb |
| Entscheidung | Akzeptabel, erneut testen, nachbessern oder Ausschlusskriterium |
Trenne Produktgrenzen von Einrichtungsfehlern. Eine fehlende Rollenzuordnung kann korrigierbar sein. Eine notwendige Funktion, die es nicht gibt, ist eine andere Art von Ergebnis. Geplante Funktionen zählen erst dann als erfüllt, wenn sie im vereinbarten Umfang verfügbar und geprüft sind.
Prüfe den späteren Ausstieg mit
Frage, wie ihr eure Daten nach dem Pilot wieder erhaltet. Lasst euch einen verfügbaren Export an einem kleinen Datenbestand zeigen. Prüft, ob er für eure Zwecke verständlich ist und welche Inhalte, Dateien oder Beziehungen nicht enthalten sind.
Damit bewertet ihr keine abstrakte Featureliste. Ihr klärt, welchen Aufwand ein späterer Wechsel oder eine interne Weiterverarbeitung verursachen würde. Notiere offene Exportfragen genauso wie offene Fragen zur täglichen Nutzung.
Entscheide anhand der Fälle
Am Ende stehen drei mögliche Ergebnisse: Der Ablauf funktioniert für euren Bedarf. Er funktioniert nach klar benannten Anpassungen. Oder eine wesentliche Anforderung bleibt offen.
Vermeide einen Gesamtscore, der ein echtes Ausschlusskriterium mit vielen kleinen Komfortpunkten verrechnet. Die Entscheidung sollte zeigen, welche Aufgaben ihr künftig besser erledigen könnt und welche Grenzen ihr bewusst akzeptiert.
Kopexa zwei Wochen begleitet testen
Kopexa bietet eine zweiwöchige begleitete Testphase. Ihr könnt den Arbeitsablauf selbst ausprobieren und offene Fragen mit uns klären.
Nutzt einen bereinigten Prüffall als roten Faden: Legt eure Erwartungen fest, testet mit den beteiligten Rollen und prüft auch eine Abweichung vom Idealfall. Haltet fest, was funktioniert und wo ihr Unterstützung braucht. Nach den zwei Wochen habt ihr eigene Beobachtungen als Grundlage für eure Entscheidung.
Besprecht mit uns, welchen Ablauf ihr in der Testphase prüfen möchtet.