Wann weiß ein Unternehmen etwas?

Am Freitag, dem 11. September 2026, ging ein Formular online. Es liegt unter portal.cra-srp.enisa.europa.eu, man kommt mit einem EU-Login-Konto und Zwei-Faktor-Authentifizierung hinein, und es dient dazu, etwas zu tun, das kein europäischer Hersteller von Software oder Hardware je in dieser Form hatte tun müssen: einer Behörde zu melden, dass eine Schwachstelle in einem seiner Produkte gerade von jemandem aktiv ausgenutzt wird.

Unter den auszufüllenden Feldern gibt es eines, das man in der Sprache lesen sollte, in der es geschrieben ist, denn die Plattform ist vorerst nur auf Englisch verfügbar: „Date/Time when you became aware of the incident/actively exploited vulnerability.“ Datum und Uhrzeit, zu der Sie Kenntnis erlangt haben.

Von diesem Feld aus läuft eine Frist von vierundzwanzig Stunden.

In den FAQ, die ENISA am 12. September aktualisiert hat, am Tag nach der Eröffnung, steht ein Detail, das ich interessanter finde als alles andere. Die Agentur erklärt, dass der 72-Stunden-Zähler in der aktuellen Version der Plattform eine Fälligkeit anzeigt, die 48 Stunden nach dem Absenden der Frühwarnung berechnet wird, und dass eine Meldung deshalb als überfällig erscheinen kann, bevor überhaupt 72 Stunden seit der Kenntniserlangung des Herstellers vergangen sind. Dann fügt sie hinzu, die Logik werde in einer künftigen Version korrigiert, sodass die Frist aus dem Feld mit Datum und Uhrzeit der Kenntnis berechnet wird.

So formuliert ist das eine Release Note. Es ist auch der Punkt, an dem jemand in einem Ticket entscheiden musste, wie man eine Zeitspanne misst, die bei einer kollektiven geistigen Tatsache beginnt. Vorerst zählt die Plattform ab dem Moment, in dem Sie gesprochen haben. Sie hat angekündigt, künftig ab dem Moment zu zählen, in dem Sie gewusst haben.

Nehmen wir also eine gewöhnliche Nacht.

Um 02:13 Uhr registriert die Telemetrie eines Produkts eine auffällige Folge von Anfragen an einem Authentifizierungs-Endpunkt. Um 02:14 Uhr korreliert das SIEM diese Folge mit einer Regel und erzeugt einen Alarm mittlerer Schwere, einen von vierhundert in dieser Woche. Um 07:55 Uhr öffnet ihn eine Technikerin der Frühschicht. Um 09:20 Uhr, nach Durchsicht der Anwendungslogs, kommt sie zu dem Schluss, dass es sich wahrscheinlich nicht um einen Scanner handelt, sondern um einen funktionierenden Exploit gegen eine Fremdbibliothek. Um 11:40 Uhr erhält der Sicherheitsverantwortliche den Bericht. Um 14:10 Uhr, nach dem Vertriebsmeeting, sagt jemand der Geschäftsleitung Bescheid.

Zwölf Stunden. Niemand hat etwas verheimlicht, niemand hat ein Verfahren verletzt, niemand hat sich unvernünftig verhalten. Jeder Schritt für sich genommen ist vertretbar.

Wann hat das Unternehmen gewusst?

Das ist keine rhetorische und keine philosophische Frage. Seit dem 11. September ist es ein Pflichtfeld in einem Formular, und von diesem Feld aus läuft eine Uhr, an der Sanktionen hängen.

Über diese Frist, darüber, dass die Plattform am selben Tag entstand wie die Pflicht, der sie dient, und darüber, was es heißt, dort ohne Registrierung anzukommen, habe ich im August schon geschrieben. Jener Text endete mit einem Satz, der mir damals wie ein Schluss vorkam und mir heute wie der Anfang von etwas anderem vorkommt: Die Uhr startet bei der Kenntnis, und Kenntnis ist eine organisatorische Tatsache, bevor sie eine technische ist. Dieser Essay beginnt dort, und er handelt nicht vom CRA.

Das Recht arbeitet mit Kenntnis seit sehr viel länger als mit Software

Der Einwand zuerst, und in seiner starken Fassung, denn wenn er trägt, gibt es keinen Essay.

An einer Regel, die eine Frist ab dem Moment laufen lässt, in dem jemand von einer Tatsache Kenntnis erlangt, ist absolut nichts neu. Es ist eine der ältesten Gesetzgebungstechniken überhaupt. Verjährung, Ausschlussfristen, Rechtsmittel, Mängelrüge: Das Recht misst Zeit seit Jahrhunderten ab der Kenntnis, und es tut das, weil die Alternative, sie ab dem objektiven Ereignis zu messen, jene bestrafen würde, die nichts wissen konnten.

Im Digitalen ist der Präzedenzfall in seiner Deutlichkeit fast peinlich. Artikel 33 der DSGVO verlangt seit 2018, eine Verletzung des Schutzes personenbezogener Daten „unverzüglich und möglichst binnen 72 Stunden, nachdem ihm die Verletzung bekannt wurde“ an die Aufsichtsbehörde zu melden. Erwägungsgrund 87 ergänzt, es solle festgestellt werden, ob alle geeigneten technischen Schutzmaßnahmen und organisatorischen Maßnahmen getroffen wurden, um sofort feststellen zu können, ob eine Verletzung aufgetreten ist. Die Leitlinien 9/2022 des EDSA, in der am 28. März 2023 angenommenen Fassung 2.0, stellen klar, dass ein Verantwortlicher als in Kenntnis gesetzt gilt, sobald er „einen angemessenen Grad an Gewissheit“ hat, dass ein Sicherheitsvorfall eingetreten ist, der personenbezogene Daten kompromittiert hat.

NIS2 macht genau dasselbe mit genau denselben Zahlen. Artikel 23 Absatz 4 der Richtlinie (EU) 2022/2555 verlangt eine Frühwarnung binnen 24 Stunden nach Kenntnis eines erheblichen Sicherheitsvorfalls und eine Meldung binnen 72 Stunden. Der CRA bildet mit Artikel 14 der Verordnung (EU) 2024/2847 dasselbe Schema fast wortgleich nach: Frühwarnung binnen 24 Stunden ab dem Moment, in dem der Hersteller „becomes aware“, Meldung binnen 72 Stunden, Abschlussbericht binnen 14 Tagen nach Verfügbarkeit einer Korrekturmaßnahme bei Schwachstellen und binnen eines Monats nach der Meldung bei schwerwiegenden Vorfällen.

Drei Rechtsakte, derselbe Auslöser, dieselben Zahlen. Es wäre sehr leicht, die Sache als weiteren regulatorischen Timer abzulegen und weiterzugehen, und bei den meisten Kommentaren, die ich diese Woche gelesen habe, ist genau das passiert.

Ich möchte diesen Text gegen jene Lesart bauen, aber nicht, indem ich sie leugne. Indem ich ihre Schlussfolgerung leugne.

Der Gesetzgeber sagt nicht, wie man weiß, und genau deshalb hat er angefangen hinzusehen

Das Dokument, das meine Meinung geändert hat, ist nicht die Verordnung. Es sind die FAQ der Kommission zur Umsetzung des CRA, erstmals am 3. Dezember 2025 veröffentlicht und am 4. September 2026 aktualisiert, eine Woche vor der Eröffnung der Plattform. Abschnitt 5 betrifft die Meldepflichten, und der erste Eintrag dieses Abschnitts, 5.1, fragt, wie ein Hersteller von einer aktiv ausgenutzten Schwachstelle oder einem schwerwiegenden Vorfall Kenntnis erlangen kann.

Die Antwort beginnt damit, dass der CRA es nicht festlegt. „The CRA does not specify how a manufacturer is to become aware“, er begründet lediglich die Meldepflicht, sobald die Kenntnis vorliegt. Dann tut die Kommission etwas, wozu sie nicht verpflichtet war: Sie zählt die Kanäle auf. Ein Kunde oder ein Partner, der ungewöhnliche Aktivität meldet. Ein Threat-Intelligence-Bericht. Sicherheitsforscher oder Cybersicherheitsfirmen, die die Analyse eines in gezielten Angriffen genutzten Zero-Days veröffentlichen. Eine staatliche Behörde, die die Ausnutzung mit eigenen Überwachungssystemen entdeckt hat. Ein ethischer Hacker. Und dann, am Ende der Liste, der Satz, um den es mir geht: Ein Hersteller kann Kenntnis auch erlangen „via internal monitoring, scanning activities or telemetry“. Sein eigenes Telemetriesystem oder ein Honeypot, das die Ausnutzung einer bis dahin unbekannten Lücke anzeigt. Sein eigenes Sicherheitsteam, das Darknet-Foren beobachtet und dort Belege dafür findet, dass jemand eine Schwäche des Produkts ausgenutzt hat.

In dieser Liste ist der Sensor nicht mehr nur ein technisches Instrument. Er ist eine der Weisen, in denen eine juristische Person von etwas Kenntnis erlangt.

Hier ist eine Präzisierung nötig, denn die Versuchung, den Text zu überdehnen, ist groß, und ihr nachzugeben wäre unredlich. Direkt nach der Liste schreibt die Kommission, all das bedeute nicht, dass der Hersteller verpflichtet sei, diese Tätigkeiten auszuüben oder diese Kanäle zu beobachten, um die Meldepflichten zu erfüllen. In Artikel 14 gibt es keine Pflicht zu sehen. Und ich behaupte nicht, dass jeder beliebige Alarm automatisch die Stoppuhr in Gang setzt: Der Text sagt das nicht, die Kommission sagt das nicht, und der konkrete Begriff der Kenntnis wird Jahre der Auslegung brauchen, bis er sich setzt.

Dieser Satz trägt allerdings eine Fußnote, die zehnte, und die Fußnote sagt den Rest. „Nonetheless“, gleichwohl, verlangt Anhang I Teil II vom Hersteller unter anderem eine zentrale Kontaktstelle, an die Schwachstellen gemeldet werden können, die Einführung und Durchsetzung einer Leitlinie zur koordinierten Offenlegung von Schwachstellen sowie Maßnahmen, die den Austausch von Informationen über potenzielle Schwachstellen erleichtern.

Übersetzt: Die Meldepflicht zwingt Sie nicht hinzusehen, aber die Verordnung, in der sie steht, zwingt Sie, erreichbar zu sein. Das ist keine Pflicht zu sehen. Es ist die Pflicht, eine Tür zu haben, sie offen zu lassen und allen zu sagen, wo sie ist.

Es gibt einen zweiten Hinweis in derselben Verordnung, auf den meines Erachtens niemand genug gedrückt hat. Artikel 14 sagt „becomes aware“, tatsächliche Kenntnis. Artikel 13 Absatz 21, dasselbe Subjekt, derselbe Text, verwendet eine andere Formel: Hersteller, die „know or have reason to believe“, dass das Produkt nicht konform ist, müssen unverzüglich Korrekturmaßnahmen ergreifen. Wissen, oder Grund zur Annahme haben. Das ist der Maßstab der zugerechneten Kenntnis, den das Recht jenen zuschreibt, die hätten wissen müssen.

Der europäische Gesetzgeber kennt den Unterschied zwischen beiden Formeln sehr genau und hat sie wenige Zeilen voneinander entfernt verwendet. Er hat die zugerechnete Kenntnis nicht auf die Meldepflicht ausgedehnt, und diese Wahl ist bewusst getroffen. Aber er hat eine Verordnung geschrieben, in der auf einer Seite Abstand der Maßstab dessen, was man weiß, und der Maßstab dessen, was man mit gutem Grund annehmen muss, nebeneinanderstehen. Wer die Unschärfe beim Begriff der Awareness für ein Versehen hält, hat nicht nah genug gelesen.

Die These lautet daher nicht, Europa habe Unternehmen zum Wissen verpflichtet. Sie ist feiner und meines Erachtens wichtiger. Stück für Stück macht das europäische Digitalrecht jene Architektur rechtlich erheblich, über die eine Organisation dazu kommt, etwas zu wissen. Es schreibt keine Überwachung vor. Es schafft einen sehr starken Anreiz, beschreiben zu können, wie aus einem Signal Kenntnis wird.

Epistemische Architektur

Als epistemische Architektur bezeichne ich die Gesamtheit der Mechanismen, mit denen eine Organisation Signale aus der Welt aufnimmt, ihnen Bedeutung zuweist, entscheidet, wann die Belege ausreichen, und diese Bewertung in eine Tatsache verwandelt, auf die hin sie handeln kann. An dem Begriff ist nichts Esoterisches und an der Sache nichts Neues. Sie existiert in jedem Unternehmen, auch in denen, die sie nie benannt haben.

Ein SOC ist eine epistemische Architektur. Ein Incident-Management-Prozess ist eine. Eine Eskalationskette ist eine. Die ungeschriebene Regel, nach der eine bestimmte Klasse von Alarmen am Freitagnachmittag stummgeschaltet wird, ist eine. Auch die Entscheidung, eine Quelle nicht anzubinden, einen Feed nicht zu verlängern, ein Postfach nicht zu lesen, ist eine: negativ, implizit, fast nie bewusst getroffen und vollkommen wirksam.

In der Software haben wir ein außerordentlich verfeinertes Vokabular gebaut, um die Beobachtbarkeit von Maschinen zu diskutieren. Strukturierte Logs, Metriken, verteilte Traces, Kardinalität, Perzentile, SLO-basiertes Alerting. Ich kann in Sekunden wissen, dass die Latenz eines Endpunkts im neunundneunzigsten Perzentil gegenüber der Vorwoche um 15 % gestiegen ist, und ich kann Ihnen sagen, aus welchem nachgelagerten Dienst sie kommt.

Weit schlechter sind wir darin, die Beobachtbarkeit jener Organisation zu beschreiben, der diese Systeme gehören.

Wann ein Alarm gesehen wurde, und von wem. Wer in jenem Moment die Mittel hatte, ihn zu deuten. Welche Belege fehlten und wer sie hatte. Zu welchem Zeitpunkt der Zweifel zu vernünftiger Gewissheit wurde. Wer die Befugnis hatte, das zu erklären, und ob diese Person erreichbar war.

Das klingt nach Verwaltungsfragen, bis eine Norm von einer dieser Fragen eine Frist von vierundzwanzig Stunden losschickt. Seit Freitag ist in Europa eine davon ein Pflichtfeld mit einem Datum und einer Uhrzeit darin.

Das Paradox der regulierten Beobachtbarkeit

Hier kommt der Einwand, den ich im ganzen Text für den ernsthaftesten halte, und ich gebe ihm allen Raum, den er verdient, weil er zutrifft.

Eine Organisation, die besser sieht, bringt sich scheinbar in eine schlechtere regulatorische Lage.

Wenn ich ausgezeichnete Telemetrie über das Produkt im Betrieb habe, wenn ich Threat Intelligence einkaufe, wenn ich Abhängigkeiten fortlaufend scanne, wenn ich um drei Uhr nachts Leute in Rufbereitschaft und eine funktionierende Eskalationskette habe, werde ich Vorfälle früher entdecken. Und entdecke ich sie früher, startet die Stoppuhr früher. Mein Kollege, der nichts davon hat, weiß nichts, und keine Uhr scheint zu starten.

In einer Zeile: Je besser Sie im Wissen sind, desto früher werden Sie für das verantwortlich, was Sie wissen.

Das ist das Paradox der regulierten Beobachtbarkeit, und es ist keine Seminarübung. Schlecht gebaute Regulierung erzeugt genau diesen perversen Anreiz, und der Anreiz zeigt sich nie in expliziter Form. Kein Aufsichtsrat beschließt „wir wollen lieber nicht wissen“. Er zeigt sich in Verschiebungen: das Projekt, die Anwendungslogs an das SIEM anzubinden, das von Quartal zu Quartal rutscht, der Threat-Intelligence-Feed, der nicht verlängert wird, weil er zu viele Fehlalarme erzeugt, die Nachtbereitschaft, die informell bleibt, das Kriterium für die Eröffnung eines Vorfalls, so anspruchsvoll formuliert, dass es den Moment, in dem jemand sagen kann, es sei wirklich passiert, um Stunden nach hinten schiebt. Jede einzelne dieser Entscheidungen hat eine vernünftige technische oder budgetäre Begründung. Die Summe ist organisatorische Blindheit, durch Anhäufung entstanden und nicht durch Wahl.

Wer lange genug in der Compliance arbeitet, weiß, dass Organisationen sich so tatsächlich verteidigen. Nicht, indem sie lügen. Indem sie sich so aufstellen, dass sie nie an den Punkt kommen, an dem die Wahrheit eine erklärbare Tatsache wird.

Man muss sich also fragen, ob die Strategie funktioniert.

Die DSGVO, die hier acht Jahre Vorsprung hat, hat schon mit Nein geantwortet, und die Antwort ist härter, als sie üblicherweise zitiert wird. Erwägungsgrund 87 sagt nicht, der Verantwortliche müsse melden, wenn er weiß. Er sagt, es solle festgestellt werden, ob geeignete technische und organisatorische Maßnahmen getroffen wurden, um sofort feststellen zu können, ob eine Verletzung aufgetreten ist. Gegenstand der Prüfung ist nicht die Meldung. Es ist die Fähigkeit, etwas zu bemerken. Der EDSA schreibt in Randnummer 37 der Leitlinien, der Verantwortliche müsse deshalb interne Prozesse haben, die es ihm erlauben, eine Verletzung zu erkennen und zu bearbeiten, und fügt hinzu, dass eine erkannte Verletzung an die zuständige Führungsebene hochgemeldet werden muss, damit sie bearbeitet und nötigenfalls gemeldet werden kann. Randnummer 126 schließt den Kreis: Verzögert sich die Meldung, muss der Verantwortliche die Gründe für die Verzögerung angeben können, und die zugehörige Dokumentation dient dem Nachweis, dass die Verzögerung gerechtfertigt und nicht übermäßig war.

Den Grund einer Verzögerung kann man nicht angeben, ohne eine Chronologie zu haben. Und eine Chronologie eines Ereignisses, das die eigenen Systeme nie aufgezeichnet haben, hat man nicht.

Unter dem CRA wird dieses Prinzip eine noch strukturellere Gestalt annehmen, und das Datum, auf das es ankommt, ist nicht das von vergangenem Freitag. Es ist der 11. Dezember 2027, wenn die Verordnung vollständig anwendbar wird und mit ihr Anhang I Teil II, der die Anforderungen an die Schwachstellenbehandlung auflistet. Der Hersteller wird die Schwachstellen und Komponenten seiner Produkte identifizieren und dokumentieren müssen, samt einer maschinenlesbaren SBOM, die mindestens die Abhängigkeiten der obersten Ebene abdeckt. Er wird wirksame und regelmäßige Sicherheitstests und Überprüfungen durchführen müssen. Er wird eine Leitlinie zur koordinierten Offenlegung einführen und eine Kontaktadresse für Meldungen bereitstellen müssen. Und Artikel 13 Absatz 7 verpflichtet ihn, die relevanten Cybersicherheitsaspekte seiner Produkte systematisch zu dokumentieren, einschließlich der Schwachstellen, von denen er Kenntnis erlangt, und aller einschlägigen Informationen von Dritten.

Aneinandergereiht sagen diese Pflichten dem Hersteller nicht, er müsse alles wissen. Sie sagen ihm, er müsse ein aktuelles Inventar dessen führen, was er gebaut hat, einen erklärten Kanal, über den Meldungen ankommen, einen Prozess, der sie aufnimmt, und eine schriftliche Spur dessen, was er gewusst hat und von wem. Ich habe an anderer Stelle geschrieben, dass europäische Compliance an fehlendem Inventar scheitert und weit weniger an fehlenden Normen. Hier weitet sich die Sache: Das Inventar betrifft nicht mehr nur die Komponenten. Es betrifft die Wege, auf denen Nachrichten über diese Komponenten zu jemandem gelangen, der entscheiden kann.

Der Gesetzgeber bietet also nicht wirklich die Wahl zwischen Wissen und Nichtwissen an. Er beginnt, die Fähigkeit zu wissen zu regulieren, und das ist etwas anderes und weit eingreifender.

Vor dem Verhalten steht die Kenntnis

Das ist der Schritt, mit dem dieser Essay nicht mehr vom CRA handelt.

Jahrzehntelang wurde Compliance als zweigliedriges Verhältnis erzählt, zwischen Verhalten und Regel. Eine Norm legt fest, was zu tun ist, die Organisation tut es und weist danach nach, dass sie es getan hat. Der gesamte Apparat aus Audit, Zertifizierung und Urkundsbeweis stammt aus diesem Schema.

Im Digitalen tritt ein drittes Glied hervor, und es steht vor den beiden anderen.

Man kann keine Schwachstelle beheben, die man nicht identifiziert hat. Man kann keinen Vorfall melden, den niemand als solchen eingestuft hat. Man kann kein Risiko bewerten, wenn die dafür nötige Information im Log eines Systems steckengeblieben ist, in das niemand schaut, oder in der privaten Sitzung eines Werkzeugs, das eine einzige Person benutzt. Die Regel sagt, was zu tun ist, aber die Möglichkeit, sie überhaupt anzuwenden, hängt an einer Tatsache, die die Regel nicht beschreibt: dass die Organisation dazu gekommen ist, es zu wissen.

Die Qualität der Compliance wird damit zu einer Funktion der Qualität des kognitiven Apparats der Organisation. Nicht ihrer Redlichkeit, nicht ihres Rechtsbudgets, nicht der Zahl der Richtlinien, die sie verabschiedet hat.

Das erklärt nebenbei, warum so viele Compliance-Programme Papier erzeugen und keine Sicherheit. Sie beschreiben die geschuldeten Verhaltensweisen mit großer Genauigkeit und beschreiben nie die Wege, auf denen die Organisation entdeckt, dass sie sie einhalten muss.

Wann weiß ein Agent

Bis hierher ist das Problem so alt wie Organisationen. Jetzt kommt, was es dringend macht.

In jener Liste nennt die Kommission internes Monitoring, Scanning und Telemetrie als Kanäle, über die ein Hersteller von einem Problem Kenntnis erlangt. Das ist mit Blick auf Systeme geschrieben, die Signale erzeugen: ein Honeypot, der anspringt, eine Regel, die auslöst, ein Zähler, der eine Schwelle überschreitet. Das Signal geht dann an einen Menschen, und der Mensch versteht.

Wir treten rasch in eine Welt ein, in der diese Systeme nicht mehr nur signalisieren.

Ein Agent kann ein vor zehn Minuten veröffentlichtes CVE lesen, prüfen, ob die betroffene Abhängigkeit in der SBOM des Produkts auftaucht, das Repository öffnen, kontrollieren, ob die verwundbare Funktion aus dem Code, den wir ausliefern, tatsächlich erreichbar ist, das Ganze mit den letzten zweiundsiebzig Stunden Produktionstelemetrie korrelieren und ein Issue mit einer in natürlicher Sprache formulierten Schlussfolgerung eröffnen: Diese Schwachstelle scheint in dieser Produktversion ausgenutzt zu werden, und hier sind die Belege.

Das ist kein Grenzszenario. Das ist ein Nachmittag Arbeit mit den Werkzeugen, die wir heute haben.

Wann weiß die Organisation?

Wenn der Agent die Schlussfolgerung erzeugt? Wenn ein Mensch sie liest? Wenn jemand sie freigibt? Wenn das Issue von triage auf confirmed wechselt? Wenn sie das Postfach erreicht, das das Unternehmen öffentlich als seinen Sicherheitskanal erklärt hat, also jene zentrale Kontaktstelle, die Anhang I ihm vorschreibt?

Die juristische Antwort habe ich nicht, und ich misstraue jedem, der sie heute mit Sicherheit gibt. Ich lasse die Frage offen, weil sie es wirklich ist, und weil es dazu auf Jahre hinaus keine Rechtsprechung geben wird.

Sagen lässt sich, dass die KI das Problem nicht erzeugt. Sie macht es unaufschiebbar. Wir haben automatische Systeme immer als Instrumente behandelt, über die Menschen Kenntnis erlangen: Der Sensor erkennt, der Mensch weiß. Mit Agenten beginnen wir Systeme zu bauen, die Belege sammeln, Schlüsse ziehen, ihre eigene Zuversicht bewerten und selbständig entscheiden, dass etwas Aufmerksamkeit verdient. Die Grenze zwischen „die Maschine hat erkannt“ und „die Organisation weiß“ wird immer weniger deutlich werden, und sie wird es schnell.

Daraus folgt eine Konsequenz für die interne KI-Governance, die meines Erachtens unterschätzt wird.

Einen Agenten zu steuern wird nicht nur heißen festzulegen, was er tun darf. Es wird heißen festzulegen, welche Tatsachen er zu organisatorischer Kenntnis machen darf.

Ein Agent, der eine Schwachstelle findet und das Ergebnis in der privaten Sitzung eines Entwicklers liegen lässt, ist das eine. Derselbe Agent, dasselbe Modell, derselbe Prompt, in die Unternehmenspipeline eingebunden, sodass er automatisch einen Sicherheitsvorfall mit Zeitstempel eröffnet, ist etwas anderes. Technisch sind es dieselben Systeme. Institutionell sind es zwei verschiedene Wesen, denn das zweite kann eine Frist in Gang setzen und das erste nicht.

Ich habe vor einiger Zeit geschrieben, dass die Autorität vor der Intelligenz kommt, und dass ein Agent nicht deshalb interessant ist, weil er Dinge allein tut, sondern weil jemand ihm das Recht dazu eingeräumt hat. Das ist derselbe Gedanke, angewandt auf das Wissen statt auf das Handeln. Das Recht, innerhalb einer Organisation zu erklären, dass etwas wahr ist, ist eine Delegation wie jede andere, und bis gestern hatten wir sie nirgends aufgeschrieben, weil nur Menschen sie hatten.

Es gibt auch eine gute Kehrseite, und die gehört gesagt. Wenn die Grenzkosten der Untersuchung eines Signals einbrechen, steigt die Menge der Ereignisse, die eine Organisation sich zu verstehen leisten kann. Wir werden nicht nur mehr maschinengeschriebenen Code bekommen. Wir könnten Organisationen bekommen, die weit empfindlicher für ihre Umwelt sind und Signale ernst nehmen können, die man heute ungelesen schließt, weil das Lesen vierzig Minuten einer guten Fachkraft kostet.

Das ist gut. Und es bewirkt eine fast gegenintuitive Verschiebung für Leute in meinem Beruf: Das Problem wird nicht mehr sein, Werkzeuge zu bauen, die klug genug sind, Risiken zu sehen. Es wird sein, den Prozess zu entwerfen, durch den das Gesehene organisatorischen Status erlangt.

Das Nervensystem einer Institution

Die Metapher, die ich benutze, wenn ich das einem Kunden erklären muss, ist anatomisch, und sie hat den Vorzug, die Rhetorik vom „mehr Monitoring“ sofort zu brechen.

Ein Unternehmen ist kein Gehirn. Es ist ein verteilter Organismus. Es hat periphere Rezeptoren, Übertragungswege mit unterschiedlichen Latenzen, Zentren, in denen Signale zusammenlaufen, und Mechanismen, durch die ein Reiz zum Reflex, zum Schmerz oder zur bewussten Entscheidung wird.

Schlechte Governance besteht in diesem Bild nicht nur darin, wenige Rezeptoren zu haben. Sie kann in einem Nervensystem bestehen, das ausgezeichnet fühlt und langsam leitet und im Zentrum ankommt, wenn der Schaden schon da ist. Oder in einem, das so viele Signale erzeugt, dass es den Schmerz nicht mehr vom Rauschen unterscheidet, was der klinische Zustand etlicher SOCs ist, die ich gesehen habe.

Wenn ein SOC zehntausend irrelevante Alarme pro Woche bekommt, ist die Organisation nicht besser informiert. Sie hat nur mehr Rauschen, und obendrein hat sie sich einen vollkommen vertretbaren Grund gebaut, den zehntausendundersten nicht anzusehen.

Epistemische Qualität fällt nicht mit der Menge verfügbarer Daten zusammen. Sie ist die Fähigkeit, Belege in Überzeugungen zu verwandeln, die verlässlich genug sind, um eine Handlung zu rechtfertigen. Das sind zwei verschiedene Dinge, und das zweite kann man nicht kaufen.

Genug wissen, um zu handeln

Der Verweis des EDSA auf den angemessenen Grad an Gewissheit ist gerade deshalb nützlich, weil er diesen Punkt anerkennt und ihn in einer Zeile ausspricht. Rechtlich erhebliche Kenntnis fällt nicht mit absoluter Gewissheit zusammen. Dieselben Leitlinien halten fest, dass eine kurze anfängliche Untersuchung legitim ist und der Verantwortliche während dieser Zeit noch nicht als in Kenntnis gesetzt gilt, fügen aber hinzu, dass die Untersuchung so früh wie möglich beginnen und mit einem angemessenen Grad an Gewissheit feststellen muss, ob eine Verletzung vorliegt. Das Detail kommt danach.

Das legt den Finger auf etwas Kulturelles, das meiner Ansicht nach schwerer wiegt als die Norm.

Sehr viele Organisationen haben ihre Entscheidungsprozesse auf einer stillschweigenden Prämisse der Gewissheit gebaut. Bevor man ein Problem nach oben trägt, muss man sicher sein. Bevor man einen Vorfall eröffnet, braucht man Bestätigungen. Bevor man Recht oder Geschäftsleitung einbezieht, muss man genau wissen, was geschehen ist, denn mit einer falschen Hypothese aufzutauchen kostet Glaubwürdigkeit, und Glaubwürdigkeit ist die Währung, in der Karrieren bezahlt werden.

Die Meldesysteme, die Europa in den letzten acht Jahren gebaut hat, sind genau darauf ausgelegt, zu funktionieren, bevor diese Gewissheit besteht. Deshalb trennen CRA und NIS2 die Frühwarnung von der späteren Meldung: Die ersten vierundzwanzig Stunden sind konstruktionsbedingt Stunden unvollständiger Information, und der in der Frühwarnung verlangte Inhalt spiegelt das. Bei einem schwerwiegenden Vorfall verlangt der CRA binnen 24 Stunden mindestens die Angabe, ob der Verdacht besteht, dass er durch rechtswidrige oder böswillige Handlungen verursacht wurde. Mindestens, ob der Verdacht besteht. Nicht, was geschehen ist.

Das Recht verlangt etwas, das viele Unternehmen kulturell sehr schwer finden: sagen zu können, und es einer Behörde schriftlich zu sagen, dass man genug weiß, um zu handeln, und nicht genug, um alles zu wissen.

Das ist eine Form epistemischer Reife, und sie ist selten.

Nach meiner Erfahrung ist der Bruchpunkt fast nie technisch. In einem komplexen Projekt, an dem ich gearbeitet habe, mit einer über mehrere Dienstleister verteilten Verantwortungskette, war das Problem nie das Fehlen der Daten: Die Daten waren alle da, mit ihren Zeitstempeln, seit Monaten. Das Problem war, dass dieselbe Anomalie ihre Natur änderte, je nachdem, wer sie ansah. Für den Entwickler war sie ein Bug fürs Backlog. Für den Betrieb ein wiederkehrender Alarm mit einem Runbook. Für den Sicherheitsverantwortlichen ein möglicher Vorfall, aber „möglich“ reichte nicht, um einen zu eröffnen. Für die Geschäftsleitung existierte sie nicht, solange keine förmliche Mitteilung eintraf, und die förmliche Mitteilung setzte voraus, dass vorher jemand die Sache einen Vorfall genannt hatte.

Die Wirklichkeit änderte sich nicht, während sie diese Grenzen überschritt. Was sich änderte, war der Status, den die Organisation ihr zuwies, und die Zeit zwischen einer Grenze und der nächsten war das eigentliche Risiko. Namen habe ich keine zu nennen und es braucht sie nicht: Wer je in einer Struktur mit mehr als zwanzig Menschen gearbeitet hat, hat die Szene bereits wiedererkannt.

Die Einwände, die eine Antwort verdienen

Zwei, und der zweite beunruhigt mich weit mehr als der erste.

Der erste lautet, ich lese zu viel in ein Wort hinein. Awareness ist eine gewöhnliche Gesetzgebungstechnik, der europäische Gesetzgeber wollte nie eine Theorie organisatorischer Kenntnis bauen, und ihm philosophische Absichten zu unterstellen ist das klassische Laster derer, die Normen kommentieren, ohne sie zu schreiben.

Der Einwand ist berechtigt, und ich nehme ihn vollständig an. Genau deshalb muss man dem Gesetzgeber überhaupt keine Absicht unterstellen. Es genügt, die organisatorischen Wirkungen zu beobachten, die verschiedene Rechtsakte erzeugen, die systematisch denselben Auslöser verwenden, sich auf denselben Akteuren überlagern und jeweils eine datierte Erklärung verlangen. Ein europäisches Softwareunternehmen wird am Ende drei Uhren haben, die bei der Kenntnis starten, und eine einzige Organisation, die sie starten muss. An diesem Punkt hört die Frage, wie man weiß, auf, philosophisch zu sein, und wird zu einem Entwurfsproblem, gleichgültig, was Brüssel im Sinn hatte.

Der zweite Einwand ist ernster. Kenntnis übermäßig zu formalisieren kann defensive Organisationen erzeugen, in denen jede Information klassifiziert, protokolliert, an die Rechtsabteilung weitergereicht und als Beweismaterial behandelt wird, mit der Folge, dass genau die Reaktionsfähigkeit leidet. Wer gesehen hat, was aus der defensiven Medizin geworden ist, weiß, dass das kein theoretisches Risiko ist. Und ein Ingenieur, der weiß, dass sein Kommentar an einem Ticket in drei Jahren von einer Behörde gelesen werden könnte, wird schlechtere Kommentare schreiben, nicht bessere.

Auch dieser Einwand trifft zu, und ich habe keine Antwort, die ihn auflöst. Ich habe nur eine Unterscheidung, die ich als Kriterium benutze, wenn ich solche Prozesse entwerfen muss.

Das Ziel ist nicht, das Wissen zu bürokratisieren. Es ist, die Mehrdeutigkeit an den wenigen Stellen zu verringern, an denen Mehrdeutigkeit eine rechtzeitige Entscheidung verhindert. Es sind wenige, und sie lassen sich abzählen: wer die Befugnis hat, einen Vorfall für eröffnet zu erklären, binnen welcher Zeit ein noch nicht bewertetes Signal trotzdem von jemandem angesehen werden muss, welches Postfach der offizielle Kanal ist und wer es nachts liest, was passiert, wenn die Person, die entscheiden muss, nicht antwortet. Vier oder fünf Gelenkstellen. Alles andere kann und soll informell bleiben, denn eine Organisation, in der jedes Gespräch ein Akt ist, denkt nicht mehr.

Der Unterschied zwischen beidem ist derselbe wie zwischen einem Nervensystem und einem Gipsverband.

Wer eine Möglichkeit in eine Tatsache verwandelt

Am Freitag hat Europa nicht einfach ein Meldeportal eröffnet.

Es hat eine Tatsache sichtbar gemacht, die die Technologieregulierung zunehmend begleiten wird. Ein Unternehmen, das digitale Produkte baut, muss in der Lage sein, sich selbst zu beobachten. Es muss wissen, welche Augen es besitzt, welche Signale es für verlässlich hält, wo die Unsicherheit endet, die es tragen kann, und wer in welchem Moment eine Möglichkeit in eine Tatsache verwandelt, für die die Organisation einzustehen bereit ist.

Jahrelang haben wir digitale Accountability als die Fähigkeit gelesen, zu erklären, was wir getan haben. Die nächste Stufe ist die Fähigkeit zu erklären, wann wir genug wussten, um es zu tun.

Damit ändert sich auch die Natur des Beweises. Der Abschlussbericht zum Vorfall genügt nicht mehr, der gut geschriebene, mit der nachträglich rekonstruierten Chronologie und den gelernten Lektionen. Erheblich werden die echten Zeitstempel, die Eskalationen, die Tickets, die Entscheidungsprotokolle, die Herkunft der Information, die anfängliche Einstufung und die Änderungen der Bewertung. Nicht, weil Brüssel Logs mag. Weil ohne diese Kette die epistemische Geschichte einer Organisation nicht rekonstruierbar ist, und eine Organisation, die sie nicht rekonstruieren kann, sich auch nicht verteidigen kann.

Es geht nicht darum zu zeigen, dass man reagiert hat. Es geht darum zu zeigen, dass man nicht nötig hatte, Nichtwissen vorzutäuschen.

Das Gegenteil von Compliance ist nicht nur, eine Regel zu brechen. Es kann sein, eine Organisation zu bauen, die nicht wissen kann, wann sie eine bricht.

Institutionen sind, wie Menschen, nicht nur für das verantwortlich, was sie wissen. Unter bestimmten Bedingungen werden sie auch für die Art verantwortlich, in der sie zu wissen gewählt haben. Ein Vater, der nicht fragt, ein Arzt, der den Befund nicht liest, ein Unternehmen, das das Log nicht anbindet: Recht und gewöhnliche Moral haben immer gewusst, dass Unwissenheit eine Konstruktion sein kann und dass sie zu bauen bereits eine Entscheidung ist.

Die Technik macht diese alte Einsicht schlicht viel konkreter und viel besser datierbar.

Der Autor

Andrea MargiovanniEU-Compliance

Ich arbeite mit Teams, die Systeme unter AI Act, CRA, NIS2, DSGVO bauen. Die Regel ist keine Checkliste: sie ist eine architektonische Einschränkung, die schon beim Entwurf an Bord muss, nicht danach.

Zum Weg →