Die Kernkomponente eines jeden Informationssicherheitsmanagementsystems, ist die Prozesslandkarte. Darüber hinaus werden Swimlane-Diagramme, RACI-Matrizen, Arbeitsanweisungen mit nummerierten Schritten, Freigabeworkflows, Checklisten für jeden denkbaren Fall erstellt. Der vorherrschende Gedanke ist: Je feiner die Granularität, desto ruhiger wird der Prüfer, denn Prozesse sind eine hervorragende Grundlage für Prüfungen: Es gibt eine klare Soll-Beschreibung, es werden Evidenzen produziert, und es gibt die Frage, ob beides übereinstimmt. Kein Wunder also, dass Managementsysteme entsprechend Standards wie ISO/IEC 27001 oder BSI IT-GS Prozesse zum Teil explizit fordern. Auch gängige gesetzliche Anforderungen DORA, NIS2 fordern diese Form der Ordnung, weil sie Nachvollziehbarkeit erzeugt.[1]

Und doch kennt jeder, der einmal einen ernsthaften Sicherheitsvorfall erlebt hat oder auch einen Blick unter die Motorhaube eines Unternehmens jenseits des Prüfungskontextes geworfen hat, den Moment, in dem die Prozessbeschreibung nur noch auf dem Papier lebt. Der Angreifer hält sich nicht an die Swimlanes. Die Eskalationskette ist um drei Uhr nachts nicht erreichbar. Der Workflow sieht eine Freigabe vor, die es in dieser Lage nicht geben kann. Dann entscheidet nicht das Handbuch, sondern ein Mensch. Die Frage ist nur, ob die Organisation ihn darauf vorbereitet hat, oder ob sie ihn jahrelang dazu erzogen hat, auf den nächsten Schritt zu warten.

Diese Spannung ist nicht neu. Das preußische Militär hat sie im 19. Jahrhundert unter zwei Begriffen verhandelt, die bis heute in Führungsakademien gelehrt werden: Befehlstaktik und Auftragstaktik. Der Name, der untrennbar mit dem zweiten Begriff verbunden ist, lautet Helmuth von Moltke. Dieser Artikel überträgt die Unterscheidung auf das moderne Sicherheitsmanagement. Die These: Ein ISMS, das primär über detaillierte Prozesse organisiert ist, folgt der Logik der Befehlstaktik. Es gefällt dem Prüfer, lässt aber wenig Spielraum für Urteilskraft. Ein ISMS, das über klar beschriebene Rollen, Ziele und Leitplanken organisiert ist, folgt der Logik der Auftragstaktik. Es ist robuster, lernfähiger und, richtig gebaut, nicht weniger prüfungsfest.

Moltke und die Geburt der Auftragstaktik

Helmuth von Moltke der Ältere (1800–1891), Chef des preußischen Generalstabs, war ein Planer von außergewöhnlicher Präzision, der Eisenbahnfahrpläne für Aufmärsche berechnete und Telegrafenlinien in die Operationsführung einband. Gerade deshalb kannte er die Grenzen des Plans so genau. In seinem kurzen Aufsatz Über Strategie von 1871 findet sich der Satz, der bis heute in jedem Projektmanagement-Seminar zitiert wird, meist verkürzt und selten im Original:

„Kein Operationsplan reicht mit einiger Sicherheit über das erste Zusammentreffen mit der feindlichen Hauptmacht hinaus.“[2]

Wenige Zeilen später folgt die Konsequenz, die weniger bekannt, aber wichtiger ist: Die Strategie sei „ein System der Aushülfen“.[2] Gemeint ist nicht Improvisation als Notlösung, sondern Improvisation als Normalfall. Wenn der Plan beim ersten Kontakt mit der Wirklichkeit zerbricht, dann kann die Führung nicht in der Vorgabe jedes Schritts bestehen. Sie muss darin bestehen, dass die Unterführer verstehen, wozu sie handeln, damit sie auch dann richtig handeln können, wenn der vorgesehene Weg nicht mehr existiert.

In den Verordnungen für die höheren Truppenführer von 1869 formulierte Moltke daraus ein Führungsprinzip: Ein Befehl soll alles enthalten, was der Untergebene zur Erreichung seines Zwecks nicht selbst bestimmen kann, aber eben auch nur dieses.[3] Je höher die Ebene, desto kürzer und allgemeiner der Befehl. Das Wie bleibt bei dem, der vor Ort die Lage kennt.

Die Unterscheidung lässt sich knapp fassen:

• Befehlstaktik gibt vor, was in welcher Reihenfolge wie zu tun ist. Abweichung ist Fehler. Der Untergebene ist Ausführender, also wie im Prozess.
• Auftragstaktik gibt vor, welche Lage angestrebt wird, warum sie angestrebt wird und innerhalb welcher Grenzen gehandelt werden darf. Abweichung vom Weg ist erlaubt, Abweichung von der Absicht nicht. Der Untergebene ist Mitdenkender, wie in einer Zielvereinbarung.

Die preußische Tradition kannte dafür eine berühmte Anekdote. Prinz Friedrich Karl soll einen Major, der sich nach einem taktischen Fehler auf einen erhaltenen Befehl berief, zurechtgewiesen haben: Der König habe ihn zum Stabsoffizier gemacht, damit er wisse, wann er nicht zu gehorchen habe.[4] Noch schärfer steht es auf dem Grabstein des Generals Johann Friedrich Adolf von der Marwitz, der unter Friedrich dem Großen einen Befehl zur Plünderung von Schloss Hubertusburg verweigerte: „Wählte Ungnade, wo Gehorsam nicht Ehre brachte.“[5]

Das ist der philosophische Kern: Auftragstaktik ist kein Organisationstrick zur Effizienzsteigerung. Sie setzt ein Menschenbild voraus, in dem der Handelnde Urteilskraft besitzt und für ihren Gebrauch verantwortlich ist. Die Truppenführung von 1933, die das Prinzip später kanonisierte, zog daraus eine bemerkenswerte Konsequenz: Unterlassen und Versäumnis belasten den Führer schwerer als ein Fehlgreifen in der Wahl der Mittel.[6]

Clausewitz: Friktion, Nebel und die Grenzen des Papiers

Moltke hat Clausewitz gelesen, und man merkt es. Carl von Clausewitz (1780–1831) liefert in Vom Kriege die erkenntnistheoretische Begründung dafür, warum Befehlstaktik an der Wirklichkeit scheitern muss. Zwei Begriffe tragen diese Begründung: Ungewissheit und Friktion.

Über die Ungewissheit schreibt Clausewitz: „Der Krieg ist das Gebiet der Ungewißheit; drei Viertel derjenigen Dinge, worauf das Handeln im Kriege gebaut wird, liegen im Nebel einer mehr oder weniger großen Ungewißheit.“[7] Wer je ein Incident-Response-Team in den ersten Stunden eines Ransomware-Vorfalls begleitet hat, wird diesen Satz ohne Übertragungsleistung verstehen. Welche Systeme sind betroffen? Seit wann ist der Angreifer im Netz? Sind die Backups sauber? Ist die Exfiltration abgeschlossen oder läuft sie noch? Man handelt, bevor man weiß.

Der zweite Begriff ist subtiler. Clausewitz nennt ihn Friktion: „Es ist im Kriege alles sehr einfach, aber das Einfachste ist schwierig.“[8] Friktion ist die Summe der kleinen Widerstände, die keinen Plan sprengen und doch jeden Plan verlangsamen: der Schlüsselträger im Urlaub, das abgelaufene Zertifikat, die Telefonnummer im Notfallhandbuch, die seit der letzten Umstrukturierung nicht mehr stimmt, das Ticket-System, das selbst kompromittiert ist. Clausewitz beschreibt sie als den einzigen Begriff, der den wirklichen Krieg von dem auf dem Papier unterscheidet.[8]

Genau hier liegt die Pointe für das Sicherheitsmanagement. Ein prozessorientiertes ISMS ist in gewissem Sinne der Krieg auf dem Papier. Es beschreibt den Ablauf unter der Annahme, dass die Friktion beherrschbar ist. Prüfungen bestätigen, dass das Papier stimmt. Aber die Friktion wird nicht geprüft, sie wird erst im Ernstfall sichtbar.

Clausewitz zieht daraus nicht den Schluss, auf Pläne zu verzichten. Er zieht den Schluss, dass der Feldherr etwas anderes braucht als bessere Pläne: Urteilskraft, die er den „Takt des Urteils“ nennt, und eine Kenntnis des Zwecks, der alles Handeln ordnet. Nicht umsonst steht am Anfang seines Werks der berühmte Satz, der Krieg sei „eine bloße Fortsetzung der Politik mit anderen Mitteln“.[9] Übersetzt heißt das: Jede Operation ist nur aus ihrem übergeordneten Zweck heraus verständlich. Informationssicherheit ist kein Selbstzweck, sondern Fortsetzung der Unternehmensstrategie mit den Mitteln des Risikomanagements. Wer das Ziel nicht kennt, kann den Weg nicht ändern, wenn er versperrt ist.

Das prozessorientierte ISMS als Befehlstaktik

Man stelle sich ein typisches, prüfungserprobtes ISMS vor. Für das Schwachstellenmanagement existiert eine Arbeitsanweisung mit siebzehn Schritten: Scan-Ergebnis importieren, CVSS-Score übernehmen, Ticket anlegen, Asset-Owner zuweisen, Frist nach Matrix setzen, Erinnerung nach Tag X, Eskalation nach Tag Y, Ausnahmeantrag über Formular Z, Freigabe durch Gremium W. Für das Berechtigungsmanagement gibt es einen ähnlich dichten Ablauf, für das Change-Management ebenso, für das Incident-Management sowieso.

Das hat unbestreitbare Vorzüge, die der Beitrag über Weber im SOC auf diesem Blog ausführlich gewürdigt hat: Berechenbarkeit, Vergleichbarkeit, Schutz vor Willkür. Wo Menschen wechseln, bleibt das Verfahren. Wo Verantwortung verschwimmen könnte, macht der Prozess sie sichtbar.

Doch die Logik dieses Systems ist die der Befehlstaktik. Sie zeigt sich in fünf typischen Mustern:

• Der Prozess ersetzt das Ziel. Die Kennzahl lautet „Anteil der fristgerecht geschlossenen Tickets“, nicht „Anteil der tatsächlich ausnutzbaren Exposition“. Wer die Frist einhält, hat seine Pflicht getan, auch wenn die kritischste Schwachstelle in einem System sitzt, das im Prozess gar nicht vorkommt.
• Abweichung wird als Fehler gewertet, nicht als Urteil. Ein Administrator, der eine Schwachstelle außerhalb des Ablaufs sofort schließt, erzeugt im schlimmsten Fall im Audit ein Finding, weil der Change nicht dokumentiert war. Einer, der sie regelkonform drei Wochen offenlässt, erzeugt keines.
• Verantwortung wandert nach oben. Wenn jeder Schritt vorgegeben ist, liegt die Verantwortung für das Ergebnis beim Autor der Vorgabe. Der Ausführende ist entlastet. Das ist bequem und gefährlich zugleich.
• Das System lernt langsam. Jede Anpassung an eine neue Bedrohungslage erfordert eine Überarbeitung der Prozessdokumentation, ein Review, eine Freigabe, eine Schulung. Der Angreifer wartet nicht auf den nächsten Dokumentenlenkungszyklus.
• Es entstehen Trampelpfade. Stark reglementierte Umgebungen erzeugen Reaktanz und regelmäßig Ausweichverhalten. Jede Prozessineffizienz wird so gern ausgenutzt, um abweichende oder informelle Wege zu etablieren.

Der Prüfer mag dieses System, weil es seiner eigenen Arbeitslogik entspricht: Soll gegen Ist. Und der Prüfer ist nicht der Feind. Aber ein ISMS, das primär für die Prüfung gebaut ist, optimiert auf die falsche Lage. Es ist ein Plan für das Manöver, nicht für das Gefecht.

Das rollen- und zielorientierte ISMS als Auftragstaktik

Das Gegenmodell beschreibt nicht den Weg, sondern den Auftrag. Statt siebzehn Schritten für das Schwachstellenmanagement erhält die verantwortliche Rolle einen Auftrag, der sich an der klassischen militärischen Befehlsgliederung orientieren kann:

1. Absicht der übergeordneten Führung: Warum gibt es diese Aufgabe? Die Bank soll gegenüber bekannten, aktiv ausgenutzten Schwachstellen auf Systemen mit Kundendaten- oder Zahlungsbezug zu keinem Zeitpunkt länger exponiert sein, als es der Risikoappetit des Vorstands zulässt.
2. Auftrag: Was ist der angestrebte Zustand? Die Exposition gegenüber Schwachstellen aus dem CISA-KEV-Katalog auf kritischen Assets wird binnen definierter Zeit beseitigt oder wirksam kompensiert.
3. Leitplanken: Was darf nicht geschehen? Eine Änderung an Produktivsystemen ohne Rollback-Möglichkeit, eine Risikoakzeptanz über Schwellenwert X ohne Vorstandsinvolvierung, das Verstreichen von Meldepflichten wird unter allen Umständen vermieden.
4. Mittel und Befugnisse: Welche Ressourcen, Budgets und Entscheidungsrechte stehen zur Verfügung? Darf die Rolle ein System notfalls vom Netz nehmen?
5. Rückmeldung: Woran wird gemessen, ob der Auftrag erfüllt ist, und wann wird berichtet?

Das Wie, also Werkzeugwahl, Reihenfolge, Priorisierung im Einzelfall, technischer Workaround, bleibt bei der Rolle. Sie wird nicht über Schritte geführt, sondern über Absicht, Grenzen und Ergebnis.

Der chinesische Stratege Tsun Zu hat dieses Verhältnis schon vor über zwei Jahrtausenden beschrieben: Siegen werde, wessen General fähig sei und vom Herrscher nicht gegängelt werde.[10] Der Satz ist kein Plädoyer für Führungslosigkeit. Er setzt einen fähigen General voraus, der auf Micromanagement verzichtet. Das ist die eigentliche Bedingung der Auftragstaktik, und sie wird in der Managementliteratur gern unterschlagen.

In der Bundeswehr hat Wolf Graf von Baudissin dieses Menschenbild mit der Inneren Führung und dem Leitbild des „Staatsbürgers in Uniform“ in eine demokratische Form gebracht: Gehorsam nicht als Unterwerfung, sondern als einsichtige Mitwirkung an einem verstandenen Zweck.[11] Übertragen auf das ISMS heißt das: Eine Organisation, die über Aufträge führt, muss in die Einsicht ihrer Mitglieder investieren. Rollenbeschreibungen sind dann nicht Stellenbeschreibungen mit Aufgabenlisten, sondern Mandate.

Der Vorteil der Auftragstaktik in der Informationssicherheit

Die Vorzüge eines auftragsorientierten ISMS lassen sich in fünf Punkten zusammenfassen.

Erstens: Tempo. Der US-amerikanische Militärtheoretiker John Boyd hat mit seinem OODA-Zyklus (Observe, Orient, Decide, Act) gezeigt, dass im Konflikt derjenige im Vorteil ist, der schneller beobachtet, sich orientiert, entscheidet und handelt als sein Gegner.[12] Boyd war ein Bewunderer der preußischen Auftragstaktik, weil sie Entscheidungen dorthin verlagert, wo die Beobachtung stattfindet. Ein Analyst im SOC, der die Absicht kennt und die Befugnis hat, ein kompromittiertes Konto sofort zu sperren, durchläuft den Zyklus in Minuten. Ein Analyst, der eine Freigabekette abwarten muss, in Stunden. Angreifer operieren heute in einem Tempo, in dem Stunden über das Schadensausmaß entscheiden.

Zweitens: Robustheit gegenüber Friktion. Wenn der vorgesehene Weg versperrt ist, weil das Ticket-System verschlüsselt, der Freigeber nicht erreichbar oder das Szenario schlicht nicht vorgesehen ist, kann eine Rolle, die die Absicht kennt, einen anderen Weg wählen. Eine Rolle, die nur den Weg kennt, bleibt stehen.

Drittens: Ausrichtung auf Wirkung statt auf Nachweis. Ein Auftrag formuliert einen Zielzustand. Er zwingt dazu, Wirksamkeit zu messen und nicht nur Aktivität. Damit adressiert er das Problem, das im Weber-Artikel als Verzauberung des Reports beschrieben wurde.

Viertens: Verantwortung bleibt dort, wo gehandelt wird. Moltkes Tradition ist in diesem Punkt unbarmherzig: Wer nichts tut, weil kein Befehl vorlag, hat versagt. Ein auftragsorientiertes ISMS macht Untätigkeit sichtbar. Wer eine bekannte, kritische Exposition laufen lässt, kann sich nicht hinter einem eingehaltenen Prozess verstecken.

Fünftens: Lernfähigkeit. Ziele und Leitplanken ändern sich seltener als Bedrohungen. Wenn sich die Angriffslandschaft verschiebt, muss nicht die gesamte Prozessdokumentation neu geschrieben werden. Die Rolle passt ihr Vorgehen an, der Auftrag bleibt. Der britische Organisationsberater Stephen Bungay hat in The Art of Action gezeigt, dass genau dieser Mechanismus Moltkes Armee anpassungsfähiger machte als ihre Gegner und sich auf Unternehmen übertragen lässt.[13]

Hinzu kommt ein weicher, aber nicht zu unterschätzender Faktor: Menschen, die mit Urteilskraft betraut werden, entwickeln sie. Menschen, die nur Schritte abarbeiten, verlernen sie. Der Fachkräftemangel in der Cybersecurity ist auch ein Mangel an Arbeitsplätzen, auf denen gute Leute ihr Können anwenden dürfen.

Prüfungsfest führen: Auftragstaktik im ISMS umsetzen

So logisch dies klingt, gibt es doch einen Einwand: Prüfer lieben Prozesse. Das stimmt nur zum Teil. Ein genauer Blick in ISO/IEC 27001:2022 zeigt, dass die Norm erstaunlich wenig über detaillierte Abläufe sagt und erstaunlich viel über Rollen, Ziele, Kompetenz und Wirksamkeit. Abschnitt 5.3 verlangt, dass Rollen, Verantwortlichkeiten und Befugnisse festgelegt und kommuniziert werden. Abschnitt 6.2 verlangt messbare Informationssicherheitsziele. Abschnitt 7.2 verlangt nachgewiesene Kompetenz. Abschnitt 7.5 verlangt dokumentierte Information nur in dem Umfang, den die Organisation für die Wirksamkeit des ISMS als notwendig bestimmt.[1] Auch DORA legt den Schwerpunkt auf die Verantwortung des Leitungsorgans, auf einen dokumentierten Rahmen und auf Lernen aus Vorfällen, nicht auf eine bestimmte Prozessgranularität.[14] Die Norm ist, wenn man so will, auftragstaktischer als die Praxis, die sich um sie herum gebildet hat.

Die Aufgabe besteht also nicht darin, die Prüfung zu umgehen, sondern ihr eine andere Art von Evidenz anzubieten. Die folgende Übersicht zeigt, wie sich die Elemente der Auftragstaktik auf Normanforderungen und prüfbare Nachweise abbilden lassen:

Element der Auftragstaktik	Normbezug (ISO 27001:2022)	Prüfbare Evidenz
Absicht der Führung	5.1, 5.2 Führung und Politik	Vom Vorstand verabschiedete Sicherheitsstrategie mit Risikoappetit
Auftrag	6.2 Ziele	Messbare Ziele je Rolle mit Zielwerten und Messmethode
Leitplanken	6.1 Risikobehandlung, Anhang A	Verbindliche Mindestanforderungen und Eskalationsschwellen
Mittel und Befugnisse	5.3 Rollen, 7.1 Ressourcen	Rollenmandate mit Entscheidungsrechten und Budget
Befähigung	7.2 Kompetenz, 7.3 Bewusstsein	Kompetenzprofile, Übungsnachweise, Planspiele
Rückmeldung	9.1 Überwachung und Messung	Wirksamkeitskennzahlen statt reiner Aktivitätszähler
Lernen aus Abweichung	10.1, 10.2 Verbesserung	Entscheidungsprotokolle und Nachbesprechungen

Aus dieser Abbildung ergeben sich sechs Gestaltungsprinzipien.

1. Zwei Schichten statt einer. Nicht alles eignet sich für Auftragstaktik. Wo Gesetze, Aufsicht oder Sicherheitslogik eine bestimmte Handlung zwingend vorschreiben, etwa bei Meldepflichten gegenüber der Aufsicht, beim Vier-Augen-Prinzip für privilegierte Zugriffe oder bei der Datensicherung, bleibt es bei verbindlichen, knapp beschriebenen Mindestprozessen. Diese bilden den harten Kern. Alles andere wird über Aufträge geführt. Der Prüfer findet also durchaus Prozesse vor, aber nur dort, wo sie einen Zweck erfüllen, den kein Urteil ersetzen kann.

2. Rollenmandate statt Stellenbeschreibungen. Jede Schlüsselrolle im ISMS erhält ein Mandat im Format Absicht, Auftrag, Leitplanken, Befugnisse, Rückmeldung. Das Mandat wird vom zuständigen Leitungsorgan freigegeben und von der Rolle gegengezeichnet. Damit ist die Anforderung aus 5.3 nicht nur erfüllt, sondern übererfüllt: Die Befugnisse sind ausdrücklich, und die Verantwortung ist an das Ergebnis gebunden.

3. Wirksamkeit messen, nicht Aktivität. Die Kennzahlen des ISMS fragen nach dem Zielzustand: mittlere Expositionsdauer kritischer Schwachstellen, Erkennungszeit bei Übungsangriffen, Anteil privilegierter Konten ohne nachgewiesenen Bedarf. Das ist für Prüfer in der Regel überzeugender als eine Quote fristgerecht geschlossener Tickets, weil es die eigentliche Frage beantwortet: Ist die Organisation sicherer geworden?

4. Das Entscheidungsprotokoll als zentrales Artefakt. Auftragstaktik verlangt keine Dokumentation jedes Schritts, aber jeder wesentlichen Entscheidung. Wer vom üblichen Vorgehen abweicht, hält kurz fest: Lage, Entscheidung, Begründung mit Bezug auf die Absicht. Das Protokoll ersetzt den Prozessnachweis. Für den Prüfer ist es oft aussagekräftiger, weil es zeigt, dass die Organisation urteilt und nicht nur abarbeitet. Clausewitz hätte es wohl einen Nachweis des Takts des Urteils genannt.

5. Kompetenz als Kontrolle. Wenn die Organisation auf Urteilskraft setzt, muss sie Urteilskraft nachweisen. Das geschieht über Kompetenzprofile je Rolle, über Planspiele, Red-Team-Übungen und Krisenstabsübungen mit dokumentierter Auswertung. Der Nachweis lautet dann nicht „Der Prozess wurde befolgt“, sondern „Die Rolle hat in einer realistischen Lage zielgerichtet gehandelt“.

6. Nachbesprechung als Pflichtschleife. Nach jedem relevanten Vorfall und jeder Übung folgt eine kurze, schuldfreie Nachbesprechung in militärischer Tradition des After Action Review: Was war beabsichtigt? Was ist geschehen? Warum? Was ändern wir? Die Ergebnisse fließen in das Management-Review nach 9.3 ein. Damit wird die Lernanforderung aus Kapitel 10 nicht durch eine Überarbeitung von Dokumenten, sondern durch eine Veränderung von Aufträgen, Leitplanken oder Befähigungen erfüllt.

Das Ergebnis ist ein ISMS, das dem Prüfer weniger Ablaufdiagramme und mehr Begründungen vorlegt. Erfahrungsgemäß ist das kein Nachteil. Gute Prüfer suchen nach Wirksamkeit, und sie erkennen sie, wenn man ihnen die Evidenz dafür anbietet.

Grenzen und Missverständnisse

Auftragstaktik ist kein Allheilmittel, und sie wird oft missverstanden. Drei Missverständnisse sind besonders verbreitet.

Auftragstaktik ist nicht Laissez-faire. Moltke gab wenige, aber klare Befehle. Wer Aufträge erteilt, muss mehr denken als jemand, der Schritte vorgibt, nicht weniger. Eine vage Absicht ist schlechter als ein präziser Prozess. „Sorgen Sie für Sicherheit“ ist kein Auftrag, sondern eine Abdankung der Führung.

Auftragstaktik setzt Vertrauen voraus, und Vertrauen setzt Befähigung voraus. Eine Organisation, die ihre Mitarbeitenden nicht ausbildet, nicht übt und keine Fehler verzeiht, kann nicht über Aufträge führen. Sie wird scheitern und daraus den falschen Schluss ziehen, dass es mehr Prozesse brauche. Die preußische Armee investierte enorm in die Ausbildung ihrer Offiziere, gerade weil sie ihnen Freiheit gab.

Auftragstaktik ist nicht für jede Lage gleich geeignet. Wo Routinetätigkeiten in hoher Zahl anfallen, wo Fehler sofort katastrophal und unumkehrbar sind oder wo die Kompetenz der Ausführenden nicht gesichert ist, haben detaillierte Verfahren ihren Platz. Auch Moltke ließ den Aufmarsch per Fahrplan durchführen und nicht nach Ermessen. Die Kunst liegt in der Unterscheidung, was Fahrplan und was Gefecht ist.

Schließlich gibt es eine organisationspolitische Grenze. Auftragstaktik verschiebt Macht. Wer Entscheidungsrechte an Rollen delegiert, gibt Kontrolle ab. Für Führungskräfte, die sich über Freigaben definieren, ist das unbequem. Ein ISMS nach dem Prinzip der Auftragstaktik ist daher nicht zuerst ein Dokumentationsprojekt, sondern ein Kulturprojekt.

Schluss: Den Zweck befehlen, nicht den Weg

Das prozessorientierte ISMS ist ein Kind des Friedens. Es funktioniert hervorragend, solange die Lage dem Plan entspricht, und es besteht jede Prüfung, die den Plan prüft. Aber Informationssicherheit ist kein Friedensbetrieb. Sie ist, um es mit Clausewitz zu sagen, ein Gebiet der Ungewissheit, durchzogen von Friktion und einem Gegner, der gezielt dort angreift, wo der Plan nicht hinreicht.

Moltkes Antwort darauf war nicht der Verzicht auf Ordnung, sondern eine andere Ordnung: eine, die den Zweck klar und die Grenzen fest, den Weg aber offen hält. Übertragen auf das Sicherheitsmanagement heißt das: Rollen statt Schrittfolgen, Ziele statt Checklisten, Leitplanken statt Arbeitsanweisungen, Wirksamkeit statt Aktivität, Entscheidungsprotokolle statt Prozessnachweise. Und ein harter Kern verbindlicher Verfahren nur dort, wo kein Urteil sie ersetzen darf.

Ein solches ISMS ist nicht weniger prüfungsfest. Es ist anders prüfungsfest. Es legt dem Prüfer nicht den Nachweis vor, dass der Plan befolgt wurde, sondern den Nachweis, dass die Organisation in der Lage ist, ihren Zweck auch dann zu erreichen, wenn der Plan zerbricht. Und das ist, genau besehen, die einzige Frage, die im Ernstfall zählt.

Vielleicht lautet die Frage an das eigene ISMS also nicht: Ist jeder Schritt beschrieben?

Sondern: Weiß jeder, wozu er handelt, und darf er es auch?

Endnoten

1. Vgl. ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection – Information security management systems – Requirements, insbesondere die Abschnitte 5.3, 6.2, 7.2, 7.5, 9 und 10.
2. Helmuth von Moltke: Über Strategie (1871), in: Großer Generalstab (Hg.): Moltkes Militärische Werke, Bd. II/2, Berlin 1900, S. 291 ff.
3. Vgl. Helmuth von Moltke: Verordnungen für die höheren Truppenführer vom 24. Juni 1869, in: Moltkes Militärische Werke, Bd. II/2.
4. Die Anekdote ist vielfach überliefert, u. a. bei Stephen Bungay (s. Anm. 13); vgl. zur Geschichte des Prinzips auch Stephan Leistenschneider: Auftragstaktik im preußisch-deutschen Heer 1871 bis 1914, Hamburg 2002.
5. Grabinschrift des Generalmajors Johann Friedrich Adolf von der Marwitz (1723–1781), Friedersdorf.
6. Vgl. Truppenführung (T.F.), Heeresdienstvorschrift 300, Teil I, Berlin 1933, Einleitung.
7. Carl von Clausewitz: Vom Kriege (1832), Erstes Buch, Drittes Kapitel: Der kriegerische Genius.
8. Ebd., Erstes Buch, Siebentes Kapitel: Friktion im Kriege.
9. Ebd., Erstes Buch, Erstes Kapitel, Abschnitt 24.
10. Vgl. Sunzi: Die Kunst des Krieges, Kapitel III (Der Angriff durch List), sinngemäß nach gängigen deutschen Übersetzungen.
11. Vgl. Wolf Graf von Baudissin: Soldat für den Frieden. Entwürfe für eine zeitgemäße Bundeswehr, München 1969.
12. Vgl. John R. Boyd: Patterns of Conflict, Briefing, 1986; dazu Frans P. B. Osinga: Science, Strategy and War. The Strategic Theory of John Boyd, London 2007.
13. Vgl. Stephen Bungay: The Art of Action. How Leaders Close the Gaps between Plans, Actions and Results, London 2011.
14. Vgl. Verordnung (EU) 2022/2554 (DORA), insbesondere Art. 5, 6 und 13; ferner Richtlinie (EU) 2022/2555 (NIS2), Art. 20 und 21.