Compliance kann man kaufen. Sicherheit nicht.
Im März 2026 wurden gegen Delve 📎, ein YC-gebacktes Compliance-SaaS-Unternehmen mit einer 32-Millionen-Dollar-Series-A 📎, Vorwürfe erhoben, die in der Fachöffentlichkeit breit diskutiert wurden: vorgefertigte Compliance-Artefakte, Vorwürfe rund um mutmaßlich simulierte Attestierungen, Kunden mit dem Eindruck vollständiger Zertifizierung – in SOC-2-, ISO-27001-, HIPAA- und GDPR-Kontexten. Delve bestreitet die Vorwürfe 📎. Die Faktenlage ist nicht abschließend geklärt. TechCrunch behandelt die Punkte ausdrücklich als Allegations 📎, nicht als festgestellte Tatsachen.
Das ist die letzte Zeile zu Delve in diesem Artikel. Denn die eigentlich relevante Frage ist nicht, was dieses Unternehmen getan oder nicht getan hat. Die relevante Frage ist: Wie kann ein solcher Vorwurf überhaupt strukturell plausibel sein?
Die Antwort liegt nicht in einem Einzelfall. Sie liegt in einem strukturellen Fehler im Design des Compliance-Modells – einem, den die Branche seit Jahren produziert und den Regulierung bisher nicht vollständig adressiert hat.
Zwei Kategorien, die die Praxis systematisch vermischt
Es gibt eine Unterscheidung, die in der täglichen Compliance-Arbeit fast nie explizit gemacht wird, obwohl sie alles andere bestimmt: die Unterscheidung zwischen Compliance-Nachweis und Compliance-Entscheidung.
Ein Compliance-Nachweis dokumentiert einen Zustand. Er beantwortet die Frage: Was war zum Zeitpunkt der Prüfung vorhanden? SOC 2 Type II, ISO 27001 📎, DSGVO-Attestierungen – sie alle beschreiben, was war oder behauptet wird. Sie garantieren nicht, was ist. Das ist kein Bug. Das ist das Design. Und genau das macht sie angreifbar.
Eine Compliance-Entscheidung beantwortet eine andere Frage: Auf welcher Grundlage vertraue ich diesem Vendor, diesem System, diesem Prozess – heute, in dieser Konstellation, für dieses Risiko? Das ist eine prospektive, kontextabhängige Bewertung. Sie kann Nachweise als Input nutzen. Sie kann sie nicht ersetzen.
Die Praxis vermischt beides systematisch. „Wir haben den SOC-2-Report“ wird gleichgesetzt mit „Wir haben die Sicherheitsfrage beantwortet.“ Das ist eine Kategorienverschiebung. Und sie hat haftungsrechtliche Konsequenzen, die viele Leitungsorgane noch nicht vollständig begriffen haben.
Das Compliance-Modell funktioniert, weil Auditoren unabhängig sind. Ihre Unabhängigkeit ist kein formales Detail – sie ist die funktionale Grundvoraussetzung des gesamten Systems. Sobald Nachweis-Dokumente erzeugt werden, bevor die zugrundeliegende Prüfung stattgefunden hat, oder wenn Schlussfolgerungen vor der Evidenz existieren, verliert Compliance ihre Funktion. Sie wird zur Signalisierung ohne Signal.
Ein System, das Vertrauen durch Delegation erzeugt, kann durch Manipulation der Delegation vollständig ausgehöhlt werden. Und niemand merkt es. Weil alle Dokumente vorhanden sind. Weil alles korrekt aussieht. Weil der Ordner vollständig ist.
Das Architekturproblem: Warum SOC 2, ISO und DSGVO strukturell dieselbe Lücke haben
SOC 2 Type II bescheinigt das Vorhandensein und die Wirksamkeit von Kontrollen – innerhalb eines definierten Prüfungszeitraums, auf Basis von Stichproben, bewertet durch einen lizenzierten Wirtschaftsprüfer. Die Bescheinigung stellt keine kontinuierliche Sicherheit fest. Sie beschreibt einen Zustand, keine Eigenschaft.
ISO 27001 zertifiziert ein Informationssicherheits-Managementsystem nach einem definierten Normenkatalog. Akkreditierte Zertifizierungsstellen führen Audits durch, deren Ergebnisse über IAF CertSearch 📎 öffentlich überprüfbar sein sollen. Die Zertifizierung belegt, dass das System zum Zeitpunkt des Audits die Anforderungen erfüllte. Zwischen Audit-Zyklus und Kontrollrealität kann eine erhebliche Lücke bestehen – und niemand sieht sie, bis sie relevant wird.
DSGVO-Attestierungen – Auftragsverarbeitungsvereinbarungen, Transfer Impact Assessments, Datenschutz-Folgenabschätzungen – sind primär Selbstauskünfte mit rechtlicher Bindungswirkung. Ihre Substanz hängt vollständig von der Integrität des Erstellers ab.
Das gemeinsame Merkmal aller drei Rahmenwerke: Sie sind Vertrauensprotokolle, keine Wahrheitsnachweise. Art. 28 Abs. 1 DSGVO 📎 ist in diesem Kontext präziser, als sein Ruf vermuten lässt: Der Verantwortliche muss nicht nur prüfen, ob ein Auftragsverarbeiter eine Attestierung vorgelegt hat – er muss prüfen, ob die Garantien tatsächlich hinreichend sind. Der EDPB hält in seinen Leitlinien fest 📎, dass diese Pflicht fortlaufend ist: Der Verantwortliche soll die Garantien in angemessenen Abständen erneut prüfen, gegebenenfalls auch durch Audits und Inspektionen. Das ist kein Verwaltungsakt. Das ist eine Daueraufgabe.
Das ist kein Gesetzeswortlaut, sondern die operative Konsequenz aus Art. 28 und den EDPB-Leitlinien: Der Satz „your processor’s attestation is not your shield“ war immer schon eine präzise Zusammenfassung – und nicht erst seit dem Fall Delve.
Was „Decision-Grade“ bedeutet – und warum der Begriff Methode braucht
Einen Compliance-Nachweis zu haben, ist eine Sache. Eine Compliance-Entscheidung treffen zu können, die einer Prüfung standhält, ist eine andere. Ich nenne das Decision-Grade – nicht als Marketingbegriff, sondern als methodische Anforderung.
Das ist keine begriffliche Unterscheidung. Es ist eine operative.
Decision-Grade setzt drei strukturelle Bedingungen voraus. Bewertbar wird Evidenz dabei entlang von vier Eigenschaften: Herkunft des Nachweises, Aktualität, Geltungsbereich und Unabhängigkeit der ausstellenden Instanz. Fehlt eine davon, ist der Nachweis möglicherweise formal korrekt – aber als Entscheidungsgrundlage nicht belastbar.
Erstens: Unabhängigkeit der Evidenz. Der Nachweis, auf dem eine Entscheidung beruht, darf nicht vom Entscheidungssubjekt selbst produziert worden sein. Ein Vendor, der seine eigene Compliance-Attestierung generiert, ist kein unabhängiger Nachweis – unabhängig davon, wie professionell das Dokument aussieht. ISAE 3000 📎 – der internationale Standard für Assurance Engagements außerhalb klassischer Finanzprüfungen – beschreibt Assurance nicht als Wahrheitsstempel, sondern als methodisch gerahmte Vertrauensübertragung unter der Bedingung von Unabhängigkeit. Compliance-SaaS-Tooling operiert genau an der Grenze, an der diese Unabhängigkeit unklar wird: Es unterstützt Prozesse, die zu einem Nachweis führen sollen. Wer den Unterschied nicht aktiv markiert, produziert Audit-Illusion – die Erscheinung von Kontrolle ohne ihre Substanz.
Zweitens: zeitliche Aktualität. Nachweise altern. Ein SOC-2-Report aus dem vergangenen Jahr beschreibt Kontrollen, die zu einem definierten Prüfzeitpunkt existierten. Die Cloud Security Alliance modelliert im Ökosystem rund um ihr Cloud Controls Matrix- und CAIQ-Framework 📎 – einen Bewertungsrahmen für Cloud-Sicherheitsanforderungen – bereits eine Trennung zwischen periodischer Assessment-Logik und ergänzender kontinuierlicher Evidenz, etwa über Continuous-Auditing-Metriken. Ein Nachweis ohne Verfallslogik ist kein Kontrollinstrument, sondern Archivmaterial.
Drittens: Scope-Klarheit. Nachweise gelten für definierte Bereiche. ISO 27001 zertifiziert ein Managementsystem in einem definierten Geltungsbereich – nicht die gesamte Organisation, nicht alle Systeme. In der Praxis werden diese Scope-Grenzen von Entscheidungsträgern regelmäßig überlesen oder überschätzt. Ein Zertifikat, das drei von acht relevanten Systemen abdeckt, ist kein Nachweis für die anderen fünf. Wer diesen Abgleich nicht dokumentiert, trifft keine informierte Entscheidung – er übernimmt eine Erwartung. Und Erwartungen sind kein Verteidigungsargument gegenüber einer Aufsichtsbehörde.
Die Governance-Dimension: Was NIS-2, BSIG und ISO tatsächlich verlangen
Drei Regelwerke ziehen dieselbe Schlussfolgerung aus unterschiedlichen Richtungen – und zusammengelesen ergeben sie ein konsistentes Bild, das in der Praxis noch nicht vollständig angekommen ist.
Art. 28 DSGVO 📎 beschreibt die operative Dauerpflicht zur Prüfung von Garantien auf Prozessebene. NIS-2 Art. 20 📎 verankert die Verantwortung für die Angemessenheit dieser Prüfung ausdrücklich auf Ebene der Leitungsorgane. Zusammengelesen bedeutet das: Nicht nur der Compliance-Beauftragte muss prüfen, ob Vendor-Garantien hinreichend sind – das Leitungsorgan muss diese Prüfung genehmigen und überwachen. Die Frage ‚Haben wir eine Attestierung?‘ reicht nicht. Die notwendige Frage lautet: ‚Haben wir geprüft, was diese Attestierung tatsächlich belegt – und ist diese Prüfung dokumentiert?‘
Im Kontext der NIS-2-Umsetzung weist das BSI darauf hin 📎, dass Leitungsorgane bei Pflichtverstößen in Haftung genommen werden können. Die entscheidende Frage im Haftungsfall ist dann nicht: Gab es ein Zertifikat? Sondern: Hat das Leitungsorgan geprüft, was dieses Zertifikat tatsächlich belegt?
Für KRITIS-Betreiber kommt §8a BSIG 📎 hinzu: Der Zweijahresnachweis gegenüber dem BSI belegt die Umsetzung geeigneter Maßnahmen – nicht deren operative Wirksamkeit im laufenden Betrieb. Ein formal korrekt ausgefüllter Nachweis, der auf substanzlosen Vendor-Attestierungen beruht, erfüllt möglicherweise die Formvoraussetzung, aber nicht die zugrundeliegende Schutzpflicht. Die Haftung bleibt beim Betreiber.
ISO 27001 Clause 5.3 verlangt die klare Zuweisung und Kommunikation von Verantwortlichkeiten und Befugnissen für informationssicherheitsrelevante Rollen innerhalb der Organisation. Compliance-as-a-Service entbindet eine Organisation nicht von dieser Anforderung. Sie verlagert die Frage: Wer in der Organisation prüft, ob der Service ausreichend ist?
Das Muster ist konsistent: Kein Regelwerk delegiert die Verantwortung vollständig nach außen. Sie alle verlagern Prozesse. Die Verantwortung bleibt.
Das Modell: Wie Decision-Grade Compliance strukturell gebaut wird
Was folgt, ist kein weiterer Normenkatalog. Es ist ein Architekturprinzip – anwendbar unabhängig davon, welche Frameworks eine Organisation nutzt.
Evidenzproduktion und Evidenzbewertung gehören in unterschiedliche Hände. Wer einen Compliance-Prozess betreibt, darf nicht gleichzeitig derjenige sein, der die daraus entstehenden Nachweise als entscheidungsrelevant klassifiziert. In vielen Organisationen fehlt diese Trennung bei Vendor-Assessments vollständig – nicht aus Absicht, sondern weil sie nie explizit modelliert wurde.
Attestierungen brauchen eine explizite Verfallslogik. Nicht jedes Dokument hat dasselbe Haltbarkeitsdatum. Vendor-Nachweise müssen in einem aktiven Risikoregister mit Verfallsdaten und Erneuerungszyklen geführt werden – als strukturelles Merkmal, nicht als administrativer Randpunkt.
Scope-Grenzen müssen bei jeder Entscheidung aktiv abgeglichen werden. Der Geltungsbereich einer Attestierung muss mit dem tatsächlichen Risikokontext der Entscheidung verglichen werden, und dieser Abgleich muss dokumentiert sein. Was nicht dokumentiert ist, existiert im Haftungsfall nicht.
Was das für Investoren bedeutet
Investoren, die Unternehmen im europäischen Markt prüfen oder finanzieren, sehen in der Due Diligence zunehmend ein vollständiges Compliance-Portfolio: SOC 2, ISO 27001, DSGVO-Dokumentation. Das erzeugt einen Eindruck von Robustheit. Die entscheidende Folgefrage wird selten gestellt: Auf welcher Evidenzbasis wurden diese Dokumente produziert? Wer hat sie mit welcher Methode und welcher Unabhängigkeit erstellt?
Im Ernstfall ist nicht das Vorhandensein eines Zertifikats entscheidend, sondern die Nachvollziehbarkeit der zugrundeliegenden Evidenz.
Das ist keine akademische Frage. Der Cyber Resilience Act 📎 – die EU-Verordnung, die Cybersicherheitsanforderungen für Produkte mit digitalen Elementen verbindlich macht – baut Haftungsszenarien aus, die im europäischen Markt in dieser Form neu sind. In diesem Umfeld entscheidet die Qualität der Compliance-Evidenz darüber, ob ein Portfolio im Ernstfall trägt oder nicht. Für Investoren in europäisch regulierte Märkte ist das kein Randthema mehr. Es ist ein Bewertungskriterium.
Wer als vCISO 📎 – ein auf Zeit eingesetzter externer Sicherheitsverantwortlicher – oder als technischer Due-Diligence-Berater an einem Deal beteiligt ist, sollte die Frage nach Herkunft, Aktualität, Scope und Unabhängigkeit der Compliance-Evidenz als Standardbestandteil jedes Assessments behandeln.
Das Compliance-System übersieht seine eigene Funktionslosigkeit – und läuft dabei weiter. Zertifikat für Zertifikat.
Das ist keine Kritik an einzelnen Unternehmen, einzelnen Tools oder einzelnen Auditoren. Es ist eine Beschreibung eines Systemdesigns, das Vertrauen durch Delegation erzeugt – und das an genau diesem Punkt angreifbar ist. Der Angreifer muss das System nicht kompromittieren. Es reicht, es zu überzeugen.
Decision-Grade Compliance ist die strukturelle Konsequenz: Nachweis und Entscheidung explizit trennen, Unabhängigkeit der Evidenz institutionalisieren, Scope-Grenzen bei jeder Entscheidung abgleichen, Verfallslogik einbauen. Das ist keine höhere Anforderung als das, was Art. 28 DSGVO, NIS-2 Art. 20 und ISO 27001 Clause 5.3 bereits verlangen. Es ist ihre konsequente Umsetzung – und die ist in der Praxis noch die Ausnahme.
Genau daran entscheidet sich, ob Compliance ein Dokument ist – oder eine tragfähige Entscheidung.
Compliance ist kein Zustand. Sie ist ein Prozess mit einer Verfallsstruktur, einer Scope-Grenze und einer Unabhängigkeitsanforderung. Wer das nicht in seiner Governance-Architektur abbildet, hat keine Compliance.
Er hat eine Erwartung.
Eine persönliche Anmerkung: Ich begleite israelische Technologieunternehmen beim Markteintritt in Deutschland und Europa – regelmäßig in Momenten, in denen ein vollständiges Compliance-Portfolio vorhanden ist und die zugrundeliegende Substanz trotzdem nicht trägt. Der Unterschied liegt fast nie in der Absicht. Er liegt in der fehlenden strukturellen Trennung zwischen dem, was erzeugt wurde, und dem, was damit belegt werden kann. Das ist lösbar. Aber es muss explizit gelöst werden.
Externe Referenzen verweisen auf öffentlich zugängliche Quellen (EDPB, ISO, BSI, IAASB, CSA, Gartner, EU-Kommission, IAF). Sie ersetzen keine juristische Beratung im Einzelfall. Die Vorwürfe gegen Delve sind nicht abschließend rechtlich oder regulatorisch festgestellt.
Sie sind Geschäftsführer, CISO oder Investor und fragen sich, ob Ihre Compliance-Evidenz einer Prüfung durch eine Aufsichtsbehörde oder im Rahmen einer Due Diligence standhält? Schreiben Sie mir direkt. 📎
Dieser Artikel ist Teil der laufenden Analyse zu Compliance-Architektur und israelischen Cybersicherheitstechnologien für den europäischen Markt. Verwandte Beiträge: Wenn das Sicherheitstool die Waffe wird 📎 · SOC Detection Observability 📎 · „Nachweislich nicht“ – Was ein einziger Satz über KI in regulierten Umgebungen verrät 📎
Anmelden zu unserem Newsletter:
Schreibe einen Kommentar