ISO-27001-Prozessdokumentation: Sicherheitsanforderungen direkt im BPMN-Diagramm
Sicherheitsanforderungen, Systeme und Dokumente direkt im BPMN-Diagramm statt in getrennten Listen. Mit Symbol-Lexikon und ISO-27001-Bezug je Anforderung.
Prozessdokumentation und Informationssicherheit leben in den meisten Unternehmen in getrennten Welten. Der Ablauf steht als BPMN™-Diagramm im Prozesshandbuch, die Sicherheitsanforderungen stehen in einer Excel-Tabelle daneben. Procevia führt beides zusammen. Sicherheitsanforderungen, IT-Systeme und Dokumente werden direkt im Diagramm erfasst und sind in jedem Export sichtbar. Der Schieberegler zeigt denselben Prozess einmal so, wie ihn ein herkömmlicher BPMN-Editor darstellt, und einmal in Procevia.
Das Problem. Prozesse hier, Sicherheitsanforderungen dort
Wer ein Managementsystem für Informationssicherheit nach ISO 27001 aufbaut oder betreibt, kennt die Doppelbuchführung. Die Prozesse sind sauber modelliert. Welche Schritte aber vertraulich sind, wer sie protokolliert, wo das Vier-Augen-Prinzip gilt und welches IT-System welche Daten hält, steht in einer separaten Tabelle. In klassischen Modellierungswerkzeugen gibt es für diese Informationen schlicht keinen Platz im Diagramm.
Das rächt sich an drei Stellen.
- Beim Audit. Die Prüferin fragt, wie die Anforderung aus der Tabelle im tatsächlichen Ablauf umgesetzt ist. Der Abgleich zwischen Prozessdiagramm und Sicherheitsliste passiert von Hand, Zeile für Zeile.
- Bei jeder Änderung. Ändert sich der Prozess, muss jemand daran denken, auch die Tabelle anzupassen. In der Praxis laufen beide Stände auseinander, ohne dass es jemand merkt.
- Im Alltag. Die Person, die den Prozess ausführt, sieht das Diagramm, aber nicht die Sicherheitsvorgaben. Die stehen in einem Dokument, das sie nie öffnet.
Behelfslösungen wie Textanmerkungen oder farbige Kästchen im Diagramm skalieren nicht. Sie haben keine feste Bedeutung, keine erfassbaren Eigenschaften und verschwinden spätestens beim Neuzeichnen des Prozesses.
Sicherheitsanforderungen in BPMN modellieren
Procevia löst das mit einer festen Notation. Elf Sicherheitsanforderungen stehen als Symbole zur Verfügung und werden dort erfasst, wo sie gelten. Am Prozessschritt, an der Rolle, am Dokument oder am IT-System. Jedes Symbol hat eine definierte Bedeutung und eigene Eigenschaftsfelder, etwa die Liste der Leseberechtigten bei Vertraulichkeit oder die Prüf-Häufigkeit bei Prüfbarkeit.
Die Notation orientiert sich an der SecBPMN2-Forschung von Mattia Salnitri, Fabiano Dalpiaz und Paolo Giorgini, erschienen 2017 in Software & Systems Modeling 16(3), die Sicherheitsanforderungen erstmals systematisch in Geschäftsprozessmodelle integriert hat. Davon profitierst du doppelt. Die Symbole sind wissenschaftlich fundiert statt frei erfunden, und sie decken die Schutzziele ab, mit denen auch die ISO 27001 arbeitet.
Drei Eigenschaften machen die Notation alltagstauglich.
- Die Marker sind Teil des Diagramms. Sie erscheinen in jedem Export, ob PNG, PDF oder SVG, im Vorschaubild der Prozessliste und in jeder gespeicherten Version. Es gibt keinen zweiten Datenbestand, der veralten könnte.
- Die Legende erklärt nur, was vorkommt. Ein Klick auf das Buch-Symbol öffnet die Legende im Diagramm. Sie zeigt genau die Symbole, die im aktuellen Prozess verwendet werden, statt alle denkbaren. Wer das Diagramm zum ersten Mal sieht, versteht es ohne Schulung.
- Das Diagramm bleibt austauschbar. Die Angaben landen als eigene Einträge in der BPMN-XML-Datei, über den Erweiterungsmechanismus, den der BPMN-2.0-Standard dafür vorsieht. Andere Werkzeuge öffnen die Datei weiterhin und ignorieren, was sie nicht kennen.
IT-Systeme und Dokumente mit Links direkt am Prozessschritt
Die zweite Hälfte des Kits beantwortet die Frage, die in jedem Audit und jedem Onboarding auftaucht. Welches System unterstützt diesen Schritt, und welche Dokumente entstehen dabei? IT-Systeme und Dokumente sind in Procevia eigene Elemente im Diagramm, mit Namen, Dokumentation und einem hinterlegbaren Link.
Der Link macht den Unterschied. Am Dokument-Element hängt die Adresse der Ablage, etwa der Vorlage im DMS oder der SharePoint-Bibliothek. Ein Klick auf das orange Link-Segment am Element öffnet das Ziel direkt. Das Prozessdiagramm wird damit zur Landkarte der tatsächlichen Ablagen, statt nur zu behaupten, dass es ein Rahmenvertrag-Dokument gibt. Für gängige Dokumenttypen stehen Standard-Symbole bereit, darunter Word, Excel, PDF, SharePoint und E-Mail, und für IT-Systeme lässt sich das eigene App-Symbol hochladen.
Damit große Prozesse lesbar bleiben, gibt es zwei Darstellungen.
- Frei. Systeme und Dokumente liegen als eigene Kästen neben dem Prozess, verbunden über gepunktete Linien. Das ist die klassische Darstellung, gut für kleine Prozesse und fürs Aufräumen.
- Am Task. Systeme und Dokumente docken als kompakte Symbole direkt am jeweiligen Schritt an, Eingangsdokumente links, Ausgangsdokumente rechts, Systeme darunter. Der Prozess braucht deutlich weniger Fläche und bleibt trotzdem vollständig.
Zusätzlich lassen sich die Ebenen Sicherheit, Systeme und Dokumente sowie Anmerkungen einzeln ein- und ausblenden. Für die Geschäftsführung exportierst du den reinen Ablauf, für das Audit die vollständige Sicht. Ausgeblendete Ebenen fehlen auch im Export.
Lexikon. Die elf Sicherheitsanforderungen im Überblick
Jede Anforderung hat ein festes Symbol, eine definierte Bedeutung und einen thematischen Bezug zu den Maßnahmen aus Anhang A der ISO/IEC 27001:2022. Wichtig fürs Einordnen. Die Zuordnung nennt die thematisch passenden Controls, sie ist kein Konformitätsnachweis. Welche Controls für euch gelten, entscheiden Risikobewertung und Anwendbarkeitserklärung eures ISMS.
Klassische Schutzziele
Vertraulichkeit
Nur berechtigte Personen haben Zugriff auf diese Information. Im Diagramm erfasst du dazu Lese- und Schreibberechtigte direkt am Element.
Einsetzbar an Dokumenten und IT-Systemen.
Typischer Einsatz. Vertragsentwürfe, Gehaltsdaten, Personalakten. Am Dokument steht, dass nur Einkauf und Recht lesen dürfen, und jeder sieht es im Diagramm.
ISO-27001-Bezug. Zugangssteuerung (A.5.15), Informationszugangsbeschränkung (A.8.3), Klassifizierung von Information (A.5.12).
Integrität
Daten sind vor unbemerkter Veränderung geschützt. Wählbar ist, ob der Schutz Personal, Hardware oder Software betrifft.
Einsetzbar an Prozessschritten und Dokumenten.
Typischer Einsatz. Prüfergebnisse, Messwerte, freigegebene Spezifikationen. Was einmal festgestellt wurde, darf niemand nachträglich still ändern.
ISO-27001-Bezug. Verwendung von Kryptografie (A.8.24), Änderungssteuerung (A.8.32).
Verfügbarkeit
Ressource oder Service muss bei Bedarf verfügbar sein. Als Eigenschaft lässt sich der geforderte Grad in Prozent hinterlegen.
Einsetzbar an Prozessschritten, Dokumenten und IT-Systemen.
Typischer Einsatz. Das ERP-System während des Rechnungslaufs, die Notfalldokumentation, die auch beim Systemausfall erreichbar sein muss.
ISO-27001-Bezug. Redundanz informationsverarbeitender Einrichtungen (A.8.14), IKT-Bereitschaft für Business Continuity (A.5.30).
Authentizität
Identität und Echtheit sind sichergestellt. Erfassbar ist, ob Identifikation nötig ist, ob die Identität verifiziert wird und welches Vertrauenslevel gilt.
Einsetzbar an Prozessschritten, Dokumenten, IT-Systemen, Rollen und Unternehmen.
Typischer Einsatz. Freigaben, die eine eindeutige Anmeldung voraussetzen, oder die Echtheitsprüfung eingehender Rechnungen vor der Zahlung.
ISO-27001-Bezug. Identitätsmanagement (A.5.16), sichere Authentisierung (A.8.5).
Datenschutz
Personenbezogene Daten werden datenschutzkonform verarbeitet. Als Eigenschaft lässt sich festhalten, welche schützenswerten Informationen betroffen sind.
Einsetzbar an Prozessschritten und Dokumenten.
Typischer Einsatz. Bewerbungsunterlagen im Einstellungsprozess, Gesundheitsdaten bei der Krankmeldung. Wie du solche Prozesse strukturiert dokumentierst, zeigt der Artikel zur DSGVO-Prozessdokumentation.
ISO-27001-Bezug. Datenschutz und Schutz personenbezogener Daten (A.5.34).
Nachweis und Kontrolle
Verantwortlichkeit
Handlungen sind eindeutig einer verantwortlichen Person zuordenbar. Erfassbar ist, wessen Handlungen nachvollziehbar sein müssen.
Einsetzbar an Prozessschritten, Rollen und Unternehmen.
Typischer Einsatz. Die Frage, wer den Vertrag freigegeben hat, muss auch Monate später eindeutig beantwortbar sein.
ISO-27001-Bezug. Informationssicherheitsrollen und -verantwortlichkeiten (A.5.2).
Prüfbarkeit
Der Schritt wird protokolliert und ist nachträglich prüfbar. Als Eigenschaften lassen sich Prüf-Häufigkeit und Zeitraum hinterlegen, kontinuierliche Protokollierung eingeschlossen.
Einsetzbar an Prozessschritten, Dokumenten, IT-Systemen, Rollen und Unternehmen.
Typischer Einsatz. Der Zahllauf wird protokolliert und quartalsweise stichprobenhaft geprüft. Genau das steht als Eigenschaft am Schritt.
ISO-27001-Bezug. Protokollierung (A.8.15), Überwachung von Aktivitäten (A.8.16).
Nichtabstreitbarkeit
Die Ausführung kann im Nachhinein nicht bestritten werden. Wählbar ist, ob der Nachweis die Ausführung oder die Nicht-Ausführung belegt.
Einsetzbar an Prozessschritten.
Typischer Einsatz. Die Freigabe einer Bestellung oder die Bestätigung eines Vertragseingangs, die später niemand abstreiten kann.
ISO-27001-Bezug. Protokollierung (A.8.15), Verwendung von Kryptografie (A.8.24), etwa über digitale Signaturen.
Regeln für die Ausführung
Funktionstrennung
Diese Schritte müssen von unterschiedlichen Personen ausgeführt werden. Das klassische Vier-Augen-Prinzip, auch dynamisch zur Laufzeit prüfbar.
Einsetzbar an Rollen und Unternehmen.
Typischer Einsatz. Wer eine Bestellung anlegt, darf sie nicht selbst freigeben. Die Trennung steht sichtbar an den beteiligten Rollen.
ISO-27001-Bezug. Aufgabentrennung (A.5.3).
Funktionsbindung
Zusammengehörige Schritte führt dieselbe Person aus. Das Gegenstück zur Funktionstrennung, wenn Kontextwissen nicht verloren gehen darf.
Einsetzbar an Rollen und Unternehmen.
Typischer Einsatz. Eine Reklamation bleibt von der Annahme bis zur Antwort in einer Hand, damit nichts zwischen Zuständigkeiten verloren geht.
ISO-27001-Bezug. Ergänzt die Zuordnung von Verantwortlichkeiten (A.5.2) im Umfeld der Aufgabentrennung (A.5.3).
Keine Delegation
Der Schritt darf nicht an andere übertragen werden. Als Eigenschaft lässt sich festhalten, wodurch das durchgesetzt wird.
Einsetzbar an Prozessschritten.
Typischer Einsatz. Die Unterschrift der Geschäftsführung unter dem Jahresabschluss oder Prüfschritte, die einer bestimmten Qualifikation vorbehalten sind.
ISO-27001-Bezug. Informationssicherheitsrollen und -verantwortlichkeiten (A.5.2).
In fünf Minuten zum sicherheitsdokumentierten Prozess
- Prozess öffnen oder anlegen. Bestehende BPMN-Diagramme importierst du direkt, neue Prozesse beschreibst du in eigenen Worten und die KI erstellt das Diagramm.
- Sicherheitsanforderungen setzen. Schritt anklicken, im Eigenschaften-Bereich die Sektion Sicherheit öffnen, Anforderungen auswählen. Es erscheinen nur die Anforderungen, die zum Elementtyp passen. Felder wie Leseberechtigte oder Prüf-Häufigkeit füllst du direkt dort aus.
- Systeme und Dokumente ergänzen. Aus der Palette ins Diagramm ziehen, mit dem Schritt verbinden, Link zur Ablage hinterlegen. Der Editor schlägt bereits verwendete Bezeichnungen vor, damit dasselbe System überall gleich heißt.
- Darstellung wählen. Für kompakte Diagramme auf die Ansicht Am Task schalten. Ebenen, die der Adressat nicht braucht, blendest du aus.
- Exportieren und teilen. PNG fürs Handbuch, PDF für die Ablage, SVG für verlustfreie Grafiken. Alle Marker, Systeme und Dokumente sind enthalten, in genau der gewählten Ansicht.
Häufige Fragen
Was ist das Notations-Kit für Sicherheitsanforderungen? Eine Erweiterung des BPMN-Editors von Procevia um elf Sicherheitsanforderungen sowie IT-Systeme und Dokumente als eigene Elemente. Alle Angaben sitzen direkt im Diagramm und bleiben in jedem Export erhalten.
Bleiben die Sicherheitsangaben beim Export erhalten? Ja, in PNG, PDF und SVG ebenso wie im Vorschaubild der Prozessliste und in älteren Versionen im Versionsverlauf. Auch der KI-Chat lässt die Marker bei Änderungen unangetastet.
Können andere BPMN-Tools die Dateien noch öffnen? Ja. Die Zusatzangaben nutzen den Erweiterungsmechanismus des BPMN-2.0-Standards. Fremde Werkzeuge öffnen die Datei wie gewohnt und ignorieren, was sie nicht kennen.
Ersetzt das ein ISMS-Tool oder die Anwendbarkeitserklärung? Nein. Procevia liefert die Prozesssicht, also wo im Ablauf welche Anforderung gilt. Risikobewertung, Anwendbarkeitserklärung und Maßnahmenverfolgung bleiben im ISMS. Beides zusammen ergibt die Dokumentation, die im Audit trägt.
Woher stammen die Symbole? Aus der SecBPMN2-Referenznotation von Salnitri, Dalpiaz und Giorgini. Procevia nutzt die Symbolformen unter der Apache-2.0-Lizenz, farblich an die eigene Oberfläche angepasst.
Quellen
- Salnitri, M. / Dalpiaz, F. / Giorgini, P. (2017): Designing secure business processes with SecBPMN, Software & Systems Modeling 16(3), S. 737 bis 757. doi.org/10.1007/s10270-015-0499-4
- ISO/IEC 27001:2022: Information security, cybersecurity and privacy protection. Information security management systems. Requirements. Anhang A, Maßnahmenziele und Maßnahmen
- OMG (2014): Business Process Model and Notation (BPMN), Version 2.0.2, Object Management Group. Abschnitt Extensibility, Erweiterungsmechanismus für herstellereigene Angaben
- Meroni, G.: secbpmn2bc-online-editor, Quelle der Symbolformen, Apache License 2.0. github.com/meronig/secbpmn2bc-online-editor
Sicherheitsanforderungen direkt im Prozess dokumentieren
Modelliere einen deiner Prozesse mit Sicherheitsmarkern, Systemen und Dokumenten und exportiere ihn für dein nächstes Audit. Dein ganzes Team arbeitet mit, von der Prozessaufnahme bis zur Freigabe.
BPMN™ und Business Process Model and Notation™ sind Marken der Object Management Group, Inc. Die Symbolformen der Sicherheitsanforderungen stammen aus der SecBPMN2-Referenznotation (Salnitri, Dalpiaz, Giorgini) und werden unter der Apache-2.0-Lizenz genutzt, farblich angepasst.