ILC Dover Zeigt: Cyber-Compliance-Erklärungen Müssen Belegt Werden

Ein Compliance-Anspruch im Bereich Cybersicherheit ist nur so belastbar wie die Nachweise, die Sie im Streitfall vorlegen können – und die Regierung hat gerade einen Preis von 13 Millionen US-Dollar auf diesen Unterschied gesetzt. Das US-Justizministerium gab bekannt, dass ILC Dover und ILC Astrospace am 3. November 2026 zugestimmt haben, diesen Betrag zu zahlen, um Vorwürfe beizulegen, sie hätten der Army, der Missile Defense Agency und der NASA Leistungen in Rechnung gestellt, obwohl sie wussten, dass sie die in den Verträgen festgelegten Cybersicherheitsanforderungen nicht erfüllt hatten. Die Einigung bezieht sich ausschließlich auf die Vorwürfe, und die Pressemitteilung des Justizministeriums stellt klar, dass keine Haftungsfeststellung erfolgt ist.

Wer die Liste der Vorwürfe liest, erkennt ein Muster, das wenig mit ausgefeilten Angriffstechniken zu tun hat. Die Regierung wirft den Unternehmen vor, kontrollierte, nicht klassifizierte Informationen bei einem Cloud-Anbieter gespeichert zu haben, ohne zu prüfen, ob dieser die erforderlichen Sicherheitsstandards erfüllt. Über Jahre hinweg fehlte ein aktueller System-Sicherheitsplan, Kontrollen wurden nicht umgesetzt und es lag keine aktuelle Bewertung beim Verteidigungsministerium vor. Jeder dieser Punkte ist ein Versäumnis in der Dokumentation, Verifizierung oder Nachweisführung – keiner setzt einen tatsächlichen Sicherheitsvorfall voraus.

Genau das sollten CISOs oder Chief Compliance Officers in die nächste Attestationsrunde mitnehmen. Der False Claims Act fragt nicht, ob Ihre Richtlinien plausibel klingen, sondern ob die von Ihnen gegenüber der Regierung gemachten Angaben zum Zeitpunkt der Abgabe wahr waren – und ob Sie das belegen können. Dieser Beitrag erläutert die Vorwürfe aus dem Vergleich, warum das aktuelle regulatorische Umfeld die Nachweisfrage verschärft und wie eine belastbare Position für CMMC 2.0 Compliance und darüber hinaus aussieht.

Wichtige Erkenntnisse

1. Die Vorwürfe drehen sich um Nachweise.

Fehlende Sicherheitspläne, veraltete Bewertungen und nicht verifizierte Cloud-Speicher sind Dokumentations- und Verifizierungslücken, die kein Sicherheitsvorfall aufdecken musste.

2. Selbstattestation verlagert die Beweislast auf Sie.

Wenn kein externer Prüfer mehr kontrolliert, wird die eigene Erklärung des Auftragnehmers zum Dokument, auf das sich die Regierung verlässt.

3. Vertrauen und Nachweis sind nicht dasselbe.

Rüstungsunternehmen berichten von großem Vertrauen in ihre Bewertungen, aber nur ein kleiner Teil kann dieses Vertrauen mit aktuellen Unterlagen belegen.

4. Drittanbieter-Cloud ist ein benannter Risikofaktor.

Die Speicherung sensibler Regierungsdaten bei einem nicht verifizierten Anbieter ist einer der fünf Vorwürfe in diesem Vergleich.

5. Audit-Trails sind die schnellste Lösung.

Ein vollständiger, manipulationssicherer Nachweis darüber, wer wann auf welche regulierte Datei zugegriffen hat, macht aus einer Behauptung einen belastbaren Nachweis, den Sie auf Anfrage vorlegen können.

Was das Justizministerium tatsächlich vorgeworfen hat

Der Vergleich betrifft Zahlungsansprüche zwischen Januar 2018 und Oktober 2024. Die Darstellung des Justizministeriums listet fünf Vorwürfe auf, jeweils mit eigenem Zeitraum – und diese Zeiträume zeigen, wie lange die Lücken bestanden.

Der erste betrifft Cloud-Speicher: Von Februar 2023 bis Oktober 2024 soll ILC kontrollierte, nicht klassifizierte Informationen bei einem Drittanbieter in der Cloud gespeichert haben, ohne sicherzustellen, dass dieser die Sicherheitsanforderungen entsprechend dem FedRAMP-Moderate-Baseline erfüllte und die Vorgaben des Verteidigungsministeriums zu Cybervorfall-Meldung, Schadsoftware, Datenträgeraufbewahrung und forensischem Zugriff einhielt. Der zweite Vorwurf betrifft die Planung: Über weite Teile von Januar 2018 bis Oktober 2024 soll ILC keinen System-Sicherheitsplan für jedes relevante Informationssystem entwickelt, dokumentiert und regelmäßig aktualisiert haben.

Der dritte Vorwurf ist der umfassendste: Von Januar 2018 bis Oktober 2024 soll ILC die Kontrollen aus NIST Special Publications 800-171 und 800-53 nicht vollständig umgesetzt haben – einschließlich solcher, deren Fehlen eine erhebliche Ausnutzung des Netzwerks oder die Exfiltration kontrollierter Verteidigungsinformationen ermöglichen könnte. Der vierte betrifft Maßnahmen- und Meilensteinpläne, die laut Regierung zeitweise fehlten. Der fünfte ist eine Berichtslücke: Von November 2020 bis Oktober 2024 soll ILC Astrospace keine aktuelle NIST SP 800-171-Bewertung beim Verteidigungsministerium eingereicht haben, und ILC Dover soll keine aktuelle und nach der Methodik des Ministeriums durchgeführte Bewertung eingereicht haben.

Zusammengenommen wird die Rolle des Whistleblowers deutlich: Philip Root, ehemaliger Director of Cybersecurity bei ILC, reichte die Klage nach den qui tam-Bestimmungen des False Claims Act ein und erhält 2,35 Millionen US-Dollar aus dem Vergleich. Jemand im Unternehmen konnte die Diskrepanz zwischen Darstellung und Realität erkennen – und das Gesetz gibt dieser Person einen finanziellen Anreiz, dies offenzulegen.

US-Staatsanwalt Benjamin Wallace aus dem District of Delaware brachte die Logik der Durchsetzung auf den Punkt: Die beste Reaktion auf Cyberangriffe ist, sie von vornherein zu verhindern, und die angeblich verletzten Pflichten von ILC dienen dazu, den Missbrauch amerikanischer technischer Innovationen zu verhindern. Für Compliance-Verantwortliche ist die nützlichere Lesart enger: Die Pflichten sind vertraglich, sie sind konkret – und die Regierung wertet eine bewusste Lücke zwischen diesen Pflichten und Ihren Rechnungen als Betrug.

Warum Selbstattestation das Risiko erhöht

Der Zeitpunkt dieses Vergleichs ist bedeutsam, weil er nach der Aussetzung des Pentagon-Übergangs zu verpflichtenden Drittanbieter-CMMC-Bewertungen liegt. Die Zusammenfassung von CBIZ zur Ankündigung vom 13. Juli 2026 beschreibt die Aussetzung des Übergangs der Phase 2 sowie aller anstehenden und zukünftigen CMMC-Meilensteine. Manche Leser interpretierten das als Pause bei der Pflicht zum Schutz von Informationen. Das ist nicht der Fall. Die Aussetzung hat lediglich geändert, wer die Angaben des Auftragnehmers prüft – nicht, was der Auftragnehmer nachweisen können muss.

Dieser Unterschied geht im Budgetmeeting leicht unter, daher sollte er klar formuliert werden: Die Selbstbewertung senkt die Einstiegshürde für einen Vertrag, aber nicht das Risiko, sobald Sie im Vertrag sind. Ein Score im Supplier Performance Risk System ist eine Aussage, auf die sich die Regierung verlässt – und eine ungenaue Aussage birgt False Claims Act-Risiken, egal ob ein Prüfer sie je sieht. Die ILC-Vorwürfe, die bis 2018 zurückreichen, zeigen, dass diese Pflichten schon lange vor dem aktuellen CMMC-Zeitplan durchsetzbar waren. Wer die Phase-2-Pause als Freibrief von der NIST 800-171 Compliance versteht, verkennt die Lage.

Die Daten zur Stimmung der Auftragnehmer sind ernüchternd. Der Kiteworks 2026 State of CMMC 2.0 Preparedness in the DIB Report befragte im Juli 2026 insgesamt 273 Organisationen mit aktiver CMMC-Pflicht. 96 Prozent waren überzeugt, dass ihr selbst attestierter Score einer Prüfung standhält – aber nur 29 Prozent davon konnten sowohl eine aktuelle SPRS-Einreichung als auch eine FedRAMP-zertifizierte Plattform vorweisen. Diese Zahlen stammen aus einer einzigen Umfrage und beschreiben daher ein Muster, keine Vollerhebung.

Dieses Muster zeigt sich auch aus anderer Perspektive: Die CyberSheath-Studie „2026 State of the DIB„, durchgeführt von Merrill Research unter 302 US-Rüstungsunternehmen im Mai 2026, ergab, dass die durchschnittlichen selbst gemeldeten Scores zwar stiegen, das Vertrauen in deren Korrektheit jedoch von 89 Prozent im Vorjahr auf 65 Prozent sank. Zwei unabhängige Studien, zwei unterschiedliche Stichproben, aber das gleiche Bild: Auftragnehmer dokumentieren Compliance besser, sind aber weniger sicher, dass diese Dokumentation einer Prüfung standhält.

Das ist kein Pessimismus, sondern ein realistisches Gespür dafür, dass ein Score eine Behauptung ist – und ein Nachweis ein Beleg. Nur Letzteres zählt für einen Regierungsjuristen.

Drittanbieter-Cloud: Wo der Nachweis oft fehlt

Der erste Vorwurf verdient eine eigene Betrachtung, weil er die Realität vieler Unternehmen beschreibt. ILC soll sensible Regierungsdaten bei einem externen Anbieter gespeichert haben, ohne zu prüfen, ob dieser die geforderte Baseline erfüllt. Fast jeder Auftragnehmer nutzt externe Anbieter. Die entscheidende Frage ist: Haben Sie die Nachweise, dass Sie die Prüfung durchgeführt haben?

Auch das regulatorische Umfeld verändert sich: Am 2. November 2026 veröffentlichte FedRAMP eine Mitteilung, dass am 29. Oktober 2026 erstmals eine vollständige FedRAMP 20x Class C-Zertifizierung vergeben wurde und zuvor 26 Unternehmen Pilotzertifizierungen erhalten hatten. Für Beschaffungsteams ist das relevant, weil sich die Labels auf Anbieterunterlagen ändern, während die vertragliche Frage gleich bleibt.

Seien Sie bei der Übersetzung alter und neuer Begriffe vorsichtig. Secureframe weist darauf hin, dass Class C die Marktposition der bisherigen Moderate-Stufe übernimmt, aber nicht deren Anforderungen – und dass Behörden mit eigenen Kontrollanforderungen möglicherweise Nachweise verlangen, die ein Class C-Paket nicht enthält. Die praktische Konsequenz: Lesen Sie die Vertragsklausel, identifizieren Sie die tatsächlich geforderte Baseline und dokumentieren Sie mit Datum, wie Sie geprüft haben, dass jeder Anbieter diese erfüllt. Dieser Nachweis macht aus der Behauptung des Anbieters Ihren eigenen Beleg – und gehört in Ihre Third-Party-Risk-Management-Akte, nicht in einen E-Mail-Verlauf.

Einige Gewohnheiten machen das belastbar: Führen Sie ein Inventar aller Anbieter, die kontrollierte, nicht klassifizierte Informationen verarbeiten. Speichern Sie die aktuellen Autorisierungs- oder Bewertungsdokumente des Anbieters zusammen mit dem Datum der Prüfung. Dokumentieren Sie, wer im Unternehmen ein Restrisiko akzeptiert hat. Ändert sich der Status eines Anbieters, sollte dies eine dokumentierte Überprüfung auslösen – nicht erst beim jährlichen Review.

Im Gesundheitswesen sind die Folgen ähnlich – aber anders verteilt

Compliance-Risiken betreffen nicht nur die Verteidigung. In derselben Woche gab es eine Erinnerung aus dem Gesundheitswesen: Gerichtsunterlagen, zusammengefasst von ClassAction.org, zeigen, dass Covenant Health und verbundene Unternehmen einem Vergleich über 2 Millionen US-Dollar nach einem Cybervorfall im Mai 2025 zugestimmt haben, bei dem die geschützten Gesundheitsdaten von etwa 502.606 Personen offengelegt wurden. Die Beklagten bestreiten ein Fehlverhalten, eine abschließende Anhörung ist für Anfang 2027 geplant.

Die Summe wirkt im Vergleich zu neunstelligen Datenschutzpannen gering, doch sie schließt die eigenen Kosten für Reaktion, Rechtsberatung und Benachrichtigung nicht ein. Mitglieder der Sammelklage können bis zu 5.000 US-Dollar an dokumentierten Schäden geltend machen und erhalten zwei Jahre Kreditüberwachung – die Verpflichtung endet also nicht mit dem Scheck. Die Klage der Kläger stützte sich auf Fahrlässigkeit, das heißt, die juristische Frage war, ob angemessene Schutzmaßnahmen vorhanden waren und ob das Unternehmen dies nachweisen konnte.

Es ist die gleiche Nachweisfrage in einem anderen regulatorischen Gewand. Nach HIPAA erwartet die Security Rule bereits Zugriffskontrollen und Audit-Trails. Ein Unternehmen, das nicht rekonstruieren kann, wer auf geschützte Informationen zugegriffen hat, argumentiert nur mit Behauptungen. Die geplante Überarbeitung dieser Regel ist noch nicht final – die Anforderungen gelten also schon heute.

Wie Compliance mit Nachweisqualität in der Praxis aussieht

Es ist hilfreich, konkret zu klären, was „Nachweis“ bedeutet, denn der Begriff wird oft unscharf verwendet. Ein Nachweis mit Beweisqualität hat vier Eigenschaften: Er ist datiert, sodass der Leser erkennt, wann die Kontrolle geprüft wurde. Er ist zuordenbar, also einer Person oder einem System zuweisbar. Er ist vollständig, deckt also alle Systeme und Dateien im Scope ab und nicht nur eine Stichprobe. Und er ist vor Manipulation geschützt, sodass niemand nachträglich unbemerkt die Darstellung verbessert.

Wendet man diesen Test auf die fünf ILC-Vorwürfe an, ergibt sich für jeden eine fehlende Unterlage: Eine Anbieterprüfungsakte würde den Cloud-Vorwurf abdecken. Ein aktueller, versionierter System-Sicherheitsplan würde den Planungs-Vorwurf beantworten. Ein Kontroll-Implementierungsnachweis mit Verantwortlichen und Prüfdaten würde den NIST SP 800-171-Vorwurf abdecken. Ein aktuelles Register offener Punkte mit Zielterminen würde den Maßnahmenplan-Vorwurf erfüllen. Eine eingereichte Bewertung mit Score und Methode würde den Berichts-Vorwurf abdecken. Nichts davon ist exotisch – aber genau diese Dokumente geraten im Tagesgeschäft leicht ins Hintertreffen.

Die nützliche Gewohnheit: Jede externe Aussage zur Sicherheit als zu lieferndes Ergebnis mit Verantwortlichem behandeln. Wenn der Vertrieb zusichert, dass Kundendaten nach einem bestimmten Standard geschützt sind, wenn die Finanzabteilung eine Versicherung beantragt, wenn ein Executive einen Score zertifiziert – jede Aussage sollte auf eine aktuelle Unterlage verweisen. Teams, die so arbeiten, entdecken Lücken im normalen Review, wenn das Schließen noch günstig ist – und nicht erst im Rechtsstreit, wenn es teuer wird. Das gibt CISO und Chief Compliance Officer auch eine gemeinsame Sprache: Der CISO verantwortet die Wirksamkeit der Kontrolle, der CCO die Richtigkeit der Aussage – und der Nachweis ist der Schnittpunkt beider.

Es gibt auch eine kulturelle Dimension: Diejenigen, die nah an der Umsetzung sind, wissen meist, wo Papierlage und Praxis auseinandergehen – und sie sagen es, wenn das Unternehmen das zulässt. Der ILC-Fall zeigt, was passiert, wenn das nicht der Fall ist. Bauen Sie den internen Eskalationsweg zuerst auf und werten Sie frühe Hinweise auf Lücken als Zeichen eines funktionierenden Programms.

Was CISO und CCO vor der nächsten Attestation tun sollten

Die folgenden Schritte gehen davon aus, dass Sie eine Erklärung unterzeichnen, auf die sich Regierung oder Kunde verlassen. Sie sind nach der Geschwindigkeit geordnet, mit der sie das Risiko senken.

Beginnen Sie mit einem Abgleich aller Aussagen zur Sicherheitslage mit den zugrunde liegenden Nachweisen. Vergleichen Sie gemeldeten Score oder Status mit dem aktuellen System-Sicherheitsplan, offenen Maßnahmenplänen und dem letzten Bewertungsdatum. Jede Abweichung ist ein Befund, den Sie selbst entdecken sollten, bevor es ein Externer tut. Eine strukturierte CMMC-Gap-Analyse ist dafür sinnvoll.

Bestimmen Sie anschließend eine namentlich verantwortliche Person, die echten Zugriff auf die Nachweise erhält. Eine Unterschrift von jemandem ohne Einblick in die Logs ist ein Risiko für beide Seiten. Testen Sie dann, ob Sie innerhalb eines Tages einen vollständigen Nachweis über Zugriffe auf sensible Inhalte liefern können – denn ein Prüfer oder Regulator wartet nicht auf Ihre Nachbereitung. Der Audit-Trail sollte zeigen, wer wann auf welche regulierte Datei unter welcher Richtlinie zugegriffen hat – und vor Manipulation geschützt sein.

Üben Sie schließlich das Whistleblower-Szenario: Wer im Unternehmen weiß, wo Dokumentation und Realität auseinanderklaffen? Geben Sie dieser Person einen sicheren internen Kanal, bevor das Gesetz einen anderen Anreiz schafft. Der ILC-Fall begann mit einem Cybersecurity-Direktor, der die Lücke sah. Die meisten Unternehmen haben jemanden wie ihn – entscheidend ist, ob das erste Gespräch intern stattfindet.

Ein einwöchiger Test Ihrer eigenen Nachweise

Eine praktische Methode, um zu prüfen, ob Ihre Compliance-Story einer Prüfung standhält, ist ein kleines internes Experiment: Wählen Sie einen Vertrag mit Sicherheitsanforderung und verfolgen Sie ihn von Anfang bis Ende. Beginnen Sie mit dem Satz, mit dem Sie Ihre Sicherheitslage beschrieben haben – egal ob im Angebot, in der jährlichen Bestätigung oder im Kundenfragebogen. Suchen Sie dann für jede Aussage den passenden Nachweis. Wenn Sie behaupten, eine Baseline sei erfüllt, finden Sie den Plan, das Bewertungsdatum und das letzte Review. Wenn Sie sagen, ein Anbieter sei autorisiert, finden Sie die Autorisierungsunterlagen und das Datum der letzten Prüfung.

Die meisten Teams finden mindestens eine Aussage, deren Nachweis veraltet, verstreut oder nur einer Person bekannt ist. Das ist ein nützliches Ergebnis und kein Scheitern – denn es zeigt, wo das Risiko liegt, solange die Behebung noch günstig ist. Dokumentieren Sie die Lücken, weisen Sie Verantwortliche und Termine zu und führen Sie eine Liste. Ein datierter Nachweis der Nachbesserung ist selbst ein Beleg. Die Darstellung der ILC-Vorwürfe durch die Regierung nennt Zeiträume ohne Maßnahmenpläne – die Gewohnheit, diese zu führen und zu aktualisieren, ist also direkt relevant.

Wie Kiteworks Compliance mit Nachweisqualität unterstützt

Gerade bei der Übertragung sensibler Inhalte – etwa per E-Mail, Filesharing, Managed File Transfer oder Web-Formularen – sind Nachweise oft über verschiedene Tools verstreut. Kiteworks Secure Data Exchange vereint diese Kanäle unter einer Richtlinie und einem Audit-Trail, sodass der Nachweis, wer eine regulierte Datei gesendet, geteilt oder empfangen hat, zentral vorliegt. Das erleichtert es Compliance-Teams, Nachweisanfragen aus einer Quelle und nicht aus fünf zu beantworten.

Die Plattform unterstützt die oben beschriebenen Aufgaben, ersetzt sie aber nicht. Sie kann Nachweise liefern und Richtlinien durchsetzen – aber System-Sicherheitsplan, Risikoakzeptanz und Attestation bleiben in der Verantwortung Ihres Unternehmens. Kiteworks bietet Secure Email und Secure Managed File Transfer mit Audit-Events, die per Syslog an ein SIEM weitergeleitet werden können. Ob eine Kontrolle eine Anforderung erfüllt, entscheiden jedoch die Prüfer, nicht der Anbieter.

Erfahren Sie mehr darüber, wie Sie prüfbereite Nachweise für Ihre Cybersecurity-Attestations aufbauen können – vereinbaren Sie jetzt eine individuelle Demo.

Weitere Ressourcen

• Blog Post Tauziehen um Ihre Daten: Wie CLOUD- und SHIELD-Acts Sicherheit gegen Datenschutz ausspielen
• Blog Post Sensible Daten schützen, indem Sie DSPM auf Ihre Compliance-Ziele abbilden
• Brief Die 3 häufigsten FERPA-Verstöße und wie Sie sie vermeiden
• Blog Post Executive Order 14117: Schutz sensibler persönlicher Massendaten von US-Bürgern
• Blog Post NIS2-Compliance erforderlich? Starten Sie mit ISO 27001