Anwendbar ist der Anfang, nicht das Ende
Der Screenshot zeigt Control para-0132 im ISMS-Modul. Oben: das Häkchen „Anwendbar" — die Statement-of-Applicability-Entscheidung nach Clause 6.1.3. In den meisten Tools wäre die Arbeit damit erledigt. In OTSM fängt sie hier an.
Denn darunter steht die eigentliche Frage in sieben Ausprägungen: Compliance-Zuordnungen. Womit im realen Betrieb ist dieses Control verbunden?
- Welche Prozesse setzen es um?
- Welche Aktivitäten führen es aus?
- Welche Rollen tragen die Verantwortung?
- Welche Work Products entstehen als Nachweis?
- Welche Richtlinien geben den Rahmen?
- Welche Schulungen stellen die Kompetenz sicher?
- Welche BCP-Elemente hängen daran?
Im Screenshot steht überall (0). Und das ist kein Fehler — das ist das Feature. Ein als „anwendbar" markiertes Control, das auf nichts zeigt, ist ein dokumentierter Selbstbetrug. OTSM malt diese Leere nicht grün. Es zeigt sie dir an. Die Zusammenfassung unten zählt ehrlich: Prozesse 0, Aktivitäten 0, Rollen 0. Solange da Nullen stehen, existiert das Control nur auf dem Papier.
Verifikation als Byprodukt der Arbeit, nicht als eigenes Projekt
Der übliche Zertifizierungsvorlauf ist ein separates Dokumentationsprojekt: Man produziert Evidenz für das Audit, parallel zur eigentlichen Arbeit. Das ist teuer, es veraltet sofort, und es misst Existenz statt Wirksamkeit.
OTSM dreht das um. Weil Controls im Universal-DAG an dieselben Entitäten angebunden werden, mit denen du ohnehin arbeitest — Prozesse, Work Products, Rollen —, wird der Nachweis zum Nebenprodukt des Tuns. Die Kette
Control → Prozess → Work Product
ist die Audit-Evidenz. Nicht eine Kopie davon, nicht eine Beschreibung davon. Das Artefakt selbst. Traceability entsteht nicht, weil jemand sie für den Auditor nachträglich zusammenklickt, sondern weil die Verankerung strukturell erzwungen ist.
Dieselbe Disziplin wie bei Anforderungen
Das ist kein Sonderweg fürs ISMS. Es ist dieselbe Regel, die in OTSM für jede Anforderung gilt: Kein Requirement ohne Messgröße/Verifikationskriterium. User Story, INCOSE, SOPHIST, Template — ausnahmslos, in strenger Lesart von 29148 §5.2.4.
Ein Control ist nichts anderes als eine Anforderung an dein Sicherheitssystem. Es unterliegt derselben Prüfung: Zeig mir das Ding, an dem ich nachweise, dass es wirkt — oder es zählt nicht. Wer diese Logik bei funktionalen Anforderungen akzeptiert und bei Security-Controls fallen lässt, hat die Logik nie verstanden.
Warum das kein „schnelleres GRC-Tool" ist
Der Reflex auf ein Audit heißt oft: GRC-Tool kaufen, um endlich Ordnung zu haben. Das Problem ist, dass die meisten dieser Tools das Häkchen-Theater nur beschleunigen. Buntes Dashboard, schnelleres Reporting, dieselbe Leere darunter.
OTSM ist bewusst kein Beschleuniger fürs Dokumentieren. Es ist ein Verweigerer: Es lässt dich Konformität nicht behaupten, wo im Graphen nichts hängt. Die Nullen im Screenshot sind der Beweis, dass das System nicht lügt. Ein Tool, das dir an dieser Stelle sofort grün gäbe, würde dir einen schöneren Käfig verkaufen — nicht mehr Sicherheit.
Die Zertifizierung beantwortet „Sieht das aus wie die Norm?". OTSM zwingt dich, die einzige Frage zu beantworten, die zählt: Wirkt es — und woran sehe ich das?
Zeig auf das Work Product. Oder nimm das Häkchen raus.